Управление разработкой
Управление командой разработки: как договориться
Разработку редко срывает техника. Срывает то, что о проблеме узнают в день дедлайна, хотя знали о ней за три недели.
Что ломается в управлении разработкой
Оценки даются под давлением и потому оптимистичны. О рисках говорят на языке «постараемся», а не «не успеем без ещё одного человека». В итоге плохие новости всплывают, когда сделать уже ничего нельзя.
Вторая частая поломка — непонятно, кто принимает решение при конфликте архитектуры и срока. Пока это не названо, спор идёт по кругу и съедает недели. Клуб не внедряет проектное управление и не консультирует по методологиям: наш продукт — недельная морская программа для команды, а не консалтинг.
Как выстроить работу
- 01
Назовите, кто принимает решение по срокам, объёму и архитектуре.
- 02
Договоритесь, как даются оценки: диапазон и условия, а не одна дата.
- 03
Договоритесь, на каком этапе разработчик обязан поднять флаг: не в день дедлайна, а когда задача перестала укладываться в оценку.
- 04
Разделите обсуждение проблемы и поиск виноватого — это разные встречи.
- 05
Регулярно разбирайте завершённые задачи, а не только провалы.
- 06
Проверьте, что тимлид умеет вести такой разговор, и научите, если нет.
Что должно быть в команде
- владелец решения по сроку и объёму
- формат оценок с условиями
- порог, при котором задача выносится на обсуждение
- регулярный разбор
- подготовка тимлида
- что делаем при срыве
Частые вопросы
Что даёт команде разработки выезд?
Общую работу, где решение и его последствие видны в течение часа. В самой разработке результат кода виден через недели, поэтому обратная связь приходит с задержкой.
Как давать оценки, чтобы им можно было верить?
Диапазоном с условиями: «две недели, если API готов; четыре, если пишем свой». Одна дата без условий — не оценка, а обещание.
Кто решает при конфликте архитектуры и срока?
Решение закрепляют за одним человеком до начала спора. Пока владелец не назван, обсуждение идёт по кругу и съедает недели.
Что делать с разбором завершённых задач?
Разбирать не только провалы. Успешная задача показывает, что именно сработало, — иначе команда учится только на катастрофах.
Обсудить программу для команды разработки
Расскажите про состав команды и то, что чаще всего срывает сроки.
Читайте также
- Смета мероприятия: как разложить и сравнить
Смета мероприятия: как разложить расходы на работу организатора, площадку и участника и привести предложения подрядчиков к одному виду.
- Вовлечённость сотрудников: что влияет и как повысить
Вовлечённость сотрудников: что на неё влияет, как её измеряют опросом и что меняет руководитель. Почему опрос без последующих решений снижает доверие.
- Делегирование полномочий: как передать и не забрать
Делегирование полномочий: чем оно отличается от поручения, как передать ответственность, какие границы задать и почему руководитель забирает задачу обратно.