Теория

Техническое задание на разработку ПО / доработку SAP (далее по тексту - ТЗ) в теории является неотъемлемым элементом процесса разработки ПО (SAP). В общих чертах, полный цикл разработки ПО выглядит следующим образом:

1. Ключевой пользователь со стороны бизнеса готовит ПЗ (Постановку задачи). В ПЗ он описывает, какой функционал должно обеспечить разрабатываемое ПО, какую бизнес-информацию и в каком формате требуется отображать и/или обрабатывать. Всё это описывается в терминах бизнес-процесса без «технической» информации.
2. SAP-консультанты по соответствующим модулям на основе ПЗ готовят ТЗ (каждый свою часть). В ТЗ детально описывается алгоритм со всеми техническими деталями: какие поля и каких таблиц участвуют в логике разработки, какие связи и зависимости используются в логике приложения, по каким критериям отбирается информация, каким образом она отображается и/или как она обрабатывается. Если предполагается использовать стандартный функционал (функции, методы классов и т.п.), то указывается, какие параметры надо передавать, какие накладывать ограничения и как использовать полученные результаты.
3. Программист, на основе ТЗ, осуществляет реализацию разработки (доработку системы).

В такой схеме от программиста не требуется знание бизнес-логики и структуры бизнес-данных того или иного модуля. Его задача сводится к чистому кодированию. Отсюда, кстати, и традиционный коэффициент 0,8 при оплате труда разработчика пришедший к нам с запада, где всё и происходит по вышеописанной схеме.

Практика

А как же всё происходит у нас в действительности? Не претендуя на объективность, буду основываться только на личном опыте, включающем около двух десятков проектов. Картина вырисовывается следующая.

Примерно на тридцати процентах проектов вообще нет какой-либо утвержденной регламентированной формы ТЗ. Постановка задачи происходит в устной форме и сводится к показу стандартных транзакций и «постановкой» типа: «Хочу, чтобы в отчете было вот это, и это, и чтобы программа делала так, как в той транзакции».

В половине случаев имеются утверждённые правила оформления ТЗ, но они не соблюдается. Разработка начинается по неоформленному ТЗ. В начале консультанты пытаются оформлять ТЗ по шаблону, но чем ближе дедлайн, тем реже это происходит и, в конце концов, всё сводится к первому варианту «отсутствия ТЗ». Стандартное оправдание в таких случаях – нехватка времени.

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

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

Как хотелось бы. Пожелания разработчика

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

• Организационная информация. В ней указывается, к какому модулю относится разработка, её код в общем реестре разработок, автор ТЗ, приоритет разработки и т.п. Информация важная с точки зрения менеджмента проекта, но разработчику малополезная.
• Описание функционала. В общих чертах. Примерно то, что пишет ключевой пользователь в Постановке задачи. Только не надо утрировать и описывать функционал в мельчайших подробностях, несущественных для разработчика. Разработчику надо «в целом» понимать, что от него хотят и что в итоге должно получиться.
• Если это ТЗ на создание отчета/формуляра, то обязателен перечень критериев отбора данных. Собственно, содержимое экрана выбора. Обязательно с указанием, можно ли задавать множество/диапазон для критерия выбора, или только единичное значение. (Иными словами, понятными техническим специалистам, это parameters или select-options).
• Если