6 історій про фейли СТО: «Ми захопилися ідеєю продукту і зовсім не подумали про маркетинг. Втрачено два роки праці та $2,6 млн»
[Fail review — рубрика, в якій ми збираємо історії про робочі провали: що відбулось, як виправляли і які висновки зробили.]
Якщо роками розробляти продукт і не пробувати продавати його, є ризик втратити мільйони доларів. Якщо неправильно обрати бізнес-партнера, може виявитися, що вам доведеться піти. CTO компаній розповідають про власні факапи — технічні, комунікаційні та менеджерські, і те, чого вони їх навчили.
Кирило Латиш, CTO у COOLS
Відсутність маркетингу і тестування на користувачах можуть обійтися дуже дорого
Мій перший великий фейл стався в першій компанії, де я був CTO. Ми створювали нову ERP-систему для керування бізнесом. Проблема полягала в тому, що ми сильно захопилися ідеєю продукту, постійно намагалися поліпшити його самостійно, не даючи тестувати людям, і зовсім не подумали про маркетинг.
Продукт розробляли два роки, але щойно він був повністю готовий і ми показали його користувачам, виявилося, що він їм незрозумілий. Продукт був розрахований на максимально широку аудиторію, але кожна окрема компанія, яка починала користуватися ним, бачила купу зайвої функціональності, водночас бракувало специфічних фіч для конкретного типу бізнесу. Людині, яка два роки розробляла продукт, він складним не здавався, а ось тим, хто бачив його вперше, просто підривав мозок.
Коли почали задумуватися над наступним етапом залучення інвестицій, не змогли пояснити інвесторам, чому стільки часу та грошей уже витратили на розробку, але жодного разу не протестували його на людях і навіть не намагалися знайти канали доставки продукту до кінцевих користувачів.
Це був складний урок, який коштував нам два роки марної праці та 2,6 мільйона доларів. Зрештою, ми нічого з цього не заробили, продукт так і не запрацював. Ми заморозили його й досі не змогли заново запустити.
Коли я зрозумів, наскільки великим був цей провал, перша моя реакція — знайти винних. На жаль, ми так влаштовані, що завжди намагаємося побачити проблему в комусь, окрім себе. Тому спочатку думав, що це CEO мав відповідати за все, це CMO мав знати, що продукт треба продавати. Дуже болісно усе сприймав, адже вклав туди душу й багато часу, та розумів, що є обставини, які неможливо подолати. Я почувався безпорадним.
Та згодом прийшов наступний етап усвідомлення проблеми, і я став сильно злитися на себе. Можливо, це й не була повністю моя провина, що ми не почали продавати продукт раніше, але все одно як
Тож я засвоїв кілька уроків із цього кейсу:
- Як у керівника у тебе не може бути виправдань, що хтось чогось не зробив. Усі люди, які керують компанією разом з тобою, — твої колеги, у тебе немає «дяді» нагорі, який скаже, як робити, і нестиме відповідальність. Ви разом розділяєте цю відповідальність за компанію, продукт, людей. Тому, якщо трапилась помилка, це ваш фейл як керівників і водночас це твій персональний фейл.
- Будь-який продукт, який створюєш, потрібно продавати з першого дня. Так влаштована культура нашого сприйняття продуктів і контенту. Яким би крутим не був продукт, але якщо про це ніхто не дізнається, він не стане успішним. Окрім того, що люди мають знати про цей продукт, треба переконатися у тому, що ти знаєш свою аудиторію. А ще краще — коли ти розумієш «біль» користувачів, за вирішення якого вони готові платити. Інакше ти приречений на поневіряння від однієї ідеї до іншої без чіткого розуміння, навіщо це комусь потрібно.
Чому не варто дружити з підлеглими
У цей період я як керівник уперше звільнив свого друга. З одного боку, в нас були класні персональні стосунки, а з іншого — у нього були провали в роботі. Спочатку я не міг пересилити себе і звільнити його, однак знав, що не можу спихнути це на когось. Це була болісна історія для мене, але я зробив з неї висновок.
Якщо хочеш бути керівником, треба бути товстошкірим і розуміти, що персональні взаємини — це одне, а робота — зовсім інше. І якщо стосунки починають впливати на роботу, ти як керівник не можеш об’єктивно оцінювати ситуацію. Тож варто зберігати дистанцію від своїх підлеглих, щоб ніхто не міг використовувати вашу дружбу в робочих цілях.
Коли ефективніше звільнити всю команду
Ще один факап, пов’язаний з роботою CTO, був на проєкті, де працювало три команди — мобільної розробки, фронтенду та бекенду. Я побачив, що між командами фронтенду та бекенду постійна напруга — кожна з них намагалася знайти проблему на іншому боці. Це дуже заважало ефективному розв’язанню проблем. Одна річ, коли ви разом збираєтеся та намагаєтеся знайти рішення, інша — коли ви намагаєтеся знайти винного.
Цей конфлікт затягнув термін виконання проєкту приблизно на місяць. Нерідко кажуть, що ефективність роботи визначається легкістю в комунікації, адже що простіше людям знаходити спільну мову, то швидше вони дійдуть компромісу та вирішать необхідні питання.
Мій головний фейл був у тому, що я дуже пізно зрозумів: найкращим рішенням на той момент було повністю звільнити одну з команд. Річ у тім, що це був фундаментальний конфлікт, який почався ще до того, як я прийшов у компанію. Неможливо було виявити його першопричину. І навіть постійний приплив свіжої крові у вигляді нових працівників, яких я наймав, не давав позитивного ефекту. Конфлікт уже так глибоко пустив коріння, що його можна було розв’язати тільки радикально. Але в мене бракувало волі на те, щоб одним махом скоротити всю команду. Зрештою довелося замінити 80% учасників команд, і так конфлікт було вичерпано. Але я вважаю, що якби це зробив раніше, то результати були б набагато кращі.
Назарій Газдун, Co-founder & CTO у Geniusee
Через неякісну комунікацію із замовником можна втратити половину користувачів
Кілька років тому, коли в наших краях набирала хайпу мікросервісна архітектура, я виконував роль архітектора в одній соціальній мережі. Ми побудували її, запустили, протестували — все було окей. Після бета-лончу наш замовник вирішив розповісти про соцмережу на телебаченні та запустити рекламу зі знаменитостями, щоб привести більше трафіку. До цього в нас було 10 тисяч користувачів, а після ефіру кількість зросла до
Мікросервісна архітектура дає змогу розподіляти навантаження між великою кількістю сервісів, і якщо навіть один сервіс падає, решта працює. А в нас падало все. Тоді я зрозумів, що припустився помилки: зберігав токени користувачів в одній базі, і ці токени перевіряв кожен мікросервіс. Довелося максимально збільшувати ресурси, але це допомагало тільки частково.
Буквально за день-півтора ми перевели соціальну мережу на інший механізм — розшифровування JWT-токена в мікросервісі, і вона почала стабільно працювали, але на той момент велика кількість користувачів уже відвалилася. Зрештою після першої маркетингової кампанії ми отримали багато негативу, люди просто не змогли використовувати аплікацію. У просування вклали кілька сотень тисяч доларів, і велика частина з них не дали жодного результату, бо користувачі встановили застосунок і видалили його одразу.
З цього кейсу я зробив такі висновки:
- Маркетинг-кампанію треба запускати поступово, без «супербуму», адже продукт ще може бути технологічно недосконалим. У моєму випадку проблема була надто банальною, про неї навіть ніхто не задумався — ні я, ні команда бекенду.
- Потрібно краще комунікувати із замовниками. Коли наш замовник сказав, що розкаже про соцмережу на телебаченні, ми подумали, що трафік збільшиться у
2-3 рази, і ми це витримаємо. Але він зріс більше ніж у 10 разів. Тому дуже важливо такі моменти докладніше проговорювати, особливо коли маркетинг і девелопмент на різних континентах.
Я вважаю, що кожен глобальний фейл — це не персональний провтик однієї людини, до цього призводить ланцюг дій різних учасників. Хтось припустився незначної помилки, хтось не помітив, хтось не подумав, не договорив — і в результаті стався провал. Так відбулося і тут.
Чому важливо ретельно обирати партнерів
У 2014 році я працював над стартапом, що розробляв продукт на базі доповненої реальності, за допомогою якого військові могли б їхати в танку й бачити все навколо. Коли хлопці воювали в Донецьку і відступали, вони могли переїхати своїх солдат, тому що видимість у танку обмежена. Тому ми вирішили створити систему, яка дозволятиме тому, хто перебуває всередині бойової машини, мати огляд на 360 градусів.
У стартапі я був CTO, з CEO мене познайомив мій друг, який був COO. Ми почали працювати, зробили прототип, отримали непогані відгуки, були на кількох виставках, і все йшло до підписання контракту. Але коли дійшло до грошей, CEO вирішив взяти їх у російського інвестора. Був 2014 рік, активна фаза війни на сході, тому для мене було незрозуміло, як можна допомагати нашим військовим і для цього брати гроші в російського інвестора, який частково стане співвласником стартапу. І що, наступним кроком почнемо продавати цю розробку в Росію? Тому я ухвалив рішення вийти зі стартапу.
У цій ситуацій основний мій фейл був у тому, що я неправильно вибрав партнера. Я не познайомився ближче з цією людиною, не почитав про неї, не зробив належний рісьорч. Уже під час співпраці дізнався багато негативних фактів про нього. З цього зробив висновок: якщо хочеш працювати з людиною в партнерстві, спочатку дізнайся щось про неї, познайомся ближче, спробуй отримати фідбек від тих, з ким вона раніше взаємодіяла.
Мені було неприємно, що я витратив на проєкт багато часу й не отримав результатів, а просто вийшов. Але тепер оцінюю це як досвід, адже це вперше я брав участь у побудові стартапу.
Дмитро Волошин, Co-founder та CTO у Preply
Як це втратити $50 000 через власну самовпевненість і дрібну проблему
Коли ми тільки починали робити Preply, я сам писав більшу частину коду і багато з рішень, які тоді ухвалював, тепер можна вважати фейлами. Наприклад, назви та зв’язки між табличками в базі даних, які досі «аукаються» всім, хто працює з даними. Також було багато менеджерських провалів, пов’язаних із пізнім наймом людей на певні посади та з помилковим наймом.
Але один із фейлів видався особливо дорогим. У нас виникла проблема з маркетинговою атрибуцією у коді, який я писав років п’ять тому. Я не делегував вчасно це завдання більш кваліфікованим розробникам, адже був занадто самовпевнений і думав, що сам можу швидко виправити проблему. Але оскільки в мене постійно багато зустрічей та інших задач, я поставився до цього питання легковажно і зробив фікс у перерві між зустрічами, не приділив належної уваги аналізу unit-тестів. Я переписав код (було 5 рядків), але помилково виніс один рядок з-під блоку if, таким чином змінивши бізнес-логіку.
Мій «фікс» у результаті не розв’язав проблему, проте ще тиждень ми думали, що це все вирішено. Бо не провели достатньо глибокий аналіз, щоб з’ясувати, у чому річ. За цей тиждень ми втратили близько $50 000 через неправильну атрибуцію платного маркетингу. А внизу Pull Request, який справді вирішує створену мною проблему, і складається лише з чотирьох пробілів.
У результаті ми правильно проаналізували, на якому етапі втрачаємо дані і в які місця треба вставити трекінг.
Оскільки у нас в Preply існує культура blameless postmortems навіть щодо таких «дитячих» помилок, ми пишемо postmortem-документ з основними уроками та намагаємось виправити процес, щоб такого більше ніколи не сталося.
Уроками з цього фейлу були додатковий моніторинг/алертинг на трекінг і рефакторинг старого коду, щоб він був більш підтримуваним. А мій особистий: у нашому масштабі компанії СТО вже не має писати код, адже є пів сотні більш кваліфікованих розробників. Кожен функціонал повинен мати свого owner’а.
Дмитро Гринь, CTO в Jooble
Як неправильне планування призводить до зриву термінів і вигорання
Мій фейл був у тому, що я погано організував переведення продукту на нову технологію, через що компанія сильно втратила в темпі.
У нас була мобільна версія сайту, написана на ASP.NET MVC, її переведення було заплановане на React. Вирішили це робити помодульно у форматі «повністю повторюємо зовнішній вигляд і функціонал». Під час планування мені здалося чудовою ідеєю перші кілька модулів закріпити за командою продуктової розробки, паралельно з бізнес-цілями. Тобто окрім цього, в команди було чимало інших завдань. Розраховував впоратися за два квартали, а в результаті робота зайняла рік.
Беклоги спринтів гойдало з боку в бік від «переводити тільки за залишковим принципом» до «не взяли жодного продуктового завдання». Про фокусування можна було забути: команда була втомлена і демотивована, а PO — постійно незадоволений темпами роботи щодо продукту. Це призводило до ще більшого урізання часу на технічні завдання.
Я відчував великий тиск через це, був засмучений і водночас не був певний, що варто було одразу передати незакінчену роботу іншій команді, не знаючи, чи вийде кращий результат.
Зрештою я зробив висновки з цієї ситуації та на наступному річному плануванні зібрав окрему команду, яка займалася лише переведенням кодової бази.
Павло Возненко, CTO в ProSiebenSat.1 Digital GmbH
Якщо продукт розробляють без тестування і фідбеку користувачів, виникають проблеми
Я почав працювати в новій e-commerce компанії в ролі CTO, у мене була невелика команда в Мюнхені та ще одна команда аутсорсерів у Польщі. В перший місяць роботи я намагався розібратися, як усе працює в компанії, хто чим займається, і злітав у Польщу, аби поспілкуватися зі спеціалістами. Ми зустрілися, і вони кажуть: «Знаєте, так класно працювати на вашу компанію. Останні чотири місяці ми працюємо над цим проєктом, і ніхто нас не чіпає». Ми поговорили, пораділи, пообіймалися — і я полетів назад у Мюнхен. Уже там до мене дійшло: хлопці чотири місяці займаються розробкою, але сервіс ще не був у продакшені. І при цьому немає навіть продакт-менеджера, який контролює процес — вони залишилися сам на сам із цим проєктом.
Протягом наступного тижня я спілкувався з ними, пропонував вивести продукт у продакшн, аби хоча б перевірити, чи буде він узагалі працювати. Можна було б пустити на нього трафік, але при цьому не показувати споживачам, щоб подивитися, як він впорається з навантаженням. Вони погодилися, минуло два тижні, але результату так і не було. Хлопці сказали, що нічого не виходить і їм потрібен ще місяць. Я відповів: «Який місяць, якщо ви вже чотири займаєтеся розробкою?». Вони пообіцяли повернутися за тиждень з результатами. Але цього так і не сталося.
На той момент проєкт був у розробці вже 5 місяців, і кінця ще не було видно. Сервіс не міг піти на продакшн, тому що програмісти зробили таку архітектуру, що він не прив’язувався до основної системи. Водночас команда постійно просила дати трохи більше часу. Зрештою на шостому місяці я вирішив це припинити. Усіх цих програмістів перекинули в інші продакт-команди, а проєкт закрили. Це було правильне рішення, а от фейл був у тому, що я не зробив цього раніше. Компанія втратила 6 місяців і багато грошей даремно.
Мій головний висновок із цього: якщо чуєш від програмістів: «Як класно, що ми працюємо над чимось без фідбеку користувачів і навіть не перевіряли, чи буде воно працювати на продакшені», це тривожний дзвіночок. Краще не тягнути, а зупинитися, перевірити все та скласти план подальших дій. Тепер, якщо я бачу схожі патерни в інших проєктах, знаю, що чекати не можна.
Чому варто відкрито комунікувати зі стейкхолдерами
Цей випадок стався в одній з моїх попередніх компаній, де я був CTO. Тоді ми тільки починали, побудували команду із 30 людей, створили три команди продакт-інжинірингу з програмістами в Мюнхені та Україні. Робота кипіла, всі були дуже завантажені. Але в один з вечорів до мене підійшов CEO компанії та сказав, що йому здається, ніби ми не працюємо і нічого не відбувається. Спочатку в мене був ступор: як це ми нічого не робимо, якщо мої люди викладаються на повну? Я відчував, що ми працюємо дуже ефективно та показуємо класні результати.
Замість того, щоб одразу реагувати агресивно, я запропонував йому поговорити наступного дня. Проаналізувавши ситуацію, зрозумів, що зі своєї позиції вгорі він не бачив, що відбувається внизу. А так сталося тому, що в нас не було достатньої прозорості у процесах: він бачив лише частину роботи, не знав, що ми паралельно працюємо з іншими стейкхолдерами (їх на той час було ще
Тож ми зібрали всі проєкти, над якими працювали в той момент, візуалізували їх, запросили всіх стейкхолдерів на зустріч і показали, що робимо і який прогрес у кожному з проєктів. Відтак пріоритизували проєкти, щоб закінчивши один, можна було одразу взятися до наступного з найвищим пріоритетом.
Олександр Нескін, Co-founder & CTO Petcube
Чому важливо ретельно обирати виробників
Коли ми тільки почали створювати Petcube у
Тож я вирішив вилетіти з материкового Китаю в Гонконг на кілька днів, щоб перезавантажитися. Наступного ж ранку після від’їзду мені зателефонував один зі співвласників фабрики, яка робить пресформи. І сказав мені ламаною англійською: «Вибач, мого партнера заарештували, фабрику заарештували — нічого не буде».
Я зрозумів, що для нас це кінець: коштів на тулінг більше немає. Зібравши всю волю в кулак, я повернувся назад, поїхав на фабрику і побачив, що вони хотіли зекономити й віддали наші пресформи на субпідряд на виробництва, які були закриті, і фізичного доступу до них не було. Зрештою шляхом довгих перемовин моєю ламаною китайською вдалося частину тулінгу повернути, а частину переробити коштом фабрики. Але це відкинуло нас у часі на кілька місяців.
З цієї історії я зрозумів: якщо щось може піти не так, воно піде не так. Але треба просто систематично розв’язувати проблеми одна за одною. Ніяк запобігти цьому фейлу нам не вдалося, бо в нас не було грошей, щоб обрати надійнішу компанію.
Ілюстрація Аліни Самолюк
Підписуйтеся на наш Telegram-канал «Редакція DOU», щоб брати участь у наступних статтях та не пропустити найцікавіше.
