В 2014 году Институт Проектного Менеджмента (PMI) изучил вопрос, как нечеткие или недостаточно хорошо прописанные требования на входе проекта влияют на весь проект в целом. Выяснились, в общем, неудивительные детали – в 51% случаев заказчик потратил больше денег, чем изначально закладывалось, а 47% проектов не были выполнены в полном объеме. Казалось бы, здравый смысл подсказывает, что в интересах самого заказчика проработать (или заказать подрядчику) требования к продукту в качестве предпроектной деятельности и, тем самым, снизить риски срыва сроков релиза, превышения бюджета, снижения качества финального решения.
Как прекрасно знают руководители проектов, бывают ситуации, когда заказчик в силу разных причин не может сам написать технические требования к продукту, и разработчикам приходится иметь дело с довольно сложной ситуацией. Чаще всего причина в «высокоуровневости» требований – по факту заказчику ближе и важнее бизнес-требования (запрос на разработку поступает от заказчика или отдела заказчика, для которого разработка/поддержка ПО не является профильным занятием), и у него недостаточно специалистов или навыков персонала для перевода этих требований в технические. Иногда такая ситуация складывается, когда заказчик работает с устаревшим или унаследованным в результате поглощения продуктом с утраченной (или недостоверной, неполной, неподдерживаемой) документацией и отсутствующими экспертами. Но встречается еще одна категория заказчиков, которые предполагают, что при использовании Agile технические требования неважны. Превратно понятая фраза из Манифеста: “Working software over comprehensive documentation” (работающий продукт важнее исчерпывающей документации) заставляет их сделать вид, что технические требования и документация вообще не важны, все равно все будет меняться. С ней-то я и хотел поспорить в этой статье. Но, прежде всего….
Как это делается в стандартных ситуациях?
Предположим, наша ситуация укладывается в первые два случая: заказчик понимает, что технические требования нужны, но не имеет возможности их написать самостоятельно. Написание технических требований – естественный шаг в проектном плане. Для начала выделенный специалист команды (аналитик) должен ознакомиться с существующей документацией, поговорить с экспертами – носителями знаний о продукте, тщательно изучить бизнес-требования, посмотреть на архитектуру продукта и уже после этого, используя существующие стандарты, методологии и своды знаний (такие как ГОСТ 34, ГОСТ 19, IEEE STD 830-1998, ISO/IEC/ IEEE 29148-2011, RUP, SWEBOK, BABOK и другие), по которым пишутся технические требования или SRS (Software or System Requirements Specification), написать технические требования, понятные разработчикам.
Эти требования фиксируются с заказчиком, и дальше проект идет по запланированному расписанию, независимо от того, выполняется он по Agile или Waterfall методологии.
А как в Agile проекте?
Бизнес-департаментам не всегда понятно, зачем нужно тратить время на составление каких-то документов и требований. Им нужен продукт, и именно за продукт они готовы платить. Поэтому, узнав про Agile, бизнес-заказчик и решает, что раз «работающий продукт» важнее «исчерпывающей документации», то она и вовсе не нужна – ни исчерпывающая, ни какая другая. Это наиболее распространенный и неверный подход. Перечислю основные заблуждения (и напишу, почему они неверны):
1. Для Agile проекта не требуется управление требованиями. На самом деле оно встроено в саму ткань Agile. На Agile проектах в качестве требований выступает беклог продукта: приоритизация и переприоритизация пользовательских историй, планирование итераций и релизов, ежедневные стендапы, burn-down и burn-up charts, добавление критериев приемки в пользовательские истории, демо и ретроспективы – это все, по сути, не что иное, как контроль требований от старта проекта до его окончания.
2. Внесение изменений в продукт на Agile проектах не контролируется. В реальности, конечно, изменения вносятся далеко не бесконтрольно. Запросы на изменения описываются как пользовательские истории, помещаются в беклог, им присваиваются приоритеты по согласованию с владельцем продукта.
3. Если беклог постоянно изменяется, незачем фиксировать требования жестко. Да, в Agile признается, что беклог продукта меняется в течение всего проекта (разработчиками или владельцами продукта). Главное, что предлагает Agile методология, – гибкость: не есть огромного слона проекта целиком, а разрезать его на более мелкие куски (спринты). Но если мы хотим получить удачный качественный продукт, остаться в рамках бюджета и расписания, требования для каждого спринта должны быть четко прописаны и согласованы до начала работы над ними, иначе объем требований будет неконтролируемо расти.
Шесть советов заказчику
Сложно начать делать продукт, не понимая, что же толком должно получиться в итоге. В такой ситуации легко оказаться на месте одного из героев известного скетча про семь красных линий. Если у вас нет ресурсов или возможностей написать технические требования и документацию, я надеюсь, мои советы помогут вам реализовать ваш проект без происшествий. Итак,
- Для начала поймите, что работа с требованиями – это часть проекта, а не прихоть подрядчика. Согласуйте этот этап с подрядчиком и заложите соответствующие расходы в бюджет. Помните, что в противном случае на кону большие риски получить продукт не в срок, дороже и не совсем с тем функционалом, производительностью и надежностью, на которую вы рассчитывали. Скупой платит дважды – это тот самый случай.
- Выделите часть времени на работу аналитика. Он задаст правильные вопросы, которые определят высокоуровневый профиль продукта (классические WWWH – Why? What? Who? How?).
- Проработайте карту коммуникаций – кто, как и когда получает информацию о требованиях, изменениях, прогрессе, проблемах. Лучше всего, если еще «на берегу» у вас будет составлен план коммуникаций на все более-менее стандартные ситуации и выбраны удобные каналы общения.
- Решите, кто и на каких условиях вносит изменения в беклог и как приоритизируются эти изменения.
- С самого начала выделите у себя владельца продукта – точку доступа для руководителя проекта и инженеров. Заложите его время на общение с командой и отслеживание прогресса. Более 37% проектов (согласно PMI) проваливаются из-за недостаточной вовлеченности владельца продукта в процесс.
- Заложите время в начале проекта на “Спринт 0”, о котором я писал в предыдущей статье. В эти две-три недели пишутся HLD и HLA, происходит наладка CI/CD, планирование и оценка основных задач и, самое главное, работа с требованиями.
