Каким должно быть ТЗ?

2016-10-13 в 9:20, admin, рубрики: Анализ и проектирование систем, как написать техническое задание, как написать ТЗ, как обновлять ТЗ, каким может быть ТЗ, навигация по техническим заданиям, навигация по ТЗ, обновление технического задания, Проектирование и рефакторинг, техническое задание образец, метки: как написать техническое задание, как написать ТЗ, как обновлять ТЗ, каким может быть ТЗ, навигация по техническим заданиям, навигация по ТЗ, обновление технического задания, техническое задание образец

Представьте, что у вас есть корпоративная информационная система в развитие которой вкладывается 100 млн. рублей ежегодно. С момента внедрения документация на систему превратилась из одного Технического задания на 600 страниц в 300 Технических заданий, у каждого из которых есть дополнение в количестве от 1 до 10 штук, и теперь она занимает объем 3 офисных шкафов и это ещё не конец… Фабрика по производству ПО исправно и ритмично (с периодичностью в месяц) выпускает обновление системы и документирует изменения.

Ребята, которые разрабатывали 34-й ГОСТ явно не рассчитывали на то, что дело может принять такой оборот. Да и книги по гибким методологиям разработки тоже не дают каких-то рекомендаций как с этим быть.

Всё что нам казалось не очень важным тогда, со временем и в масштабе приобрело вид серьезной проблемы.

Как в этом объеме документов найти те, что описывают работу определенного функционала системы?
Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?
Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?

Часть №1 “Разработка ТЗ”

«Заказчик: Ребята, это фигня какая-то, ничего не работает.
Разработчики: У нас всё сделано согласно ТЗ.»

Технические задания к КИС выглядели как систематизированные перечни требований. Разработать формы, создать поля такого-то типа, такой-то размерностью и логикой формирования… Отличный документ для разработчика, который быстро превращается в чек-лист того, что нужно сделать и проверки что сделано.

Была у этого одна проблема, если сравнить разработку КИС с постройкой ракеты, то это выглядело так, нужные детали создали, а в отдельных местах собирать и присоединять их не стали, так как не было сказано: а) что это нужно сделать, б) как нужно собрать.

При попытке запустить такую ракету в космос она взрывается, с КИС же:
«Заказчик: Ребята, это фигня какая-то, ничего не работает. Разработчики: У нас всё согласно ТЗ».
Чем больше был размах функционала КИС, тем больше аналитики залипали в детали, и тем чаще теряли виденье задачи целиком.

Итог: Заказчик недоволен и считает, что мы плохие Аналитики… и он прав.

Документ составлен для Разработчиков, а подписывается под ним Заказчик. Всё что в нём изложено «какие поля добавить и т.д.» его не интересует, он в этом не понимает и не должен разбираться, ему интересно получить работающее ИТ-решение его бизнес-задачи. Когда Заказчик ставит подпись на ТЗ он верит, что получит именно последнее.

Я прихожу к директору, я говорю:
— Кто сшил костюм? Кто это сделал? Я ничего не буду делать, не буду кричать, я только хочу в глаза ему посмотреть.
Выходит сто человек. Я говорю:
— Ребята, кто сшил костюм?
Они говорят:
— Мы!
Я говорю:
— Кто это «мы»?
Они говорят:
— У нас узкая специализация. Один пришивает карман, один — проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть?
— Нет! Пришиты насмерть, не оторвёшь! Кто сшил костюм? Кто вместо штанов мне рукава пришил? Кто вместо рукавов мне штаны пришпандорил? Кто это сделал?
Они говорят:
— Скажите спасибо, что мы к гульфику рукав не пришили.
Представляете? Их – сто, а я – один. И все стоят, как пуговицы: насмерть. И я сказал:
— Привет, ребята! Вы хорошо устроились!

Аркадий Райкин

Новый шаблон ТЗ мы разбили на две части: первая для Заказчика, вторая для Разработчиков.

Первую часть ТЗ разрабатывал Бизнес-аналитик с Заказчиком с установкой ни в чем себе не отказывать. На выходе этого полета фантазии идеальный описанный и иллюстрированный вариант выполнения бизнес-операции Заказчика с использованием КИС.

Дальше мечта бизнеса спускалась на бренную землю возможностей КИС, где Системный аналитик, Архитектор и Главный разработчик думали над тем как сказку сделать былью. Из горнила рождалась вторая часть ТЗ, которая трассировала бизнес-логику в требования к системе.

После появления второй части и подтверждения «Разработкой», что всё будет работать как описано в первой, Заказчик подписывал первую часть ТЗ и только её.

Так был дан ответ на вопрос «Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?».

Часть №2 “Обновление ТЗ”

«Собери общую картину работы функционала из 20 документов (Пазл 18+)»

Документ №1 (основное ТЗ): Сделать поле 1.
Документ №2 (Дополнение №1 к ТЗ): Сделать поле №2.
Документ №3 (Дополнение №2 к ТЗ): Внести изменения в поле №1, сделать поле №3.
Документ №4 (Сменился РП по направлению, поэтому создано новое ТЗ): Внести изменения в поле №2 и поле №3.
Документ №5 (Дополнение №1 к новому ТЗ): Внести изменение в поле №3 и №1, сделать поле №4.
Документ №6 (Новый РП нашел основное ТЗ, Дополнение №3 к основному ТЗ): Внести изменение в поле №2 и поле №4.
…
Вот что собой представлял набор документации по функционалу. Новый шаблон ТЗ имел все шансы повторить участь предшественника, в качестве решения выбрали «переписывать слова в песне».

С каждым новым изменением основное ТЗ переписывалось.

Мотив: у нас всегда один актуальный документ.

Нарисовалась проблема. Заказчик начал грустить, что из-за одного нового поля, он должен перечитывать весь документ, чтобы поставить на нем свою подпись. Представим, что одно ТЗ в среднем это 40 страниц, а в месяц Заказчик получает около 10 таких документов (фабрика же / быстрая разработка …).

Вернули дополнения к ТЗ и в них стали указывать, что на что меняем в основном ТЗ или какой новый раздел в него добавляем. Заказчик согласовывает дополнение к ТЗ на 2-3 страницы, а на его основании вносятся изменения в основное ТЗ. На выходе всё тот же один единственный документ, который описывает актуальное состояние ИТ-решения.

Так мы ответили на второй вопрос «Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?».

Часть №3 “Навигация по Техническим Заданиям”

Для навигации по ТЗ-ям мы использовали реестр ТЗ, изначально предназначенный для резервирования номеров под ТЗ и указание к нему такой исторической информации как:

Подразделение заказавшее разработку
Заказчик в подразделении, который формулировал и ставил задачу
Руководитель проекта нашего отдела, который отвечал за его реализацию
Системный аналитик подрядчика, писавший ТЗ для разработчиков

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

Вот такое решение для последнего вопроса «Как в этом объеме документов найти те, что описывают работу определенного функционала системы?».