ТЗ: розбираємо важливість технічного завдання

Застосунок починається з ідеї. Ви бачите загальну картину, але знаєте, з якого боку схопитися, щоби розпочати? Як же приборкати цей хаос? Відповідь проста — скласти письмовий план. Ми називаємо його ТЗ, ви могли чути також назву технічне завдання. Наскільки якісним буде цей документ залежить від безлічі чинників. Пропоную поговорити про це та обговорити досвід Brander у складанні технічок.

Бізнесмени вихваляються вмінням пояснювати роботу на пальцях, але з технічним завданням так не можна. У процес залучені фахівці: дизайнери, програмісти, копірайтери. Усі вони мають розуміти своє завдання, читаючи документ. Він на всіх один, для кожного писати затратно.

Якщо врахувати, що читатимуть клієнт і команда, технічне завдання — настільне керівництво для обох сторін. Просто кожна бачить у ній необхідне для себе. Ми приступаємо до написання ТЗ одразу після знайомства. Чим раніше ви побачите, якою має бути робота, тим швидше та ефективніше її вдасться виконати.

Дружнє нагадування!
Не сподівайтеся, що зрозуміли один одного 🙃

У більшості випадків це не так. Розробники можуть скільки завгодно розповідати бізнесмену про важливість фреймворку, інтуітивність інтерфейсу та лаконічність коду, але він зрозуміє не більше 30 %. На слух така інформація сприймається дуже складно. Тому ми в доступній формі розписуємо цей документ.

Нам нескладно приділити цьому пару робочих днів, але в результаті ми отримаємо не просто перелік пунктів завдання, а й дороговказ. У ньому вказано ключових виконавців — людей, які займаються вашим проєктом. Ви можете підтримувати зв’язок, просити тримати в курсі проєкту. Ми не проти такої комунікації між клієнтом та нашими хлопцями.

Не рекомендуємо: 
Докладно розписувати всі вміння колег. Клієнт приховано розуміє, що якщо на його шановний проєкт поставили людину, він професіонал за умовчанням. Не змушуйте його в цьому засумніватися.

Розписуємо, скільки годин у нас піде на написання вашої програми. Ділова людина має контролювати свій час на всіх рівнях зайнятості. Ми допомагаємо їй в цьому та вказуємо орієнтовні терміни.

Важливо! 
Застосунок забирає чимало часу доти, доки його доведуть до досконалості. Іноді тестування може вимагати додаткового часу, вам не варто переживати про це. Ми не змусимо переплачувати за ці години, адже завжди враховуємо форс-мажорні обставини, складаючи план.

Грошовий пункт. Найчастішому питанню клієнта ми присвятили не лише пункт технічного завдання, а й лонгрід. Питання виявилося аж настільки комплексним, уявляєте?

Скласти грамотну інструкцію — це велике та дуже цінне в нашій компанії вміння. Ми поділяємо процес розробки на складники:

• ідеологічний;
• маркетинговий;
• механічний;
• приклади.

Ідеологічна частина

Команда має з першого погляду зрозуміти, яка робота їх чекає. Якщо це редизайн сайту, утримайтеся від формулювань «Приведення сайту компанії до нового унікального оформлення». Скорочуйте в місцях, де краще зберегти лаконічність. З іншого боку, пояснюйте клієнтові складні моменти. Наприклад, якщо мова про функції фреймворку, поясніть їх простими словами й додайте, що їх використання принесе клієнту. Виявляйте турботу та терпіння.

Маркетингова частина

Починається з кабінетних досліджень, продовжується в польових, а закінчується знову в кабінеті. Ми перевіряємо ринок, щоби зрозуміти, у яких умовах буде працювати ваш застосунок. Чи потрібно додати просунуті функції, які є в конкурентів? Чи правильний слоган ми вибрали для комунікації? Чи готова до продукту цільова аудиторія? Відповіді на ці питання коштують дуже дорого. Від них залежить успішність розробки.

Механічна частина

Ми визначилися з цілями та тепер хочемо зрозуміти, як робити продукт. На зборах обговорюємо механізми та технології, які підійдуть найкраще. Уже на цій стадії ми дізнаємося про структуру програми, наскільки інформативним робити інтерфейс і як масштабувати продукт у недалекому майбутньому. Останній пункт заслуговує на особливу увагу, тому опис зростання краще супроводжувати діаграмою з наочною статистикою.

Приклади

Так, продукт, що розробляється, оригінальний, але у світі, де інформація поширюється так швидко, ми є продовжувачами ідей, так само як програміст на тому кінці океану спадкоємцем наших напрацювань. Тому немає нічого ганебного в тому, щоби навести якісний приклад. Повірте, куди гірше винайти велосипед, який нікому не потрібний. Сподіваюся, метафора зрозуміла.
 

Ідеального шаблону для технічного завдання немає!
Але чи привід через це засмучуватися? 🤔

Кожне ТЗ унікальне й має висвітлювати конкретні аспекти роботи та бізнесу клієнта. Необхідно пояснювати, чому варто робити саме так, а чи не інакше. Керуйтеся трьома принципами, створюючи застосунок.

1. Не уникайте конкретики

Клієнту та виконавцю варто уникати розпливчастих формулювань, на кшталт: «Гарний шрифт із вензелями». Скажіть одразу Helvetica 18pt. Жодних питань не виникне. У разі віддаленої роботи виникають труднощі із вибором кольору. Описати колір складно, а в параметрах RGB клієнт не розуміється. Краще провести розмову через засоби відеозв’язку та поділитися своїм екраном.

2. Усі ролі розподілені

Ми звикли розподіляти роботу на парні команди. Над застосунком працюють дизайнер та програміст. Якщо ми хочемо уникнути токсичної обстави в цьому дуеті, їх обов’язки мають бути прописані в ТЗ докладно та поетапно. Уже в процесі вони навчаться розуміти де мухи, а де котлети.

3. Говоріть фактами, а не оцінюванням

У словах «красиво», «корисно» та «ефективно» сили рівно стільки, скільки в білому шумі телевізора. Клієнт має на власні очі бачити все, про що йдеться. Не полінуйтеся внести додаткову інфографіку. У цьому форматі зручно представляти цифри проєкту: його бюджет, годинник робіт тощо.
 

❌: ТЗ розробляє одна людина. Їй складно врахувати всі нюанси, але підключати команду він усе ще не наважується.

✅: Командна робота. Відповідальні виконавці допомагають розподілити час та вносять у план деталі, відомі лише їм. Наприклад, програміст може помітити, що на тестування у зв’язку зі складністю майбутніх робіт виділено недостатньо часу. Дизайнер побачить несумісність шрифтів, обраних клієнтом, та маркетингового завдання.

❌: Запевняємо клієнта, що робота буде технічно досконалою. Крім гучних слів, докази не наводимо.

✅: Показуємо приклади робіт і фото/відеодемонстрації будь-якого технічного параметра, що описується. Як інакше клієнт зрозуміє, що йому пропонують? Запам’ятайте, замовники не мають ступеня в комп’ютерних технологіях та програмуванні.

❌: Відмовляємось від проведення дослідження. Довіряємо під час розробки інтуїції, адже вона ніколи не підводила.

✅: Ставимо на обізнаність. Нема чого стріляти наосліп! Дізнаємося, що потрібно ринку та майбутнім клієнтам, а після вносимо відомості в документ.

Любителів не зробити ТЗ багато. Це не лише колеги в Україні, ми стикалися з необов’язковістю також за кордоном.

Засуджуємо такий підхід!

Роботи, що виконуються без ТЗ, відрізняються поганою комунікацією та горілими дедлайнами. Це не дивно, адже виконавець та замовник відмовилися працювати із турботою один про одного.

Чому немає розуміння?

Ви не захотіли вкластися у якісне ТЗ. У результаті замовник до кінця не зрозумів, які процеси виконуватимуться, у які терміни. Йому не повідомили про бюджет, не розповіли про конкурентів. Він як сліпе кошеня, тому візит до агенції залишить у нього поганий післясмак.

Не будьте ледарями, амігос!
 
Пишіть технічне завдання просто і зрозуміло, не опускаючи деталей та піклуючись про клієнта. Це ставлення повернеться до вас подвійним бумерангом подяки.
Ваші Brander!