Мобільна розробка – складна послуга, яка вимагає вкладення коштів та часу замовника. Як зрозуміти, що розробник спроможний реалізувати проект? Як правильно побудувати співпрацю, зробити якісний додаток з першого разу? Назвемо 7 поширених ситуацій, результатом яких стають невиправдані надії замовника. Але всього цього можна уникнути, якщо заздалегідь враховувати деякі нюанси побудови взаємин з підрядником.
Причина невдачі # 1: Менеджер з продажу завищує очікування і обіцяє золоті гори
Перший, з ким знайомиться клієнт – це менеджер з продажу (сейлз). Він – представник компанії-розробника на етапі вибору підрядника. Головна мотивація сейлза – продаж. Чим більше контрактів і чим вони дорожчі, тим вищий його бонус. Сейлзам кожного деня доводиться спілкуватися з великою кількістю потенційних клієнтів, одиниці яких перетворюються на замовників. Тому вони часто занижують вартість і завищують перспективи майбутнього проекту. Так легше продати.
Що варто враховувати
Живе спілкування та наснага сейлза – це чудово, але краще познайомтеся з людиною, яка буде керувати розробкою. У нього напевно більш реалістичні погляди на проект, терміни і вартість. І дивіться на факти. Якщо у компанії портфоліо не дуже, а сейлз каже, що вони все зроблять на вищому рівні – можливо, у них крутий менеджер з продажів, а не команда. (Як оцінювати роботи в портфоліо – читайте нижче.)
Причина невдачі # 2: Недостатня технічна експертиза підрядника
Болюче питання для багатьох замовників: як зрозуміти, що ці хлопці потягнуть рівень проекту і не доведеться через рік переписувати все з нуля? Як дізнатися, що «під капотом»? Якщо у вас немає людини, здатної якісно оцінити код підрядника, то ось декілька порад, які дозволять мінімізувати ризики.
Що варто враховувати
– Подивіться роботи підрядника. Зручність додатків, рівень дизайну, відгуки в «сторах» та історію оновлень.
– Скачайте і протестуйте додатки. Не просто увімкніть, а спробуйте виконати сценарії використання. Особливу увагу приділіть нестандартним сценаріями. Наприклад, роботі без або з поганим інтернетом.
– Вивчайте останні випущені додатки. Багатьом компаніям на зорі мобільної розробки пощастило попрацювати з великими брендами, але це було давно. Дізнайтеся, що із себе представляє компанія зараз.
– Сильні розробники часто діляться досвідом і знаннями: виступають на конференціях, пишуть статті, діляться напрацюваннями в github. Поцікавтеся внеском компанії в галузь.
– «Не складайте всі яйця в одий кошик». Укладіть договір не на весь проект, а на малу частину. Якщо терміни будуть зірвані або якість буде кульгати, можна з мінімальними втратами переключитися на іншу компанію.
Причина невдачі # 3: Позначено неадекватні терміни
Завжди враховуйте ризики. Розробник може некоректно оцінити час, замовник може затриматися з відповіддю на запитання і оцінкою роботи. Причин для зриву термінів може бути маса, тому потрібно страхуватися. Більшість компаній додає в оцінку буфер – час на узгодження і налагодження або ризиковий бюджет. З досвіду, мінімальний термін розробки проекту буде складається з наступних пунктів:
– узгодження і підписання договору – 1 тиждень;
– збір вимог на розробку і написання ТЗ – 2-3 тижні + час на узгодження;
– проектування інтерфейсу – 1-2 тижні + час на узгодження;
– дизайн – 1-2 тижні + час на узгодження;
– розробка – 1 місяць;
– тестування і налагодження – 1 тиждень + час на тестування замовником.
– завантаження додатків в App Store і Google Play – 1-2 дня, якщо все пройде добре.
– РАЗОМ (від ідеї до втілення проекту) – мінімум 2,5 місяці.
Частина цих етапів можуть відбуватися паралельно, але рідко буває швидше. І не забувайте, що якщо сьогодні ви домовилися, не факт, що вже завтра почнеться розробка. Коли компанія затребувана, співробітники не сидять склавши руки і приступити до роботи зможуть, коли закінчать поточні завдання. У топових компаній цей термін іноді займає кілька місяців.
Що варто враховувати
Дивіться реально на терміни виконання і використовуйте стратегію MVP (Minimum Viable Product): почніть з мінімального функціоналу. Якщо вам потрібен «зореліт» через тиждень, то ви вже спізнилися. Не треба підписуватися з тими, хто каже, що зможе це зробити. Краще знайдіть тих, хто за 2 місяці зробить вам «кукурузник», ще через місяць «винищувач», а ще через місяць – довгоочікуваний «зореліт». А поки «літальний засіб» удосконалюється, аналізуйте поточні показники. Такий підхід дозволить вам реалізувати якісний продукт в найкоротші терміни і застрахує від неправильного розподілу ресурсів.
Причина невдачі # 4: Неправильно розрахований бюджет
З боку виконавця бюджет безпосередньо залежить від точності оцінки термінів і ризиків. З боку замовника бюджет заснований на його розумінні ринку або досвід спілкування з іншими розробниками. Багато хто хоче розробку «під ключ» за ту суму, яка є. Але такого не буває ніде. Коли програма розроблена, наступний етап – внутрішні роботи по залученню аудиторії та аналізу метрик. На основі цих даних приймаються рішення про доопрацювання і розвитку продукту, а це теж коштує грошей. Не існує успішних продуктів, які не випустили хоча б десяток оновлень.
Що варто враховувати
Тримайте в голові, що вам знадобиться додатковий бюджет на розвиток і просування. Краще спростите ідею до мінімуму і реалізуйте (про MVP я вже говорив). Зосередьтеся на основному функціоналі, інше вам підкажуть користувачі. А після релізу розвивайте виходячи з даних аналітики і відгуків аудиторії.
Причина невдачі # 5: Невдалий проект
Безглузді проекти можуть принести гроші, але їх не можна покласти в портфоліо. Досвідчені студії не беруться за них. Доробок не буде, оскільки проект помре при старті, а команда проекту буде противитися робити те, що нікому, крім замовника, не потрібно. Самі вперті і талановиті розробники можуть навіть звільнитися, ще й команду прихопити, тільки б не займатися тим, що відверто не подобається. Погані проекти демотивують. Якщо ви принесли купу грошей і прийшли з відверто нікому не потрібним проектом, адекватні розробники запитають вас: як і хто буде користуватися цим додатком, як ви на ньому будете заробляти і як плануєте розвиватися. Можливо, ви зрозумієте, що у проекту немає перспектив і не варто витрачати на нього ресурси, або змініть бачення в ході обговорення. (Але це не означає, що інші розробники не поласяться на ваші гроші без будь-яких обговорень.)
Що варто враховувати
Порада стартапам
Вивчіть конкурентів і аналоги. Якщо їх немає – поганий знак. У такому випадку потрібно бути впевненим, що ідея буде затребувана. Хороші ідеї витають в повітрі і, швидше за все, ваше ноу-хау вже хтось робить, може навіть випустив. Це не означає, що слід відмовитися від проекту, просто варто врахувати помилки конкурентів і зробити краще.
Порада функціонуючому бізнесу
Наявність мобільного додатку не приведе вам одразу купу нових клієнтів. Для багатьох сфер бізнесу додатки взагалі не потрібні. Спирайтеся на цифри і аналітику.
Порада для всіх
Запитайте потенційних клієнтів, чи потрібний їм додаток. Створіть опитування або зробіть лендінг. Відгуків друзів мало, щоб об’єктивно оцінити продукт. Постарайтеся зібрати якомога більше даних і кількісних підтверджень.
Причина невдачі # 6: Незнання власного продукту
Для точної оцінки потрібні докладні матеріали (ТЗ, мокап екранів). Чим менше попередніх даних, тим нижчою буде точність оцінки.
Порада
Якщо ваша ідея хороша і вам потрібно мобільний додаток, розпишіть хоча б коротко: що вміє, навіщо потрібно користувачеві, що буде робити і як ви плануєте заробляти на ньому. Такий документ займе мінімум 2-3 сторінки, але навіть це допоможе вам чіткіше сформулювати ідею, а розробникам – більш точно оцінити проект на етапі пресейл.
Причина невдачі # 7: Невикористання експертизи підрядника
Іноді замовник забуває про кінцевого споживача і керується інтуїцією, власним смаком або порадами друзів. Такі рішення можуть обернутися повним провалом, якщо вчасно не зупинитися.
Проста порада
Порадьтеся з підрядником. Студія, як правило, бачила сотні проектів і тисячі екранів, набила гулі і виправляла купу багів. Мета студії – взаємна вигода: замовник отримує працюючий продукт, який приносить йому прибуток, а студія – гроші за розробку, хороший проект для портфоліо і, ймовірно, контракт на подальшу підтримку програми (як було сказано вище – з додатком, яким люди дійсно користуються, потрібні доопрацювання та оновлення).
Висновок: як отримати те, що потрібно?
Для розробки якісного продукту і замовник, і виконавець повинні працювати як злагоджена команда. Це означає, що ви повинні знайти потрібних виконавців і дотримуватися простих правил «гри».
На самому початку:
– визначіться, який проект ви хочете зробити, хто його ЦА, як на ньому заробляти;
– опишіть проект і постарайтеся виділити MVP;
– визначте, який виконавець вам потрібен. Виберіть два з трьох параметрів: дешево, швидко, якісно.
При виборі виконавця:
– орієнтуйтеся на портфоліо і відгуки;
– досвід і технічну експертизу;
– склад команди і думка / ставлення до проекту.
Починаючи роботу:
– узгодьте періодичність і формат звітів;
– виділіть час на спілкування з виконавцем або призначте того, хто буде займатися розробкою;
– не прагніть зробити максимум функціоналу за мінімум часу і мінімум грошей. У всьому має бути баланс;
– ще краще, якщо ви почнете з реалізації частини функціоналу, щоб зрозуміти, наскільки вам комфортно працювати разом;
– пам’ятайте про можливі додаткові витрати;
– пам’ятайте, що бюджет і терміни залежать і від вас.
Після запуску проекту:
– стежте за цифрами і показниками;
– прислухайтеся до думки користувачів;
– будуйте гіпотези, вивчайте конкурентів. На основі цього вдосконалюйте продукт;
– пам’ятайте, що завантаження програми в магазини – це лише початок!
Для кого-то це здасться очевидним. Але практика показує, що багато замовників мобільних додатків погано уявляють, як буде будуватися робота з підрядником. Сподіваємося, ці поради скорегують бачення і допоможуть реалізувати якісний проект.
За матеріалами сайту: http://www.cossa.ru/