Тезисы второй встречи (работа с требованиями)

В этой заметке -- несколько запоздалые тезисы второй встречи самарского "профсоюза ПМ-ов"

Встреча состоялась 22 мая, в офисе Mercury Development и была посвящена работе с требованиями. Участники встречи: Калугин Александр, Константин Быченков, Игорь Степин, Константин Иванов, Александр Сергеев, Андрей Чернов, Денис Пушкин, Андрей Суббота, Зиннур Темербеков, Анастасия Печкурова.

Первая часть встречи прошла в формате круглого стола. Участниками были высказаны обсуждены несколько вопросов управления требованиями. Во второй части А.Калугин (то есть я :) ) рассказывал о работе с нефункциональными требованиями (по мотивам ReqLabs’2011).

Итак, тезисы первой части:

1. Работать с требованиями необходимо на всех этапах проектах. В зависимости от стадии проекта – приоритеты различных требований могут меняться (одни требования могут становиться более приортетными – другие постепенно терять свой вес). При этом работа с функциональными и нефункциональными требованиями принципиально не отличается.

2. Требования не всегда позволяют достичь удовлетворенности заказчика

Иногда, видение проекта, формируемое на его начальном этапе (возможно пре-сейле), содержит лишь очень высокоуровневое описание проекта (бизнес-цели, возможно основные аспекты функционала), и попадая к разработчику – часто эти требования не формализуются, и детали ПМ просто поясняет устно (сделай «как в том проекте»). Разумеется, что требований, переданных таким образом – недостаточно. Проблемы начинаются на этапе разработки – потом на этапе тестирования, и часто выливаются в проблемы с точки зрения заказчика. Когда заказчику ставят билд – ему не нравится.

Да, в описанной ситуации – очевидная проблема с глубиной и полнотой сбора требований, но иногда заказчик может просто сказать – мне ваше видение это всё фигня, и мне надо вот так как я хочу… И как бы требования не формализовались – это может не помочь

А раз так – нужны ли вообще формализованные требования?

3. Обсуждение необходимости формальных требований
В процессе обсуждения необходимости формализованных требований были высказаны следующие мнения:

• Формальные требования нужны, чтобы сделать первый вариант продукта, который «не понравится»
• С точки зрения разработчиков – намного проще и удобнее работать с формализованными требованиями. С точки зрения заказчика или Product Owner-а – ситуация обратная: есть идея и наброски и дизайн – и давайте сделаем чтобы было хорошо.
• Заказчику и Product Owner-у, у которых есть идея – детальные формальные требования не интересны, им интереснее чтобы на основе минимальной информации команда смогла создать рабочий прототип, на основании которого – двигаться дальше
• Требования – это линия, по одну сторону которой находится команда разработки, а по другую – заказчик. Причем с точки зрения команды – требования должны быть стабильны; с точки зрения заказчика – ему интереснее их постоянно менять и дорабатывать.
• Даже если заказчик понимает, что формализованные требования нужны -- постепенно ему становится скучно с ними работать.
• Разработчики и QA влюблены в требования – и они счастливы, когда они формализованы. Наличие формализованной согласованной спецификации – на деле не спасает от изменения требований. Но по крайней они хоть как-то помогают.
• Так как заказчику требования это не очень удобны -- формат описания требования необходимо согласовывать с заказчиком – чтобы ему было удобнее с ними работать.
• Формализация требований должна включать критерии приемки продукта на высоком уровне, чтобы задавать хоть какие-то правила игры, даже без детализации конкретных требований.
• Несмотря на то, что формализованные требования необходимы для успеха проекта, их отсутствие – это скорее проблема разработчика, а не заказчика.
• Техническое задание/спецификация требований, если будет фиксировать требования в том, виде в котором их готов формулировать заказчик – будет очень неровной, так как различные требования будут иметь различный уровень детализации. Поэтому при формализации требований – необходимо концентрироваться на ключевых моментах. Например, спецификация должна содержать набор функций продукта, возможно без детального описания отдельных функций.
• Проблема набора функций в том, что список функций никак не отражает принципиальные нефункциональные требования к тому, как эти функции должны быть реализованы. Даже если минорные модификации функции можно пережить, дополнительное нефункциональное требование – может повлечь полную переработку системы.
• Формализация требований должна быть на нескольких уровнях. При этом необходимо стараться сделать так, чтобы вероятность изменения требований более высокого уровня была как можно меньше.
• На этапе заключения контракта чаще всего фиксируется прототип требований – который призван демонстрировать что заказчик и разработчик в общем говорят на одном языке и обе стороны в принципе ожидают, что этот прототип будет изменяться. Этого уровня детализации может быть достаточно, чтобы достичь соглашения.
• Формализация требований необходима как можно глубже. Но есть проблема связанная с тем, что если требования формализуются до заключения контракта – то работа про их детальной проработке может быть проведена впустую.
• Формальные требования помогают разрешать недопонимания и конфликты между командами тестирования и разработчиков.
• Формальные требования – позволяют продолжить отношения разработчика и заказчика после реализации функциональности, специфицированной этими требованиями.
• Способ, уровень, подход к формализации требований зависит от контракта между разработчиком и заказчиком. Если проект состоит из «мини-фаз» размером с неделю, то в такой ситуации – формальное описание требований может быть излишним – так как объем требований на неделю – небольшой.
• В договор с заказчиком можно закладывать возможность модификации требований заказчиком в процессе разработки. А раз так – то уровень формализации – может быть менее жестким. Всё зависит от позиции разработчика и тут есть две альтернативы: «дискаунтеры» -- когда только то что явно описано входит в scope – остальное за доп плату – тогда фиксация требований должна быть очень жесткой. Или “luxury” – когда прямая противоположность.
• Для модели «дискаунтера» формальные требования необходимы, но есть специфика приоритета того что должно быть в требованиях: требования должны формально и жестко фиксировать внешние границы проекта. Внутри этих границ – обычно изменения требований не столь критичны.
• Отдельный интерес представляют собой контракты между заказчиком и исполнителем – в которых исполнитель является экспертом очень высокого уровня. В такой ситуации – фактически исполнителю дается зеленый свет на реализацию функциональности тем методом, каким он это видит. В такой ситуации фиксация требования необходима только на уровне бизнес-целей проекта.
• Необходимо понимать в каком виде происходит формализация требований – чтобы ответить на вопрос, нужны ли формальные требования. В общем виде ответ на вопрос – да. Но видом формализации может быть, например, просто аудиозапись разговора с заказчиком – или детально проработанное ТЗ.
• Даже если требования между заказчиком и компанией-разработчиком не формализованы – до разрабочиков и тестировщиков – требования должны доходить в формальнизованном виде.

3. Участники обсудили необходимость учета возможности изменения требований в процессе разработки на уровне контракта с заказчиком:

• Проблема может быть решена с использованием контракта, подразумевающего итеративный agile-процесс. В этой ситуации – основные момент работы с требованиями это детализация требования до уровня, необходимо для корректной оценки итерации и некоторая жесткость при попытке изменения требований в процессе итерации.
• Иногда у заказчика есть фиксированный бюджет и он хочет реализовать в рамках этого бюджета некоторый фиксированный функционал, чтобы затем попробовать этот функционал и принять решение о том, стоит ли двигаться дальше – в такой модели подразумевается, что никаких изменений в требования контракт не подразумевает – и иногда заказчик именно этого и хочет.
• Если по каким-то нефинансовым причинам проект компании-разработчику интересен, то даже если возможность внесения изменений контрактом не подразумевается – разработчик может соглашаться на эти изменения.
• Одним из вариантов является фиксация функционального состава системы на высоком уровне /основных workflow взаимодействия пользователей – подразумевая возможность внесения изменений «внутри» функции/незначительных изменений workflow.
• Необходимо различать контракты по разработке АИС – где определенная жесткость функционала задается существующим бизнес-процессом в организации, который автоматизируется – и разработке коммерческого ПО на заказ – где требования могут быть очень гибкими.
• Уровень переделок подразумеваемый проектом – зависит от «правил игры» на рынке, «как принято».
• Если проект начинается от бюджета, выделенного под реализацию определенной системы, а не в обратную сторону, то уровень изменений должен быть таковым, чтобы достичь удовлетворенности представителей заказчика.
• Даже в рамках единого уровня формализации требований – возможность изменений, которую надо учитывать, в контракте может происходить не из модификации требований – а из некоторых дополнительных требований к процессу разработки, которые изначально не ясны, и которые могут требовать значительных усилий, со стороны разработчика. В такой ситуации – чем большего размера структурой является заказчик – тем более высокий уровень подобных изменений должен подразумеваться.
• Процент возможных изменений, которые подразумеваются контрактом зависит от уровня формализации требований. Чем менее детальные/глубокие требования – тем более высоким должен быть процент.
• Закладываемая возможность изменений в проекте зависит от «опытности заказчика» в разработке ПО на заказ. Чем менее опытный заказчик, тем более высоким должен быть уровень ожидаемых изменений.

4. Требования с точки зрения команды: как работать с требованиями, чтобы не было стресса для команды.

С точки зрения разработчика – две основные причины стресса, связанные с требованиями это:
a. полное изменение видение – что редко.
b. неполнота спецификации -- отсутствие в ней архитектурной информации об особенностях реализации – а так как спецификация уже подписана – то никто не берет на себя ответственность за внесение изменений в эту спецификацию.

Спецификация, по которой договорились аналитики и заказчик – может быть всё равно не содержать информации о том, как реализовывать отдельные требования с точки зрения команды-разработки или с точки зрения команды тестирования. Одним из возможных способов решения проблемы стрессовости спецификации – это совместная работа над спецификацией представителей различных ролей – что дополнительные расходы.

Однако, на практике получается так, что привлечение всех ролей к разработке спецификации на проекте – всё равно необходимо делать. А раз так, то чем раньше это будет сделано, тем лучше.

Например, команда должна привлекаться на этапе выявления бизнес-цели. При этом можно дать разработчикам возможность общаться с заказчиком – задавая им вопросы и выявляя детали. Задача ПМ-а при этом построить этот процесс взаимодействия команды разработки с командой заказчика.

ВСЁ!!!