Из неочевидного – если разработчик неправильно поймет спецификацию или она по содержанию не несет в себе требований, то может возникнуть опасная иллюзия, что все под контролем и работа идет к цели по плану, хотя на самом деле разработка ведется даже не «со слов», а из предположений разработчика как это могло бы быть в спецификации.
Письменные спецификации требований характерны для сложных проектов с широким охватом бизнес-процессов, интеграционными взаимодействиями, длительным жизненным циклом решения и, соответственно, сроком сопровождения. Применяются чаще в крупных организациях, склонных к тяжелым, например, водопадным, методологиям внедрения.
Еще один момент – время разработки спецификации. Мир сейчас меняется быстро, и бизнес-среда тоже, поэтому время создания решения, в том числе требований к нему, часто критично.
Проработка хорошей спецификации требований требует времени, которого может и не быть – это следует сопоставить с бизнес-окружением, конкурентами, сроком жизни разрабатываемого решения и вовремя остановиться с детализацией.
Случаи, когда требования к моменту завершения их подготовки уже устарели – увы, обычная история в современном корпоративном мире.
Поэтому хорошая спецификация требований – отличное подспорье проекту разработки ИТ-решений, но нужно чтобы она была действительно хорошей и завершалась до того момента, когда ее содержание устареет.
Agile-подход
Нужны ли письменные спецификации в Agile? Недальновидные поклонники методологии думают, что ее придумали, как отказ от документирования. Гуру указывают, что они такого не замышляли, и вот почему. Посмотрим на Agile манифест, широко известный в русском переводе, где говорится, что:
– Люди и взаимодействие важнее процессов и инструментов.
– Работающий продукт важнее исчерпывающей документации.
– Сотрудничество с заказчиком важнее согласования условий контракта.
– Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Все заявления затрагивают требования, попробуем понять, как.
«Люди и взаимодействие важнее процессов и инструментов» говорит нам о том, что нужно выбирать тот объем и характер взаимодействия специалистов заказчика и разработчика, который позволил бы им максимально быстро и комфортно сформировать единое мнение о том, какое ИТ-решение нужно разработать. Для хорошо сыгранной команды и простого решения это может быть разработка «со слов», для множества распределенных команд и сложной корпоративной системы – объемная согласованная стандартизованная документация. Именно выбор людьми команды подходящего ситуации инструмента и процесса декларируется здесь.
«Работающий продукт важнее исчерпывающей документации» не отрицает документирование, а лишь указывает на ее вторичную, поддерживающую роль. Пока продукт работает корректно и не развивается, принцип может трактоваться как отсутствие документации. Как только заходит речь о поддержке и развитии – сразу требуется наличие минимально необходимой документации, в которую обычно входят и бизнес-требования «для чего и почему именно так мы действуем».
«Сотрудничество с заказчиком важнее согласования условий контракта» говорит о готовности к изменениям даже если законтрактованы жесткие требования. Увы, жизнь сложнее и многообразнее любой спецификации требований, однако контрактные рамки позволяют цивилизованно и к обоюдной выгоде разрешать такие отклонения. Документирование требований, в частности, являющееся приложением к контракту, эти рамки создает.