3 типові помилки стартапів

2 березня
Ярослав Буга, Business Development Manager, DataArt
3 типові помилки стартапів
Наприкінці минулого року я відвідав Dallas Technology Meetup, присвячений застосуванню Agile-методології у стартапах. Було цікаво послухати історії та думки досвідчених людей, особливо про невдачі у конкретних проектах.

Цікаво, що хоча стартап-середовище сильно відрізняється від ентерпрайз-розробки, помилки в різному оточенні часто виявляються схожими. Просто тому, що люди — не роботи, і від помилок ніхто не застрахований.

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

1. ТЕХНОЛОГІЧНО ДОСКОНАЛЕ РІШЕННЯ НА ПІДСТАВІ ПОМИЛКОВОГО ПРИПУЩЕННЯ

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

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

2. СУВОРЕ ДОТРИМАННЯ ДРУКОВАНИХ ГАЙДІВ

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

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

3. СПРОБА ВМІСТИТИ МАКСИМАЛЬНИЙ ОБСЯГ ФУНКЦІОНАЛУ В ОДИН РЕЛІЗ

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

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

Пам'ятайте, як починав Google? Це була проста пошукова система, пізніше — обмежена за функціональністю система електронної пошти.

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