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

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

Среди традиционных способов сбора требований упомянем такие как:

– Проведение фокус-групп типичных пользователей.

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

– Проведение интервью для выявления требований.

– Проведение совместных семинаров.

– Наблюдение за пользователями на рабочих местах.

– Разработка и раздача опросных листов.

– Анализ документов.

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

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

– со слов, без документирования;

– с использованием спецификаций требований, то есть с предварительным документированием и согласованием требований до разработки;

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

Ознакомимся детальнее с каждым из перечисленных подходов.

Разработка «со слов»

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

Так в чем же сильные и слабые стороны такого подхода? Какие условия необходимы для достижения успеха проекта при его реализации?

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

Как это может выглядеть? Например, так: заказчик вызывает к себе разработчика и рассказывает ему, что хотел бы видеть в ИТ-решении. Разработчик его выслушивает, возможно конспектирует, и после этого начинает разработку.

Важно, что этапа согласования письменных требований нет – как понял разработчик, так и реализует.

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

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

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

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

Ценна и возможность оперативной обратной связи разработчика с заказчиком – можно просто быстро устно спросить, получить ответ и сразу брать его в разработку.

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

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

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

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

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