Мы продолжаем делиться своим опытом, чтобы помочь сократить уровень неопределенности при сборе новой команды. Наш рассказ строится от обратного – мы делимся своими ошибками, которые когда-то допустили при формировании команд. В данной статье расскажем об экспертизе, коммуникациях и практических идеях для тимлидов и разработчиков. Первую часть статьи можно прочитать здесь.

Экспертиза

1. Не внедрять концепцию T-shape c самого начала.
   Концепция T-shape очень полезна командам – ее стоит прививать с самого начала. Здорово, когда сотрудник одной практики хочет попробовать на себе другую роль – так он развивает свои навыки горизонтально и становится экспертом в нескольких сферах. Например, разработчик кроме разработки может и протестировать, и проанализировать. Часто T-shape относят только к разработке, но эту концепцию можно применить и к аналитике, и к тестированию. В статье подробно описано, как немецкая компания применяет данную концепцию на практике. В результате: команды с данным подходом легко масштабируются, а сотрудники могут легко заменить друг друга в случае чьего-либо отсутствия.

2. Не передавать экспертизу заранее.
   Рассмотрим кейс: перспективный сотрудник хочет перейти на новую для себя роль в соседнюю команду, с которой вы работаете над различными несвязанными задачами. Например, старший разработчик хочет стать лидом разработки, и как только выдается такая возможность, вы сразу переводите его на эту роль в другую команду, где он сразу вживается в свою роль и занимается новыми лидерскими задачами. Когда коллегам из старой команды нужна помощь, консультация или обучение, сотрудник уже не готов этим заниматься. Ошибка данного кейса состоит в том, что сотрудник не передал экспертизу никому из своих коллег заблаговременно, до перехода на новую роль – в идеале в течение 2-3 месяцев. Хотя и команда, и новая роль по смыслу близки к прежней деятельности сотрудника, для него это пройденный этап и делиться опытом он не готов. 

3. Не вести базу документации.
   Чтобы наладить процесс в команде, недостаточно рассказать об изменениях на словах. Фиксируйте информацию не только о системе, но и о правилах игры в команде, о принятых процессах и регламентах – так вы сократите свое время на объяснение коллегам одного и того же по десять раз, ведь у вас будет ссылка на статью, где уже есть ответы на вопросы. Также мы часто пренебрегаем описанием узких мест и редких кейсов, встречающихся в системе. Когда главные хранители информации уволятся или перейдут в другую команду, их коллегам, оставшимся в команде, не обязательно проходить путь исследования узких мест с нуля. Пусть уходящий напишет статьи о сложных кейсах, с которыми он сталкивался – наверняка эта информация пригодится коллегам. Например, раз в год с прода прилетает команде дефект. Ваши разработчики каждый год его отклоняют, потому что в письме от 10.08.2018 года зафиксировано, что бизнес-архитектор заказчика подтвердил, что данный случай дефектом не является. Если бы эта информация не была зафиксирована, то каждый год вашей команде приходилось бы в течение нескольких часов или дней доказывать инициатору дефекта, что дефект – не дефект. Но вы написали регламент работы, куда приложили ссылку на письмо с договоренностями, поэтому отклонение дефекта занимает ровно минуту.
   Именно поэтому база документации – драйвер для расширения команды.

4. Не иметь единую информационную среду.
   Помимо базы документации в новой команде особенно важно формировать единую информационную среду. Контрольные точки, цели, график, скоуп задач проекта должны видеть все члены команды и учитывать в своей работе. Заведите место, где будет храниться такая информация, и доступ к ней должен быть простым и удобным для всех: страница в Confluence или в MS Teams, закрепленное сообщение в Telegram и т.д. Так сотрудники будут понимать – куда двигается команда.

Коммуникация 

1. Замыкать коммуникацию на одном сотруднике.
   Такая проблема возникает часто у старших специалистов и является блокером для расширения команды. Здесь возможно два кейса:

   1) Старший сотрудник не доверяет младшему сотруднику, а младший сотрудник боится самостоятельно писать письма заказчику/коллеге с более высоким грейдом. Старший специалист не учит младших ведению коммуникации. Здесь важно, чтобы на первых порах младший сотрудник показывал черновики писем куратору/более старшему специалисту/тимлиду. Тому, кто проводит ревью, не следует позволять делать это на регулярной основе и садиться на шею. Старший специалист должен отследить тот момент, когда младший уже способен самостоятельно писать письма, и отпустить контроль, а тимлид или менеджер – проконтролировать, что старший сотрудник все-таки пустил младшего сотрудника в коммуникацию.

   2) Бывалый эксперт настолько хорошо ведет коммуникацию с заказчиком/коллегой, у которого более высокий грейд, что команда отожествляется только с его персоной. Сотрудник не хочет делиться зоной ответственности и пускать других сотрудников во внешнюю коммуникацию, то есть ваш эксперт стал единственным (основным) «окном» в команду. Здесь существует опасность, ведь если его по какой-то причине не окажется, коммуникация с внешим миром быстро сломается и потребуется довольно много времени, чтобы вновь ее наладить. Введите правило: каждый сотрудник ставит в копию своих писем кого-то из команды. Другим вариантом решения проблемы может стать создание общего репозитория писем. Также может помочь разделение зон ответственности по коммуникации на нескольких сотрудников: сотрудник А ведет коммуникацию с заказчиком 1, сотрудник Б – с заказчиком 2.

2. Не делать карту коммуникации.

   Когда набирается новая команда, как правило, никто не понимает, к кому и по какому вопросу обращаться. Имея карту коммуникации, вы сократите количество вопросов со стороны новичков в разы и сбережете время кураторов. Без карты коммуникации онбординг происходит дольше, особенно у аналитиков.

3. Не прививать в команде идеологию agile, если используете её.
   Убедитесь в том, что каждый участник команды понимает смысл и преимущества agile-ритуалов (backlog grooming, daily не больше получаса, планирование не больше двух часов в спринт). Если кто-то в команде не принимает agile, в скором времени он будет демотивировать себя и команду, подвергая сомнению необходимость того или иного мероприятия. Не забывайте объяснять команде, зачем нужны ритуалы, так как если вы не объясните им на старте, позже им будет тяжелее это понять.

4. Не выделять роль координатора команд.
   Когда команд на проекте становится более одной, необходимо вводить роль координатора, который будет эти команды связывать. Этот человек будет видеть проблемы команд, налаживать вопросы взаимодействия, заниматься ресурсным планированием и ротациями. Если не вводить данную роль, то каждая из команд пойдет по своей дороге, а новая команда с большой вероятностью не будет пользоваться наработками, которые есть у соседней команды. Кроме того, в командах будут ресурсные проблемы: при увольнении специалиста из команды А, сотрудника на эту позицию начнут искать с рынка, хотя в команде Б есть скучающий сотрудник этой же роли. В итоге это может привести к дефициту или профициту кадров. 

Про тимлида новой команды

1. Не делегировать.
   Обычно тимлид новой команды готов сделать все и за всех, потому что ему, например, может быть сложно делегировать задачи новым сотрудникам. В худшем случае такая частая практика может быстро расслабить команду и вся ответственность за результат свалится на одного тимлида. В лучшем случае тимлид, выполняя все сам, не дает команде развиваться и быстрее погрузиться в проект. 
   Например, тимлид хочет нарисовать карту коммуникаций. Но ведь эта карта нужна не только тимлиду, но также, как минимум, аналитикам. Если отдать эту задачу кому-то из аналитиков вместо того, чтобы сделать самому, таким образом хотя бы еще один человек в команде разберется с коммуникациями – что уже хороший результат.

2. Не соблюдать баланс между интровертом и экстравертом.
   Если тимлид слишком общительный и дружелюбный, он может потерять уважение команды – его просто перестанут слушаться. Если тимлид слишком отстранен от команды, к нему будут бояться прийти с проблемами. Соблюдайте баланс: не пытайтесь стать другом каждому члену команды, но и не замыкайтесь в себе. Проводите регулярные one-to-one со всеми членами команды с самого ее основания. Отправляйтесь в командировки и встречайтесь хотя бы раз в полгода со своей командой face-to-face.

3. Работать 24/7.
   Если вы «вывозите» проект на себе, значит, вы высококлассный специалист, но плохой тимлид, потому что команда без вас не может, а значит, вы не наладили процессы. Тимлид = дирижер. Занимайтесь процессами, а не тушением пожаров. Не замыкайте все процессы на себе, придумывайте разные роли для членов команды и назначайте ответственных за ту или иную зону. Если вас одного на проекте недостаточно, не стесняйтесь и скажите об этом руководству, чтобы вам нашли подмогу – еще одного тимлида.

4. Относиться к juniors как к juniors.
   Если тимлид относится к младшим специалистам как к младшим специалистам – жалеет их, не дает сложные задачи – у них не будет шанса вырасти.
   Даже если к вам в команду пришел новичок и младший сотрудник, загружайте его реальными задачами, так он быстро вырастет в толкового специалиста. Не забывайте при этом проверять за ним выполненную работу и назначать куратора.

5. Выделять любимчиков среди членов команды.
   Тимлид или менеджер должен уделять внимание всем, даже если кажется, что кому-то внимание не нужно. Обратное неизменно ведет к дисбалансу в команде, развитию токсичности. У каждого члена команды – свой KPI, поэтому будет ошибкой оценивать всех по одинаковым критериям. 

Про разработку

Если в существующей команде правила, приведенные ниже, не соблюдаются – не страшно, но обязательно введите их в новой команде:

1. Не регламентировать повторяющиеся действия.
   Прививайте своим сотрудникам привычку писать регламенты для того, чтобы зафиксировать повторяющиеся действия и правила. Например, когда нужно писать с большой буквы, а когда – нет. В дальнейшем такая привычка оптимизирует время на передачу знаний. Минимизируйте и оптимизируйте рутину! 

2. Не договариваться на входе о code style.
   Чтобы код был единообразным, договоритесь на старте проекта с разработчиками о том, какие правила code style вы все вместе будете использовать (комментирование, java doc, использование тех или иных методов и т.д.).
   За основу можно взять чек-лист из книги Роберта Мартина.  
   Учтите, что бывают требования от заказчика, которые могут отличаться от тех, которые вы приняли. В таком случае клиентские политики учитываются в первую очередь.

3. Не соблюдать взаимозаменяемость.
   Если вы выделяете зоны с задачами определенного типа на какого-то конкретного разработчика, это значит, что он не будет развиваться в других зонах и задачах.
   Разработчики должны уметь «быть на подхвате», чтобы когда один уходит в отпуск, второй мог взять задачу на себя с минимальными потерями. Даже если вы договорились о code style и код разработчика понятен, другой разработчик не подхватит задачу быстро, если не знает контекста. Поэтому планируйте задачи разной тематики на разных разработчиков и меняйте их местами в следующем спринте. Когда Вася уже делал логирование, а Петя еще нет, значит, задачу нужно отдать Пете, чтобы его экспертиза выросла. Agile подразумевает единообразие – когда разработчики равны и каждый из них умеет делать всё.

4. Не пользоваться линтерами.
   Хорошим тоном считается использование линтеров, проверяющими code style (в github, например). С самого начала проекта возьмите за правило пользоваться этим инструментом. Разработчики используют линтер перед коммитом локально, а затем линтер централизовано запускается на github с тем же или другим набором правил валидации кода. Линтеры помогут вам оптимизировать рутину и освободить ревьюеров от проверки банальных ошибок.

В качестве вывода отметим, что, хотя можно игнорировать все рекомендации, описанные в наших статьях, следуя им, расширение команды пройдет для вас бесшовным. Особенно важно задать правила игры по всем перечисленным пунктам с самого начала работы команды, а лучше – еще во время поиска ее членов, ведь «как корабль назовешь, так он и поплывает». Информацию из нашей статьи можно использовать для чек-листа, чтобы вычеркивать пункты по мере формирования и адаптации новой команды. Если вы не будете допускать ошибки, которые мы перечислили выше, то сэкономите материальные ресурсы, время и силы, как свои, так и всей команды. Надеемся, что наш опыт поможет вам с легкостью планировать ротации, нанимать новых людей, проводить онбординг, а новым членам команды – наладить процесс передачи экспертизы и эффективной коммуникации.

Источники:

1. Summary of 'Clean code' by Robert C. Martin

2. Операция «Т», или выйти в прод за полгода