Юрий Дубровский - Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ

Недостатки не столь очевидны, но они есть:

– существенные искажения, если они случились при восприятии разработчиком требований, будут выявлены только при демонстрации результатов разработки. То есть высок риски доработок и переделок (причем многократных, так как искажения возможны и в восприятии замечаний);

– перенос единолично на разработчика задачи детализации требований и разрешения противоречий, существующих в требованиях, так как не делается детальной проработки и согласования требований с заказчиком;

– отсутствие возможности восстановления истории требований. Это негативно влияет на ведение изменений, может привести к «хождению по кругу», когда одно и то же требование то возникает, то пропадает в последовательных правках решения;

– практическая сложность и высокая стоимость поддержки и развития как сторонними разработчиками, так и самим автором по истечении времени. Это произойдет потому, что требования, под которые построена система, забудутся или просто будут неизвестны новому разработчику, принятые технические решения и их обоснование, известное только первоначальному разработчику, будет непросто понять и развить (в том числе, возможны ошибочные представления, ведущие к нарушению работоспособности ИТ-решения при попытках его модификации и развития);

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

– потребность в многократном объяснении запутанных моментов со стороны заказчика при доведении информации до разработчика – излишние временные затраты и все тот же риск недопонимания и искажения восприятия;

Таким образом, решение разрабатывать «со слов» целесообразно для небольших задач без необходимости сопровождения и развития, выполняемых в хорошо сработанных командах, где заказчик и разработчик отлично понимают детали бизнес-процесса и идеи друг друга с полуслова.

В иных случаях шанс достижения цели разработки «со слов» без разочарований невелик.

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

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

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

Что дает нам письменная согласованная специалистами заказчика спецификация требований (пропустим про спокойный сон руководителя проекта, поскольку у него юридически ограничены рамки проекта, хотя это тоже есть)?

Хорошая спецификация дает нам предварительно построенную достаточно детальную и непротиворечивую картину, что же мы должны построить.

При этом еще и определены приоритеты, как это строить, проработаны и сняты основные нестыковки, с которыми при построении решения столкнется разработчик.

То есть, хорошая спецификация существенно повышает шансы достигнуть цель разработки в плановые сроки и бюджет. Также проще планировать путь и ресурсы исполнения проекта.

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

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

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

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

Еще один момент – время разработки спецификации. Мир сейчас меняется быстро, и бизнес-среда тоже, поэтому время создания решения, в том числе требований к нему, часто критично.

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

Случаи, когда требования к моменту завершения их подготовки уже устарели – увы, обычная история в современном корпоративном мире.

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

Нужны ли письменные спецификации в Agile? Недальновидные поклонники методологии думают, что ее придумали, как отказ от документирования. Гуру указывают, что они такого не замышляли, и вот почему. Посмотрим на Agile манифест, широко известный в русском переводе, где говорится, что:

– Люди и взаимодействие важнее процессов и инструментов.

– Работающий продукт важнее исчерпывающей документации.

– Сотрудничество с заказчиком важнее согласования условий контракта.

– Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Все заявления затрагивают требования, попробуем понять, как.

«Люди и взаимодействие важнее процессов и инструментов» говорит нам о том, что нужно выбирать тот объем и характер взаимодействия специалистов заказчика и разработчика, который позволил бы им максимально быстро и комфортно сформировать единое мнение о том, какое ИТ-решение нужно разработать. Для хорошо сыгранной команды и простого решения это может быть разработка «со слов», для множества распределенных команд и сложной корпоративной системы – объемная согласованная стандартизованная документация. Именно выбор людьми команды подходящего ситуации инструмента и процесса декларируется здесь.