Как стать автором
Обновить
0

Возможный способ обойти правило Парето

Время на прочтение 3 мин
Количество просмотров 3.1K
Всем привет,
Предлагаю обсудить одно из возможных решений проблемы 20/80, реально используемое в нашей компании.


Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, срыв сроков, низкое качество, беготня, стресс и прочие удовольствия PM'a.

Частая ошибка – дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) — задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное — итерация должна быть сделана полностью и проверена.

Теперь по-порядку:
  1. Все работы разбиваются на отдельные задачи. Когда проект разбит на задачи, можно организовать правильное управление этими задачами
  2. Задачи объединяются в пакеты, объемом примерно на неделю (в зависимости от числа разработчиков размер пакета может варьироваться)
  3. Главная фишка: задачи сдаются заказчику по частям (пакетами), каждую неделю — это позволяет еще в начале проекта понять многое важные вещи:
    — Правильность оценки трудоемкости задач
    — Адекватность и ответственность заказчика
    — Насколько качественный результат выдает команда
  4. Важно доводить решение задач до конца, т.к. выполненной можно считать только принятую заказчиком задачу, т.е. не просто передать пакет задач заказчику на приемку, а добится чтобы заказчик принял работу (и соответственно, исправить баги)

Конечно, такой процесс сложнее организовать и кажется что это создает дополнительную нагрузку на менеджера, но на самом деле, нагрузка нормируется и распределяется более равномерно и на менеджера проекта и на всю команду. В реальной работе ситуация, когда пакет задач передан заказчику и команда ждет ответа, вызвала бы простои. Поэтому, «итерации» должны идти с наложeнием, т.е.
  • 1-я неделя – выполняем 1-й пакет работ и готовим (внутренние тестирование) к передаче Заказчику
  • 2-я неделя – передаем 1-й пакет заказчику и выполняем 2-й пакет работ. Важно, чтобы исправление ошибок по 1-й итерации шло с наибольшим приоритетом
  • 3-я неделя – закрываем 1-й пакет, исправляем ошибки по 2-му пакету, делаем 3-й пакет

Если к 4-й неделе все еще остались недоделанные задачи по 1-й и 2-й итерации, то нужно сосредоточить усилия на них и не брать в работу 4-ю итерацию.

Бонусы, которые мы получаем от такого подхода:
  • Четкое понимание текущего состояния проекта и отклонение от планов, понимание, «что осталось сделать для сдачи этапа работ» (и получения оплаты)
  • Понимание «баланса сил» — сколько задач на стороне исполнителя, а сколько на стороне заказчика
  • Значительное уменьшение эффекта 20/80
  • Снижение рисков в отношениях с заказчиком (сдача работ начинается в самом начале)
  • Уменьшение количества новых требований и споров на их счет: разобрался в задаче, сделал, сдал
  • Снижение себестоимости — исправлять ошибки в только что написанном коде значительно дешевле, чем по прошествии 3-х месяцев
Наш подход вовсе не претендует на абсолютную истину и вообще, может быть, что он подходит только нам. Но возможно, эта статья будет кому-нибудь полезна. Также буду рад ответить на вопросы и обсудить другие решения проблемы 20/80
Теги:
Хабы:
+5
Комментарии 6
Комментарии Комментарии 6

Публикации

Информация

Сайт
www.qsoft.ru
Дата регистрации
Дата основания
2004
Численность
31–50 человек
Местоположение
Россия

Истории