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