Есть обширные руководства по управлению разработкой. Но, как оказалось, там не всегда есть прямой ответ на те вопросы, которые возникают по управлению разработкой на практике. В этой статье на основе того, что попадалось мне, ответим на такие вопросы:

• Как должна быть организована коммуникация с разработчиками?
• Что необходимо для наиболее продуктивной работы разработчиков?
• Что делать с системной ошибкой оценки разработки?

Коммуникация с разработчиками

Коммуникация может быть поделена на 2 вида:

• Оценка планового срока разработки
• Уточнение деталей по конкретной задаче

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

• Оценка каждого разработчика – тут получаем случайные величины
• Оценка бизнес-аналитика – аналогично

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

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

Условия продуктивной работы разработчиков

Если разработку представить, в идеальном случае, как ритмичный конвейер, то для его чёткой работы необходимы:

• Команда
• Постановка задачи
• Минимум совещаний

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

Постановка задачи означает чёткое описание того, что должно быть сделано, но при этом без деталей реализации, которые должен продумать сам разработчик. В целом внедрение качественной постановки задачи – отдельная история, которая предполагает:

• Обучение бизнес-аналитиков
• Обсуждение проблем с постановкой задач вместе с разработчиками
• Разработку и внедрение шаблонов для разных видов задач, повторное использование успешных примеров

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

• Ограничения по срокам (которые кто-то установил и свалил)
• Юридические или налоговые ограничения решения; задача аналитика – перевести их в технические ограничения задачи
• Подробности организации внедрения: как обучают пользователей и т.п.

Иногда кажется, что если "все будут знать всё", то будет как-то легче. В моей практике "все будут смотреть за всеми" не работает, должно быть разделение не только труда, но и ответственности за разные части проекта.

Что делать с системной ошибкой оценки разработки

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

• Оценку разработки нельзя показывать заказчику
• Оценку для заказчика нельзя показывать разработке
• В целом оценка, скорректированная на ошибку – это всё равно "впритык", поэтому хорошая практика – прибавлять ещё 20%

Хуже системной ошибки может быть несистемная (кто-то употребляет наркотики?). Но хуже несистемной может быть только отсутствие данных об ошибках, тогда вместо обсуждения фактов обсуждаем оценки и мнения. "Я считаю, что разработка делает всё вовремя", "А я считаю, что не вовремя". Пожалуйста, не делайте этого, поставьте систему учёта план-факта.