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

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

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

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

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

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

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

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

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

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

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

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

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