Pull to refresh

Каким должно быть ТЗ на Корпоративную ИС?

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

image

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Пример бизнес-сценария


Пример системного сценария


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

Часть №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 страницы, а на его основании происходило обновление основного ТЗ. На выходе всё тот же один единственный документ, который описывает актуальное состояние ИТ-решения.

Пример внесения изменений в основное ТЗ с помощью дополнения
image

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

Часть №3 “Навигация по ТЗ”


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

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

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

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

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

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


Один всегда актуальный документ. Достаточно прочитать только его, чтобы понять как устроен бизнес-процесс и его автоматизация. Чтобы найти нужные ТЗ в них есть метки в виде названия функционала КИС, бизнес-процессов и процедур, которые оно затрагивает.
Шаблон Технического Задания


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

Что почитать по теме


  1. Применение Сценариев использования (use case) при разработке ТЗ
  2. Что такое Use Case и зачем они нужны?
  3. Книга Алистера Кокберна «Writing Effective Use Cases» на русском языке
  4. Техническое задание на сайт
  5. Техническое задание на сайт. Практика
  6. Описание процесса разработки ПО в компании Nevlabs с примером ТЗ (размещен на сайте компании)

UPD.
Рекомендую прочесть комментарии к статье. Особенно ветку комментария habrahabr.ru/post/312538/#comment_9897642
В нём хорошо раскрывается первая часть статьи «Разработка ТЗ» (на Корпоративную ИС).
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+10
Comments 27
Comments Comments 27

Articles