Про ИТ-менеджмент

Постараемся сделать мир чуточку счастливее

Previous Entry Поделиться Next Entry
Какому проекту какая методология. Удачная модель
anton_nix

Раньше я часто сталкивался с вопросом: когда какую методологию использовать, какая лучше и т.д. Теперь, мне кажется, пришел к довольно удачной модели.

Основные факторы, влияющие на методологию

В статье Коберна “Каждому проекту своя методология” указаны следующие основные факторы:


  • Критичность продукта. Одно дело разрабатывать интернет-магазин и другое - ПО для АЭС.


  • Размер команды. Кол-во коммуникаций растёт квадратично, поэтому их часть начинает заменяться на формальные документированные.



Для нас, аутсорсеров, также очень важен фактор:


  • Доверие заказчика


Потому что недоверие обычно означает строгий контроль, фиксированный контакт и большие проблемы с оценкой, планированием и рисками.


Около года назад я стал выделять еще один фактор, который часто влияет больше всех остальных:


Жизненная стадия продукта

Именно стадия развития продукта, который разрабатывается. Моя скромная версия этих стадий:


  1. Concept


  2. Minimum Viable Product


  3. Active Improvement


  4. Maintenance



С точки зрения РМа, их удобно представить на картинке:

Какому проекту какая методология.jpg

Опишу каждую стадию, и какие методологии там оптимальны, с моей точки зрения.


Здесь самое главное - это отличать продукт от проекта. Эти вещи часто путают. Для компании-аутсорсера проект может начаться в любой стадии развития продукта - когда заказчик решил передать разработку на аутсорс, тогда и начинается. И от этой стадии, как раз, очень сильно зависит выбор методологии.


Concept


До этой стадии продукт не существовал. Его только что придумали, это ещё идея, и всё его описание занимает пару страниц текста. На этой стадии оценивается польза и затраты на разработку продукта и, в конце этой стадии принимается решение, стоит ли вообще начиать разработку.


На этой стадии проект еще редко называют проектом. Т.е. обычно точкой окончания этой стадии является некий документ, подписывающий создание команды разработки и выделение бюджета.


Minimum Viable Product


Главная цель этой стадии - создать первую версию продукта, которая выйдет в продакшн, которой будут пользоваться люди.


Кончается она, собственно, первым продакшн-релизом.


Эта стадия обычно самая тяжелая, т.к. она самая затратная, соответственно, с ней связаны самые большие риски: нужно за короткий срок сделать огромный объем работы по созданию рабочего красивого продукта.


Active Improvement


На этой стадии основные страсти уже улеглись, продукт работает, им кто-то пользуется, он уже начал приносить какие-то деньги. И нужно просто лпаномерно “молотить фичи”, допиливать продукт то там то сям, чтобы он обрастал всякими свистелками и перделками. Но основная бизнес-идея уже была закончена на прошлой стадии - MVP.


Т.к. продакт овнеру хочется увидеть, как оно полетит, и основной функционал закончен, то, как правило, здесь уже не нужна такая большая команда, как была в стадии MVP.


После этой стадии есть два варианта:


  1. Новый виток жизненного цикла.


  2. Maintenance.



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


Maintenance


Здесь продакт овнер решает, что что-то уже нечего больше особо доделывать в продукте и пора с него снимать основные сливки. Поэтому команда сокращается почти до нуля - чтобы просто исправлять ошибки и как-то поддерживать продакшн.

Каждой стадии - своя методология

Теперь рассмотрим как связаны эти стадии и методологии.

Concept & MVP


Как я писал выше, это самая критичная фаза. Продукт еще не приносит денег, а вложиться надо очень много. Риски очень высоки. Очень важно сделать точную оценку сроков и бюджета: когда мы выйдем в продакшн? Чтобы заказчик мог оценить, стоит ли овчинка выделки.


Классические гибкие методологии такие как скрам и экстремальное программирование здесь не работают, т.к. они не умеют планировать больше, чем на 1-2 итерации вперед.


А планировать нужно, ведь если не хватит денег чтобы вывести продукт в продакшн, то проект провален, а продукт умер.


Эта стадия должна бывают очень эффективной, очень важно экономить время, т.к. быстрее надо начать зарабатывать на продукте. И экономить деньги, т.к. если продукт не взлетит, а это случается часто, чтобы потери были минимальны.


На этой фазе заказчик часто очень хочет фиксированный контакт - т.к. он очень боится превышения сроков и бюджета.


Поэтому, на фазе MVP лучше использовать так называемые прогностические методологии - методологии, которые пытаются как можно быстрее понять, за какой срок и бюджет мы сделаем такой-то скоуп (и, кстати, какой именно скоуп). Я такую методологию хорошо знаю только одну: Rational Unified Process.


Она полностью сконцентрирована на том, чтобы быстрее спрогнозировать итоговую стоимость и сроки и вывести продукт в продакшн. Так что если вам достался проект по разработке продукта с нуля, скорее всего это ваш выбор.


Единственное известное мне исключение, это когда продукт разрабатывается по Lean Startup. Т.е. делается какой-то очень маленький продукт, быстро выводится в продакшн, получает обратную связь от пользователей, дальше опять инкремент, опять обратная связь и т.д. Но! Во-первых, чтобы разработать даже такую маленькую первую версию, как предполагается при лин стартап, нужно времени обычно намного больше чем один-два спринта. Во-вторых, далеко не все продукты можно разрабатывать по лин стартап, т.к. это должны быть продукты, нацеленные на уникальную нишу. У них должна быть какая-то уникальная бизнес-идея. Например, будет странно, если вы сделаете очередной текстовый редактор, основная фишка которого, это распознавание текста и рекомендации по вставляемым иллюстрациям-картинкам в соответствии с тематикой текста. Но при этом, как бы круто не работала эта фишка, если вы не сделаете остальные необходимые атрибуты современного редактора, такие как выбор шрифта, его цвета, размера, выравнивания, стиля, вставка таблиц, буллетовых и нумерованных списков и т.д., то ваш редактор никому особо не будет нужен.


Active Improvement


Здесь, когда у заказчика уже не одна большая идея, а куча маленьких, которые нашлёпываются сверху на готовый каркас, как раз очень хорошо работает скрам и другие чисто-итеративные методологии. Когда договариваемся только на одну итерацию, делаем, выпускаем, и опять по новой.


Maintenance


Здесь хорошо работает канбан или ITIL, которые ориентированы на сокращение времени поставки отдельных фич.


Выводы

Т.о. смотря на какой стадии вы получили продукт, или до какой стадии его довели, такую методологию лучше и применять.


Ну и влияют факторы, озвученные в начале статьи:


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

  2. Или если у вас очень критичный продукт, то его всегда надо будет разрабатывать очень внимательно с кучей артефактов и проверок проверку качества, как в RUP максимальной комплектации. Или если команда большая, то гибкие методологии тоже начинают сбоить и приходится придумывать как их масштабность, добавлять костыли.

Ну а как применяются конкретные методологии расскажу в другой раз.


  • 1
С тем, что в RUP заложены годные принципы спорить сложно.
Можно ли взять из методологии только то, что удобно и продолжать называть ее RUP - возможно, спорить не стану.

На счёт скрама - он вовсе не мой, года 4 назад ребята на AgileCamp в Новосибирске докладывали, что Scrum с оцененным backlog-ом (все еще "классический" scrum) - единственная (по их мнению) методология, гарантирующая, что команда уложится в бюджет и в срок при открытом scope-е.

Не уверен, что Reliable Scrum в те далекие времена уже существовал, хотя попытки статистического управления конечно были.

  • 1
?

Log in