[Про автора: Віктор Гайдін — директор з продуктової стратегії ELEKS, очолює відділ Products & Services і відповідає за формування бачення того, якими повинні бути продукти та сервіси компанії у довгостроковій перспективі. Свій кар’єрний шлях розпочинав як .NET Software Developer, згодом очолював R&D-напрямок компанії. З січня 2016 — викладач курсу Business Development при Lviv IT School].

Про перехід в українській ІТ-індустрії від аутсорсингової бізнес-моделі до продуктової неодноразово писали як на DOU, так і на інших ресурсах. Досвідом такої трансформації у нашій компанії мене запросили поділитися під час недавнього Lviv International Outsourcing Forum. Викладаю тут основні тези моєї доповіді і, сподіваюся, вони будуть вам корисними. Забігаючи наперед, скажу, що стаття не претендує на глибинний аналіз проблематики, більше того — я не зможу підтвердити свої слова безсумнівною історією успіху. Це швидше записки на полях, зроблені у ході роботи, які стануть у нагоді тим, хто не хоче наступати на граблі, і допоможуть обрати більш оптимальний спосіб управління продуктово-сервісним бізнесом.

Щоб прояснити контекст, коротко розкажу про компанію, в якій працюю. ELEKS був заснований 25 років тому як продуктова компанія і перші 7-8 років працював переважно у цій бізнес-моделі. Криза 1998 року, яка вбила місцевий ринок, змусила перевести компанію на рейки аутсорсингової моделі, спрямованої на Захід. Я працюю в компанії майже дев’ять років і за цей час спостерігав за розвитком десяти різних продуктів. Два з них існують вже понад 10 років, ще два запущені наразі як стартапи, один провалився в 2009 року, і ми продали його за безцінь; три інші просто провалилися (причому два з них закрилися ще до того, як отримали своїх перших користувачів). Всього, на сьогодні у нас є п’ять продуктів, які можна вважати живими (і я впевнений, що до кінця року доживуть не всі з них — і це нормально).

Важливо те, що жоден з цих продуктів навіть близько не наблизився за своїми фінансовими показниками до материнського (аутсорсингового) бізнесу — навіть у найкращі для продуктів часи різниця становила понад 10 разів. Тобто досвід, яким я з вами хочу поділитися, — це не історія успіху чи провалу. На нашому шляху були і злети, і падіння, однак усі вони були досить обмеженого масштабу, тобто нічого епічного ніколи не траплялося.

Про те, як зазвичай аутсорсингові компанії починають робити продукти

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

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

Спочатку ентузіазму в усіх дуже багато, всі працюють натхненно і активно: пиляють прототипи, дискутують про архітектуру, малюють UI. А якщо хтось із них ще й читав книжку Lean Startup, то є шанси, що усе це відбуватиметься з процесної точки зору менш-більш правильно.

Але проходить якийсь час, і продуктивність команди починає падати. Як правило, все починається з lead-інженерів, яких поступово починають забирати, наприклад, на pre-sale-активності, адже аутсорсингова частина бізнес нікуди не ділася — у ній відбуваються продажі, і в них хтось мусить брати участь. Тоді домовляються про часткову зайнятість (а дослідження стверджують, що part-time мультизадачність знижує продуктивність до 40%). Приблизно те саме відбувається і зі спонсором. До початку розробки він, швидше за все, був частиною топ-менеджменту компанії і (формально чи неформально) виконував певну життєво важливу функцію. В такому випадку можливі три сценарії: страждає або продукт, або аутсорсинг, або — що найбільш імовірно — і перше, і друге. Таким чином, у кращому випадку, повоністю задіяними в розробці продукту залишаються джуніори, які, скоріш за все, не надто розуміють, що вони роблять. Не важко здогадатися, що за таких обставин станеться з продуктом: за півроку-рік його можна буде вважати мертвим. Я, звісно, трохи перебільшую, але в цілому, такий сценарій — доволі типовий. Я спілкувався на цю тему з багатьма представниками ІТ-індустрії, і майже всі вони спостерігали подібні історії в тій чи іншій формі.

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

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

Про синергію аутсорсингу та продуктів, і різницю між ними

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

Проте, якщо ми проаналізуємо, що саме з аутсорсингового бізнесу ми можемо використати для запуску продукту, то побачимо, що ресурсів не так вже й багато:
— Люди та їхній досвід. Як правило, це інженери. Продуктові менеджери чи продуктові маркетологи — надзвичайно рідкісні птахи в нашій індустрії. Хоча останнім часом з’являються позитивні тренди, які дозволяють вірити у зміни на краще у наступні декілька років.
— Система продажів, яка в окремих випадках здатна генерувати і закривати можливості для продукту. Особливо, якщо це B2B-продукт, і він націлений на ту саму аудиторію, що і сервіс.
— Частина інфраструктури (офіс, допоміжні служби, технічне обладнання), яка може бути корисною для продукту.

Спробуймо детальніше поглянути на аутсорсинг і продукти як на бізнес-моделі. На перший погляд може здатися, що вони різні — як чорне і біле. Але в реальному світі між чорним і білим, як правило, мусить бути ще 50 відтінків сірого. Так само і тут. Безперечно, існують як суто аутсорсингові, так і суто продуктові компанії, однак є чимало й таких, що поєднують в собі і те, й інше. Я виділив для себе декілька типових сценаріїв таких «проміжних» моделей:

1. Перший тип — це так звані акселератори. Вони з’являються, коли в аутсорсинговому бізнесі виникає ідея розробити набір компонентів, які можна буде перевикористовувати на різних проектах. За моїми спостереженнями, такі моделі були дуже популярні 10-15 років тому. Зараз цю нішу зайняв open source, і акселератори, як правило, зводяться до конфігурації і обв’язки довкола декількох open source-рішень, що, погодьтеся, дешево і сердито.

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

2. Наступний тип — Solution Platforms. Зазвичай, це набір цеглинок, з яких можна будувати рішення для певного типу проблем — як правило, бізнесових. Недавно під час дослідження ринку я натрапив на невелику індійську компанію. Декілька років тому вони побачили тренд продуктів типу «Uber для чогось» і виділили в ньому набір спільних для більшості з них компонентів. Тоді оформили це у вигляді платформи, і сьогодні у них є конвеєр, який штампує такі сервіси один за одним. Вони кажуть, що завдяки цьому їм вдалося досягнути до 80% перевикористання коду. Не знаю, наскільки це правда, але навіть якщо йдеться про 50% — то це вже дуже круті результати.

Загалом, solution-платформи — це дуже цікавий тип продуктів. Бувають випадки, коли вони виникають з fixed price-проектів. Ми в компанії такого практично не пробували, але якщо уважно прочитати фінансові звіти одного з лідерів ринку, можна помітити, що іноді вони включають в договори пункт, який дає їм право викупити права на софт після того, як вони здали його за певну узгоджену суму. Простіше кажучи — перший клієнт оплачує розробку, а другий і всі наступні — забезпечують маржу.

3. Ще один тип — це вже справді повноцінний продукт, який все ще певним чином пов’язаний з тим сервісом, який надає клієнтові аутсорсер. Наприклад, ми в компанії свого часу писали багато десктопного софта, і в якийсь момент вирішили зробити продукт на кшталт «google analytics for desktop software». Це, власне, той випадок, коли ви отримуєте синергію через продажі — покупцями вашого продукту є ті ж замовники, які купують ваш аутсорсинг. Таким чином продукт можна продавати на додачу до основного сервісу (cross-sell). Я ще повернуся до цієї теми пізніше, коли говоритиму про ризики.

Між акселераторами і Solution Platforms можна провести умовну межу. Зліва від неї замовник все ще купує аутсорсинг — професійну послугу (навіть якщо вона продається як рішення). Тобто йому потрібні ваші люди, процеси і попередній досвід. Справа він купує вже софт, навіть якщо той потребує багато кастомізації і тягне за собою аутсорсинговий контракт, який в 10 разів перевищує вартість ліцензії.

Таким чином, я сформулював для себе просте емпіричне правило: акселератори можна і треба тримати всередині аутсорсингового бізнесу; все інше — краще виділяти в окремі бізнеси. Найбільше питань викликають solution-платформи, оскільки ці бізнеси часто до останнього не розмежовують, що призводить до багатьох проблем.

Про мух і котлети, або нащо розділяти

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

— Контроль над фінансами. Лише за умови, що ви розмежуєте бізнеси, ви зможете зрозуміти, скільки вам коштує розробка продукту, і поміряти його ROI. Можливо, це звучить надто просто, і може виникнути ідея оформити продукт як проект, оскільки контролювати фінанси на рівні проектів вміють усі. Однак на практиці виникають нюанси. Уявіть собі, що серед ініціаторів продукту є хтось з топ-менеджерів — нехай це буде СТО. Швидше за все, зарплата йому і надалі буде виплачуватися з аутсорсингового бізнесу, де він обіймає певну посаду. Оскільки зарплата в топів немала, це буде штучно занижувати затрати на розробку продукту, і в результаті продукт може здаватися беззбитковим, хоча насправді він таким не є.

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

— Фокус. З цим, здається, усе зрозуміло: робити одну річ добре — набагато легше, ніж декілька. Люди — істоти однозадачні, і спроби виконувати декілька речей одночасно, як правило, завершуються падінням продуктивності, а іноді й «забиванням» на частину задач. Навіть при умові, що продуктова команда на 100% сфокусована на продукті, але бізнеси не розмежовано — розфокусування топ-менеджменту компанії не уникнути.

— Інвестиції. Розробка продукту — це дорого, при чому гроші треба платити наперед. Я думаю, для більшості українських аутсорсерів (а це переважно компанії зі штатом до 200 працівників) фінансування розробки повноцінного продукту — це серйозний виклик. Відповідно, відділивши продуктовий бізнес, ви зробите його більш зрозумілим зовнішньому інвестору, і тим самим підвищите власні шанси на успіх.

— Pivot. Звісно, ви можете розвивати продукт, не відділяючи його від основного бізнесу, однак розмежування надасть вам значно більше гнучкості. Я вже згадував, що колись ми створювали Software Analytics-сервіс, який на початку таргетував ентерпрайзний софт. Зрозуміло, що це давало ефект синергії з основним бізнесом компанії, адже ми могли продавати підписку на сервіс разом із розробкою продукту. Після кількох років роботи над ним стало зрозуміло, що на enterprise-ринку ми або спізнилися, або не можемо зайти на нього в силу певних обмежень. Тоді ми вирішили розвернути продукт у бік аналітики мобільних ігор, оскільки на той момент ця ніша була менш-більш незаповненою. Однак проблема полягала в тому, що ELEKS не займається розробкою ігор, відповідно таке рішення нищить синергію. Довелося піти на компроміс, щоби не дати фокусувати продукт винятково на мобільних іграх. Я думаю, саме це було однією з причин, чому продукт в результаті провалився. Цей останній випадок особливо цікавий ще й тому, що формально продуктовий бізнес там був відділений від аутсорсингового як окрема компанія, але фактично ліквідувати прив’язку до материнського бізнесу повністю так і не вдалося. Прив’язка існувала як на рівні обліку фінансів, компенсацій, людей, так і на рівні автономії, котру мала команда при прийнятті рішень тощо.

Як розмежовувати бізнеси

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

1. Знайду людину чи декількох людей, які здатні розвивати цей продукт як бізнес.

2. Домовлюся з ними про інвестиційний план для цього бізнесу, його цілі, стратегію, структуру власності і управління (через раду директорів).

3. Дозволю їм набрати core-команду з ресурсів аутсорсингового бізнесу чи ззовні компанії. При цьому, поставлю умову, що при переході в продуктовий бізнес ці люди заново передомовляться про свою компенсацію і отримують її частину через опціони. Якщо люди з цим не погодяться, швидше за все — вони не підходять для роботи в стартапі, і краще їх туди не залучати без зовсім крайньої на те необхідності.

4. Домовлюся і зафіксую на папері механізм взаємодії компаній між собою (якщо в цьому буде потреба).

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

Наступне завдання — успішна побудова бізнесу з нуля, але це вже зовсім інша тема.

Про те, що аутсорсинг — зло

Я би не хотів розпочинати активну полеміку з Сергієм Петренком, який опублікував свою колонку про шкоду, яку аутсорсинг завдає продуктовій індустрії, декілька днів тому. З одного боку, він правий у тому, що аутсорсинг через «роздування» зарплат сильно зашкодив місцевому ринку продуктів. З іншого, як казав Ніцше, все, що нас не вбиває — робить нас сильнішими. Ті продукти, яким вдасться вижити в умовах зарплатного тиску з боку аутсорсингу, матимуть шанси на великий успіх, на глобальних ринках у тому числі.

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

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