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

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

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

Якість контенту цього документа безпосередньо впливає на ефективність розробки. Чим детальніше та зрозуміліше описані всі аспекти проєкту, тим швидше та з меншими витратами його можна реалізувати.

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

Роль технічного завдання на розробку сайту чи додатку

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

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

Дружнє нагадування!

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

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

Типи техзавдань для розробників та хто їх пише?

ТЗ бувають різними:

1. Формальне ТЗ. Детальне, зі схемами, діаграмами та специфікаціями. Підходить для серйозних проєктів, де все має бути чітко прописано.
2. Неофіційне ТЗ. У стилі "Ну ти ж розумієш, що я хочу", що часто призводить до катастрофічних наслідків.
3. Агільне ТЗ. Короткі описи завдань, які уточнюються у процесі розробки.

Хто займається розробкою технічного завдання? Залежить від команди. Часто це менеджери, аналітики або навіть сам замовник (якщо дуже хоче).

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

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

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

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

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

Обговорити цілі проєкту

Щоб розробка не перетворилася на хаос, потрібно чітко визначити цілі:

1. Що ми створюємо? (інтернет-магазин, додаток, CRM-систему, чи лише прототип?);
2. Хто цим буде користуватися? (клієнти, менеджери, адміністратори?);
3. Яку проблему це вирішує? (спрощує покупки, автоматизує процеси?).

Без чітких цілей розробка нагадуватиме гру "Збери пазл без картинки".

Опис функціоналу

Опис функціоналу – це перелік можливостей, які має реалізувати команда. Наприклад:

1. Реєстрація користувачів. Через email, соцмережі або магію.
2. Кошик. Користувачі додають товари, не забувають про їх розташування через хвилину.
3. Фільтри. Бо ніхто не хоче гортати 1000 сторінок товарів.

Головне – конкретика. Фраза "Зробити зручно" – не варіант. Краще "Кнопка має бути червоною та виводити сповіщення при натисканні".

Технологічні вимоги

У технічному завданні для програміста важливо визначити:

• сумісність з пристроями (чи буде це працювати на тостері?);
• безпека (наскільки легко зламати систему?);
• продуктивність та швидкість завантаження сторінок (щоб не висло при 1000 користувачах одночасно).

Тут вже серйозно: які мови програмування, які фреймворки, яка база даних? Все це потрібно визначити.

Вимоги до дизайну

Тут важливо:

• кольори, шрифти, кнопки – щоб виглядало красиво та зручно для кожної сторінки;
• логіка навігації – щоб не треба було гуглити "Як користуватися вашим сайтом";
• адаптивність – щоб не виглядало жахливо на мобільних.

Якщо функціонал – це тіло, тоді дизайн – це одяг та макіяж.

Терміни та бюджет

Хороше технічне завдання на розробку сайту чи додатку чітко визначає:

• коли що має бути готове;
• скільки це коштує;
• які етапи контролю.

Це три речі, які завжди обговорюють, але рідко дотримуються.

Ми поділяємо процес розробки на складники:

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

Скласти грамотну інструкцію – це велике та дуже цінне в нашій компанії вміння.

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

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

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

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

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

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

Приклади

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

Ідеального шаблону для технічного завдання немає!

Але чи є привід через це засмучуватися? 🤔

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

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

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

2. Усі ролі розподілені між виконавцями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не будьте ледарями, амігос! 

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

Ваші Brander.ua!