Технічне завдання це документ, що визначає мету, структуру, властивості та методи будь-якого проєкту, що виключають двозначне тлумачення різними виконавцями.
Коротко кажучи, це такий інструмент комунікації між замовником і виконавцем, наділений баченням, побажаннями та знаннями замовника.
Я вже писав про те, що написане технічне завдання – найкращий спосіб перевірити системність мислення автора. У моїй роботі, під час пошуку фахівців у маркетинг-команди саме технічне завдання – те, що заведено називати тестовим завданням перед співбесідою.
Претенденту не потрібно нічого спеціально робити, достатньо показати ТЗ, яке він робив на минулому місці роботи.
Сьогодні я трохи розповім про те, яким має бути ідеальне технічне завдання для чого завгодно: від банера для реклами у Facebook до відеоінтерв’ю, нового лендінгу чи функціонування форми збору заявок.
1. Що обов’язково має бути у ТЗ:
1.1. Вказівка проблеми. Проблема – чітка та коротка відповідь на питання “яку проблему я хочу вирішити”.
1.2. Інтерфейс. Правило: “якщо ти щось не можеш намалювати, то не можеш чітко поставити ТЗ”.
1.3. Коментарі до інтерфейсу. Правило: “що менше коментарів потрібно до інтерфейсу, то успішніше твоє ТЗ”.
2. Технічне завдання обов’язково має бути розбите на логічні чи функціональні частини:
2.1. Кожна частина ТЗ має бути затитулована та пронумерована, всі пункти всередині кожної частини також мають бути пронумеровані.
2.2. Завжди роби відступи між пунктами, щоб ТЗ було легше сприймати. Не заощаджуй місце.
3. Ключові моменти, описані в ТЗ, повинні бути проілюстровані у вигляді картинок, скриншотів та/або ескізів інтерфейсів. Причому не у вигляді посилань, за якими потрібно кудись переходити, а бути вбудованими в текст:
3.1. Для проєктування зразкових інтерфейсів можна використовувати сервіси типу Moqups.com або навіть Google SpreadSheet і Google Drawings.
3.2. Додай більше прикладів та посилань, якщо бачиш, що твоя думка може бути трактована інакше або з використанням значних розумових витрат.
4. ТЗ має бути вільно від філософських думок та води. Якщо не знаєш, як щось описати, порадься заздалегідь із виконавцем, у нього вже можуть бути приклади подібних завдань від інших замовників.
5. ТЗ потрібно обов’язково складати в Google Docs (або будь-якому іншому сервісі, де тексти можуть одночасно коментувати та правити різні користувачі).
6. Іноді завдання є настільки складним, що є сенс написати загальну концепцію для себе. Потім у цій концепції виділити певні блоки. І ставити ТЗ до кожного із цих блоків.
7. Перше правило для ТЗ щодо доопрацювань готових систем (наприклад, створення нової сторінки в структурі наявного дизайну сайту): “не плоди нових сутностей без 100% необхідності”.
8. Друге правило для ТЗ щодо доопрацювань готових систем: “думай системно – роби все так, ніби цим користуватимуться всі”.
9. Коли ти дописав ТЗ, то спитай себе: чи може виконавець завдання зрозуміти чітко, що ти від нього хочеш, без уточнень. Якщо ні, то допрацьовуй ТЗ.
10. Дійсно гарне технічне завдання буде зрозумілим не тільки вузькому фахівцю, для якого воно готується, але й будь-кому, хто з ним ознайомиться. Саме так я перевіряю тестові завдання претендентів.