Ахмед Шериев: проблемы управления командой и способы их решения
Продолжаем публиковать статьи по материалам подкастов DevOps Дефлопе, проводимых инженерами компании «Экспресс 42» Виталием Хабаровым и Андреем Александровым. Сегодня поговорим о том, как трансформировать команды разработки, какие бывают с этим проблемы и с чего начинать.
— Здравствуйте, Ахмед. Расскажи, пожалуйста, немного о себе.
Всем привет! У меня есть опыт работы программистом, тимлидом, архитектором, руководителем, директором по разработке. Обычно меня зовут для управления, как бы это помягче сказать, провальными проектами, когда качество разработки оставляет желать лучшего, все сроки срываются и команду готовы уволить. И чтобы исправить эту ситуацию, меня и приглашают.
— С какими командами больше всего проблем? Которые работают в стартапах или в крупных Enterprise-компаниях?
Больше всего проблем как раз в самих людях вне зависимости от типа компании. Если говорить об Enterprise, то здесь основной источник проблем — это руководство. И чаще всего проблемы наблюдаются, если крупная не IT-компания начинает производить IT-продукт.
Дело в том, что у многих «матёрых» руководителей есть большой стаж управления в разных сферах, связанных с преимущественно операционной работой. Но когда они впервые сталкиваются с другим типом работы, возникают сбои. Те механизмы управления, которые работали у них везде и всюду, могут не сработать в IT, поэтому многое приходится делать иначе, а это бывает сложно принять руководству.
Возьмём, к примеру, ключевые показатели эффективности KPI. Очень часто KPI внедряют, не разобравшись, почему команда работает плохо, убивая тем самым разработку продукта напрочь. А всё потому, что разработчики теряют интерес к качественному выполнению своей работы и пытаются достичь определённых показателей, навязанных сверху. И в моей практике такие примеры случались.
— Что бы ты посоветовал тем, кто попадает в «гиблый» проект?
Что я могу посоветовать… Говоря по правде, я сам стал тимлидом, именно находясь в таком проекте. Предыстория следующая: директор по разработке дал команде полную свободу действий, и каждый писал, как хотел. Это был проект с общим кодом для Android, iOS и Windows, разным UI, общим ядром и логикой. Но если ты говнокодишь, делая проекты на одной платформе, это ещё может сработать. А если говнокодишь в проекте с общим ядром, который работает на разных платформах, то здесь нарушения архитектуры не могут не привести к неприятным последствиям. Проще говоря, проект попросту перестаёт собираться и именно с этим мы и столкнулись.
В какой-то момент я понял, что проект загнётся, но я очень этого не хотел. В итоге я пришёл к директору и сказал, что знаю, как спасти проект и что нужно для этого сделать. И… попросил назначить себя тимлидом. И тут же встретил сопротивление — мол, зачем тебе становиться руководителем команды? Если ты действительно прав, объясни это команде, и все сделают, как ты говоришь, а тимлидом становиться необязательно. Но я настоял на своём, так как твёрдо знал, что прав, но также я был уверен и в том, что многие со мной не согласятся. И чтобы получить возможность повлиять на работу других людей в приказном порядке, нужно было стать их руководителем. А так как проект всё равно был в плачевном состоянии, то терять было нечего и директору пришлось согласиться.
Вначале я делал банальные вещи, например, жёстко определил стиль кода и архитектуру на всех платформах. Естественно, обязал всех выполнять код-ревью и даже устроил ротацию ревьюеров, когда джуниоры ревьюили опытных разработчиков, причём следил, чтобы они это делали по-настоящему, а не просто ставили галочку. Мало того, если джуниоры не понимали код, написанный ведущим разработчиком, они просили объяснить содержимое, что позволило дополнительно запустить ротацию опыта в команде. И очень быстро все начали обмениваться опытом.
В итоге проект запустился, и руководство было довольно. А мне предложили взяться за всю разработку в компании. Так я стал директором разработки.
— Что нужно, чтобы поменять команду? Достаточно ли просто громкого названия «тимлид» или нужен авторитет, «кнуты и пряники», какие-то особые знания?
Вопрос хороший, но очень неоднозначный. Конечно, тимлид или директор по разработке не может быть экспертом во всех технологиях. И когда я указывал подчинённым, как нужно писать код, я нередко встречал сопротивление со стороны более опытных программистов или учёных.
В моём случае помогал авторитет и предыдущие заслуги в этой компании. Но ведь существуют разработчики, для которых нет никаких авторитетов. Здесь приходилось уговаривать людей взвешенной аргументацией, приводить примеры из технической литературы, ссылаться на общепризнанные авторитетные источники. Если это было невозможно, я говорил: «Окей, я понимаю, что ты мне не веришь, но ты сделай под честное слово, как я говорю. Если мы увидим, что результата нет, я признаю свою ошибку и больше тебя не побеспокою, будешь писать код, как считаешь нужным». И в большинстве случаев я оказывался прав. А когда сотрудники видят, что твои рекомендации в 90 % случаев положительно влияют на разработку, они прекращают спорить и начинают доверять тебе как руководителю.
Также я хочу отметить, что самое главное — не менять сразу всё, а начинать с элементарных вещей, которые гарантированно дадут результат. И двигаться от простого к сложному.
— А как насчёт саботажа?
Увы, случалось. У меня была история, когда мы договорились написать код по-моему, но человек саботировал наши договорённости и сделал всё по-своему. Узнал я это через два спринта (две недели). То есть разработчик делал ровно противоположное тому, о чём мы договорились, и это привело к определённым проблемам, мы не смогли выполнить слияние кода. Как мне объяснил виновник ситуации, он посчитал, что так будет лучше. В итоге нам пришлось потратить ещё неделю, чтобы всё исправить. Когда это повторилось несколько раз подряд, нам пришлось расстаться. И знаете, вся команда с облегчением вздохнула, а некоторые даже принялись укорять меня, что я слишком долго терпел.
Но самое интересное заключается не в этом, а в том, что данный разработчик был на хорошем счету у начальства, считался очень эффективным программистом. При этом он постоянно жаловался начальству, что я его постоянно прессую, мешаю работать. А всё потому, что я начал ужесточать требования к качеству кода, что, разумеется, привело к его дискомфорту.
Так вот, с точки зрения начальства он был просто идеальным работником, трудоголиком, который больше всех вкалывал и чуть ли не тянул на себе весь проект. НО! Когда я начал внедрять гибкие методологии, когда начал внедрять спринты и оценки, очень скоро стало понятно реальное участие каждого человека в проекте. А показал я это начальству и всей команде следующим образом: я повесил огромный интерактивный монитор посреди комнаты, где отображались задачи, выполняемые сотрудниками. То есть стало наглядно видно, кто и какой задачей сейчас занимается, сколько времени он на неё уже потратил. И руководство с удивлением обнаружило, что данный сотрудник, несмотря на весь свой опыт, является одним из наименее эффективных работников. В результате конфликты с начальством прекратились, а этот человек решил уволиться сам.
Полную аудиоверсию подкаста слушайте на сайте подкаста DevOps Дефлопе, который проводят инженеры компании «Экспресс 42» Виталий Хабаров и Андрей Александров. Впереди ещё много интересного, не пропустите! Там же вы найдёте и массу других полезных выпусков.
