?

Log in

Решение проблемы 20/80 - Денис Митрофанов
July 28th, 2010
07:57 pm

[Link]

Previous Entry Share Next Entry
Решение проблемы 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

(5 comments | Leave a comment)

Comments
 
From:ex_svinonra
Date:July 29th, 2010 05:41 pm (UTC)
(Link)
иногда сложно разбить задачу на итерации (я так это называю)... т.е. проверить её работу можно только в комплексе. да... отдельные модули можно протестировать, но отдать их на тестирование заказчику - невозможно. как тогда поступать?
[User Picture]
From:dmitrofanov
Date:July 30th, 2010 08:17 am (UTC)
(Link)
Ну конечно, могут быть исключения, если 10% задач в проекте будут занимать не 1, а 2 недели, это не мешает общей концепции.
Вообще, практика всегда отличается от теории, вопрос только в том, насколько.

Давайте обсудим на конкретном примере, какую задачу нельзя разделить на части, размером в неделю?

Вообще, под 1 задачей мы понимаем 1 бизнес-функцию, включающую в себя все этапы ее реализации: проектирование, дизайн, программирование, верстку, тестирование.

Например, лента новостей, список товаров, товар детально (карточка товара), корзина, оформление заказа и т.д.
From:ex_svinonra
Date:July 30th, 2010 08:21 am (UTC)
(Link)
например задача "рассчёт зп". для предпиятия у которого 100 филиалов.
или сейчас я работаю над "улучшение логистики". задача вообще размыта,ибо смогли только наметить далёкие цели:
- построить справочник гео-данных (вот как раз за неделю заканчиваю, но сам по себе он не интересен заказчику и не нужен)
- пракладывание оптимального маршрута (тут всё получилось по вашей схеме.. где-то неделю и ещё недели две "допиливание", так длительно по причине больших таймаутов отклика от заказчика)
- рассчёт нагрузок на автопарк (определение необходимых машин, их количества, выставление приоритетов распределения автомобилей по зонам)

вот задача одна... но разбив её на подзадачи (это можно, не спорю) мы не можем отдать на тестирование полноценное заказчику. даже в первом приближении...
[User Picture]
From:dmitrofanov
Date:July 30th, 2010 09:03 am (UTC)
(Link)
Все-таки не соглашусь, Вы приводите примеры скорее не задач, а целых проектов (или подпроектов). Заметьте, я не говорю, что 1 задача (по нашей методике) нужна заказчику сама по себе. Например, "корзина" в интернет-магазине не нужна без каталога товаров и оформления заказа, но ее можно протестировать.
From:ex_svinonra
Date:July 30th, 2010 09:10 am (UTC)
(Link)
возможно... наверное меня ввело в заблуждение "задача"
My Website Powered by LiveJournal.com