Это вторая статья из серии публикаций на тему «Техническое задание. Вопросы и ответы».

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

Мы оговорили, что в постановочном техническом задании заказчик описывает свои требования крупными мазками, которые уточняются в частных технических заданиях. Частные технические задания создает исполнитель при содействии заказчика. Но дело в том, что исполнители используют свою терминологию, связанную с конкретным базовым программным обеспечением. Например, в 1С используется понятие «провести документ», а специалисты по Navision используют почти синонимическое по функционалу «учет документа». По большому счету, ничего страшного здесь нет. Однако может так получиться, что исполнитель по каким-либо причинам не сойдется с заказчиком и контракт будет разорван. Прецеденты были.

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

Вернемся к вопросу о том, кому нужны «технические задания для программистов». Действительно, они нужны только лишь для программистов. По сути дела, это внутренний документ группы разработки. Заказчику он не нужен за маленьким исключением: он нужен заказчику, если у того есть своя собственная группа разработки и поддержки. А что же нужно заказчику? Постановочное техническое задание ему, безусловно, нужно. Там, как никак, сосредоточено нынче модное «видение» будущей системы. А дальше начинается самое интересное. Нужен документ, с одной стороны, содержащий детальные требования заказчика, исходя из бизнес-процессов, а, с другой стороны, детали, необходимые исполнителю. Да еще надо умудриться, чтобы при возможной смене исполнителя не пришлось менять этот документ.

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

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

Минус, который якобы «напрашивается» сам собой. Зачем делать два задания, ведь чаще всего исполнитель не меняется? Но мы говорили, что первую часть пишет заказчик в лице отдела координации, а это означает, что одни и те же люди, применяя один и тот же подход, могут описывать требования к системам или их компонентам на разных базовых ПО. Понятно, что для «мелкого» бизнеса это не очень актуально, но ведь бизнес имеет приятное свойство расти, а, стало быть, количество систем будет увеличиваться. Почему это происходит, будет рассмотрено в одной из следующих заметок, но факт остается фактом: чем крупнее предприятие, тем больше у него систем. В качестве примера можно взять любой крупный холдинг с разносторонним, хотя и связанным бизнесом. Для одного бизнеса используется одно ПО, для другого – другое (пусть даже на той же самой платформе), для бюджетирования – отдельное, для бухгалтерии – в каждом бизнесе свое, да еще нужна консолидированная отчетность. И самое печальное, что для каждой системы свой глоссарий, свои технические задания, свои обозначения в схемах, бизнес-процессы описаны в разной нотации.

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

А вот почему эта «красивая» идея не работает, любознательный читатель узнает в одной из следующих заметок.

Читайте в следующих выпусках:

Почему исполнитель не может дать адекватного технического задания?

Почему в крупных компаниях не используют одно единственное ПО?

Почему «красивые» методологии внедрения работают не так красиво, как обещали?

Что включать в частное техническое задание, а что – нет?

Как избежать изменения требований к программному обеспечению?

А. Стрельников