— Как съесть слона, используя только нож и вилку?
— По кусочку.
Проведение больших доработок качественно отличается от мелких. Заказчик хочет здоровенный и очень сложный кусок функционала (будем называть его продуктом). Как не облажаться?
Если собрать требования ко всему продукту, сформулировать техзадание, потратить массу времени на реализацию, при сдаче выяснится, что заказчик хотел совершенно не это и нужно потратить ещё столько же времени на переделку. Разработчик и аналитик теряют впустую много времени, очевидный риск.
Если собрать требования ко всему продукту, сформулировать техзадание, разбить функционал на законченные куски, относительно быстро сделать и сдать первый, при сдаче выяснится, что требования к остальным кускам продукта существенно меняются. Это нормально — заказчик, увидев фрагмент продукта сразу начинает воспринимать его совсем иначе по сравнению с тем, что ранее было у него лишь в голове. Аналитик потратил впустую много времени, очевидный риск.
Избежать этих ключевых ошибок возможно, если использовать при написании требований вариацию на тему «метода прогрессивного джипега».
Давайте разберём контрольный пример.
Бизнес-проблема: «Для того, чтобы более эффективно продвигать и продавать наш товар (одуванчиковый лимонад), мы хотим онлайн-каталог».
Результат предварительного сбора требований:
На сайте должны быть разделы:
- Главная страница
- О компании
- Каталог
- Оплата и доставка
- Контакты
Ключевой момент — заказчику не понадобится оформление заказа с сайта. Только онлайн-каталог и форма отправки заявки.
Хорошо. Составляем крупноуровневый план работ:
- Разработать и согласовать концепт дизайна контентных страниц.
- Изготовить Главную страницу.
- Изготовить Каталог.
- Изготовить прочие контентные страницы.
В ходе первой итерации мы будем делать концепт дизайна, а затем — Главную страницу.
Ключевой момент — на первом этапе детализируем только требования к дизайну и главной странице. Остальные пункты плана для нас как бы в тумане. Мы знаем их состав и очень примерно — какими они должны быть. Пока не нужно об этом думать — после того, как сдадим Главную страницу, желания заказчика могут смениться на диаметрально противоположные.
Итак, на первом этапе готовим для согласования документ, содержащий:
- Детализированные требования к дизайну: корпоративные цвета, количество колонок, общий вид вёрстки блоков, шрифты, стиль иллюстраций.
- Детализированные требования к главной странице (обязательно с wireframes), состав блоков, назначение каждого блока, порядок следования и проч.
Для остальных кусков функционала пишем требования на уровне возможностей: «Каталог позволяет просматривать карточки товаров с возможностью фильтрации, карточки содержат описания товаров и форму обратной связи». Такой детализации пока вполне достаточно.
Есть ли риски в данном случае? Увы, есть. После сдачи первой итерации требования могут измениться настолько принципиально, что результат первой итерации придётся переделать полностью. К сожалению, с этим можно бороться только уменьшением количества требований на итерацию до минимально возможного. Правда, в этом случае возрастают расходы на тестирование (короче итерации — больше регрессионных тестов в единицу времени).
Предположим, первая итерация прошла удачно. Дизайн понравился, главная страница свёрстана грамотно, замечаний немного или нет вовсе. Наши дальнейшие действия — в первую очередь, актуализация плана. Не устарели ли требования? Если всё нормально, переходим к детализации требований на вторую итерацию, иначе корректируем, пересогласовываем, переоцениваем.
Резюме:
- Разбиваем функционал на блоки.
- Составляем общий план.
- Детализируем требования только к тому блоку, который пойдёт в работу в ближайшую итерацию, остальные блоки описываем на уровне возможностей.
Такой подход делает разработку предсказуемой и минимизирует риски.
