10 помилок при створенні ТЗ на мобільну розробку

15-11-23

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

Для чого потрібно технічне завдання на мобільну розробку 

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

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

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

Помилка 1 – технічне завдання створено без попередньої аналітики

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

• додаток ризикує стати незручним, неактуальним для ЦА, не відповідати реальним вимогам користувачів;
• закладається функціонал, який подобається замовнику, але не вирішує повний комплекс бізнес-задач;
• застосунок може помітно програвати на фоні конкурентів;
• ускладнюється подальше просування, коли немає росту аудиторії або приходять нецільові користувачі.

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

Помилка 2 – пункти техзавдання недостатньо деталізовані

Технічне завдання – це не просто опис застосунку. Це перелік деталізованих вимог до всіх складових продукту – від його зовнішнього вигляду до логіки роботи, де чітко зважене та обгрунтоване кожне слово. Узагальнені формулювання (“красивий”, “складний”, “стильний”, “функціональний” і тому подібні) без детальних пояснень можуть по-різному трактуватися замовником і виконавцем, що призводить до непорозумінь. Наприклад, замість поняття “розгорнута структура” потрібно прописати конкретний перелік розділів і логіку їх взаємодії, оформити ці вимоги у текстовому форматі або у вигляді блок-схем, ескізів, прототипів. Більше деталізації – швидше йде процес розробки, адже всі нюанси узгоджені, не потрібно витрачати час на додаткові обговорення, план роботи оптимізовано з урахуванням вимог ТЗ.

Помилка 3 – неповноцінний зміст технічного завдання

Якісне технічне завдання містить інформацію про всі складові проекту:

• структура, кількість і вкладеність розділів, особливості навігації;
• логіка роботи, перелік функцій, алгоритми взаємодії компонентів у форматі блок-схем user-flow;
• інтерфейс, стиль дизайну, структура сторінок у вигляді ескізів wireframes;
• призначення і можливості адміністративної панелі;
• вимоги до back-end частини; 
• перелік технологій, які будуть використовуватися при розробці;
• особливості операційних систем, для яких створюється застосунок;
• вимоги до безпеки, конфіденційності;
• алгоритми тестування, контролю якості.

Недостатнє опрацювання хоча б однієї складової нівелює цінність всього техзавдання, повноцінна реалізація проекту значно ускладнюється.

Помилка 4 – не враховані особливості операційної системи

Мобільна аудиторія ділиться на дві групи – користувачі девайсів Android та iOS. Кожна з цих платформ має свої особливості та вимоги до застосунків, що обов’язково враховується під час розробки. Щоб додаток коректно працював на всіх пристроях, створюються окремі нативні версії під кожну операційну систему або єдиний кросплатформний продукт, адаптований під вимоги обох ОС. Нативна розробка передбачає розробку двох додатків для Android та iOS, що дозволяє врахувати всі вимоги операційних систем. Гібридний варіант вимагає певного компромісу, але має іншу перевагу – скорочує терміни і трудовитрати на розробку. Перед формуванням технічного завдання потрібно остаточно вирішити, яким буде мобільний застосунок – нативним або гібридним (кросплатформеним).

Помилка 5 – не опрацьовано користувацькі сценарії

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

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

Користувацькі сценарії простих застосунків є короткими та очевидними – достатньо описати їх блок-схемами або текстом. Для складних додатків потрібне інтерактивне прототипування, яке дає можливість узгодити і протестувати сценарії ще до початку програмування і розробки дизайну.

Помилка 6 – зміни у затвердженому ТЗ не фіксуються письмово

Оптимальний варіант, коли техзавдання розробляється раз і назавжди, не потребуючи змін. Але ніхто не застрахований від непередбачених обставин, які змушують вносити правки до ТЗ. Небезпечна помилка в такій ситуації – обмежитися усною домовленістю. І навіть якщо це “лише одна маленька правка”, вона може потягнути за собою інші незаплановані зміни. Все це – зайвий клопіт, збільшення трудовитрат і зрештою вихід за межі бюджету. Чим сильніше проект віддаляється від технічного завдання, тим менше шансів на успішну, якісну і вчасну реалізацію. Тому замовнику і виконавцю вигідно не просто домовитися про зміни в ТЗ, а прописати і затвердити правки. Це займе певний час, але зекономить нерви та ресурси у майбутньому.

Помилка 7 – не затверджено календарний план робіт

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

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

Помилка 8 – не закладено потенціал для розвитку додатка 

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

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

Помилка 9 – замовник створює ТЗ без допомоги розробників

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

Помилка 10 – замовник не бере участь у створенні ТЗ

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

Отже, написання ТЗ має стати комплексною роботою за участі замовника і команди розробників – програміста, дизайнера, маркетолога (фахівця по просуванню), бізнес-аналітика, керівника проекту. Тільки такий підхід дозволить уникнути зайвих витрат часу та бюджету, забезпечити повне порозуміння між замовником та виконавцем, реалізувати проект вчасно та у повній відповідності “очікування і реальності”.