Яких помилкок варто уникати під час запуску свого продукту та чому якість важливіша за запити ринку.
Ми побували на IT Weekend, який проводила компанія SoftServe. Провідні IT-спеціалісти ділились своїм досвідом роботи, зокрема зупинились на поширених помилках.
Для молодих стартапів буде корисною інформація від Олександра Конотопського, CEO Ajax Systems. Він розповів про найбільші факапи, які перешкоджали розвитку його компанії.
Факап 1: Feature Request — основне, а про якість подбаємо потім
Feature Request — це запит на нову функцію продукту, яка ще не реалізована в компанії. Наприклад замовник запитує щось, що ще не підтримується у програмному забезпеченні і т.д.
Саме у цьому сегменті управління допустило помилку. Спочатку Ajax Systems розробляла датчики на батарейках, які сповіщали про зломи, пожежі, затоплення. У цих датчиках звісно був Soft, який управляв всіма процесами. Попит на сучасні системи безпеки завжди користуються популярністю, тому після укладення перших угод почали надходити Feature Request.
Кожен IT-засновник мріє збільшити свій капітал і буде намагатись приймати Feature Request, обіцяти клієнтам якомога більше і змушувати інженерів продукувати результат з подвійною силою.
Чому це не спрацювало? Спочатку компанії вдалося підняти свої продажі, однак потім розробники виявили серйозний недолік свого продукту. Датчики сповіщень почали швидко розряджається. В результаті, мікросхема почала споживати значно більше електроенергії, ніж повинна при нормальному функціонуванні. Внаслідок цього клієнти стали поступово відмовлятися співпрацювати з компанією.
Висновок. Попри фінансові потреби ніколи не можна забувати про якість продукту, інакше стартап втратить всі свої досягнення і повернутись на ринок йому буде вкрай складно.
Факап 2: працювати без перерви, щоб отримати результат від команди
Цю помилку компанія допустила через декілька років. Ajax Systems була вже на ринку і вдосконалювала свої IT-рішення. Після випуску продукту знову почали надходити Feature Requests, однак цього разу компанія не квапилась їх задовольнити, усвідомивши свою неспроможність охопити запити ринку.
Чому? Річ у тім, що дизайн гаджетів та команда, що їх продукувала, не була розрахована на швидке долучення до нових проектів. Щоб вирішити цю проблему, команда почала шукати нових айтішників, щоб лише прискорити свою роботу, а не збільшити виробництво в цілому.
Під час розробки IT-рішень, CEO повинен зібрати все і масштабувати виробництво. Потрібно звертати увагу не тільки на функціональні вимоги, але й оглядатись на майбутнє, в протилежному випадку бізнес просто зупиниться.
Управління компанії часто зосереджене тільки на бізнес-потреби. Це призводить до зниження продуктивності інженерної команди, якій потрібен рефакторинг для перезапуску своїх думок, переоцінки ідей тощо.
Якщо керівник не звертає на це увагу, його команда не генеруватиме ідеї з високою швидкістю та не йти в ногу з часом. Тому Ajax Systems зробила крок назад і в результаті почала знову отримувати набагато більше Future Requests.
Висновок. Бізнес-процеси генерують не тільки зовні, а й всередині команди айтішників. Потенційний погляд на розвиток продукту — головне при його запуску. Ситуацію виправили, і незабаром компанія отримала довгоочікуваний результат.
Факап 3: наймаю чудотворця, а не розробника для збалансованої команди
Цю помилку компанія зробила, взявши великий проект. На цей момент вона мала і досвід і знання, щоб випустити продукцію на запит клієнтів. У цьому випадку мінус був лише один — нестача робочої сили.
Упродовж того періоду команда почала наймати siniour, supersiniour за будь-яку плату, очікуючи швидкої генерації ідей, іншими словами “чуда”. В результаті жодної кореляції між витраченим блоком і продуктивністю інженера не відбулося.
Висновок. Компанія не повинна звертати увагу на брендове ім’я айтішника, його резюме чи інше. Важливо, чи підходить людина команді і чи знайде спільну мову з іншими інженерами.
