[Из песочницы] Каким должно быть ТЗ?

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

image

Ребята, которые разрабатывали 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 «Навигация по Техническим Заданиям»


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

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

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

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


Моё мнение — оно должно быть постоянно эволюционирующим, решающим насущные задачи команды. Цель не впихнуть в него побольше, а фокусироваться на том с чем чаще всего команда сталкивается в виде проблемы, то с чем работать умеем плохо. Ровно тоже самое, что мы делает с ИТ-продуктом: начинаем с минимально необходимого, затем добавляем красоту и удобство, и в конце оптимизируем.

Поделитесь какое ТЗ у вас, под какие задачи оно у вас настроено и как с ними справляется.

Что хорошего почитать на Хабре по этой теме


  1. Применение Сценариев использования (use case) при разработке ТЗ
  2. Техническое задание на сайт
  3. Техническое задание на сайт. Практика

Будет дальше регулярно пополняться.

» Пример первой части нашего ТЗ (в виде pdf на яндекс.диске)

Комментарии (0)

© Habrahabr.ru