×Закрыть

6 історій про фейли СТО: «Ми захопилися ідеєю продукту і зовсім не подумали про маркетинг. Втрачено два роки праці та $2,6 млн»

[Fail review — рубрика, в якій ми збираємо історії про робочі провали: що відбулось, як виправляли і які висновки зробили.]

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

Кирило Латиш, CTO у COOLS

Відсутність маркетингу і тестування на користувачах можуть обійтися дуже дорого

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

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

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

Це був складний урок, який коштував нам два роки марної праці та 2,6 мільйона доларів. Зрештою, ми нічого з цього не заробили, продукт так і не запрацював. Ми заморозили його й досі не змогли заново запустити.

Коли я зрозумів, наскільки великим був цей провал, перша моя реакція — знайти винних. На жаль, ми так влаштовані, що завжди намагаємося побачити проблему в комусь, окрім себе. Тому спочатку думав, що це CEO мав відповідати за все, це CMO мав знати, що продукт треба продавати. Дуже болісно усе сприймав, адже вклав туди душу й багато часу, та розумів, що є обставини, які неможливо подолати. Я почувався безпорадним.

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

Тож я засвоїв кілька уроків із цього кейсу:

  1. Як у керівника у тебе не може бути виправдань, що хтось чогось не зробив. Усі люди, які керують компанією разом з тобою, — твої колеги, у тебе немає «дяді» нагорі, який скаже, як робити, і нестиме відповідальність. Ви разом розділяєте цю відповідальність за компанію, продукт, людей. Тому, якщо трапилась помилка, це ваш фейл як керівників і водночас це твій персональний фейл.
  2. Будь-який продукт, який створюєш, потрібно продавати з першого дня. Так влаштована культура нашого сприйняття продуктів і контенту. Яким би крутим не був продукт, але якщо про це ніхто не дізнається, він не стане успішним. Окрім того, що люди мають знати про цей продукт, треба переконатися у тому, що ти знаєш свою аудиторію. А ще краще — коли ти розумієш «біль» користувачів, за вирішення якого вони готові платити. Інакше ти приречений на поневіряння від однієї ідеї до іншої без чіткого розуміння, навіщо це комусь потрібно.

Чому не варто дружити з підлеглими

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

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

Коли ефективніше звільнити всю команду

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

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

Мій головний фейл був у тому, що я дуже пізно зрозумів: найкращим рішенням на той момент було повністю звільнити одну з команд. Річ у тім, що це був фундаментальний конфлікт, який почався ще до того, як я прийшов у компанію. Неможливо було виявити його першопричину. І навіть постійний приплив свіжої крові у вигляді нових працівників, яких я наймав, не давав позитивного ефекту. Конфлікт уже так глибоко пустив коріння, що його можна було розв’язати тільки радикально. Але в мене бракувало волі на те, щоб одним махом скоротити всю команду. Зрештою довелося замінити 80% учасників команд, і так конфлікт було вичерпано. Але я вважаю, що якби це зробив раніше, то результати були б набагато кращі.

Назарій Газдун, Co-founder & CTO у Geniusee

Через неякісну комунікацію із замовником можна втратити половину користувачів

Кілька років тому, коли в наших краях набирала хайпу мікросервісна архітектура, я виконував роль архітектора в одній соціальній мережі. Ми побудували її, запустили, протестували — все було окей. Після бета-лончу наш замовник вирішив розповісти про соцмережу на телебаченні та запустити рекламу зі знаменитостями, щоб привести більше трафіку. До цього в нас було 10 тисяч користувачів, а після ефіру кількість зросла до 100-200 тисяч. Тому наша мікросервісна архітектура почала валитися. Вона мала б витримувати такі навантаження, але щось пішло не так.

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

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

З цього кейсу я зробив такі висновки:

  1. Маркетинг-кампанію треба запускати поступово, без «супербуму», адже продукт ще може бути технологічно недосконалим. У моєму випадку проблема була надто банальною, про неї навіть ніхто не задумався — ні я, ні команда бекенду.
  2. Потрібно краще комунікувати із замовниками. Коли наш замовник сказав, що розкаже про соцмережу на телебаченні, ми подумали, що трафік збільшиться у 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 компанії та сказав, що йому здається, ніби ми не працюємо і нічого не відбувається. Спочатку в мене був ступор: як це ми нічого не робимо, якщо мої люди викладаються на повну? Я відчував, що ми працюємо дуже ефективно та показуємо класні результати.

Замість того, щоб одразу реагувати агресивно, я запропонував йому поговорити наступного дня. Проаналізувавши ситуацію, зрозумів, що зі своєї позиції вгорі він не бачив, що відбувається внизу. А так сталося тому, що в нас не було достатньої прозорості у процесах: він бачив лише частину роботи, не знав, що ми паралельно працюємо з іншими стейкхолдерами (їх на той час було ще 8-9). Мій фейл полягав у тому, що з мого боку не було чіткої комунікації про те, якими завданнями ми займаємося та як організована робота. Я більше фокусувався на побудові команд та оптимізації процесів розробки, водночас недостатньо уваги приділяв самим стейкхолдерам, тому в якийсь момент їм почало здаватися, що ми їх ігноруємо та не виконуємо задачі.

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

Олександр Нескін, Co-founder & CTO Petcube

Чому важливо ретельно обирати виробників

Коли ми тільки почали створювати Petcube у 2013-14 роках, я 8 місяців провів у Китаї, де займався запуском масового виробництва наших пристроїв, не досипаючи та недоїдаючи. Тоді вже майже все було готово й ми мали укласти контракт з компанією, що виготовляє тулінг (пресформи). Це найдорожча та найдовша частина виробництва: виготовлення пресформи потребує кількох місяців, а за вартістю це можна порівняти з крутою тачкою. Оскільки грошей у нас було не дуже багато, перебирати виробників ми не могли. Просто зупинилися на одному з них і підписали контракт. У мене вже було відчуття, що настав останній етап роботи, попереду три місяці виготовлення, і можна запускати виробництво.

Тож я вирішив вилетіти з материкового Китаю в Гонконг на кілька днів, щоб перезавантажитися. Наступного ж ранку після від’їзду мені зателефонував один зі співвласників фабрики, яка робить пресформи. І сказав мені ламаною англійською: «Вибач, мого партнера заарештували, фабрику заарештували — нічого не буде».

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

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


Ілюстрація Аліни Самолюк


Підписуйтеся на наш Telegram-канал «Редакція DOU», щоб брати участь у наступних статтях та не пропустити найцікавіше.

LinkedIn

33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

На одной из прошлых работ случился очень похожий фейл с тем, что в заголовке. Была идея типа:
1) Есть потенциальные продавцы ресурса, которым или облом, или бюрократия и тупые законы не позволяют возиться с каждым покупателем;
2) Есть покупатели, которым нужны мелкие порции потребления ресурса, и они не в курсе, кто его поставляет, потому что продавцы не очень светятся;
3) Есть поставщики хитрого софта для ресурса, которым нужны гарантии, что софт не будут сильно красть;
и тут мы все в белом устраиваемся меж ними и снимаем сливки.
И тут оказывается, что полноценное сочетание всех трёх, на котором бы получился полноценный бизнес, выполняется только... в России. В других местах продавцы гибче и не скрываются, и у покупателей нет таких тупых барьеров; а в России фиг пробьёшься, потому что пускают только своих и под откатами. Ну и ещё инвестиционный кризис начался. Шёл 2013 год.
Единственное что радует в сравнении — денег было убито сильно меньше, ну и от российского источника не жалко :)

Ребята, спасибо за истории. 👏

Спасибо за публикацию, интересно было почитать коллег и что многие ошибки по сути перекликаются. Если что задавайте вопросы, готов помочь чем могу.

Спасибо за вашу историю. Сколько людей на данный момент у вас в компании?

На момент описания историй, было около 85 человек в компании, когда в Продакт и Инжиниринг департаменте нас было 32 человека в 4х разных странах (в какой то момент было 5 стран).

Интересно было бы посмотреть на архитектуру сервиса с проблемами с jwt.

Я думаю, что там все банально, есть некий AuthService, который выдает токены и умеет их валидировать\парсить
И все сервисы, которые получают токен, ходят на AuthService по http, тем самым его ддосят под нагрузкой

Быстрее бы они заддосились чем ауз, к тому же горизонтальное масштабирование никто не отменял

Ну, они же налепили микросервисов — думали, этого достаточно.

ну дык и пусть размножат ауз, он же тоже микросервис

Спасибо авторам за кейсы. Поделюсь лайфхаками, за многолетнюю работу BizDev получилось собрать самые ключевые боли стартапов и предпринимателей. На их базе собрать самые работающие инструменты и техники на практике.

1.Есть один известный, универсальный инструмент, который позволяет команде и фаундерам на бумаге, используя только свои мозги, оценить риски и перспективы — Lean Canvas. Это бизнес-модель с 9 ключевыми блоками, проработав которые, можно найти все узкие места и зоны роста. Такая краткая стратегия, элемент дизайна. Инженерный подход в бизнесе родоначальником которого стала компания TOYOTA и автор книги Lean Startup Эрик Рис. Просчитать наилучшие способы реализации, сделать аудит, сплотить команду. Так как любое бизнес-моделирование или разработка стратегии делается командой с ключевыми ролями: фаундеры и маркетинг и финансисты и разработчики (это в случае цели на результат , а не на процесс).

2.Вторая самая распространенная боль — это Soft Skills. Есть гениальные инженеры, которые не могут рассказать о своем решении клиенту или не владеют менеджерскими качествами. Поэтому очень важно работать в команде, чтобы понимали насколько роль одного эксперта зависит и важна для всего проекта. А также учиться именно управленческому мастерству.

3. Самая крутая прокачка проекта и валидация — участие в хакатоне. Можно взять любую идею (или часть вашего реального решения). Сразу несколько преимуществ. За хакатон проходит экспертная и менторская прокачка. Команда учится презентовать идею и прототип за 3 минуты. Валидация и от менторов и от потенциальных юзеров. И конечно PR потому как такие события освещаются. Или как фаундер поучаствовать в жюри, посмотреть на проекты пообщаться с другими экспертами. Успешных всем проектов, и велкам если интересно.

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

«Большинство стартапов (новых компаний, продуктов) погибло не потому что у них был плохой продукт, а потому что этот продукт был никому не нужен», Эрик Рис.

> Тому наша мікросервісна архітектура почала валитися
Так же это говорит о том, что вы точно должны знать какие нагрузки ваша система вывозит и обсуждать это с маркетинг отделом.

Сам сталкивался в нескольких проектах с этим и факапился похожим образом. Когда проект уже запущен и имеет активных пользователей очень важно:
— Проводить нагрузочные тесты на регулярной основе
— Имееть работающий автоскейлинг

Это так же позволит лучше понимать текущий счет за инфраструктуру и где его можно оптимизировать

как человек, который лично попадал в аналогичную ситуацию и выгреб из нее успешно хочу добавить 2 дополнения:

1) Не любит бизнес платить на начальной и средней стадии платить на НГ. Тяжело уговорить и втащить в бюджет это
2) как это не смешно звучит, но маркетинг:
а) часто вообще никто не думает налаживать коммуникацию маркетинг <> технари
особенно это бывает в ситуации, когда тех команда не совсем родная — к примеру нанятая извне
б) сам маркетинг не всегда понимает последствия того, что делает.
Иногда та или иначе тактика дает такой прирост, что диву даешся

потому необходимо:
— архитектура, способная к гор. масштабированию
— иметь в боевой готовности эти мех. гор. масштабирования
— иметь в наличии четкие метрики работы системы, которые могут быстро показать где именно происходит деградация производительности и почему
и иметь историю метрик

Если бизнес не готов платить за п.1, то почему согласится платить за все пункты из списка «необходимо»?

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

Напишіть багато тексту, як буде час. Цікаво.

Первые 2 истории про то, что менеджеры такого уровня должны уже прекрасно знать как устроен бизнес и как происходит запуск продукта в реальную жизнь. И нехватка простых экономических знаний тут может приводить к подобным результатам.

Коли наш замовник сказав, що розкаже про соцмережу на телебаченні, ми подумали, що трафік збільшиться у 2-3 рази, і ми це витримаємо. Але він зріс більше ніж у 10 разів.
Маркетинг-кампанію треба запускати поступово, без «супербуму», адже продукт ще може бути технологічно недосконалим.

Серьёзно? Маркетинг виноват в том, что не протестировали как следует готовность продукта?

Маркетинг молодці) Просто очікування двох департаментів були різними.

Я бы даже сказал больше. Я институт закончил в 2001 году и понятно, что тогда там не было модных преподавателей с большим практическм опытом работы. Но мне очень хорошо запомнилось, что мы писали бизнес-план для программного продукта и важным моментом были маркенинговые исследования, выявление конкурентов, определения основных преимуществ конкурентных продуктов и формирования набора возможностей своего ПО, которые будут конкурировать с остальными. И, наконец, составления графика выхода на точку безубыточности. Поэтому вызывает огромное удивлиение, что человек C-уровня не знает элементарных вещей. Для этого не нужно ходить на спецкурсы, получать MBA и т.д.
Фраза про «отсутствие тестирования на людях в течении 2 лет» вообще убивает. Для кого придумали Agile, спринты, MVPи многое другое, чтобы не наступать на эти самые старинные и распространенные грабли?
А по поводу ответственности, то С-должности тем и отличаются от остальных, что все в равной мере несут ответственность за успешность бизнеса и рассуждения, что наверное виноват был CEO, просто вызывают непонимание.

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

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

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

Виходить, що чим раніше продемонструєш продукт користувачам, тим краще, але продукт повинен бути готовий, інакше його очікує провал.

Це невірні висновки.

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

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

Другий кейс про фейл після маркетингової компанії — це скоріше фейл СTO, який спочатку такий «Ми побудували її, запустили, протестували — все було окей.», а потім «ми подумали, що трафік збільшиться у 2-3 рази, і ми це витримаємо. Але він зріс більше ніж у 10 разів»

Виходить, що до успіху також потрібно бути готовим, але як до нього підготуватися — поки що не зрозуміло.

Читайте про менеджмент, маркетинг та економіку в цілому, і все стане свої місця.

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

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

Я уявляю діалог між СЕО та СТО накшталт цього:
СЕО: — Ми ж побудували систему, яка витримує великі навантаження? Система готова до просування? (в думках орієнтуючись на кількасот тисяч користувачів)
СТО: — Так, звіcно! Ми все протестували (тестували на 20-30 тисяч)
СЕО: — Ок, запускаємо маркетингову кампанію!
— error -

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

Ви ж, сподіваюсь, розумієте що і CEO, CTO, і маркетологи працюють в умовах неповних даних, тому заздалегідь не можуть знати «де тонко». Shit happens.

Тут питання комунікації між ними. Маркетинг має оцінювати кількість очікуємих користувачів, яку охопить кампанія. СТО має упевнитись, що проект витримує таке навантаження.

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

Так, як приклад можна навести PokemonGo

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

Як часто ви для цього залучаєте зовнішніх консультантів?

Подписаться на комментарии