ТЗ (технічне завдання) — це докладний опис задачі, яку потрібно виконати. Від того, як сформульоване ТЗ, залежить, чи потрібна додаткова комунікація, чи правильно вас зрозуміють та наскільки швидко виконають завдання. Які відмінності та що спільного в технічних завданнях розробників, дизайнерів та копірайтерів? Чому не можна попросити дизайнера просто зробити «вау-ефект» або описати задачу розробнику одним реченням? Як працюють із завданнями у продуктових командах? Та чи існує універсальна формула ТЗ? Відповідають Андрій Жулідін, Head of Product & UX в AmoMedia, Віктор Антоненко, Unity Lead в OBRIO, та Настя Бондаренко, Head of Content & Communications в Headway.
ТЗ у дизайні: тест на «велику червону кнопку»
У продуктовому дизайні всі завдання починаються з користувацької історії (User Story), тобто з вивчення потреб аудиторії. Якщо спрощено: дослідження показали, що користувачу не вистачає фічі Х, щоби досягти Y. Базові відповіді на запитання «що зробити?», «для кого?», «що це дасть?» є ядром ТЗ. Далі воно проходить через різні департаменти, обростаючи «м’ясом». На етапі розробки ТЗ вже описано дуже чітко й скрупульозно, починаючи від того, як це має виглядати, і закінчуючи механікою, як це працюватиме.
У графічному дизайні якісні вхідні дані — про користувачів, ринок, конкурентів, позиціювання — допомагають звузити область прийняття рішень. Отже, і результат буде більш передбачуваним.
Деталізація ТЗ також залежить від рівня кваліфікації спеціаліста. Через брак досвіду джуніори ще багато чого не розуміють, тому завдання для них мають бути більш детальними. Чим вище рівень виконавця, тим менше уточнень може містити ТЗ. Сеньйору зайва деталізація тільки заважатиме, і він не зможе зробити свій професійний вклад. У фахівця такого рівня достатньо експертизи, щоб самостійно провести додаткові дослідження.
Завдання для людини, яка проходить онбординг в компанії, також мають бути максимально розгорнутими, з посиланнями на додаткові документи або людей, які можуть допомогти.
Під час співбесід я проводжу тест на «велику червону кнопку»: демонструю кандидатам неправильне ТЗ та оцінюю їхню реакцію. Цінно, коли дизайнер вміє відходити від статус-кво, орієнтуватись не стільки на завдання, скільки на проблему. Тобто не просто зробить червону кнопку, як попросили, а запропонує альтернативне рішення.
Найболісніше, коли в завданні пишуть: «зроби красиво, ти ж дизайнер». Зараз із цим простіше, ринок зростає професійно та змінюється. Але ще років п’ять тому це був досить поширений формат ТЗ.
ТЗ та геймдев: трансформація бізнес-завдання в технічне
Технічне завдання розробнику має бути достатньо зрозумілим, однозначним та вичерпним, щоби він міг узятися до роботи без зайвих запитань та уточнень. Не маючи чіткого ТЗ, члени команди витрачатимуть багато часу на зайву комунікацію. Тому краще обдумати завдання, детально прописати та зафіксувати загальне бачення в документі.
В OBRIO навіть для маленької задачі ми практикуємо заведення карток. Найменші завдання не розписуємо докладно. Коли всі в контексті та розуміють, про що мова, іноді швидше виконати цю задачу, ніж описати. У нас є два типи завдань: баги та фічі/покращення. Баги заводяться напряму розробникам через систему карток, яку створює тестувальниця, усі покращення та фічі — через мене. Я трансформую та декомпозую бізнес-завдання внутрішнього замовника в те, що буде зрозуміло розробнику.
У якому вигляді завдання має прийти до мене? Воно має містити відповіді на шість запитань. Пропустивши ідею через такий фреймворк, стає зрозуміло, чи варта вона зусиль на реалізацію.
Де ця фіча виникає?
Як вона працює?
Який ефект приносить?
Як впливає на все, що відбувається в грі?
На який тип/категорію гравців це орієнтовано?
На які метрики це може вплинути?
Прочитавши ТЗ, розробник має не просто зрозуміти, як працює фіча, а «побачити» це очима користувача: як це виглядає, що відбувається, коли натискаєш на ту чи іншу кнопку тощо. Крок за кроком опишіть всю механіку та всі варіанти дій, які може зробити користувач.
Коли я був джуніором та працював у компанії, де не було інших юніті-розробників, мені приходили загальні ТЗ без уточнень та деталей. Це було дуже незручно. Найгірше в моїй практиці — коли замість правок скидають фікси та коментар «в тебе не так».
Опис бага краще почати з виділення в дужки назви модуля гри, в якому він виник. Так розробнику буде зручно орієнтуватися в системі карток. Далі — покроковий опис відтворення (за яких обставин виник баг та які наслідки спричинив), фактичного та очікуваного результату, додати фото або відео.
ТЗ для копірайтерів: мікроменеджмент чи необхідність
Технічне завдання — це спосіб оформити очікування «клієнта» від кінцевого результату, що надає «виконавець». В Headway продуктовим контентом є самарі, тобто короткий зміст нон-фікшн книжок. Кожна наступна одиниця контенту має таку ж цільову аудиторію, призначення, структуру, формат тощо.
Щоб оптимізувати час на підготовку ТЗ та уніфікувати його, ми використовуємо ґайдлайни. Це розширене технічне завдання, у якому детально описані підходи до створення контенту. Наприклад, структура самарі, кількість слів у кожній главі, кількість виділених ключових ідей та цитат. Аудіоверсія має свій ґайд: вимоги до підготовки та редагування аудіофайлів, їхньої тривалості, інтонації начитки, рекомендації, як підготувати аудіо до завантаження в додаток. Для штатних копірайтерів ТЗ часто замінюють командне обговорення та брифування. Вони є частиною команди, а тому можуть уточнити деталі у колег. Деталізоване технічне завдання в цьому випадку може перетворитися на мікроменеджмент, а його варто уникати. Але у роботі з копірайтером-фрилансером чи новою продакшн-студією весь контекст і вимоги потрібно передати через технічне завдання. Найважливіші три питання, на які має відповідати ТЗ — «що?» (формат та тема), «для кого?» (цільова аудиторія) та «навіщо?» (результат, що очікуємо). У кожного матеріалу є своя задача: познайомити аудиторію з продуктом, покращити пошукову видачу чи допомогти у побудові особистого бренду.
Також мають значення майданчик розміщення (корпоративний блог, медіа чи соцмережі), тон голосу, кількість символів, дедлайн та контекст: що саме обумовило вибір цього інформаційного приводу.
Можна прописати орієнтовну структуру матеріалу або залишити її на розсуд автора, вказати ключові слова, показати референси. Всі ці пункти не є вичерпними і можуть відрізнятися залежно від потреб бізнесу. Незмінними завжди залишаються три питання: «що?», «для кого?» та «навіщо?».
Універсальна формула
Як бачимо, у різних сферах — свої вимоги до опису задачі, але ядром будь-якого ТЗ є користувач. Це те, про що думають спеціалісти всіх професій, виконуючи завдання чи готуючи для нього ТЗ: які емоції в користувача викликає цей дизайн, якою має бути форма даних, щоб її було зручно заповнювати, навіщо йому читати цей текст, що нового читач дізнається з цієї статті, чим йому буде корисною нова фіча в грі, як її реалізувати, щоби він був щасливий?
У разі необхідності додаються: референси, антиреференси, план узгодження (ким і як), інформація чи контакти людини, до якої можна звернутися з питаннями тощо.
В особистому спілкуванні варто окремо підкреслити цінність задачі. Зрозумівши, чому це важливо, на які речі впливає, виконавець вийде з кола «отримав, виконав, забув» та докладатиме максимум зусиль, щоб зробити особистий внесок.