Влітку ми говорили з Володимиром Беком про те, що значить бути підприємцем, як будувати свої проекти і як вести їх до успіху. Сьогодні ми зосередимося на типових помилках, які роблять молоді підприємці, працюючи над своїм стартапом. До речі, це інтерв’ю буде корисно почитати не лише тим, хто запускає свій проект, а й тим, хто працює зі стартапами.
Наш сьогоднішній співрозмовник – Олексій Столітній, Managing Director в Sigma Software Inc. (США). Більше 10 років Олексій працює зі стартапами в Америці і Європі, він не з чуток знає, на які «граблі» найчастіше наступають стартапери.
До команди Sigma Software Олексій приєднався, навчаючись на першому курсі ХНУРЕ. Протягом усіх цих років він займався різними задачами, спочатку був програмістом, потім менеджером проектів, в 2010 році став головою департаменту мобільних рішень і провів на цій позиції шість років. За цей час департамент виріс з 15 осіб до 65. У 2015 році, з відкриттям першого офісу Sigma Software в Америці, Олексій переїхав в США і займається розвитком американських офісів. Зараз їх уже чотири: в Лос-Анжелесі, Нью Йорку, Сіетлі та Сан Хосе. Майже всі замовники, з якими він працює сьогодні – стартапи.
Олексій, на твою думку, чим найчастіше «обпікаються» стартапери?
Досить часто, коли ми починаємо працювати з новим стартапом, я задаю питання: що, на ваш погляд, важливо для проекту в перші тижні і місяці? І чую дуже різні відповіді: отримати клієнта, придумати круті фічі, провести аналіз ринку, завести знайомства, і ще багато чого. Але насправді, ваша головна задача на самому початку – перевірити свою бізнес ідею, зрозуміти працює вона чи ні.
Ось простий приклад. Припустимо, ви вирішили заснувати компанію, яка буде продавати вікна. Що ви будете робити насамперед? Напевно, продумаєте, чим ваші вікна будуть відрізнятися від інших на ринку, визначитеся з матеріалом, кольором, замовите різні ручки, що повторюють форму пальців? Ви витратите на це цілий рік і всі ваші кошти, і все це лише для того, щоб виявити, що ваші вікна ніхто не купує, бо обраний вами матеріал на поверхах вище десятого йде тріщинами від вітру.
А що ж потрібно робити?
Proof of concept з мінімальним набором фіч, витративши при цьому мінімальну частину коштів. Потрібно постійно проводити краш-тести для проекту, щоб на початковій стадії виявити проблеми, з якими продукт не зможе далі жити. Якщо повернутися до питання про вікна, то замість того, щоб витрачати час і гроші на підбір кольорів, ручок та інших «примочок», обравши матеріал вам потрібно протестувати, як він себе веде в різних умовах. Якщо він йде тріщинами, значить потрібен інший. Спробували інший, але він виходить занадто дорогим? Значить спробуйте третій. І так поки не знайдеться ідеальний варіант, з яким вже можна працювати далі.
Ваша бізнес модель повинна працювати на практиці, а не у вашій голові. Щоб це зрозуміти, не потрібно одразу навантажувати продукт всіляким функціоналом. Оберіть мінімальний. Але при виборі будьте обережні. Поширена помилка стартапів – вибір непотрібних або не тих фіч для першого етапу. Ваш функціонал, навіть мінімальний, вже на початковому етапі повинен забезпечувати повний цикл. Якщо ви зробили вікна, але не врахували, що в них повинно стояти скло – ви не перевірите, чи працює ваша бізнес модель. Вона не буде працювати просто тому, що в ній не вистачає життєво важливих речей.
Найкраще ця ідея відображена на діаграмі Minimum Viable Product – створюйте зріз всіх прошарків, замість того, щоб робити повністю лише один з них.
Ще одна поширена помилка – «контракти має сенс укладати, коли продукт повністю готовий». Це не так. Шукати клієнтів і продавати їм продукт потрібно одразу. Так, нехай спочатку його ціна буде куди менше тієї, яку ви планували – просто тому, що ваше рішення ще не повністю готове. Натомість у вас буде можливість на практиці перевірити, як працює ваша ідея в реальних умовах, отримати фідбек від замовника і, нарешті, получити гроші, які можна інвестувати в доопрацювання продукту.
До речі, з монетизацією затягувати теж не варто. Нерідко доводиться чути: «Запустимо зараз додаток безкоштовно, наберемо аудиторію, а потім зробимо його платним». Це помилка. Повірте, ваша аудиторія, звикнувши користуватися продуктом безкоштовно, після не захоче за нього платити. А частина користувачів встановили додаток тільки тому, що він був безкоштовним. Важливо монетизувати одразу, нехай спочатку і за меншу вартість.
І не потрібно захоплюватися поліпшеннями та оптимізацією – це порада і для тих, хто володіє стартапом, і для тих, хто зі стартапами працює.
Хіба оптимізація не піде на користь продукту, не зробить розробку швидше і дешевше?
Зробить, якщо підходити до неї зважено. Але такий підхід бачиш не часто.
Якщо ваша команда мотивована і відчуває відповідальність за продукт, який робить, зрозуміло, що кожному хочеться щось поліпшити – в процесах, підходах, в коді і т.д. Але ніхто не відстежує і не аналізує: а чи дійсно буде краще, або як в тій приказці: «хотіли як краще, а вийшло «як завжди». Чи справді рефакторинг, який запропонував розробник, принесе користь або від нього буде тільки затримка?
Як це контролювати? По-перше, провести дослідження, визначити показники, які будуть важливі для бізнесу, які поліпшення насправді допоможуть продукту швидше розвиватися, а які ні, скласти метрики і визначити KPIs. Останні повинні мати цінність для продукту і бізнесу. Поліпшення в дусі: «у нас було 100 рядків коду, а стало 90» – нічого не дасть. Ваші дії повинні скорочувати витрати, час, допомагати продавати продукт – тоді на них варто витрачати час, гроші та енергію.
Ти сказав: «якщо ваша команда мотивована». А що робити, якщо ні, і чому таке трапляється? Адже вважається, що найбільш цікаві проекти – це як раз стартапи.
Мотивація команди залежить не від проекту, а від того, як побудована робота. Досить часто доводиться бачити ситуації, коли команда не знає концепцію і не розуміє, як буде працювати майбутній продукт, для кого він і які проблеми вирішує. Щоб заповнити цю прогалину, кожен член команди вибудовує свої припущення, які можуть бути далекі від істини. Такі проблеми породжує брак спілкування бізнесу і команди. Іноді доводиться спостерігати, як розробників штучно «екранують» від замовника, залишаючи їм можливість спілкуватися тільки з менеджером проекту.
При такій роботі частина інформації обов’язково буде губитися, у команди не буде відчуття, що вони щось вирішують у долі продукту, не буде розуміння чому приймаються ті чи інші рішення. Команда не відчуватиме гордість за виконану роботу, і як результат – команда демотивована.
Будь ви засновником стартапа, Product Owner, проектним менеджером або розробником – ви повинні бути зацікавлені в тому, щоб налагодити ефективне і постійне спілкування один з одним 🙂
А якщо ви лише плануєте свій вхід в IT, обирайте онлайн курси програмування від Sigma Software University.
