Работа тимлидом в 2018-ом году
Чтобы всем было полезнее и проще читать, статья разбита на главы, каждая из которых рассказывает об одной отдельной проблеме и её решению. В статье я расскажу о моём опыте работы на должности тимлида в компании по разработке сайтов. Хотя по возможности будет сохранена хронология событий.
Надеюсь, что описанный ниже опыт станет для кого-то чужими граблями, а в комментариях я и сам почерпну что-то от более опытных коллег.
Договор о неразглашении, все дела. Но никаких названий, компаний, клиентов, имён коллег.
Предыстория. Как и где я вообще стал тимлидом
Для меня это был качественный скачок в плане карьерного роста. Это первая фирма, куда я пришёл сразу тимлидом. Но градации разработчиков слишком субъективны и часто зависят лишь от компании, где они работают. На прошлую работу (1,5 года) я пришёл миддлом и вырос там до сеньора. Когда я начал искать работу, мне бы хватило и позиции сеньора (и её я искал), но предложение тимлидства меня перекупило и немного польстило. Какое-то время я много изучал вопрос оценки программистов и по сути всё свелось к тому, что если “взяли миддлом/сеньором/старшим — стал миддлом/сеньором/старшим”.
Я же наоборот давно мечтал уйти от Битрикса, но возможность самореализоваться в новом качестве и хорошая зарплата не оставили мне шансов отказаться. Собственно при самом поиске вакансий уже на второй день меня сманили в столичную фирму, которая занимается разработкой сайтов на Битриксе (так что дальше всё происходит на фоне разработке сайтов на Битриксе).
Забавный факт: единственным условием при приёме меня на работе было то, что я могу сам выбирать технологических стек, но нельзя ни в коем случае не отказываться от Битрикса, если на нём настаивает клиент.
На новом месте
Довольно странная ситуация и я до сих пор не понимаю, как она сложилась и не схлопнулась сразу. На новом месте оказался очень хороший начальник-технарь, плохой менеджер, джун, миддл и несколько действительно больших проектов на Битриксе. Но возможно меня и пригласили как раз для того, чтобы всё наладить.
В первые же дни в глаза бросилось множество “детских” проблем:
- информация по проектам хранилась в головах у одного-двух человек и нигде более. Инструкций и документации тоже никаких не было, и чтобы узнать как работает тот или иной функционал, нужно было пытать того, кто его делал, если вообще мы его создавали
- каких-либо налаженных систем и процессов считай не было, всё делалось “как-то”, “по привычке”. Отсюда соответственно суета, неразбериха, срывы сроков, напряжение
- задачи ставились считай на словах. В трекерах были лишь названия задач, просто чтобы можно было залогировать время куда-то (нужно было набирать 40 часов в неделю)
- сама разработка тоже была не ахти:
- где-то что-то разрабатывалось даже вне гита
- где-то программисты по очереди правили файлы на одном сервере
- где-то были тестовые площадки, а где-то их не было (но в любом случае они не сильно помогали)
- вдобавок везде было очень, очень много говнокода. Предвосхищая комментарии, сам Битрикс тут, к сожалению, не причём
- Всё общение происходило в скайпе. Но к нему у меня просто личная неприязнь
Это меня даже в какой-то степени обрадовало, так как можно с первых же месяцев влиять на показатели. В общем, всё очевидно плохо, улучшения можно начинать сходу, не проводя предварительных исследований. Они правда ещё не считались, но из-за Парето, это пока и не важно.
Во-первых, мне самому приходилось по 8 часов в день работать над клиентскими задачами, как программисту, так как рук просто не хватало. К моему разочарованию процессы первые месяцы двигались довольно медленно. Во-вторых, в условиях такого цейтнота, довольно опасно было делать большие изменения, которые могли бы привести к путанице и к потере кода или времени.
Первым делом в новой компании нужно было как-то сориентироваться. Теперь переходим непосредственно к статье и решению проблем.
Вытаскивание информации из голов сотрудников
Поэтому первым делом, я начал вытаскивать информацию из голов коллег в тексты. Когда я пришёл, я совсем ничего не знал ни о проектах, ни о клиентах, и эта информация не хранилась
нигде в текстовом виде.
По сути в фирме, занимающееся разработкой, есть 2 больших подмножества важных и/или полезных текстов:
- инструкции, регламенты, статьи, описания функционала, пользовательские истории,...
- Задачи с их названием, описанием, комментариями, логами времени, подписи к коммитам, комментарии в коде, автотесты,...
Но поскольку у меня поначалу был ещё совсем незамыленный взгляд и мне приходилось изучать проекты, видя их впервые, я просто начал транслировать свои исследования в текст, создавая тем самым инструкции и описания функционала. По началу я просто просил новых коллег расписать для меня какие-то конкретные вещи из первого пункта, но все конечно ленились, тем более, что инструкцию писать это не фичи пилить.
И у меня почему-то изначально был большой авторитет в глазах коллег. Так же повезло, что в то же время фирма начала активно переезжать на scrum (просто совпадение), менялось рабочее ПО (тоже совпадение), соответственно с нуля создавались бизнес-процессы. Поэтому я просто начал писать регламенты самостоятельно (в рамках компетенции) и перестраивать на них ребят, то есть по сути просто диктовать правила и быть примером их исполнения.
Это оказалось бутылочным горлышком и в последующих главах я ещё не раз подниму эту тему. Решение же проблемы с постановкой и ведением задач затянулось не на один месяц.
Пример: название задачи — “Исправить баг на сайте” и всё: ни какого-либо описания, ни скринов, только название и отсылка к проекту. На момент начала моей работы менеджер ставила задачи ужасно. Были конечно попытки донести принципы SMART и важность описания задач до менеджера, но все начинания разбивались об “У меня нет времени расписывать задачи”.
Одно время я пытался перенять часть ответственности за постановку задач, но тут иронично, что у меня на это тоже не хватало времени, так как практически всё время я писал код.
А вот смежную проблему получения актуального статуса задач в произвольный момент времени мы решили в обход, через координационные созвоны и планы на день.
Пополнение штата, интеграция в команду
Практически изначально было понятно, что людей катастрофически не хватает (я сам полный рабочий день писал код, но мы всё равно не успевали).
Первым решили взять фронта, так как оба прогера в фирме были беками (и я себя тоже отождествлял больше с бекендом), а задач, особенно по вёрстке, хватало, и на горизонте ещё начали маячить задачи по реакту и vue.
Тут очень повезло, что у меня был (и есть) друг фронт, который в то же самое время начал подумывать уйти с фриланса, поэтому мы смогли быстро заткнули вакансию, а я получил премию за приведение сотрудника (ещё один плюс начальству, до этого не видел hr-премии).
И где-то в это же время ушёл джун (чей код меня выбешивал ещё несколько месяцев после его ухода). Почти сразу же после фронта нашлись 2 бека.
Итого в разработке сложилась следующая ситуация:
- один “старичок”
- я
- трое абсолютных новичков
- работа ещё не налажена
- часть знаний уже потеряна
В основном это были вопросы по жизненному циклу кода (где писать код, как показывать, куда его отправлять потом, как собирать релиз), по ведению задач (как брать задачи в работу, как показывать статус, как определять приоритеты) и по работе с гитом. Закономерно, что на меня, как на тимлида, сразу посыпались десятки вопросов от новичков. Плюс ребята ещё пытались задавать вопросы “Как работает А?”, “Есть ли у нас на сайте В?”, но практически всё в тот момент сводилось лишь к необходимости изучать код.
Я проводил с ними ознакомительные беседы, отвечая на их вопросы, потом конечно же решил свести все вопросы и схемы в статью, которая затем переросла в лекцию, а потом и вообще в совершенно новую схему работы в фирме, о которой я расскажу в следующей главе. Первым делом важно было дать прогерам возможность в принципе работать и писать код самостоятельно.
Здесь же стоит сказать пару слов о процессе найма в нашу фирму, которая работает до сих пор.
Процесс найма
Во-первых, у нас есть бонус за привлечение сотрудника, что довольно хорошая практика.
Это удобно тем, что временные затраты на найм снижаются лишь до поиска подходящих резюме и лёгкого интервью с соискателями для проверки на адекватность и рассказа про тестовое задание, и, конечно, непосредственно проверки задания. Во-вторых, мы решили не устраивать экзамен на собеседовании, а давать очень объёмную задачу, приближенную к нашим повседневным.
Именно эта гибкость реализации помогает нам оценить уровень соискателя. Задачу на самом деле может решить и джун за пару вечеров, объёмной её делает большая свобода в реализации, улучшениях и напрашивающихся фишках. Мы не оговариваем использование каких-либо подходов и технологий, их выбирает сам исполнитель, но чтобы пойти на встречу и дать подсказки, мы перечислили возможные улучшения списком, как задания со звёздочкой, например, работа через аякс, доп. Мы сразу говорим, что самое главное для нас это лишь уложиться в сроки решения задачи (называет сам исполнитель) и в конце показать рабочий код в репозитории. валидация на бэке, защита от спама, оформление в виде модуля, использование D7, ...
Итого:
- по резюме и интервью мы можем судить о характере человека
- по сроку исполнению задачи, факту работоспособности кода и использованию гита мы принимаем само решение о приёме на работу
- по качеству выполнения мы определяем уровень и соответственно зарплату, которые можем предложить
- плюс уже на тестовом задании мы показываем, какие задачи придётся решать на новом месте
Налаживание системы разработки и поставки кода
На тот момент у нас было несколько проектов, которые разрабатывались довольно хаотично:
- где-то на бою был мастер, где-то другая ветка
- где-то были тестовые площадки, где-то нет
- а если и были, то адреса у всех разные
- гит в принципе использовался слабо и со скрипом
- изменения в базы данных вносились вручную
- …
Например, вынул папку bitrix из под гита, переименовал основную ветку обратно в master. Сначала я маленькими порциями пытался исправлять ситуацию, чтобы программистам нужно было меньше переучиваться, и соответственно путаться.
Приходилось много объяснять, напоминать и писать нелогичные инструкции, так как текущая структура разработки была ну совсем не интуитивно-понятной. Но когда к нам пришло большое пополнение, ситуация стала критическая.
Я не любитель инструкций как таковых, считаю, что их наличие само по себе индикатор проблемы, поэтому было решено создать общую для всех проектов систему, которую нужно понять один раз и которая самой своей структурой убирает множество проблем и вопросов.
Система заключается в следующем:
- у каждого разработчика есть удалённая личная рабочая площадка, где он работает
- есть площадка, где накапливается функционал для следующего релиза
- при необходимости есть демонстрационная площадка для демонстрации всяких зачатков функционала
- весь код для одной задачи держится в одной отдельной ветке, где название ветки равно названию задачи в трекере
- чтобы залить код на общую площадку, ветку нужно просто смержить куда-надо и запушить
- изменения в базах данных хранятся в виде файлов миграций в ветке задачи
Я провёл большую лекцию на тему этой системы, и мы начали пилотный переход на неё на одном проекте, куда как раз кинули новоприобретённого сеньора.
Процесс перевода всех проектов на эту систему, конечно же, затянулся (например, на одном проекте мы мистическим образом не смогли переехать в мастер с первого раза), и он до сих пор продолжается, но по итогу мы получили как минимум:
- возможность релизить только нужные задачи, а не релизить вместе с полезным кодом недоработанный функционал
- делать релиз задачи без привлечения автора кода
- параллелить работу над проектом между исполнителями
- не терять код
- тестировать функционал изолировано от другого и не стопорить при этом работу прогера
Плюс не нужно теперь объяснять лишние тонкости работы с гитом или тестовыми площадками новым прогерам, так как всё универсально и интуитивно. Всего этого раньше просто не было.
Scrum, коммуникации, регламенты
Конечно, в статье я намеревался рассказать о том, как я помогал в развитии фирмы, будучи тимлидом, но нельзя говорить о развитии нашей компании, не упомянув нашего начальника и его инициативы, иначе это будет не совсем честно.
Также в этот момент перевёл её из Битрикс24 в Джиру. Во-первых, он внедрял scrum и на момент моего прихода процессы в компании начали очень активно переделываться.
За переобучением менеджеров, их исполнением координационных созвонов, открытием/закрытием/планированием спринтов следил сам начальник, как старший в этом звене. Скрам конечно же привносил больше ритма в компанию и уменьшал хаос.
Всё это вылилось во множество регламентов: по общению с клиентами, по постановке задач, по работе с беклогом, по принятию в работу багов. Также он много работал над самими менеджерами, в особенности над тем как они общаются с клиентами и программистами, так как большАя часть их работы (но, конечно, не ограничиваясь) в том и состоит — общаться: изолировать программистов от клиентов, транслировать пожелания клиентов в задачи в беклоге и в спринтах, находить и перерассказывать пользовательские истории. На коммуникации был сделан сильный упор и управляющее звено действительно показывало прогресс.
И я очень рад, что получил множество новых знаний по гибким методологиям и продуктам атлассиана. Сам переход на скрам, конечно же, очень тяжёл и на момент написания статьи, мы ещё не стали его профессионалами, хотя к этому всё идёт.
Новый менеджер. Тексты, постановка задач, беклог
В какой-то момент пришёл ещё один человек, который должен был помочь нам совершить качественный скачок — новый менеджер (до этого у нас был один).
Данное звено было слабым местом в компании, но мы пытались решить эту проблему развитием существующих кадров. Этот момент я не ожидал, так как проектов и программистов у нас было не так много и в теории должно было хватать всего одного менеджера. Ещё одна премия) Просто так совпало, что один отличный менеджер, которого я хорошо знаю, решила сменить работу, об этом узнал мой начальник, так как она внезапно собеседовалась к нашим подрядчикам и я обмолвился об этом забавном инциденте, и мы позвали её к себе.
В частности, первым делом вытащила список контактов клиентов и подрядчиков. По началу новый менеджер повторяла часть моего пути, так как столкнулась с теми же проблемами (ничего не знает и негде почитать) и начала всё по новой, но с тем отличием, что она не трогала код, инфраструктуру разработки и навыки прогеров, а работала с постановкой задач, общением с клиентами, чисткой беклога, а также усердно вытаскивала информацию из головы старого менеджера.
Плюс задачи стали ставится более подробно, негатива она не добавляла и не передавала его от клиента, статусы у задач стали более актуальными в любой момент времени. Команда уже была с ней знакома, так как мы как-то раз приглашали её лектором, чтобы рассказать нам про контроль времени. Поэтому мы сразу же возложили на неё большие надежды.
Кроме этого в принципе выплыло много задач, которые нужно было сделать месяц назад. Первые недели они с начальником наводили порядок в беклоге на одном проекте, в частности нашли просроченный на 2 месяца и ещё не начатый эпик. Хорошо конечно, что беклог был почищен, но это было сделано слишком поздно.
Задачи стали реже теряться в беклоге, программисты стали реже переспрашивать. Сама она правда “вешалась” от бардака и не раз порывалась уйти, но менеджерское звено мы так или иначе сильно улучшили.
Мораль истории будет в конце.
Кризис
К слову сказать, об отпуске я договорился ещё при устройстве на работу, так как это планировалось как свадебное путешествие, поэтому период моего отсутствия был известен сильно заранее. Спустя почти полгода после начала работы мне нужно было уйти в отпуск. Но я всё равно, конечно, нервничал до последнего, потому что мы только недавно перестали работать “на износ”.
Ничего не предвещало беды в середине июля. В неделю перед отпуском я закончил делегирование обязанностей, научил выбранных людей выполнять специфичные дела вне кода, закрепил за каждым программистом ответственность за конкретный проект, закончил или передал все свои текущие задачи (я тогда всё ещё программировал большую часть дня).
И в первые дни отпуска тоже ничего не предвещало беды.
А потом произошёл кризис.
Мы и сами это заметили не так давно при полной переработке беклога и активному общению с клиентом (глава про нового менеджера), но было слишком поздно. На одном проекте у клиента кончилось терпение из-за того, что его ожидания выполнения задач (сроки, список, приоритеты) не соответствовали делу.
Но новый функционал внезапно повалил боевой сайт под неподъёмной нагрузкой, и миддл с фронтом неделю ничего не могли с этим сделать. А на втором проекте наконец-то приняли очень большую и долгожданную задачу, закончили тестирование и зарелизи её. Естественно этот клиент тоже начал материться и подумывать отказаться от наших услуг.
Хотя я и не мог весомо помочь, так как был в другой стране без интернета и ноутбука. Первая проблема не относилась непосредственно к разработке, поэтому я активно участвовал в исправлении ситуации на втором проекте. Максимум моей помощи был в консультациях прогеров, особенно, когда уже купил интернет.
Ответственный за проект бэк перерабатывал целую неделю каждый день в попытках завести новый функционал в боевом окружении и вместе с фронтом разбирался в кодовой базе vue, где большую часть писали не они двое (я как раз, кстати).
Коллега попал в ужасную ситуацию — работал до часу ночи всю неделю, сильно стрессовал, но и на него же по итогу свесились все шишки, в особенности из-за того, что он всё это время повторял “починю к обеду / к концу дня / к ночи / к утру”.
Ситуацию по итогу смогли исправить, но всё это вылилось в то, что пока мы решали его дальнейшую судьбу, он сам написал заявление об увольнении, так как устал такого стресса.
Самым странным было то, что судя по общению с ребятами, всё это время, они действительно работали, и даже довольно быстро нашли проблемное место, но на решение понадобилось множество десятков часов и столько же потом на исправление появившихся поломок второстепенного функционала.
Явно вскрылся недостаток профессиональных навыков и мастерства оценки задач, поэтому для профилактики мы решили ввести добровольно-принудительное подтягивание программистов внутри фирмы. Мы много думали о том, почему сложилась такая ситуация и как их предотвращать в будущем. На необходимость этого ещё намекало и то наблюдение, что у прогеров с сайд-проектами не возникали похожие проблемы.
Развитие программистов
Стагнация это в принципе маленькая смерть (и уже один реальный прецедент увольнения), к тому же уже начали проявляться проблемы из-за недостаточности знаний или умений: Критично важным было повышать квалификацию программистов.
- накапливался технический долг
- ребята часто жаловались на проблемы с гитом
- исправления непредвиденных багов занимало очень много времени
- новые технологии внедрялись очень тяжело
- встреча с чужим кодом была прямо преградой
Поэтому нужно было развивать программистов централизованно силами компании. Кто-то развивался самостоятельно, кто-то нет, а кто-то вообще ушёл не в те дебри, хотя это может быть и полезно.
Кодревью
Ребята, конечно, читали мои комментарии, но замечания повторялись раз за разом. Я пытался почаще ревьюить код, но выхлопа от этого было недостаточно.
Лекции
Например, однажды я собрал все примеры говнокода, которые находил при кодревью, в один большой файл с объяснениями каждого случая и рассказал о них на созвоне. Ещё одной идеей было проведение лекций. Такое прямое обучение, конечно, было более полезно.
Кстати, именно в формате лекции я научил ребят работе со vue, который мы потом много использовали.
Во-первых, никто из других программистов так и не подготовил свою лекцию. Всего мы провели не так много лекций, где-то около 5. И проблем с говнокодом и превышением оценок это не решало, а они были самым главным.
Совместные сессии
Особенно меня расстраивала проблема с гитом, никогда до этого не встречал такое их количество: мерджы приводили к потере кода, решение конфликтов иногда клало сайт, файлы в коммиты иногда приходили помеченными как полностью переписанные, да и в принципе коммиты и сообщения к ним были совсем неинформативны.
Это привело к идее не просто созваниваться и проводить лекции, а созваниваться и писать вместе код, показывать как работать в Шторме, как делать коммиты, как решать конфликты через удобный интерфейс, как рефакторить код и между делом и просто обсуждать всякое программисткое. Я подумал, что это из-за того, что ребята работают с гитом через консоль или ещё как-то по своему.
И такой формат выстрелил.
Показываем друг другу всякие фишки в Шторме, куда вся команда, благодаря созвонам, наконец-то переехала, избавляемся от вопросов по гиту, улучшаем само качество разработки. Мы стараемся собираться каждую пятницу.
И не только я бываю на них ведущим, наоборот довольно часто отдаю инициативу и ребята сами начинают вещать полезные вещи. Плюс я верю, что такие еженедельные программисткие созвоны поднимают дух программистов, так как мы не просто разбираемся, почему из 1с пришла неправильная цена или добавляем очередной раздел с акциями на сайт, а как-то развиваемся, тесно общаемся без менеджеров и клиентов рядом, каждый немножко делится опытом и тем, что ему интересно, разбираем возникшие технические проблемы, подтягиваем отстающих.
Эффективность команды, оценка задач
Иногда среднее превышение по часам за месяц доходило до двух раз. Одной из самых больших проблем в компании было постоянное превышение сроков по задачам.
Проблема встала особенно остро во время моего отпуска, когда целую неделю задача с самого начала переносилась ещё на несколько часов вперёд, то есть каждые 3-4 часа говорилось “нужно ещё 3 часа”, и по итогу она заняла почти 40.
Опять же благодаря руководству мы не были в минусе и никого не увольняли, но растягивание задач отнимало у нас как минимум премии, а как максимум могло привести и к убыткам.
КПД всей команды стало моим КПИ, как основная задача тимлида. Мы прозвали соотношение факт/оценка выполнения работ в часах — КПД (ну как прозвали). И моя радость усилилась ещё и тем, что в это же время я, наконец-то, перестал программировать по 8 часов каждый день и теперь мог полноценно заниматься тимлидскими делами. Я был рад тому, что у меня появилось числовое КПИ.
Явных протечек видно не было: Мы оооочень много думали над проблемой КПД.
- программисты оценивали задачи довольно здраво
- реально над ними работали, а не просто ставили таймер
- с коммуникациями не было никаких проблем
Но потом всегда что-то шло не так и каждый раз разное:
- находился подводный камень
- итоговое решение не устраивало клиента
- отваливался какой-то смежный функционал
- при тестировании что-то пропускали и потом переделывали
- теряли время на поиск каких-то доступов
- ...
Я решил (не без интервью с каждым программистом в отдельности), что проблемы кроятся в:
- качестве оценки задач, что ребята всё-таки часто просчитываются
- в самом уровне программистов, из-за чего образуются задачи-”чёрные дыры” и исправление багов затягивается на часы. Это также могло вызывать ступор при встрече с неизвестными технологиями
- говнокоде, связанности кода. Хотя эта проблема косвенно пересекается с предыдущей
- в постановке задач, так как я часто слышал жалобы о неполноте информации в описании, плюс этот же момент мог приводить к лишним переделкам
И это принесло несколько новых открытий: Потом я решил провести исследование — проверил все логи времени во всех задачах с превышением оценки за последнее время.
- задачи изначально оцененные ровно в 1 час практически всегда были превышены
- тестирование задачи практически никогда не было заложено в оценку и часто именно оно давало превышение
- неожиданно и неприятно, но в логах времени часто упоминались проблемы с гитом. Причём большие логи, иногда по полтора часа
На основе всех этих знаний мы придумали контрмеры:
- я ежедневно лично проверяю все оценки и постановку всех новых задач, особенное внимание, конечно, уделяю маленьким задачам. Так мы боремся с неадекватностью оценки и неполнотой постановки
- переводим всех ребят в шторм, чтобы они как минимум перестали возиться с мерджами в консоли
- во все задачи закладываем время на тестирование, общение и сдачу клиенту
- проводим еженедельные созвоны узким программистким кругом, где вместе программируем, делимся знаниями, хитростями, учимся решать конфликты и рефакторить код между делом
Например, уже после второго созвона ушли проблемы с гитом.
Кпд начал выправляться, хоть и не очень быстро. Это всё начало довольно быстро приносить свои плоды, особенно программисткие созвоны. В данный момент мы всё ещё прикладываем много усилий и не перестаём изучать этот вопрос.
Чему я сам научился на новой должности
Кадры — самое важное
Ты можешь скупить все продукты атлассиана и джетбреинса, понарассказывать умные вещи, ввести кучу регламентов, договориться с клиентами насчёт схем постановки задач, но если твои коллеги саботируют регламенты, работают “по привычке” и не используют новые инструменты, то толку от нововведений нет.
Также проактивный человек всегда выгодно отличается от просто хорошего работника, хотя бы тем, что может выйти из своей “законной” зоны ответственности и не дать задаче застопориться или может предложить какое-то общее улучшение без просьбы сверху.
Личные качества важнее профессиональных
Такой приносит несравнимо больше проблем, чем пользы, особенно при обнаружении багов в его задачах. Например, у тебя может быть крутой спец, который всегда укладывается в сроки, может решить любую задачу, пишет идеальный код, но он появляется на связи дай бог 2 часа в день или внезапно берёт выходной посреди недели.
Изначально они одинаковы и в зарплате и в навыках, но через время второй начинает тянуть компанию вниз и факапить, а второй всё также продолжает выполнять свои задачи или даже обгонять более опытных коллег. Или можно представить ситуацию, когда есть два одинаковых работника, но один из них читает профессиональную литературу и/или ведёт личные проекты, а второй нет.
Это выливается в саботаж поручений или мёртвой остановке задач, если с изначальным исполнителем нет связи, и/или если нужно сделать что-то потенциально опасное, например, разрешить конфликт или выполнить какие-то действие на боевом сайте. Ещё очень вредны моменты, когда люди отказываются брать на себя ответственность.
Эмоции от коллег влияют на многое (большее, чем я раньше считал)
Стресс может быть вызван, например, уровнем зарплаты, токсичностью коллег, глупостью клиентов, дорогой на работу, рабочими обязанностями, миллионом других причин. Многие не любят свою работу из-за стресса.
Но от первого можно абстрагироваться, второе решить, а вот вечно ноющих и депрессивных сослуживцев ты будешь видеть каждый день. Новый стресс на работу могут принести клиенты, непредвиденные обстоятельства, коллеги.
И возможно, что именно общение с командой определяет задержится ли человек в компании или нет. Вообще чтобы мы не делали: писали код, занимались дизайном, работали с бухгалтерией, мы всё равно так или иначе работаем с людьми, и именно они больше всех влияют на наше настроение.
На два стула не сесть
Но это как катить квадратное колесо, когда тебя попросили обточить его. Первое время мне приходилось писать код весь день, из-за чего я считай совсем не успевал свои чисто тимлидские обязанности, только что помогал команде в целом более менее укладываться в сроки.
Ещё популярные вредные примеры перемешивания обязанностей:
- программисты долго общаются с клиентами и не укладываются после этого в сроки
- руководители занимаются распределением всех задач между исполнителями, что съедает всё их время
- контент-менеджеры пытаются править код и ломают сайт
- менеджер пытается передать жалобу программиста по коду другому программисту
- 1сники пытаются придумать хорошее решение
Здесь конечно не озвучены всякие постулаты о важности саморазвития или, например, гигиены труда, но лишь потому что это не новый опыт мне их открыл.
Планы
Изначально, когда я ещё только начал задумываться о смене работы, я хотел уехать на Кипр, потому что ждал от него солнца (стереотипы про Питер совсем не стереотипы), спокойствия, хорошей зарплаты, интересных вызовов и отсутствия стрессов.
Но Москва мне предложила условия, от которых я не смог отказаться (карьерный рост, зп в 2 раза больше текущей, площадку для экспериментов и почти полную свободу действий).
Поэтому я хочу “приближать Кипр сюда”, то есть чтобы команда: С другой стороны, если подумать, мы же тоже Европа.
- меньше стрессовала на работе
- перестала дико уставать
- избавилась от негатива исходящего от коллег и клиентов
- имела возможность гордиться своей работой, то есть перестать править баги и разгребать факапы, а пилить что-то крутое
- когда-нибудь ушла от Битрикса использовала новые технологии.
- ну и конечно же увеличила прибыль
Ну то есть всего того, что мы ждём от прекрасного далёко.
Часть 2
Во второй части я бы хотел рассказать о том, как мы движемся к целям с помощью: Эта статья охватила примерно полгода моей работы в новой должности.
- автотестирования, которые мы только начинаем внедрять. Странно, но почему-то на Битриксе нет достойных примеров
- избавления от наследства в коде
- дальнейшего ускорения и упрощения разработки
- того что я почерпну из комментариев
- множества других пока секретных вещей (вдруг меня мои ребята читают)
Буду очень рад комментариям, особенно, если вы знаете более оптимальные пути решения проблем, с которыми мы сталкивались. Всем спасибо за прочтение.
Всем удачи и радости в работе и жизни!