Решение проблемы 20/80
Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий - лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, врыв сроков, низкое качество, беготня, стресс и прочие "удовольствия" менеджера проектов.
Частая ошибка - дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) - задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное - итерация должна быть сделана полностью и проверена.
Теперь по-порядку:
1) Все работы разбиваются на отдельные задачи. Когда проект разбит на задачи, можно организовать правильное управление этими задачами
2) Задачи объединяются в пакеты, объемом примерно на неделю (в зависимости от числа разработчиков размер пакета может варьироваться)
3) Главная фишка: задачи сдаются заказчику по частям (пакетами), каждую неделю - это позволяет еще в начале проекта понять многое важные вещи:
- Правильность оценки трудоемкости задач
- Адекватность и ответственность заказчика
- Насколько качественный результат выдает команда
4) Важно доводить решение задач до конца, т.к. выполненной можно считать только принятую заказчиком задачу, т.е. не просто передать пакет задач заказчику на приемку, а добиться чтобы заказчик принял работу (и соответственно, исправить баги)
Конечно, такой процесс сложнее организовать и это создает нагрузку на менеджера, но на самом деле, нагрузка нормируется и распределяется более равномерно и на менеджера проекта и на всю команду. В реальной работе ситуация, когда пакет задач передан заказчику и команда ждет ответа, вызвала бы простои. Поэтому, «итерации» должны идти с наложением, т.е.
- 1-я неделя - выполняем 1-й пакет работ и готовим (внутренние тестирование) к передаче Заказчику
- 2-я неделя - передаем 1-й пакет заказчику и выполняем 2-й пакет работ. Важно, чтобы исправление ошибок по 1-й итерации шло с наибольшим приоритетом
- 3-я неделя - закрываем 1-й пакет, исправляем ошибки по 2-му пакету, делаем 3-й пакет
Если к 4-й неделе все еще остались недоделанные задачи по 1-й и 2-й итерации, то нужно сосредоточить усилия на них и не брать в работу 4-ю итерацию.
Бонусы, которые мы получаем от такого подхода:
- Четкое понимание текущего состояния проекта и отклонение от планов, понимание, «что осталось сделать для сдачи этапа работ» (и получения оплаты)
- Понимание «баланса сил» - сколько задач на стороне исполнителя, а сколько на стороне заказчика
- Значительное уменьшение эффекта 20/80
- Снижение рисков в отношениях с заказчиком (сдача работ начинается в самом начале)
- Уменьшение количества новых требований и споров на их счет: разобрался в задаче, сделал, сдал
- Снижение себестоимости - исправлять ошибки в только что написанном коде значительно дешевле, чем по прошествии 3-х месяцев
- Наш подход вовсе не претендует на абсолютную истину и вообще, может быть, что он подходит только нам. Но возможно, эта статья будет кому-нибудь полезна. Также буду рад ответить на вопросы и обсудить другие решения «проблемы 2000», т.е. проблемы 20/80
Частая ошибка - дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) - задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное - итерация должна быть сделана полностью и проверена.
Теперь по-порядку:
1) Все работы разбиваются на отдельные задачи. Когда проект разбит на задачи, можно организовать правильное управление этими задачами
2) Задачи объединяются в пакеты, объемом примерно на неделю (в зависимости от числа разработчиков размер пакета может варьироваться)
3) Главная фишка: задачи сдаются заказчику по частям (пакетами), каждую неделю - это позволяет еще в начале проекта понять многое важные вещи:
- Правильность оценки трудоемкости задач
- Адекватность и ответственность заказчика
- Насколько качественный результат выдает команда
4) Важно доводить решение задач до конца, т.к. выполненной можно считать только принятую заказчиком задачу, т.е. не просто передать пакет задач заказчику на приемку, а добиться чтобы заказчик принял работу (и соответственно, исправить баги)
Конечно, такой процесс сложнее организовать и это создает нагрузку на менеджера, но на самом деле, нагрузка нормируется и распределяется более равномерно и на менеджера проекта и на всю команду. В реальной работе ситуация, когда пакет задач передан заказчику и команда ждет ответа, вызвала бы простои. Поэтому, «итерации» должны идти с наложением, т.е.
- 1-я неделя - выполняем 1-й пакет работ и готовим (внутренние тестирование) к передаче Заказчику
- 2-я неделя - передаем 1-й пакет заказчику и выполняем 2-й пакет работ. Важно, чтобы исправление ошибок по 1-й итерации шло с наибольшим приоритетом
- 3-я неделя - закрываем 1-й пакет, исправляем ошибки по 2-му пакету, делаем 3-й пакет
Если к 4-й неделе все еще остались недоделанные задачи по 1-й и 2-й итерации, то нужно сосредоточить усилия на них и не брать в работу 4-ю итерацию.
Бонусы, которые мы получаем от такого подхода:
- Четкое понимание текущего состояния проекта и отклонение от планов, понимание, «что осталось сделать для сдачи этапа работ» (и получения оплаты)
- Понимание «баланса сил» - сколько задач на стороне исполнителя, а сколько на стороне заказчика
- Значительное уменьшение эффекта 20/80
- Снижение рисков в отношениях с заказчиком (сдача работ начинается в самом начале)
- Уменьшение количества новых требований и споров на их счет: разобрался в задаче, сделал, сдал
- Снижение себестоимости - исправлять ошибки в только что написанном коде значительно дешевле, чем по прошествии 3-х месяцев
- Наш подход вовсе не претендует на абсолютную истину и вообще, может быть, что он подходит только нам. Но возможно, эта статья будет кому-нибудь полезна. Также буду рад ответить на вопросы и обсудить другие решения «проблемы 2000», т.е. проблемы 20/80