В колонці для AIN.UA Дмитро Сікорський, власник та керівник компанії UBRAINIANS, наводить типові помилки при розробці програмного забезпечення та розповідає про те, як вибудувати процес розробки, аби все йшло за планом.
1. Відсутність технічного завдання
Це, мабуть, найжахливіше, що може статися з вашим продуктом. Якщо ви не узгодили і не зафіксували з розробником у найменших деталях, що саме ви розробляєте до початку роботи, ви гарантовано згаєте час і гроші на постійні зміни у процесі. Дуже спокусливо почати якомога швидше. Особливо, якщо часу обмаль. Але це ілюзія, що лише навпаки затримає вас.
Єдиний оптимальний шлях отримання гарного результату вчасно — продумати всі сценарії використання програмного продукту користувачами, розробити прототипи інтерфейсів, що забезпечують виконання цих сценаріїв, описати неочевидні моменти текстом і тільки після цього оцінити терміни та вартість розробки.
Навіть якщо мова йде лише про MVP для стартапу (просто у цьому випадку не потрібно заглядати далеко у майбутнє, процес може і навіть повинен іти ітеративно, невеликими кроками). Так ви будете впевнені, що вам вистачить ресурсів зробити найголовніше перед тим, як поринати у деталі.
Простий приклад. Можна занадто пізно згадати, що для більшості українських проєктів вкрай важливо бути двомовними. Але якщо цього не передбачити заздалегідь (особливо, якщо локалізувати потрібно не лише інтерфейс, але й контент), це без проблем може зайняти цілі робочі дні і тижні на пізніх стадіях розробки.
Окрім очевидного здорожчання, робота без технічного завдання має ще один ще більш небезпечний наслідок. Через постійні хаотичні зміни вимог, якість технічних рішень погіршується. Архітектура, що була з любов’ю спроектована під певні початкові вимоги, втрачає актуальність, стає неоптимальною. Цілком її переробити та адаптувати вже не вистачає часу та ресурсів. Також, команда проєкту поступово втомлюється від невизначеності, втрачає енергію та віру в результат, мотивація потребує все більших і більших зусиль, і в певний момент проєкт психологічно стає «небажаним». Через деякий час такої роботи це все накопичується, зробити будь що стає все довше та все важче, і зрештою проєкту приходить кінець.
2. Технічне завдання із білими плямами
Важливо, щоб після ознайомлення з ТЗ у голові виникала повна картина майбутнього продукту, без білих плям. Наприклад, можна написати, що всі нові користувачі мають пройти модерацію перед тим, як отримати повноцінний доступ до сайту.
- Але як саме вони будуть її проходити? Тобто, має ж бути якийсь розділ у панелі адміністрування.
- Які дані там будуть відображатись, які можливості модератор матиме?
- Як модератор буде знати, що з’явився новий користувач?
- Що, якщо реєстрацію користувача буде відхилено, чи зможе він зареєструватись знову з тими ж даними, чи це вже назавжди (і як він взагалі знатиме, що його відхилили та чому) тощо.
Якщо все це не продумати заздалегідь, то в процесі розробки виникнуть і питання щодо фінансів та термінів, і логічні проблеми та неузгодженості.
3. Занадто формальне технічне завдання, яке ніхто не читає
Ще однією частою проблемою технічних завдань є їх надмірна формальність.
Наприклад: «…натискання кнопки «Додати» призводить до відкриття вікна додавання…». Але ж це і так очевидно. Якщо продукт великий, то документ складатиметься з десятків аркушів тексту з нульовою цінністю інформації. Необхідність його прочитати викликатиме величезний супротив.
Справлятися з цим можна по-різному. У себе в компанії ми, наприклад, вирішили робити більш візуальні технічні завдання, основою яких є прототипи. А текстом ми лише доповнюємо необхідні деталі. Наприклад: «…у користувача є 3 спроби ввести код із SMS, після чого його обліковий запис блокується для входу на 30 хвилин…».
Інколи все ж необхідно, наприклад, перелічити поля форми з такими їх параметрами, як обов’язковість, мінімальна чи максимальна кількість символів і так далі, але це є корисна інформація і у цьому немає нічого поганого.
4. Бажання зробити все одразу
Ми проходили це з нашими клієнтами не раз. Усім хочеться зробити краще, більше. Приходять нові ідеї про нові можливості та зручності, хочеться їх одразу реалізувати, переробити і вдосконалити те, що вже є. Години, дні, тижні можуть витрачатися на вдосконалення інтерфейсів чи написання ідеальних текстів. А потім, коли продукт врешті запускається, виявляється, що користувачі дивляться на нього зовсім інакше, інакше бачать його цінність, і що деякі речі, на які було витрачено багато часу, взагалі нікому не потрібні, а замість них потрібні зовсім інші, котрих немає.
Це взагалі стандартна історія. Тому тут є просте правило: краще запустити щось просте якомога швидше, віддати це користувачам та почати збирати від них зауваження і побажання. Це зекономить ваші час і гроші.
І тут навіть не допомагають такі речі, як фокус-групи чи опитування, а тільки реальний досвід експлуатації. Так стається, тому що зазвичай люди займаються своїми справами и знаються саме на них, а не на, наприклад, розробці програмних інтерфейсів. Тому їм вкрай важко зрозуміти наперед яким вони бачать ваш продукт. Але як тільки вони почнуть ним користуватись, вони одразу помітять усі недоліки і ви отримаєте цілу купу думок з цього приводу. Тому і став популярним термін «MVP» — мінімально життєздатний продукт. Це вірний шлях.
5. Некваліфікована технічна команда
Здається, що це доволі очевидно. Погано тут те, що складно зрозуміти, що команда некваліфікована, поки вона не зіпсувала вам проєкт, якщо ви не спеціаліст із розробки програмного забезпечення. І ще більша проблема у тому, що зовні все може йти добре, продукт може виглядати так, як треба, але якщо, наприклад, його архітектуру, або «фундамент», робили люди без досвіду, у нього буде дуже обмежена тривалість життя. Тобто момент, коли ці чи наступні розробники скажуть вам, що «все потрібно переписувати з нуля», настане швидко. Для невдалих стартапів це не проблема, але якщо справа пішла, вам потрібно розвивати продукт, додавати нові можливості, то ось тут неправильна архітектура швидко себе покаже.
Це виглядатиме так: у якійсь момент додавання навіть невеликої нової штуки (такої як, наприклад, фільтр товарів) почне займати багато часу, кожного разу буде з’являтись купа помилок у несподіваних місцях, потрібно буде все більше і більше тестування (та грошей).
То що ж із цим робити?
- Можна мінімізувати ризики, якщо обрати команду і почати з нею лише з прототипування та розробки технічного завдання. У процесі ви побачите наскільки команда розуміє вас та ваш продукт, наскільки вам комфортно з нею комунікувати, наскільки вона віддана своїй справі. Це буде також тест пунктуальності. Тобто, чи своєчасно ви отримаєте цей перший результат. Далі, варто оцінити не тільки зміст технічного завдання, але й форму, у якій воно подане, відсутність помилок (граматичних у тому числі), неточностей, білих плям. Досвід як раз дозволяє уникати більшої кількості помилок та передбачати проблемні місця, отже якщо ви як не спеціаліст будете знову і знову знаходити їх у технічному завданні, то варто замислитись.
- Ви можете запитати розробників щодо стеку технологій, який вони планують використовувати на вашому проєкті. Чому вони обрали саме його, які інші варіанти є, чому було вирішено від них відмовитись. Навіть абсолютно нічого не розуміючи у цій справі ви зможете відчути наскільки ґрунтовними є відповіді. Також, ви можете подивитись статистику популярності різних технологій (дуже легко гуглиться) щоб пересвідчитись, що вам пропонують актуальний набір.
- Важливо робити все поетапно. Зараз дуже популярні «гнучкі методології розробки», типу Scrum (загальніше — Agile). І не дарма. Суть у тому, що ви розбиваєте весь проєкт на невеликі змістовні шматки: реєстрація, обліковий запис користувача, каталог товарів і корзина тощо, і приймаєте кожен із них незалежно. Тобто отримали результат, усе перевірили, підписали акт, оплатили.
- Ну і наостанок, звісно, це роботи та відгуки.
6. Втрата контролю над обліковими записами та кодом
Критично важливо, щоб права на усі ресурси та облікові записи, що використовуються у проєкті, належали вам. Наприклад: доменне ім’я (його втрата взагалі може призвести до необхідності зміни назви проєкту), облікові записи розробника Apple та Google (без них ви не зможете оновити ваші мобільні застосунки), хостинг. Актуальна версія всього вихідного коду всіх складових продукту також має буди доступна вам, інакше можлива ситуація, що в разі припинення відносин з поточною командою розробників вам доведеться все починати з початку.
Також, важливо мати права на використання графічних матеріалів, аудіофайлів тощо, щоб запобігти зайвим проблемам із правовласниками. Є спеціальні сервіси, де можна легально обрати і придбати такі речі.
7. Нехтування важливістю контенту
Враження від продукту складається з дрібниць. Навіть такі речі, як правильна типографіка у текстах чи зрозумілі повідомлення про помилки впливають на відчуття цілісності (що краще, «Наразі з’єднання з інтернетом відсутнє» чи «Error»). Тож важливо написати і відредагувати тексти, підготувати ілюстрації, дотримуватись єдиного стилю.
8. Недооцінювання маркетингу
Важливо зрозуміти, що після того, як ви запустите свій проєкт, про нього дізнається рівно 0 людей. Ніхто, абсолютно ніхто не почне його використовувати просто так. Ніхто не зайде на ваш сайт, не завантажить застосунок. Тож немає жодного сенсу розглядати програмні продукти як, наприклад, додатковий канал продажів, без розуміння наперед маркетингової стратегії, яка дозволить їх просувати. Розробка програмного продукту гарної якості це лише перший необхідний крок, а далі все залежить від маркетингу, рівня сервісу тощо, залежно від вашої сфери.
Якщо проаналізувати успішні стартапи, то багато з них починають маркетингові заходи ще задовго до того, як будуть готові вийти на ринок.
Яким може бути вірний шлях
Напевне, найкращою стратегією для початківця було б підготувати для себе щось на зразок плану або роадмапу, та рухатись по ньому переходячи на кожний наступний етап лише коли ви повністю задоволені результатами попереднього. Так у критичній ситуації ви зможете навіть змінити команду не втративши попередні напрацювання.
Алгоритм може бути таким: проектування/прототипування і написання технічного завдання, оцінка термінів і вартості розробки, визначення того, що буде зроблено у якості MVP та запущено у першу чергу (це може бути лише частиною загального технічного завдання), розділення цього на окремі невеликі шматки, їх поетапна розробка, повне тестування та приймання, далі публікація та запуск продукту, а вже після цього — збір відгуків, внесення змін, додавання можливостей тощо.
Автор: Дмитро Сікорський, власник та керівник компанії UBRAINIANS
