6. Делать оценки в «Зоне невероятности»

Здесь нужно пояснить, что же подразумевается под зоной невероятности. Для произвольного проекта представим вот такой диалог (прим. сильно сокращён): — Смогут ли 12 разработчиков закончить Проект за 10 месяцев? — Да, может быть — отвечаем мы. — А 15 разработчиков за 8 месяцев? — Ну да, — отвечаем мы — скорее да, чем нет. — А 30 за 4? — Вряд ли — становится очевидно, что 30 человек, скорее всего, не смогут сработаться за такой короткий срок. — 60 за 2 месяца? — Ну это уже смешно!, — ответите вы… — А 120 разработчиков за 1 месяц? — Ну а это вообще не смешно. Издевательство просто… Из этого диалога видно, что «сжатие» сроков при заданной трудоёмкости не может происходить бесконечно — есть предел. Так вот идея данного пункта состоит в том, чтобы не производить оценок за этим пределом. Такие оценки не могут быть состоятельными. Предел «на сжатие», по мнению Стива, находится где-то около 25% от номинальных оценок.

7. Переоценивать выгоду от новых методов и технологий

Использование новых технологий сопряжено с:

• затратами на обучение

• рисками, связанными с использованием непроверенной технологии

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

Личная рекомендация Стива: «Считать, что использование новой технологии в первый раз снизит продуктивность разработки». И снова тезис: «Нет серебряной пули».

8. Использовать только один метод оценки трудоёмкости

В этом пункте автор предостерегает от двух вещей:

• от использования только одной методики оценки

• от усреднения значений, полученных разными методиками

При использовании разных методик важно понять, почему возникли различия.

9. Пренебрегать специализированным по для оценки трудоёмкости

Моделирование при помощи компьютерных программ может повысить адекватность оценок. Естественно, использование специальных средств не гарантирует вам надёжность и адекватность оценок. Но при умелом использовании может заметно повысить их точность. Одно из главных достоинств специального ПО в том, что результаты выглядят более убедительно для «потребителей» оценок.

10. Давать поспешные оценки

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

Заключение

Я не буду пытаться убедить вас в истинности всех тех утверждений, которые делает Стив. Вы вольны полагаться на свои знания и опыт. Стив — человек с огромными знаниями и опытом, но он человек, а людям свойственно ошибаться. Если вы считаете, что где-то он не прав, то отпишитесь, пожалуйста, об этом в комментариях — будет очень интересно обсудить.

Что делать, чтобы проекты не занимали в 2-3 раза дольше, чем планируется? Часть 1

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

• Грамотно обрабатывайте запросы на изменение требований

• Урезайте лишний функционал

• Управляйте рисками

• Используйте гибкие методологии

• Научитесь управлять Death March проектами

Грамотно обрабатывайте запросы на изменение требований

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

Урезайте лишний функционал

Очень важным фактором успеха реализации проекта является приоритезация функционала и разработка в первую очередь самый важный функционал, который принесет больше денег и/или будет наиболее полезен пользователям. Также необходимо функционал, который не будет использоваться — удалить из продукта. Посмотрите на продукцию компании Apple, посмотрите на продукты компании 37signals, и вы поймете, о чем я говорю.

Управляйте рисками

Для завершения проекта в срок надо осознанно управлять рисками. Управление рисками может носить тяжеловесный характер.

Используйте гибкие методологии

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

Научитесь управлять Death March проектами

Есть проекты, которые фактически заранее обречены на провал, поэтому их по меткому выражению Эдварда Йордана стали называть Death March проекты. Управление ими отличается от стандартных проектов, поэтому эту специфику надо знать и учитывать:

Что делать, чтобы проекты не занимали в 2-3 раза дольше, чем планируется? Часть 2

Д авайте продолжим обсуждение инструментов и методов по соблюдению сроков проектов, учитывая что предыдущий топик вызвал достаточно активную дискуссию и более двухсот человек добавили топик себе в избранное. На этот раз пост будет более унылым, постараюсь дать более подробные рекомендации в текстовом виде. Следующий набор рекомендаций выглядит так:

• Убедитесь, что срок действительно жесткий

• Не берите на себя проекты с нереальными сроками

• Планируйте методом «набегающей волны»

• Периодически пересматривайте оценку проекта

• Оценивайте проект эмпирически

• Привлекайте к первоначальной оценке команду

Убедитесь, что срок действительно жесткий

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

Не берите на себя проекты с нереальными сроками

Еще одним антипаттерном является взятие командой на себя обязательств по реализации проекта с нереальным сроком, причем часто это понятно до старта проекта. Проблема заключается в том, что команда рассматривает такое вынужденное взятие проекта как приказ «сверху» и ответственность за сроки остается только формальная. По неудачному завершению проекта команда скажет: «Мы же вас заранее предупреждали, что сроки выдержать не возможно». Обычно самым верным решением для такого типа проектов, является резкое сокращению объема реализуемого функционала для первого релиза.

Планируйте методом «набегающей волны»

Для больших проектов очень важно иметь грамотный и реальный план работ. Давайте возьмем пример с картой, по которой Михаэль Вольф строил план. Она фактически на всём протяжении была одного масштаба и из-за этого начались проблемы в самом начале проекта. Правильным методом в данном случае было бы планирование «набегающей волной» (Rolling Wave Planning): для первого участка, который мы собираемся пройти мы делаем более подробный план, используем карту с большим масштабом, смотрим фотографии местности, а участки, которые мы пройдем позже — рассматриваем на карте с небольшим масштабом. Для проектной деятельности в рамках PMBoK такой подход означает более подробную декомпозицию работ в ИСР для первых этапов реализации проекта. В гибких методологиях применяет такой же подход: мы храним элементы беклога с высокой важностью, разбитыми на небольшие «кусочки», а элементы беклога с низкой важностью храним в виде больших эпиков. Т.е. у команды есть подробный беклог на один-два спринта вперед. С другой стороны то, что мы не расписываем весь функционал проекта позволяет нам избежать Big Upfront Design подхода и долго запуска разработки, не говоря уже про то, что достаточно большая часть требований (макетов дизайна и т.д.) просто «протухнет», когда до нее дойдет очередь.

Периодически пересматривайте оценку проекта

При использовании водопадного подхода необходимо пересматривать оценку сроков завершения в конце каждого этапа работ, а если используется метод критической цепи такую оценку можно делать более оперативно с помощью буфера проекта. В итеративных методологиях такую переоценку рекомендуется делать по завершении очередной итерации. Дело в том, что оценки сделанные на ранней стадии проекта, как правило содержат очень большое количество неопределенности. Со временем эта неопределенность уточняется (часть рисков снимается) и оценку можно дать более точной. Классической иллюстрацией к вышесказанному является «конус неопределенности»:

Оценивайте проект эмпирически

Оценка на основе скорости работы команда является достаточно точной, поэтому ее стоит использовать во всех проектах, где это возможно. Запустите несколько спринтов и определите, сколько функционала (например, в сторипоинтах) ваша команда делает и посчитайте общий срок завершения проекта. Такое планирование основанное на фактах позволяет получить достаточно точные оценки.

Привлекайте к первоначальной оценке команду

Достаточно часто приходится оценивать проекты на очень ранней стадии. Как было сказано выше такая оценка не имеет ничего общего с действительностью не очень точна. Повысить точность можно, привлекая к оценке команду (либо ее ядро) с самой ранней стадии проекта, дополнительно команда будет разделять ответственность за указанные сроки.