Посмотрев на темы, о которых мы недавно писали, я понял, что давно не было примеров из реальной жизни. В этот раз хочу рассказать кейс одной команды и услышать мнение читателей.
Для одного проекта собралась команда. Люди были из разных команд и до этого вместе не работали, хотя многие, так или иначе, были знакомы внутри организации. В команде были и опытные разработчики, которые участвовали уже не в одном проекте, и начинающие. Проект был интересен сам по себе и вызывал энтузиазм у всей команды.
Лидер команды был грамотным и опытным, поэтому с самого начала он договорился о деталях со всеми и описал процесс, по которому будет работать команда. Определили состояния, которые проходит каждая задача до того, как команда может сказать «готово», договорились о способах отслеживания прогресса и наглядности планов. Даже договорились сразу о «полезных практиках», таких как взаимный пересмотр (peer review).
И вот все дружно начали работать.
Первые пару итераций пролетели на общем запале энтузиазма достаточно быстро. Каждый делал свое дело, кто-то быстрее, у кого-то возникали трудности. Все вместе следили за качеством и обсуждали лучшие пути решения проблемных мест.
И вот, в какой-то момент, один из опытных разработчиков решил, так сказать, «проявить инициативу». Он начал пересматривать уже готовые решения и находить в них много «идей к улучшению». Причем часть решений уже были в состоянии «завершено», и к тому моменту их обычно смотрел кто-то из других членов команды. Также не обошел он своим вниманием и задачи, которые были в работе. «Добрался» он также и до нескольких концептуальных вопросов внутри системы, что сразу вызвало дискуссии относительно архитектуры и ее дальнейшего развития.
В общении с людьми он был достаточно безапелляционен и навязывал свою точку зрения и неохотно соглашался с чужим мнением. Более того, лидер команды, зная его как опытного и толкового разработчика (или может по каким еще причинам), не пресекал такие действия. Можно сказать даже попустительствовал, пусть и молчаливо. Доходило даже до того, что в списке задач стал появляться отдельный признак, говорящий о том, что задача была просмотрена этим разработчиком.
Поскольку в команде был не один опытный разработчик, то как минимум пара других не всегда соглашались с его мнением. Они спокойно и аргументировано отстаивали свои точки зрения и иногда приходили к согласию, а иногда просто уставали спорить и соглашались.
Как-то само собой получилось, что все члены команды, видя такую ситуацию, потеряли первоначальный энтузиазм. Работа стала делаться медленнее, даже та которая в начале казалась простой. Или задача, похожая на уже сделанную, стала занимать больше времени. Интенсивность общения в команде тоже снизилась, люди обсуждали только небольшие практические вопросы. Выглядело все так, как люди либо пытались увильнуть или старались побыстрее «избавиться» от задач, за которые они взялись.
Поскольку проект еще не закончился и ситуация может измениться, то я бы хотел, чтобы читатели прокомментировали этот кейс и высказались.
Какие ошибки, вы считаете, были допущены?
На что еще, возможно, нужно обратить внимание, чтобы ситуация не усугубилась?
Какие шаги можно предпринять, чтобы исправить ситуацию в команде?
Тимофей, хочется прокомментировать ситуацию, т.к периодически читаю ваши статьи:
1. Похоже слабый тимлид в команде, раз допускает такое (либо не пользуется авторитетом, что сеньоры его так двигают).
2. Любое решение можно улучшать до бесконечности. Но есть время, выделенное под конкретную задачу.Если хочется что-то улучшить, пусть “опытный программист” записывает где-то пункты, которые хотел бы улучшить(после того как решение выполнено). Так например мы делаем у себя на проекте. У нас была техническая итерация, перед которой собрались все технич. улучшения и выбрались те, которые действительно надо(и почти все были сделаны).
3. А то, что человек хочет ревьювить чужие решения – это вообще отлично. Только надо делать до того, как решение запустили в продакшин. Иначе – смотри пункт 2.
4. Насчет уменьшение интенсивности общения в команде – так это нормально. Со временем она уменьшается и люди общаются только по делу, обсуждая конкретные вопросы( не все время же жить на голом энтузиазме).
Допущенные ошибки:
1. Не контролируемый не толлерантный гиперактивный опытный разработчик – это всегда плохо. Картина на лицо – безапеляционно “давит” своим мнением/авторитетом/опытом. Ожидаемый доп. минус в ближайшее будующее – снижение мотивации у остальных опытных разработчиков (смысл напрягаться, предлагать – если всё равно будет как решил он. Вероятно, что будут пропускаться заведомо неправильные/неоправданные решения. Даже из принципа – раз он говорит, что так нужно – давате сделаем, и потом тыкнем носом, раз на словах доказать не можем). Кроме того, если напрямую просматривается попустительство тимлида, то очень быстро разовьется недоверие/неуважение к последнему.
2. Ошибка тимлида – никогда нельзя ставить личное отношение/уважение к сотруднику выше задач команды. В данном случае возможны очень дружеские взаимоотношения, либо очень удачный предыдущий опыт работы программиста с тимлидом. В результате решение принимает один человек, сам, а это НЕ командная работа.
3. Исправления в готовых фичах. Определённо демотивируют членов команды. Т.е. есть функционал, он закончен – сдан. Затем пересматриваются решения и задача отправляется на переработку. Создаётся впечатление, что как ни делай, всё равно через неделю что-то ещё поменяют и нужно править заново. Пресмотр готовых решений – это по хорошему рефакторинг, который не стоит делать слишком часто. Т.к. складывается впечатление, что архитектура изначально не правильная, и не стоит продолжать кодить вообще, пока не пересмотрят всё.
Как захолдить ухудшение ситауции.
Самым действенным/быстрым будет нейстрализация (не физическая 🙂 ) опытного программера. Один из мягких способов – переключить его внимание на какую-то сложную/нетривиальную задачу. Т.к. похожая гиперактивность замечается у специалистов у кот. скучные текущие задачи – вот они и начинают активничать через меру.
Также стоит дать прочитать эту статью с коментами – тимлиду!
Если он действительно опытный тимлид, то должен увидеть свои ошибки, проанализировать их и сменить свою позицию, дав всем опытным прогерам равные права в голосовании. Как вариант можно ввести голосование за солюшн (анонимное) – у опытных девелоперов вес голоса 2, у обычных – 1 🙂
Шаги по исправлению ситуации.
К предложенному выше можно добавить следующее:
1. Разрешить пересмотр решений для законченных фич, только в случае если они сильно афектят дальнейшую разработку. И делать более глобальный рефакторинг только после промежуточного релиза. Т.к. релиз это всегда награда для программеров – есть результат трудов, рабочий!
2. В случае, если опытный програмер не остепенится и тимлид не сможет им управлять, и ситуация будет ухудшаться – я бы предложил заменить тимлида. Т.к. это менее болезненно для команды, чем менять прогера. Но это крайние меры.
3. Анализ со стороны. Пригласить специалиста по решению внутри-командных проблем, чтобы локализовать оную (если мы таки здесь в каментах не правильно определили корень зла) и дальше уже действовать.
ЗЫ (Простите мою лексику – как говорю, так и пишу 🙂 )
В дополнение к сказанному:
Как и в любой подобной конфликтной ситуации, самое первое, что нужно сделать, это поговорить с «зачинщиком». Построить диалог насколько возможно доверительным и понять причину его действий. Если он хочет стать руководителем, то скажите ему, что хороший руководитель должен быть не только хорошим специалистом, но еще и уметь создавать командный дух. Если он хочет повышения заработной платы, то напомните ему, что результативность его работы в первую очередь оценивается по успешности проектов, в которых он работает как ключевой разработчик. Думаю, и в других случаях хороший руководитель найдет, как мотивировать «оптимизатора» работать на благо команды и проекта.
полностью согласен. Добавлю, что задача менеджера еще и в том, чтобы поддерживать конструктивный диалог (процесс коммуникации в команде) и мотивацию, а не чтобы все в кусты…
В дополнении к сказанному:
Как и в любой подобной конфликтной ситуации, самое первое, что нужно сделать, это поговорить с «зачинщиком». Построить диалог насколько возможно доверительным и понять причину его действий. Если он хочет стать руководителем, то скажите ему, что хороший руководитель должен быть не только хорошим специалистом, но еще и уметь создавать командный дух. Если он хочет повышения заработной платы, то напомните ему, что результативность его работы в первую очередь оценивается по успешности проектов, в которых он работает как ключевой разработчик. Думаю, и в других случаях хороший руководитель найдет, как мотивировать «оптимизатора» работать на благо команды и проекта.
Тим, спасибо за интересный кейс.
А в чем собственно проблема в данном кейсе, и у кого? Мне видится примерно так:
1) Из-за повышения объема работ и замедления скорости проект может сорван по срокам и бюджету
2) У команды пропал groove, из-за чего команда стала хуже работать
3) Тимлида оттерли.
Третья проблема – это проблема тимлида, пусть он её сам и решает. Первая и вторая – проблемы менеджера, вот ими и займемся.
Первое. А знает ли команда и гиперактивный товарищ в частности, что из-за его гиперактивности проект под угрозой? Это нужно срочно донести! И возложить так сказать персональную ответственность за то, чтобы успеть вовремя на команду и в частности на ведущего разработчика – источник проблем. Может, ему просто заняться нечем? Тогда это тоже срочно нужно исправить ))
Второе. А знает ли гиперактивный товарищ, что он делает что-то несокультурное с остальной командой, т.е. несовпадающее с их ценностями? И осознает ли вообще команда, какие у неё ценности, и почему у них у всех все упало?
Итого, мой план такой:
1) всех собрать
2) сказать “Товарищи! Революция в опасности, осталось столько-то работы до такого-то числа, и нам НАДО это сделать! Но нас кто-то тормозит…” После чего поговорить о Good Enough и прийти к соглашению, что считать “Готовым”.
3) После этого нарисовать красивенький Burndown и его каждый день обновлять и показывать всем (с паническими нотками в голосе).
4) Поговорить с командой на тему “Какие наши ценности добавляют нам groove / какие наши ценности делают нас успешной командой”. Потом выписать эти ценности на листик, повесить на стенку и при каждой попытке товарища “предложить улучшения” тыкать в ценность №2: мол что ты делаешь, это противоречит!
Выскажу личный ИМХО.
Мне кажется, менеджер повел себя некорректно, когда слишком рано оставил команду без поддержки и контроля. Мол “вроде работают, сами справятся”. Команда подошла к этапу “шторминг” и тут их накрыло без направляющих.
Присоединяюсь к идее совместно вспомнить (и если нужно записать) критерии “Готовности”. Это позволит избежать переделки законченной работы и заодно напомнить “самому активному”, что мол если другие члены команды взяли на себя ответственность во время ревью, то еще один проверяющий не нужен.
Я не совсем уверен, есть ли у команды жесткий дедлайн или возможны подвижки в финальных сроках. Хотя, будучи сторонником визуализации текущего состояния я всеми руками за составления Project Burndown, как предложил Артем.
Остальные идеи и приемы уже добавлять по вкусу.
История поднана с негативной коннотацией к “раздражающему” разработчику, без оценок насколько правильные решения он принимал – и большинство народу высказалось в колее. А вдруг он был прав и всех спас?
1. Ошибка менеджмента в том, что не были определены протоколы работы в команде: консенсус, голосование, авторитаризм тимлида и т.д. Все члены команды должны быть согласны работать по указанным правилам. А если у кого-то “падает мотивация” потому, что кто-то имеет свое мнение и отстаивает его – это следствие того, что в команде срабатывают детские обиды. А причина этого – отсутствие преопоределенного протокола, из-за чего народ не знает, как делить апельсины (несоглашающиеся опытные люди), или “не туда попал” – собирался в детский лагерь, а попал в армейскую дедовщину. Повторю – все это вина орагнизатора команды – то есть менеджера. Чтобы не падала мотивация должны не цветочки рости на окнах, а условия контракта соответствовать реальности.
2. Ответственность – только за принятые решения. Людям должно быть понятно, что за принятые решения отвечают они. Если “опытный разработчик” будет полностью отвечать за решения, которые принимает, он должен будет либо делать сам то, что предлагает, либо отвечать за то, что делают другие, а такого никто для себя не захочет. То есть, если в команде безответственная демократия (по факту решения навязанные одними делаются командой и команда отвечает полностью) – получаем с одной стороны аггресивных безответственных продвигателей идей, с другой стороны неагресивных демотивированных соглашателей¸ “которых никто не слушает потому что они не говорят ничего”, но которые за все отвечают + примадон с той или другой стороны с кучей детских обид. То есть опять же – ошибка менеджмента который не учел, что люди все разные и не продумал механизм связи между решениями и ответственностью. А собрать людей ранее вместе не работавших, возможно психологически и профессионально несовместимых, и надеятся, что они сделают успешный процесс на основе здравого смысла – это по меньшей мере наивно. Все равно, что напустить пауков в банку и надеятся что они устроят парламентскую республику.
3. Команды так собирать нельзя. Потому что пауки в банке. Команды надо выращивать. Это конечно, если целью есть производство софта, а не эксперименты в области менеджмента.
4. Трекинг результатов принятых решений. Здесь тема не раскрыта совсем полностью. Решения который принимал этот опытный разработчик – были таки правильными или таки нет? Если правильные – значит ему медаль и пирожки бесплатно, а “демотивированная команда” – это либо набор примадон вида “дело не в том что ты сказал, а в том как ты сказал”, и/или ошибки менеджмента по пунктам 1 и 2. Если решения не правильные, почему он одолжал их принимать и появилсь колонка его одобрения? Тема не раскрыта – команда что демотивировалась от того, что появился умный человек, который принмал правильные решения? От того, что их перестали спрашивать вообще? Или от чего?
Не надо забывать, что цель – производство работающего софта, а не существование мотивированной команды. Мотивированная команда – это механизм и работать он может неправильно. Я не раз наблюдал процесс, когда высокомотивированные радостные группы работали как квалифицированные специалисты, которые “с успехом решают локальные проблемы уверенно продвигаясь к глобальной катастрофе”.
Все это проблемы отстутвтия проработанных принципов работы в команде. Все с ними изначально должны соглашаться, или не начинать работать в этой команде. Если человек обижается на результаты голосования, при установленных принципах демократии – он знал на что шел.
Формирование эффективных команд – это искусство, разные команды могут работать по разным принципам, переходя в процессе своей жизни от авторитаризма тимлида к консенсусному принципу автоматически по прохождении времени притирания разработчиков. Нельзя совершенно разных людей напустить в одно помещение и ожидать, что они будут жить счасливо – это фантасмагория. Хайп вначале бывает очень часто. Здесь причиной демотивации мог быть совсем не гиперактивный разработчик – а проблемы с которыми столкнулась команда в целом, а он возможно единственный, кто пытался не закрывать на них глаза. Если это не так в конце концов режим, когда все делают все может быть изменен в пользу режима разбиения проекта на две или более частей, этот активный разработчик может быть посажен за отдельный модуль, который он сделает скольугодно качественно, остальная ком
анда делает остальную часть как хочет. Надо рассаживать несовместимых пауков по разным банкам.
То есть глобально здесь очевидная ошибка менеджмента – невыполнения его прямых функций – _эффективного_ управления.
PS: “Программист довольный по окончанию проекта результатами своего труда – плохоя программист” (C) Я
При любом виде совещания, собрания, обсуждения нужен опытный Модератор. Желательно, чтобы это умел делать руководитель. В конце концов, можно и на спецкурсы сбегать. А в данном случае этот вопрос стоит остро (особенно, когда два опытных аргументировано возражают третьему, а он «не слышит»).
>>Исправления в готовых фичах. Определённо демотивируют членов команды. Т.е. есть функционал, он закончен – сдан.
Согласен. Люблю образы. Представьте, что некто привязал кусочек сала и дал проглотить котенку. А потом за ниточку вытаскивает его назад. По себе знаю, когда над тобой довлеет «дамоклов меч» – и в любой момент нужно возвращаться, переделывать сданную работу… Демотивация на лицо… и на голову тоже.
Согласен с коллегами. Геперактивность лечится увеличенной нагрузкой.