Comments 11
Не лид должен быть в авангарде реагирования на инцедент. Должны быть дежурные и это точно не тимлид на постоянной основе. Или SRE с правом отката релиза и дежурный разработчик из команды - хороший вариант, или просто дежурный разработчик из команды. Тимлида надо подключать только если SRE и дежурный не справились.
Если документации нет, то пытаться писать её когда появились новые члены команды - поздно. Целесообразнее описать систему крупными мазками плюс подключить новых разработчиков к документированию. У вновь пришедшего больше шансов заметить неточности. При этом лид должен и сам понимать, и до бизнеса донести, что разработка не заканчивается на написании кода. Процесс включает в себя так же написание тестов и исправление документации. Чтобы не было такого, что разработчик находится под постоянным прессом быстрее-быстрее, а тесты и документация когда-нибудь потом. Соотвественно, если бизнес пришел необходимостью новой функциональности, которая нужна вчера, то допустимо релизить как только будет написан код, но на этом задача не закончится. Процесс написания тестов, рефакторинг того, что было только что написано, правка документации - начинается сразу же. Иначе, потом об этом все забудут.
Собственно одна из задач лида - понимать, что является проверкой гипотезы и не требует скурупулезного покрытия тестами и документирования, в какой момент проверка гипотезы становится частью продукта, чтобы выделить время на покрытие тестами, рефакторинг и документирование. И это надо все донести до бизнеса, чтобы он не третировал разработчиков в моменты написания тестов и документации, и до разработчиков. Так как кто может считать, что тесты нужны везде и всегда, а кто-то наоборот, так же с документацией.
На устранение технического долга лучше не время команды выделять, а отдельных людей, которые не будут брать никакие продуктовые задачи. Своего рода дежурные по тех долгу. И разработчиков ротировать периодически между этими ролями. Так будет проще контролировать, что время на устроение тех долга действительно выделяется. При этом в момент смены роли, если какая-то задача не была доделана, то разработчик, если у него роль поменялась, передает её другому, вине пытается доделать сам тратя на это не предусмотренное время. Это важно, должно быть четкое разграничение иначе легко откладывать исправление тех долга. Ну и должен быть план работ.
Ну и где старшие разработчики? Управление джуном, мидлом и сеньором требует разных подходов, то, что сеньор будет считать микроменеджментом со стороны лида, для джуна может быть необходимо. Если за сеньора будут выбирать технологии, архитектуру, говорить как и что делать - он уйдет, если так делать с мидлом, он может никогда не вырасти, а джун без этого может утонуть в задаче. У разработчика должна быть свобода действия и ответственность и чем выше роль, тем больше свободы и больше ответственности. Это позволит разжечь и не дать погаснуть тому самому огона в глазах, который так любят видеть у кандидатов. :) Хотя это вскользь упоминает, как то, что тимлид помогает в сложных задачах, но нюанс в том, что в случае со старшими разработчиками их компетенции и опыт могут быть выше чем у лида и лиду с этим тоже надо уметь работать.
А ну и ОБЯЗАТЕЛЬНЫЕ навыки лида - уметь признавать перед командой свои ошибки и слушать свою команду, меня процессы в соответствии с потребностями команды, даже, если это идет в разрез с представлением об идеальном процессе в голове лида. Он может пробовать привести к этому, но должен быть готов измерить это, если команде это будет мешать.
А ну и должны быть инструкции для дежурных - куда и на что смотреть, что делать. Чтобы даже вновь пришедший разработчик впервые заступивший на дежурство мог как минимум собрать всю необходимую информацию и предоставить её при эскалации инцидента выше. В идеале, справится с около типичными проблемами самостоятельно.
Идея с подключением новых разработчиков к документированию интересна, можете немного подробнее рассказать, как это организуется? Разработчик подключается к проекту и ему ставится задача разобраться в проекте, параллельно документируя? Такой фул-тайм техпис на первых порах, или подход должен быть какой-то другой?
Посадить писать документацию - это скорее исключительная ситуация. Где документация была и ведение её не возбранялось, то когда приходил новый разработчик ему документацию (какая есть) и задачу. Если в ходе задачи он находил проблемы с документацией, то правил её. Важнее, даже не то, чтобы он написал всю документацию прямо здесь и сейчас, а показать, что она есть, что мы владеем документацией и её можно и нужно править. Далеко не всем разработчикам нравится читать документацию, а писать документацию, нравится еще меньшему числу. А те, кто могут написать хорошую документацию, которую будет приятно читать - единицы. Так что как временного техписа использовать нового разработчика не стоит.
Так же очень важно определиться для кого документация. Если для разработчиков команды, то, по моему опыту, стоит ограничится диаграммами. Я сам в явном виде не использовал модель C4, но всё что мы делали, было похоже на этот подход. Этого достаточно, чтобы понять взаимосвязи в приложении. Плюс небольшое описание зачем продукт нужен. В таком виде, если уж документации не было, то лид может обрисовать с 1 по 2, частично 3 уровни, а более полно 3 и 4 уровни уже доделывать силами разработчиков. Т.е. он взял задачу, разобрался, что и как надо сделать и тут же внес необходимые правки в диаграммы.
Если документация для пользователя, то тут чуть проще, так как сами пользователи могут быть драйвером для документации заваливая команду вопросами. В этом случае разработчик просто вносит и дополняет документацию по мере работы над функциональностью. И в этом случае, если есть процесс ревью, надо так же проверять, что документация поменялась. Идеальный вариант, если документация пишется где-то рядом с кодом и потом экспортируется куда-то в общедоступное место. Тогда на ревью проще смотреть. Но можно вести и на вики, просто не забывать смотреть, что соответствующие изменения (черновик) были сделаны.
И опять же, надо помнить и быть готовым к тому, что документирование функциональности может занять сравнимое с разработкой время, а в некоторых случаях и большее время. Нормальная ситуация, что кода поправил 10 строчек, а поведение системы изменилось и документацию переписывал два дня. И новому разработчику это так же надо объяснить и показать, что команда в целом заинтересована в документации и считает это полезным, чтобы она смотрела на то, что опишет новый разработчик, если увидят неточности, то чтобы поправили. Ну и в целом, чтобы остальные разработчики так же писали документацию. Если это делать силами только новых разработчиков, то это больше похоже на дедовщину и мотивации им не добавит.
Ситуацию с написание документации на фуллтайм я встречал два раза, один раз мне такая задача ставилась, другой раз мой лид этим занимался. Ситуации объединяло, то, что в обоих случаях мы были единственными разработчиками на проекте и от которого был только код. И тут, написание документации - это способ понять как и что работает. Поэтому я и упомянул, выше, что на это скорее исключительная ситуация.
Как-то подытоживая. Вместе с задачей (как часть) ставить задачу на проверку/дополнение документации в объеме задачи. Условно задача касается двух компонент, по итогу выполнения на диаграмме должны появится эти компоненты с указанием с кем и как они взаимодействуют, какие данные пересылают. Если компонент с которыми они взаимодействуют еще на диаграмме нет, то добавить их без уточнения с кем эти компоненты еще взаимодействуют. И это должно делаться не только новыми разработчиками, иначе это убьёт мотивацию новых разработчиков. Ну и форма документации должна быть такой, чтобы прочие разработчики были готовы её читать.
Анимированные картинки с текстом - плохая идея. Отвлекают, плюс дошел до неё, она в этот момент показывается вся (ну вот так совпало), начал читать, а у картинки начался новый цикл повтора и то, что ты сейчас читал - исчезло. Брр…
Статью не читал а минус уже за это хочется поставить. Рекламный баннер, давайте еще какое нибуть "дерево вырубим" чтобы лучше видно было его.
На этот моменте я бросил читать статью. Вообще, подача материала в формате: 2 предложения, левая картинка, 2 предложения, левая картинка... - очень сильно выбешивает. Так, зачем-то, стали делать многие.
@Sprytin, почему просто не написать весь текст буквами? Достаточно выкинуть все смишные картинки и получилась бы нормальная статья. Пора уже на хабре изображения отключать по умолчанию, ничего ценного и полезного в них, в большинстве случаев, нет.
Имхо, красивая, но слабая статья. Сравнивается джун и лид в компании с 5-ю разрабами.
Не смог прочитать все из-за мыргающих отвлекающих внимание гифок. Это отвратительно.
Трансформируемся от разработчика до тимлида