[Из песочницы] Каким должно быть ТЗ?
Ребята, которые разрабатывали 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 «Навигация по Техническим Заданиям»
Для навигации по ТЗ-ям мы использовали реестр ТЗ, изначально предназначенный для резервирования номеров под ТЗ и указание к нему такой исторической информации как:
- Подразделение заказавшее разработку
- Заказчик в подразделении, который формулировал и ставил задачу
- Руководитель проекта нашего отдела, который отвечал за его реализацию
- Системный аналитик подрядчика, писавший ТЗ для разработчиков
Описали базовый бизнес-процесс компании (без фанатизма, крупными мазками) и внутри по мере необходимости детализировали/дробили процессы на процедуры. Каждому ТЗ указывали в рамках какого бизнес-процесса выполняются работы и какую процедуру он реализует. По запросу бизнес-подразделения, определив какой бизнес-процесс будем автоматизировать или дорабатывать, сортировали общий пул и определяли будет ли это новое ТЗ или дополнение к существующему, что там уже есть и как работает.
Вот такое решение для последнего вопроса «Как в этом объеме документов найти те, что описывают работу определенного функционала системы?».
Каким должно быть ТЗ?
Моё мнение — оно должно быть постоянно эволюционирующим, решающим насущные задачи команды. Цель не впихнуть в него побольше, а фокусироваться на том с чем чаще всего команда сталкивается в виде проблемы, то с чем работать умеем плохо. Ровно тоже самое, что мы делает с ИТ-продуктом: начинаем с минимально необходимого, затем добавляем красоту и удобство, и в конце оптимизируем.
Поделитесь какое ТЗ у вас, под какие задачи оно у вас настроено и как с ними справляется.
Что хорошего почитать на Хабре по этой теме
- Применение Сценариев использования (use case) при разработке ТЗ
- Техническое задание на сайт
- Техническое задание на сайт. Практика
Будет дальше регулярно пополняться.
» Пример первой части нашего ТЗ (в виде pdf на яндекс.диске)
