В мире вредных советов Workflow препятствует успеху проекта, а делегирование ответственности ни к чему хорошему не приводит. И, между прочим, только TeamLead или Project Manager должны знать всю информацию о ходе проекта, а остальным в команде это не нужно…
Рассказываем, что делать, чтобы все полетело в тартарары 🙃

🔺1. Не выстраивайте workflow

Разработчики сами разберутся, как нужно работать, а в статусе ваших тасков появится еще одна характеристика: «хаос». На выяснение деталей участники команды потратят дополнительное время, которое могли бы потратить на выполнение задач на проекте.

✅Благодаря workflow команда работает более эффективно, так как все специалисты находятся в одном информационном поле и понимают текущее состояние реализации каждой фичи. С его помощью просто и быстро обнаруживается, на каком этапе «застрял» процесс, а также сокращаются временные лаги между блоками работы.

🔺2. Не проводите планирование спринтов с командой

Участникам команды совершенно не нужно понимать цель и сроки очередной итерации. Пусть каждый реализует задачи на свое усмотрение. Вы же хотите, чтобы конечный результат вас удивил.

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

🔺3. Перенагружайте команду

Выгорать нельзя отдыхать. Поставьте запятую после первого слова – и в течение проекта вас будут сопровождать безынициативность и непродуктивность.

✅ Когда специалисты могут выполнить свои задачи в срок, при этом не выходя за рамки 8-часового рабочего дня, у них остается достаточно свободного времени для отдыха и восстановления. Такой баланс даст им возможность не просто быть исполнителями, но творчески подходить к вопросам, например, предлагать идеи по реализации задач.

🔺4. Не назначайте ответственных и не делегируйте

Зачем руководителю развивать сотрудников, формировать их ответственность и создавать себе подушку безопасности, когда можно все взвалить на себя. После десятого выгорания его организм точно выработает иммунитет (спойлер: нет).

Концентрирование обязанностей на одном человеке приведет к тому, что снизится вовлеченность всех участников, и они не будут ощущать свою значимость. Если TeamLead временно не сможет выполнять свои функции, например, из-за болезни или командировки, никто не заменит его. В итоге возрастет риск приостановки проекта.

✅Делегирование позволяет расширять компетенцию команды и формировать ответственность каждого участника за результаты, а руководителю – сохранять продуктивность и work-life balance.

🔺5. Сконцентрируйте весь набор знаний в голове одного или двух разработчиков

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

Когда на проекте всего несколько хранителей знаний, опасное значение принимает bus factor («фактор автобуса»). Так называют количество членов вашей команды, при постоянном отсутствии которых работа попадет в кризисное положение ☹️ Чем показатель выше, тем лучше: от 3-5 и более, в зависимости от команды. Если все знания сосредоточены на одном специалисте, он равен единице. В таком случае к катастрофе может привести любой больничный этого сотрудника или его незапланированный отпуск.

✅Нужно заранее подумать о том, как обеспечить циркуляцию знаний внутри команды, назначить ответственных, распределить сложные задачи между разными разработчиками. Разбор затруднительных моментов проекта лучше проводить вместе со всеми участников. Тогда «супермены» команды смогут в доступной форме задокументировать информацию о реализованных ими решениях и подсказать лучший выход в тех или иных условиях.