Правильне технічне завдання, або ТЗ, — яке воно?
Грубо кажучи, воно має відповідати на два запитання:
1. ЩО ми хочемо отримати?
2. ЯК це має бути зроблено?
Тобто складатися з двох великих частин.
Дуже часто стикався з тим, що у відділ розробки надходили такі собі ТЗ, у яких була лише перша частина. Опис того, чого хочемо. Іноді з розумними формулами, ескізами сторінок, діаграмами процесів...
Ми називали їх побажаннями.
Немає проблем.
Притомний аналітик брав ці побажання й, озброївшись знаннями про Шарика з фоторушницею, ішов дописувати другу частину. І з більшістю замовників це цілком працювало.
Але була особлива група колег, яких це не влаштовувало:
— Я вам там усе написав чи написала в ТЗ, ваше діло — виконувати, а не ставити мені запитання. Я все знаю краще за будь-якого аналітика.
— Там навіть скриншоти є, що ж ви такі нетямущі?
— Ну ви ж програмісти! Я не розбираюся в цьому вашому програмуванні, зробіть те, що написано.
Навіть не знаю, яка з фраз найбільше нас спантеличувала.
Була ще одна група, мабуть, охоча «увійти в АЙ ТІ», яка завдавала найбільше проблем. Замість другої частини там був потік свідомості. Начебто щось написано, але змісту й суті не вловити.
Зате є відчуття власної величі:
— Це чудове ТЗ, там усе є. Вам щось незрозуміло, так? Ви не знаєте нотації BPMN? Вам незрозумілі назви змінних? Давайте я все поясню...
І дивиться при цьому на тебе з таким жалем...
Бережіть аналітиків.