Процеси, що підвищують шанси технологічних стартапів на успіх

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Усім привіт! Мене звуть Савицький Артем. За останні кілька років мені пощастило консультувати низку технологічних стартапів, допомагаючи їм запускати та оптимізувати їхні виробничі процеси. Цей досвід дозволив мені побачити безліч унікальних підходів — як успішних, так і не дуже — і зрозуміти, як вони впливають на бізнес.

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

У цій статті я хочу поділитися своїми знаннями та досвідом у застосуванні деяких процесів, інженерних та продуктових практик. Я розгляну ключові стратегії та підходи, які, на мою думку, здатні значно підвищити шанси стартапу на успіх. Ці стратегії містять Lean-методологію, Domain-Driven Design, No-code прототипування, Trunk-based Development та особливості тестування на ранніх фазах у розробці продукту.

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

Lean

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

Lean Canvas

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

На відміну від стартапів, які існували 10-15 років тому, сучасні підприємці не пишуть багатосторінкові бізнес-плани. Натомість вони використовують Lean Canvas. Це стратегічний інструмент, який детально описує бізнес-ідею та її ключові аспекти. Він допомагає швидко оцінити основні складові проєкту.

Прикріплюю посилання на Miro, можливо, комусь буде корисно. Докладніше про кожну частину Lean Canvas ви зможете прочитати окремо — рекомендую книгу Юргена Аппело.

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

Цей метод допоможе вам краще зрозуміти ключові аспекти вашого проєкту та ідентифікувати потенційні проблеми на ранньому етапі.

Ключова перевага Lean Canvas, яку я особливо ціную, — його універсальне застосування. На відміну від бізнес-плану, орієнтованого переважно на партнерів та інвесторів, Lean Canvas підходить для демонстрації всій команді. Це робить його практичнішим інструментом для колективної роботи.

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

Персонажі та цільова аудиторія

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

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

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

1. Проблема «пластилінового користувача» виникає, коли розробники або дизайнери проєктують продукт, ґрунтуючись на абстрактному, нереалістичному уявленні про користувача. Персонажі допомагають подолати це, надаючи конкретні, деталізовані та реалістичні профілі користувачів. Вони мають вік, професію, інтереси та інші реалістичні характеристики, які допомагають команді краще зрозуміти та орієнтуватися на реальних користувачів.
2. Проєктування «під себе» виникає, коли дизайнери та розробники проєктують продукт, виходячи з власних потреб, стереотипів і переваг, а не потреб цільової аудиторії. Персонажі допомагають сфокусуватися на потребах й очікуваннях реальних користувачів, мінімізуючи суб’єктивні уподобання розробників.
3. Проєктування для виняткових ситуацій — ще один синдром. Персонажі дають можливість перевірити рішення на відповідність реальності. Ви можете запитати себе: «Наскільки часто користувач захоче виконувати цю дію? Чи захоче взагалі?». Озброєні цим знанням, ви можете чітко призначати пріоритети різним функціям.

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

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

Висновок

Lean-методологія — не найпоширеніша в Agile, але вплив має значний. Вона ідеальна для стартапів, але менш пасує для «дорослих» бізнес-структур, за винятком, можливо, окремих R&D-проєктів. Принципи Lean, озвучені тут, — це лише частина великої картини. Для глибокого вивчення рекомендую спеціалізовану літературу.

Було цікаво виявити, що принципи Lean простежуються не лише у роботі Product-менеджерів. Цикли дослідження → моделювання → проєктування, що містять процеси інтерв’ю, створення персонажів, розробки контекстних сценаріїв і вимог, мають застосування в різних сферах.

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

Важливим спостереженням було те, що команди, які почали практикувати Lean раніше, адаптуються набагато краще. Але якщо у вас уже є досвід в Agile, не соромтеся застосовувати його в стартапі.

Domain-driven design

Domain-Driven Design є підходом до розробки програмного забезпечення, який ставить у центр уваги бізнес-логіку та потреби користувачів. В умовах стартапу, де ресурси обмежені, а потреба швидкої адаптації до ринку висока, DDD може запропонувати значні переваги. Нижче наводжу ключові аспекти DDD.

Вивчення домену

У процесі впровадження DDD на моїй практиці я помітив, що команди не лише краще розуміють технічні та бізнесові аспекти своєї роботи, але й зміцнюють внутрішній зв’язок. Відсутність глосарію та необхідність вивчення домену «на льоту» в командах, які не використовують DDD, часто веде до технічних боргів та проблем у комунікації. Навпаки, впровадження DDD та створення структурованої доменного мови забезпечують такі ключові переваги:

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

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

Core, Generic і Support

Розуміння того, які бізнес-елементи є ключовими (core), які загальними (generic) і які підтримують (support), має критичне значення для кожного члена команди. Це знання не тільки визначає напрям розробки та планування ресурсів, але й сприяє об’єднанню команди навколо спільних цілей та пріоритетів.

Крім того, ясне розмежування між Core-, Generic- та Support-елементами є основою для стратегічного планування. Воно дозволяє команді не тільки правильно розставляти пріоритети, але й ефективно розподіляти час та ресурси, фокусуючись на ключових елементах, які матимуть найбільший вплив на успіх продукту.

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

Також прикріплюю посилання на Miro.

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

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

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

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

No-code прототипування

Спостерігаючи, як важливо швидко переходити від ідеї до продукту, що тестується, і водночас зберігати ресурси, я звернув увагу на інтерактивне no-code прототипування. Цей підхід дозволяє економити час та гроші, що є критично важливим для стартапів з обмеженими бюджетами.

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

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

Застосування no-code інструментів для створення прототипів прискорює процес розробки та дозволяє оперативно отримувати зворотний зв’язок від користувача, доменних експертів та інших зацікавлених осіб.

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

Швидше за все, ви вже використовуєте інструменти UI/UX, що підтримують інтерактивне прототипування, і вам не доведеться освоювати новий продукт. Ось декілька популярних інструментів, які зможуть вам допомогти в цьому питанні: Figma, InVision, Adobe XD.

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

Важливий компроміс тут полягає в тому, що платформи, подібні до Bubble.io, дозволяють створювати функціональні продукти, але мають обмеження в кастомізації UI. Наприклад, створення складного аналітичного графіку може бути трудомістким та дорогим.

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

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

Trunk-based development

TBD — це методологія розробки програмного забезпечення, яка наголошує на коротких циклах розробки та частих інтеграціях. Основна суть підходу полягає в:

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

У цьому підході всі розробники працюють на одній головній галузі коду (Trunk), що сприяє швидкому впровадженню змін і спрощує процес управління версіями. У цьому розділі не будуть розглядатися конкретні приклади впровадження TBD, для детальнішого вивчення рекомендується ознайомитися з відповідною літературою на цю теми. Замість цього розглянемо основні переваги використання TBD у стартапах.

Time-to-market

Для стартапів критерій time-to-market грає вирішальну роль, де TBD є ефективним інструментом. Традиційний підхід GitFlow не стимулює і не зобов’язує часто оновлювати виробничу версію продукту дрібними змінами. Натомість він схильний утримувати нас від швидкого релізу, надаючи можливість накопичити більше функціоналу для наступного великого оновлення.

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

Feature-flag та A/B-тестування

Feature-flags, будучи ключовою частиною TBD, особливо важливі в секторі B2B та multi-tenant архітектур. Вони надають гнучкість в управлінні доступом до різних функцій продукту для різних груп користувачів, що спрощує процес тестування та плавне впровадження нових функцій.

Використання feature-flags значно полегшує проведення A/B-тестування, даючи можливість оцінювати ефективність нових функцій на конкретних сегментах користувача без ризику для всієї користувальницької бази.

Крім цього, feature-flags дозволяють швидко реагувати на зворотний зв’язок від користувачів, оперативно вносячи зміни в продукт, що сприяє створенню більш адаптивних і орієнтованих рішень. Це, своєю чергою, підвищує шанси на успіх продукту на ринку, роблячи його більш конкурентоспроможним.

Метрики

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

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

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

Висновок

На основі мого досвіду успішність впровадження TBD багато в чому залежить від готовності та адаптивності команди. Також я помітив, що перехід з Git Flow або альтернативним підходом на TBD може бути більш складним та тривалим процесом, порівняно з впровадженням TBD із самого початку розробки.

Основна рекомендація: якщо у вас уже встановлений процес CI/CD або управління релізами, почніть із невеликих змін. Ви задоволені термінами виведення вашого продукту на ринок, але хочете продати A/B-тестування? Тоді першим кроком може стати впровадження feature-flag.

Чи виникають у вас часті конфлікти під час доставки функціоналу, чи з часом функції стають несумісними? У такому разі, TBD може виявитися рішенням, але спочатку пригляньтесь у бік комунікації та планування. Можливо, саме там і криється проблема.

Тестування

Виконання та стратегічне планування тестування відіграють ключову роль у виробничому циклі, причому сильно залежать від загальних розмірів компанії. Процеси тестування в організаціях з 50, 150 та 500+ інженерами суттєво відрізняються одне від одного.

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

Масштабування

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

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

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

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

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

Unit vs E2E

Якщо на вашому досвіді є робота у великій компанії, то ви, швидше за все, знайомі з необхідністю Unit-тестування перед випуском оновлень. У таких компаніях зазвичай ретельно тестують близько 80-90% коду, щоб забезпечити стабільність продукту.

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

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

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

Trunk-based Development та автотести

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

Альфа- / бета-версії та Market-fit

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

Shift right проти Shift left

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

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

Резюме

Усі вищеописані принципи лежать на стику цілей та можливостей компанії. На щастя (або не щастя) можливості тут — початкові.

Наприклад, вам буде складно організувати процес інтерв’ю зацікавлених осіб без прямого доступу до цієї групи людей. Те ж саме можна сказати й про тестування гіпотез — вам же необхідно зрозуміти цінність товару, правда? Впровадження DDD вимагатиме від команди експертності та правильного планування. Така сама тенденція притаманна й іншим принципам.

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

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