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

Суть проста. Во всех мифологиях, всех религиях, сколько найти, и в основе любой истории лежит один и тот же мотив. Разбиваете кусок функциональности на блоки. Например:

1. Хливкие шорьки
2. Хрюкотающие зелюки
3. Мюмзики в мове
4. Бармаглота сын
5. Злопастный Брандашмыг

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

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

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

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

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

И только после этого вы садитесь расписывать требования ко второму пункту или пункту, ставшему вторым. Этот подход здорово экономит время на анализ и проектирование, минимизируя объём требований, выкинутых в мусорку.

Вы наверняка замечали, что в программах для рисования календарных планов есть несколько видов связей, хотя почти всегда используется End-to-Start. Да, в правильно спланированных проектах таких связей должно быть большинство.

Также должен сказать, что существует четыре вида задач:

• Атомарная задача
• Агрегационная задача
• Веха
• Гамак

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

Вот четыре задачи, связанные End-to-Start, в рамках которых проводятся некие работы:

А теперь представьте, что существует работа, которая должна проводиться всё время, пока проводятся задачи 2 и 3. Например, если в рамках этих задач проводятся работы по проведению публичного мероприятия, нам нужно дополнительной задачей обеспечить охрану и эта охрана должна работать ровно столько, сколько продолжаются мероприятия. Эту работу обязательно нужно включить в план, так как она требует трудовых ресурсов (время охранников).

Это делается так:

Задача 2 соединяется с задачей-гамаком связью Start-to-Start, задача 3 — связью End-to-End. Главное — не забудьте стереть у задачи-гамака оценку, иначе она будет отображаться неправильно.

Вот для таких случаев разработчики прожектовского софта и запасли для нас экзотические типы связей. Для скриншотов использовал Merlin Project.

Эта статья может быть полезна начинающим PM-ам.

Снизу вверх

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

Недостатки метода в том, что он не работает, когда нет чёткого ТЗ и в том, что он относительно медленный.

Сверху вниз

Этот метод мной применяется чуть реже. Он работает, когда бюджет уже известен. Заказчик, к примеру, готов выделить на проект от 2 до 2,5 миллионов рублей и не более полугода срока. И тут уже исходя из этой суммы нужно определить доли, сколько каким специалистам уйдёт и какие работы мы в рамках данного бюжета можем сделать.

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

Оценка по аналогам

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

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

Параметрическая оценка

Усложнённый вариант оценки по аналогам. Например, если мы говорим о вёрстке, вы можете по опыту предыдущих проектов понять, что, например, блок обратной связи ваш верстальщик делает за 3 часа, а классический слайдер с кружочками и стрелками по бокам — за 4 часа. Таким образом, можно рассчитать стоимость достаточно быстро и точнее, чем при оценке по аналогам.

Чаще всего параметрическая оценка применяется не в айти, а в ремонтно-строительном деле или бытовых услугах. Например, компания может заявить стоимость мытья полов в квартире, равной 50 рублей за квадратный метр и делать оценку, исходя из количества квадратных метров.

Анализ предложений

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

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

Экспертная оценка

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

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

— Как съесть слона, используя только нож и вилку?
— По кусочку.

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

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

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

Давайте разберём контрольный пример.

Бизнес-проблема: «Для того, чтобы более эффективно продвигать и продавать наш товар (одуванчиковый лимонад), мы хотим онлайн-каталог».

Результат предварительного сбора требований:

На сайте должны быть разделы:

1. Главная страница
2. О компании
3. Каталог
4. Оплата и доставка
5. Контакты

Ключевой момент — заказчику не понадобится оформление заказа с сайта. Только онлайн-каталог и форма отправки заявки.
 
 
Хорошо. Составляем крупноуровневый план работ:

1. Разработать и согласовать концепт дизайна контентных страниц.
2. Изготовить Главную страницу.
3. Изготовить Каталог.
4. Изготовить прочие контентные страницы.

 
 
В ходе первой итерации мы будем делать концепт дизайна, а затем — Главную страницу.

Ключевой момент — на первом этапе детализируем только требования к дизайну и главной странице. Остальные пункты плана для нас как бы в тумане. Мы знаем их состав и очень примерно — какими они должны быть. Пока не нужно об этом думать — после того, как сдадим Главную страницу, желания заказчика могут смениться на диаметрально противоположные.

Итак, на первом этапе готовим для согласования документ, содержащий:

1. Детализированные требования к дизайну: корпоративные цвета, количество колонок, общий вид вёрстки блоков, шрифты, стиль иллюстраций.
2. Детализированные требования к главной странице (обязательно с wireframes), состав блоков, назначение каждого блока, порядок следования и проч.

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

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

Предположим, первая итерация прошла удачно. Дизайн понравился, главная страница свёрстана грамотно, замечаний немного или нет вовсе. Наши дальнейшие действия — в первую очередь, актуализация плана. Не устарели ли требования? Если всё нормально, переходим к детализации требований на вторую итерацию, иначе корректируем, пересогласовываем, переоцениваем.
 
 
Резюме:

1. Разбиваем функционал на блоки.
2. Составляем общий план.
3. Детализируем требования только к тому блоку, который пойдёт в работу в ближайшую итерацию, остальные блоки описываем на уровне возможностей.

 
 
Такой подход делает разработку предсказуемой и минимизирует риски.

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

В США продолжительное время один пациент из пяти тысяч прооперированных умирал из-за ошибки анестезиолога. Внедрение карт контрольных проверок в сочетании со стандартизацией интерфейса оборудования и сглаживанием градиента авторитета (объяснение медсёстрам, что доктор не всемогущ и если они видят ошибку, они обязаны о ней сообщить) привело к снижению смертности до одного пациента на 200-300 тысяч прооперированных (снижение смертности в сорок раз).

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

Автор работает в организации, в которой менеджер продукта выполняет не столько функции специалиста по развитию, сколько именно организационную работу и обеспечивает качество всего итеративного процесса. Выяснилось, что без карты контрольных проверок слишком легко упустить одно из мероприятий и навредить срокам выпуска версии → разозлить заказчиков, ожидающих выпуск функционала к определённой дате.

Был разработан и внедрён протокол планирования итераций, содержащий перечень мероприятий, даты, отметки о выполнении, а также фамилии сотрудников, ответственных за каждый этап. В качестве инструмента был выбран OneNote. К сожалению, протоколы проведённых итераций содержат конфиденциальную информацию, поэтому приведённый пример будет гипотетическим.

Таким образом, процесс состоит из:

1. планирования работ
2. написания требований к доработкам
3. демо требований
4. старта разработки
5. кодфриза разработки
6. регрессионного тестирования
7. съёмки ролика о новом функционале
8. передачи билда на поддержку.

 
 
Каждый из этапов состоит из группы действий, которые нужно не забыть провести. Некоторые действия (такие, как «Бэклог оформлен в TFS») являются сложными и сами состоят из групп действий, описанных в протоколах нижнего уровня.

Ответственный в данном случае — сотрудник, имеющий полномочия о принятии решения об успешном прохождении этапа. Как видно из примера, за все действия до кодфриза отвечает менеджер продукта Бычко, за выход на кодфриз — тимлид Ригельман, организацию и проведение регрессионного тестирования — глава QA Бунг и, наконец, за съёмки ролика и передачу на поддержку — глава управления продуктом Гольдштейн.

Ниже данной таблицы в протоколе располагается детализированная информация о проведении каждого из этапов. Расшаривание через OneDrive и соответствующие права доступа позволяют ответственным лицам «расписаться» о проведении этапа.

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