Ця розмова повторюється із завидною регулярністю. Клієнт приходить з ідеєю, ми обговорюємо задачу, і я пропоную почати з проєктування: аналітика, архітектура, технічне завдання. Клієнт хмуриться: «Зачекайте, а чому я маю платити за документ? Я ж хочу систему, а не папірець. Давайте я сам напишу, що мені потрібно, а Ви просто порахуєте й зробите». І приносить за тиждень три сторінки тексту, у якому є побажання, приклади конкурентів, фраза «як в Excel, тільки зручніше» й обовʼязкове «інтуїтивно зрозумілий інтерфейс». Я цей документ дуже ціную, чесно. Але це не технічне завдання. Це лист Діду Морозу.
ТЗ не список побажань, а креслення
Порівняймо з тим, що всі розуміють. Ви вирішили збудувати будинок. Можна прийти до будівельної бригади й сказати: «Хочу двоповерховий, світлий, з великою кухнею і щоб було затишно». Бригада, звісно, щось збудує. Але де пройдуть несучі стіни, який потрібен фундамент під цей ґрунт, як піде каналізація, чи витримають перекриття ванну на другому поверсі, вирішить виконроб на ходу. А потім виявиться, що для другого санвузла немає стояка, і щоб його зробити, доведеться довбати вже готову стіну.
Тому в будівництві давно ніхто не сперечається, що спершу потрібен проєкт від архітектора, і за нього платять окремо. У розробці програм чомусь сперечаються досі. Хоча програмна система нічим не простіша за будинок: у неї теж є фундамент у вигляді моделі даних, несучі стіни у вигляді архітектури, комунікації у вигляді інтеграцій і оздоблення у вигляді інтерфейсу. І помилка у фундаменті, виявлена на етапі оздоблення, коштує в десятки разів дорожче, ніж якби її знайшли на папері.
Технічне завдання це найдешевший момент, щоб помилитися. Потім помилятися буде лише дорожче.
Чому самописне ТЗ небезпечне
Я не кажу, що замовник не здатен написати добре ТЗ. Іноді здатен, особливо якщо має досвід і в компанії працює аналітик. Але здебільшого самописне ТЗ страждає від тих самих хвороб, і справа не в розумі автора, а в його позиції.
Перша хвороба: замовник не знає технічних обмежень. Він не знає, що ось ця маленька фраза «і щоб усе синхронізувалося в реальному часі» перетворює простий проєкт на складний і подвоює бюджет. Він не знає, що в обраного ним платіжного сервісу немає потрібної функції. Це не його професія, і не мусить бути.
Друга хвороба: описується рішення, а не задача. «Потрібна кнопка, яка вивантажує звіт в Excel» замість «бухгалтерові треба щомісяця звіряти оплати з відвантаженнями». Перше можна зробити, але, можливо, друге розвʼязується зовсім інакше і без жодного Excel.
Третя хвороба: пропущено найнудніше. Права доступу, обробка помилок, що відбувається під час скасування замовлення, хто і як виправляє неправильно введені дані, що буде, якщо два менеджери одночасно редагують одного клієнта. Саме на цьому й ламаються проєкти, а в листі Діду Морозу цих пунктів немає ніколи.
Підсумок передбачуваний. Розробники, отримавши таке ТЗ, роблять одне з двох. Або закладають величезний запас на невідомість і переоцінюють проєкт, і клієнт іде до того, хто назвав меншу цифру. Або чесно роблять рівно те, що написано, і за три місяці виходить система, яка формально відповідає документу і водночас не розвʼязує задачу. Далі починаються суперечки, хто винен, і спойлер: програють у цих суперечках зазвичай усі.
Чому проєктування це окремий оплачуваний етап
Добре ТЗ це результат роботи. Аналітик розбирає процеси компанії, розмовляє з людьми, які користуватимуться системою, знаходить суперечності між тим, що каже керівник, і тим, що насправді роблять працівники. Архітектор вирішує, як система буде влаштована, які технології потрібні, де ризики. Це тижні кваліфікованої праці, і безкоштовною вона може бути лише в одному випадку: якщо її вартість таємно схована в ціну розробки. Тоді Ви за неї все одно платите, просто не бачите, скільки і за що.
Окремий етап проєктування має ще одну величезну перевагу, про яку рідко говорять: він робить Вас вільним. Отримавши оплачене ТЗ, Ви ним володієте. Ви можете віднести його будь-якому підрядникові, порівняти пропозиції за однаковим документом, а не за різними фантазіями, і обрати найкращого. Без ТЗ кожен підрядник оцінює свою версію Вашого проєкту, і порівнювати ці оцінки так само безглуздо, як порівнювати ціни на «якусь машину».
Що робити замовникові
Моя порада не в тому, щоб нічого не писати самому. Навпаки: напишіть усе, що знаєте. Опишіть, як працює Ваш бізнес сьогодні, де болить, які процеси зʼїдають найбільше часу, хто користуватиметься системою і чого Ви чекаєте за рік. Зберіть приклади документів, таблиць, звітів, скриншоти того, чим користуєтеся зараз. Це безцінний матеріал, який заощадить аналітикові тижні. Але перетворювати цей матеріал на технічне завдання має той, хто вміє будувати системи.
І ще одне: ставтеся до проєктування як до страховки. Невелика частка бюджету, витрачена на етапі паперу, захищає основну частину від переробок. Ми в Systems завжди починаємо з цього етапу, а результат передаємо замовникові як самостійний документ, з яким він вільний робити що завгодно. А Fractal дає нам змогу перетворювати опис системи на робочий прототип дуже швидко, тому ТЗ у нас не лежить мертвим папером, а майже одразу стає екраном, який можна помацати. Але починається все з креслення. Будинок без креслення будують лише один раз, удруге вже ніхто не хоче.
