Технічне завдання на розробку: як описати проєкт, щоб його точно оцінили

Опис проєкту — ще не ТЗ

Запит на ціну легко відкласти до того часу, коли з’явиться повне ТЗ. Але воно для цього не потрібне. Опис проєкту пояснює, що має робити продукт і для кого; технічне завдання — як саме його будуватимуть, екран за екраном і метод API за методом. Детальне ТЗ зазвичай складають під час узгодження обсягу робіт разом із командою, яка будуватиме продукт, бо саме вона знає, які деталі впливають на ціну, а які ні.

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

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

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

Дев’ять частин опису, який можна оцінити

1. Проблема і в кого вона є

Два-три речення. Що сьогодні не працює чи чого бракує, у кого саме й чого це їм коштує. «Менеджери щодня годинами відповідають на дзвінки „де моє замовлення“, бо клієнти не бачать статусу» корисніше, ніж «нам потрібна CRM».

2. Як виглядає успіх

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

3. Користувачі й ролі

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

4. Головний сценарій, крок за кроком

Опишіть один шлях, який має працювати від початку до кінця, — пронумерованим списком від першої дії користувача до моменту, коли він отримує користь. Наприклад:

1. Клієнт реєструється за поштою й одноразовим кодом.
2. Клієнт створює замовлення й додає документи.
3. Менеджер переглядає замовлення й встановлює ціну.
4. Клієнт платить карткою.
5. Клієнт стежить за статусом, доки замовлення не виконано.

Потім додайте найважливіші альтернативні шляхи: що буде, якщо оплата не пройшла, замовлення скасували чи документ відхилили.

5. Функції, розкладені за пріоритетом

Не список побажань, а впорядкований список. Досить трьох колонок:

Усе з першої колонки потрапить в оцінку. Дві інші підкажуть студії, як спроєктувати першу версію, щоб решту можна було додати без переписування.

6. Платформи

Веб, iOS, Android, Telegram Mini App, адмінка — і чому саме вони. «Наші клієнти замовляють з офісу, а кур’єри працюють з телефонів» — це причина; «у всіх є застосунок» — ні.

7. Інтеграції й наявні системи

Усі системи, з якими продукт має обмінюватися даними: платіжні сервіси, облік, CRM, сервіси розсилок і SMS, карти, API партнерів. Для кожної напишіть, які дані й у який бік рухаються, і додайте документацію, якщо вона є. Окремо згадайте дані, які вже існують і які треба перенести в новий продукт.

8. Обмеження

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

9. Приклади й орієнтири

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

Шаблон, який можна скопіювати

1. Проблема: у кого вона є, чого коштує сьогодні
2. Успіх: один вимірюваний результат першої версії
3. Ролі: усі типи користувачів, включно з адміністраторами
4. Головний сценарій: пронумеровані кроки від першої дії до користі,
   плюс що буде, коли щось пішло не так
5. Функції: на старті / незабаром / згодом
6. Платформи: веб, iOS, Android, Mini App — і чому
7. Інтеграції: системи, напрям даних, документація,
   плус наявні дані для перенесення
8. Обмеження: кінцевий термін, діапазон бюджету, правила, обсяги
9. Орієнтири: продукти й екрани, що подобаються, і чому

Приклад заповненого опису

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

1. Проблема. Менеджери приймають бронювання телефоном і ведуть їх у таблиці. Ту саму машину часом бронюють двічі, а клієнти не бачать, що вільне.
2. Успіх. Половина бронювань — онлайн протягом трьох місяців після запуску.
3. Ролі. Клієнт, менеджер, працівник складу, адміністратор.
4. Головний сценарій. Клієнт обирає техніку й дати, бачить ціну й наявність і вносить передоплату карткою; менеджер підтверджує; склад позначає видачу й повернення. Якщо оплата не пройшла, бронь не утримується; якщо менеджер відхилив бронювання, клієнт отримує всю суму назад.
5. Функції. На старті: каталог, календар наявності, бронювання, оплата карткою, статуси. Незабаром: нагадування листом і звіт про те, як часто орендують кожну машину. Згодом: окремий застосунок для складу.
6. Платформи. Веб для клієнтів і менеджерів; працівники складу користуються телефонами, тож їхня частина продукту має зручно працювати на телефоні.
7. Інтеграції. Облікова система (перелік техніки й рахунки) і платіжний сервіс для карток; близько 300 позицій треба перенести з таблиці.
8. Обмеження. Запуск до весняного сезону, діапазон бюджету, персональні дані клієнтів, до 50 бронювань на день у сезон.
9. Орієнтири. Вибір дат на сайті бронювання готелів, який їм подобається, і поточна таблиця — у вкладенні.

Дві студії, прочитавши такий опис, уявлять той самий продукт. Жодній не доведеться вгадувати, хто такий працівник складу і що буде, коли картку відхилено.

Слабкі й точні формулювання

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

Прогалини, через які оцінки помиляються

• Приховані ролі. Адміністратор, бухгалтер, партнер, якому «треба лише дещо бачити».
• «Прості» інтеграції без документації й тестового доступу.
• Не названі обсяги. Каталог на 200 товарів і каталог на 200 000 — різні проєкти.
• Наявні дані. Роки таблиць, які треба імпортувати й почистити.
• Юридичні вимоги, що з’являються на п’ятому тижні: згоди, місце зберігання даних, рахунки в певному форматі.
• Що вже є. Бренд, дизайн, бекенд, домен, акаунт розробника в App Store чи Google Play — або нічого з цього.

Чи робить деталізація проєкт дорожчим?

Зазвичай навпаки. Студії оцінюють невідоме як ризик. Розмите формулювання отримує щедру оцінку, бо студія мусить покрити найдорожче тлумачення; точне — оцінку рівно того, що ви описали. До того ж деталізація скорочує кількість запитань від команди до договору, а отже, наближає старт.

Справедливий виняток — деталі, які не важать для першої версії. Витрачайте зусилля на головний сценарій, ролі й інтеграції, а не на колір кнопок. Якщо сумніваєтеся, чи потрібна певна деталь, запитайте себе: чи зміниться від неї обсяг роботи? Якщо так — запишіть її.

Пишіть з думкою про приймання

Добрий опис уже містить відповідь на запитання, яким завершується кожен модуль: чи це готово? Якщо головний сценарій записано кроками, а для кожної функції є речення про те, що вона має робити, ці самі речення згодом стануть критеріями приймання. Саме це робить перевірки короткими, а суперечки — рідкісними. Докладніше — у статті як приймати роботу в розробника.

Три помилки, що зводять опис нанівець

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

Перевірте опис, перш ніж надсилати

Дайте його колезі, який нічого не знає про проєкт, і попросіть переказати головний сценарій своїми словами: хто що робить, у якому порядку і що продукт робить у відповідь. Якщо колега спотикається, спіткнеться й студія. Потім перечитайте опис очима конкурента: чи зрозуміло, для чого продукт і хто за нього платить? Якщо обидві перевірки пройдено, надсилайте.

Що далі відбувається з описом

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

Що надіслати в EVA-X

Технічне завдання й спеціальне оформлення не потрібні. Опишіть продукт своїми словами, вставте посилання на конкурента, додайте PDF, файл Word чи зображення або запишіть голосове повідомлення — і оцінка приблизно за 15 секунд перетворить це на модулі з годинами, термінами й ціною. Потім команда читає опис і оцінку, уточнює прогалини — у кабінеті чи телефоном — і підтверджує обсяг та ціну ще до договору. Опис, побудований на дев’яти частинах вище, просто робить цю розмову коротшою. Що буде далі, читайте в статтях фіксована ціна чи погодинна оплата і скільки коштує розробка MVP. Більше про те, як ми працюємо, — на сторінці розробка програмного забезпечення на замовлення.