ГЛАВА 18

Формирование требований к продукту проекта

Все вещи создаются дважды. Первый раз ментально, второй раз — физически. Ключ к креативности в том, чтобы начинать работу, зная заранее результат, который хочешь получить.

Стивен Кови

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

Механизм обязательно отрабатывается на этапе подготовки, но может быть запущен и несколько раз в ходе проекта — при появлении новых заинтересованных сторон, новых результатов или каких-то других изменений.

Казалось бы, достаточно очевидно. Но очень часто этот механизм срабатывает… плохо. Давайте рассмотрим курьезный случай.

Французская государственная железнодорожная компания SNCF и оператор железнодорожной сети RFF купили за 15 млрд евро у Alstom и Bombardier 341 пассажирский поезд (более двух тысяч вагонов), которые оказались слишком широкими для платформ железнодорожных станций в регионах Франции, как сообщила газета Le Monde.

Новые поезда были на 20 сантиметров шире, чем того требуют платформы на многих станциях в регионах Франции. На переделку 1300 платформ, края которых расположены близко к рельсам и не рассчитаны на габариты новых вагонов, потребуется не менее 50 млн евро. Французский министр транспорта Фредерик Кювилье назвал ситуацию трагикомической, а железнодорожную систему страны — бестолковой. По его словам, подобное происходит, когда железнодорожная компания отделена от компании, эксплуатирующей пути. Эти функции были разделены между SNCF и RFF несколько лет назад по требованию законодательства Евросоюза.

История довольно забавная. Но что уж там, всякое бывает.

Мне нравится цитата одного из наиболее авторитетных теоретиков государственного управления — Томаса Гоббса: «Систему характеризует не ошибка, а реакция на ошибку».

Ситуацию делает феерической то, что не было извлечено никаких уроков. Через год появилась свежая информация. SNCF получила новые поезда у канадской Bombardier, но не может начать ими пользоваться из-за того, что они на несколько миллиметров выше, чем нужно. В результате они не могут проехать по тоннелям на линии между Францией и Италией, на которой их планировалось использовать. О неожиданной высоте новых составов сообщил профсоюз. По их данным, в ближайшие месяцы поезда все-таки начнут курсировать по линии Лез Арк — Вентимилья, но будут останавливаться на границе Италии и Франции, где пассажирам придется пересаживаться на другие поезда.

Злейший враг Франции Отто фон Бисмарк говорил в таких случаях: «Глуп тот, кто учится на своем опыте, я предпочитаю учиться у других и избегать расплаты за свои ошибки». Не делайте как SNCF! Делайте как Бисмарк — учитесь на ошибках других.

Типовые шаги механизма следующие.

1. Провести предварительное выявление требований заинтересованных сторон. Чего они хотят от проекта? Важно спрашивать не только Заказчика. Его, конечно, обязательно нужно спрашивать. Но не только его — всех, кто имеет значительное влияние на проект.
2. Определить список обязательных результатов (продуктов проекта) — что будем принимать на выходе. В него должны входить перечисленные выше комплементарные активы. Но скорее всего, не только они.
3. Сформировать требования под каждый из результатов.
4. Провести анализ требований — что подходит, что не подходит, какие есть противоречия и приоритеты.
5. Согласовать требования с ключевыми заинтересованными сторонами.
6. Официально утвердить документ, фиксирующий требования.

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

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

Очень важно «снять показания» со всех ключевых заинтересованных сторон. Нам важно следующее.

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

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

Алистер Кокберн в своей книге Agile Software Development описывает различные способы коммуникации, которые люди могут выбрать при совместной работе. Рисунок 18.1 показывает связь между эффективностью коммуникаций и богатством (насыщенностью) используемого канала связи.

Как видите, у разных каналов коммуникаций разная эффективность. Самое НЕЭФФЕКТИВНОЕ — общение через бумагу (официальные документы, служебные записки и так далее). Этот канал хорош для того, чтобы зафиксировать уже принятые решения, но не для достижения взаимопонимания.

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

Поддерживайте взаимопонимание с заинтересованными сторонами!

После того как мы собрали требования, важно убедиться, что требования разных заинтересованных сторон не противоречат друг другу, провести их анализ. А если противоречат? На этом этапе у нас еще есть время устранить проблему.

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

• Критичные (must) — то, что необходимо сделать в любом случае. Без выполнения этих требований продукт не решит проблему.
• Важные (should) — не самые критичные требования, но они тоже должны быть выполнены. Однако только после реализации must.
• Желательные (could) — требования, которые можно выполнить, если останется время и будут ресурсы.
• Дополнительные (would) — эти требования хотелось бы выполнить, но их можно проигнорировать или перенести на следующие этапы без особого вреда для продукта.

Важно правильно приоритизировать требования в самом начале. Можно каждому из них приписать одну из букв — К, В, Ж или Д. Тогда при реализации проекта будет проще организовывать работу и управлять изменениями.

Имейте в виду: требования обязательно будут меняться. Такова жизнь. Надо заранее подумать и понять, как вы будете проводить изменения. Если не предусмотреть варианты, согласование изменений будет таким же трудоемким, как утверждение исходного документа. Мы еще поговорим об этом, когда будем обсуждать механизм внесения изменений.

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

В каждой предметной области есть свои документы и подходы: в IT — бизнес-требования страниц на десять, которые потом детализируются в ТЗ страниц на двести, и далее — вплоть до технического проекта на тысячи страниц. В строительных проектах свои форматы, которые диктуются ГОСТами этой отрасли. В проектах создания новых продуктов — свои. Гибкие подходы вообще не фиксируют требования в официальном документе, а используют рабочие документы: бэклог, пользовательские истории и так далее.

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

На сайте книги (см. ) есть самый простой и универсальный вариант шаблона требований. Если нет необходимости в фиксации в каком-то строго определенном формате, этот вполне подойдет.

Отдельный нюанс: часто, когда нет внешних подрядчиков, требования не фиксируют вообще. Плохая идея! Как в конце понять, получили ли мы то, чего хотели? Обязательно нужно описать, как будут выглядеть результаты проекта; и тот, кто будет их принимать, должен с этим официально согласиться. Это можно сделать и неформально, например в виде презентации PowerPоint. Главное — пройти алгоритм: вы ознакомили куратора или заказчика со сформированными требованиями и услышали в ответ: «Да, все ясно. Это именно то, что мы хотим получить».

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

Отправить