На дорогу розробку піднімаються інвестиції, витрачаються накопичення підприємців. Вона затягує
Чому важливо розпочинати розробку нового продукту з No-code без залучення класичної розробки
Коли ми дивимося на успішні продукти на ринку,такі, як Airbnb, Amazon або Yandex, потрібно розуміти, що такими, якими вони є зараз, вони стали не відразу, і цьому передував довгий і багатоетапний шлях поступового розвитку. Процес еволюції продукту зазвичай має кілька етапів:
- Ідея продукту/бізнесу.
- Прототип – швидка, чорнова реалізація майбутнього продукту.
- MVP (мінімальний життєздатний продукт) - найпростіша версія товару, послуги або сервісу з мінімальним набором функцій (іноді навіть однієї), яка несе цінність кінцевого споживача.
- Продукт 1.0 - продукт, що має більш просунуту функціональність, визначену з потреб клієнтів та бізнесу після успішної реалізації етапу MVP.
- Продукт 2.0 - комплексний продукт з розширеною функціональністю та набором фіч, більш досконалий, ніж продукт 1.0.
- Повнофункціональний продукт (продукт версії n) — розвинений та розширений продукт, функціонал якого розвивається та доповнюється у міру масштабування бізнесу.
Етапи еволюції ІТ-продукту
Перші три етапи є фазою пошукуproduct-market fit, де бізнес або продукт тільки шукає форму та бізнес-модель, рентабельну та потрібну ринку. На цій фазі завдання фаундерів чи власників бізнесу — максимально дешево та швидко протестувати всі гіпотези та знайти те, що працює.
З 4-го по 6-й етапи відбувається фазамасштабування бізнес-моделі, яка показала свою стійкість на ринку та фінансовий успіх. Тут дуже важливо відзначити, що масштабування продукту має відбуватися зі зростанням бізнесу, а бізнес характеризують гроші, які він заробляє. Тобто ускладнення продукту та значне доопрацювання функціональності мають прямо корелювати зі зростанням фінансових показників, але ніяк не навпаки.
Для того, щоб перейти з однієї фази до іншої, необхідно пройти точку біфуркації, яка означає знаходження робочої бізнес-моделі (product-market fit) та старту етапу масштабування.
Один із недоглядів багатьох стартаперів та власниківбізнесу в тому, що вони вважають, що розвиток їх продукту йтиме по такій прямій лінії зі стадії в стадію. Але найчастіше з першого разу ніхто не потрапляє у працюючу та прибуткову бізнес модель. Як правило, доводиться робити від двох до п'яти пивот (від англ. pivot — «зміна бізнес-моделі»), перш ніж знайдеться та сама працююча бізнес-модель, яку варто масштабувати. Саме на стадії пошуку product-market fit застряє більшість компаній-початківців. Це відбувається тому, що стартапери витрачають усі ресурси на розробку MVP, роблять це довго і дорого, так що при необхідності змінювати бізнес-модель продукт стає настільки негнучким, що для них стає неможливим.
Тому у розробці більшості бізнес-продуктів варто застосовувати менш затратні інструменти. No-code - один з них, він ідеально підходить для створення та тестування MVP.
Етапи розробки продуктів за допомогою No-code з нуля
Головна особливість No-code підходу в тому, щоВиробництво MVP-продукту може проходити самостійно без залучення команди, як у класичній розробці. Весь цикл створення продукту від ідеї продукту до запуску може виконати один фахівець.
Розглянемо всі етапи:
Етапи розробки ІТ-продукту
Етап 1. Опис ідеї продукту/проекту
Перш ніж розпочинати розробку, необхідно чітко сформулювати відповіді на питання про те, що, навіщо та чому ви розробляєте. Запитайте себе:
- Що за бізнес/продукт ви бачите?
- Яку проблему вирішує?
- Хто його аудиторія, як він зараз вирішує проблему?
- Чи достатній обсяг ринку, чи є конкуренти, як вони оперують, чому ви робите те саме або відмінне від них?
- Як буде відбуватись монетизація, який бюджет ви готові вкласти розробку MVP-версії?
Етап 2. Упорядкування бізнес вимог
На даному етапі необхідно продумати та описати, як працюватиме продукт, які функціональні вимоги мати.
- Як працює бізнес-модель, як виглядає весь ланцюжок процесу від приходу користувача до завершення замовлення?
- Хто залучений до використання продукту: клієнти, виконавці, рекрутери, бухгалтерія, чи потрібен їм інструментарій і функціонал?
- У яких країнах планується запускати сервіс і якими мовами?
- Які платіжні системи планується використати?
- Які додаткові зовнішні сервіси необхідно використовувати, які виробляти інтеграції?
Етап 3. Виділення MVP (мінімально життєздатний продукт)
В даному випадку з бізнес-вимог потрібновиділити мінімальний набір критично необхідного функціоналу, який дозволить перевірити гіпотезу, тобто сформувати функціонал MVP. Важливо пам'ятати, що основне завдання перевірити життєздатність ідеї, а не розробити повнофункціональний продукт. Необхідно сфокусуватися лише на тому, без чого сама бізнес-ідея не працює, відокремити головне від другорядного.
Етап 4. Підбір стека інструментів
Розуміючи, який функціонал буде реалізовано в MVP,а який залишиться для наступних версій продукту, можна приступити до вибору стека (набору) No-code-інструментів для його реалізації. Це може бути мікс із 2–6 різних No-code-платформ та сервісів. Але варто враховувати: що більше сервісів інтегрується, то більший ризик. Система/продукт стають більш крихкими: якщо одна з ланок не спрацює, то може впасти вся система. Саме тому краще орієнтуватися на оптимальну кількість інструментів у стеку та завжди відстежувати їхню роботу.
Крім того, важливо визначити можливістьпідключення до платіжних сервісів того стека, який обрано, а також перевірити можливість його інтеграції з необхідними зовнішніми сервісами. Подумайте не тільки про те, що потрібно для створення MVP, але ще й про те, як потім (за умови успішності бізнес-моделі) можна масштабувати продукт, і чи не виявиться набір інструментів для перешкод MVP.
Етап 5. Складання продуктово-технічного завдання
Визначившись із тим, який саме функціоналбуде реалізований в MVP і яким набором No-code-інструментів можна переходити до складання продуктово-технічного завдання. Воно включає в себе детальне опрацювання та опис логіки клієнтських шляхів, складу та зв'язків кожної зі сторінок/екранів, опис ролей користувачів та доступи відповідно до них, налаштування приватності, статусну модель замовлень/оплат, відтворення вайрфреймів у Figma та прототипування функціоналу з метою перевірки бізнес-логіки.
Етап 6. Складання бази даних
Цей пункт можна застосувати для розробки повноцінних додатків. Тут важливо виділити основні сутності та їх атрибути, продумати статуси та зв'язки таблиць.
Етап 7. Відображення дизайну
Маючи продуктове ТЗ та вайрфрейми, а також знаючи,на якому No-code-стеку буде реалізовано кожен із елементів продукту, потрібно відмалювати дизайн. Буває, що в деяких No-code інструментах немає можливості кастомізувати дизайн повністю, можна тільки змінити будь-які характеристики: колір, тіні, зовнішній вигляд, фон. Дані обмеження слід враховувати. Але якщо вибраний No-code-інструмент дозволяє зробити кастомний дизайн, можна скористатися шаблонами або залучити дизайнера.
Етап 8. Розробка
У No-code-підході розробка frontend та backendнемає такого явного розмежування і виконується паралельно. Найкраще додаток розділити на частини та послідовно створювати функціональність кожної з них. Наприклад, особистий кабінет клієнта може містити головну сторінку, сторінку входу, сам кабінет та профіль.
Починати найкраще зі створення бази даних. Вона буде пов'язувати всі сторінки/вкладки та частини вашої програми, бути її основою. А далі сміливо приступати до frontend та backend:
Frontend-розробка:
- Створення структури сторінок.
- Розробка елементів інтерфейсу.
- Адаптація інтерфейсу під різні пристрої.
Backend-розробка:
- Створення функціоналу та логіки для кожного елемента/дії/сторінки.
- Завдання внутрішніх процесів/розрахунків системи.
- Створення реєстрації та авторизації користувачів, ролей та налаштування приватності/доступів та інше.
Етап 9. Інтеграції із сервісами
У No-code-інструментах інтеграції із зовнішнімисервісами зазвичай вже нативно вбудовані за допомогою плагінів. Однак часом необхідно робити кастомну інтеграцію через API. Тому на етапі підбору стека варто перевірити, чи є відкрите API у сервісу і чи може No-code-інструмент виконати цю інтеграцію.
Основні інтеграції, які потрібно врахувати дляпродукту: платіжні системи, послуги розсилок (email, SMS), внутрішні послуги (crm, slac), послуги аналітики, послуги конференцій (Zoom). Якщо інструменти та сервіс не мають вбудованої інтеграції, в деяких випадках може знадобитися допомога розробника.
Етап 10. Тестування.
При тестуванні дуже важливо перевіритипрацездатність докладання та коректність функціональності, яка була спочатку закладена при складанні продуктово-технічного завдання. Тестування може проходити кілька етапів, з підготовкою плану, веденням журналу помилок і перевіркою працездатності різних пристроях. Тестування — один із ключових етапів, ставитись до нього варто з підвищеною увагою.
Етап 11. Запуск
Після проведення тестування та усунення всіхзауважень необхідно підготувати продукт до запуску користувачів. Для цього важливо наповнити його контентом (картинки товарів та послуг), провести копірайтинг текстів, додати користувальницьку угоду, угоду на обробку персональних даних, перевірити відповідність усім необхідним початковим вимогам та розпочинати тестування на користувачів.
Після запуску продукту дуже важливо стежити за йогопрацездатністю та підтримкою, звертати увагу на зворотний зв'язок від користувачів, проводити з ними інтерв'ю. Тільки так можна зрозуміти, чи збігаються ті сенси та ідеї, які ви закладали при розробці, з тим, як розуміє та використовує користувач ваш продукт.
Перехід із No-code на класичну розробку
Перехід на класичну розробку релевантний вже тоді, коли No-code стає шийкою пляшки, і ви стикаєтеся з обмеженістю функціоналу, що заважає розвитку бізнесу.
No-code досить потужний інструмент, що дозволяє ускладнювати функціональність із масштабуванням бізнесу. Багато продуктів/бізнесів так і залишаються на ньому.
Однак, якщо ви все-таки зважилися, для переходунайкраще використовувати часткову паралельну заміщувальну розробку. Тобто паралельно з роботою існуючого продукту та процесів розпочинати розробку найбільш критичної частини продукту. Потім поступово переводити дані користувачів на новий продукт, створений за допомогою класичного підходу, і лише потім замінювати сам продукт. Так ітераційно можна повністю перевести всі частини бізнесу з No-code на код.
Початок переходу зазвичай починається із клієнтських зовнішніх продуктів, які вимагають вищої якості дизайну, нативних функцій. Внутрішні продукти можуть зачекати.
Читати далі:
Вчені із зони вічної мерзлоти: як вони розробляють розумний одяг та вакцину проти раку
«Ходячі мерці» існували мільйони років тому: вчені розповіли, як вони з'явилися
Яйце скинули з космосу: подивіться, що сталося з ним.