Яким має бути ТЗ?

Уявіть, що у вас є корпоративна інформаційна система в розвиток якої вкладається 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 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.