Кар’єра СТО в стартапі без прикрас

Мені часто доводиться спілкуватися з технічними співзасновниками стартапів і друзями-програмістами, які хочуть робити IT-бізнес. Граблі, на які наступають люди з технічним складом розуму, переважно схожі. Як і те, що картинка стартапу як ідеальної роботи для будь-якого програміста, не завжди відповідає дійсності. Я хотів би поділитися досвідом розбудови «кар’єри» у ролі CTO у стартапі Preply і деякими порадами з власного досвіду.

To be or not to be

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

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

Потрібно розуміти, що робота в стартапі — це не про гроші (принаймні в перші роки). Якщо основна мотивація — заробити кошти, то набагато легше піти в аутсорс або емігрувати.

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

Перші кроки

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

На початку проекту часто виникає дискусія: чи почати писати проект на тому, на чому вмієш, чи взяти нову технологію. Перевагою першого варіанту, очевидно, є швидкість, проте другий варіант цікавіший з точки зору професійного розвитку. Мені доводилось працювати як з першим варіантом, так і з другим варіантом (освоював Groovy).

З точки зору побудови бізнесу, необхідно задати собі питання: «Чи зможу я на технології, яку вже знаю, побудувати таку архітектуру проекту, щоб на етапі росту проекту, команди і навантажень його можна було птимізувати/переписати/ефективно підтримувати?»

Якщо відповідь «так», то моя порада — писати на тому, що знаєте, а проблему професійного росту вирішувати поліглотною архітектурою мікросервісів. У нас основний проект на Python, проте вдало вибравши архітектуру з самого початку, ми вільно можемо писати функціонал на Java, JS, який комунікує з основним проектом через RabbitMQ. Рекомендую по темі безкоштовну книгу Сема Ньюмена.

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

На початковому етапі основна задача — це зарелізити MVP. Тут порада проста: швидко писати хороший код і ефективно вести комунікацію з колегами, які займаються бізнесовою частиною проекту. Частою є ситуація, коли бізнес-частина команди чекає тижнями чи місяцями, поки СТО і його команда напишуть код, а до того часу нічого для проекту не робить. Для СТО це перший red flag, що у команді є проблема. Бізнес-частина повинна робити «продажі» продукту до релізу. І бажано, щоб за реальні гроші. У нашому випадку, коли ми писали MVP, у нас була односторінкова посадочна сторінка — на неї падали заявки, а наш СЕО «ручками» обдзвонював потенційних клієнтів і робив продажі.

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

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

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

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

Не завжди очікуваним моментом є також і те, що у малих командах роль СТО не обмежується лише написанням коду. Часом необхідно брати на себе інші речі, такі як налаштування корпоративної пошти, переустановлення операційної системи чи налаштування sip call-центру. Це рутина, до якої також треба бути готовим.

Етап росту

Як тільки вашим продуктом почне користуватися постійно зростаюча кількість користувачів, закономірно постане питання можливості витримувати навантаження, що збільшуються. Слід згадати слова Дональда Кнута: «Premature optimization is the root of all evil». Двічі подумайте, чи існує для вас така проблема. Загальне правило полягає в тому, що коди переписуються заново при зростанні навантаження на порядок. При лінійному зростанні часто ефективніше вирішувати проблеми навантажень вертикальним масштабуванням серверів і баз даних.

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

Прикладами таких задач є:

— Локалізація продукту. Українські стартапи приречені виходити на глобальний ринок, адже робити продукти для локального ринку недоцільно з економічної точки зору. Я часто помічав, коли колеги з інших проектів регулярно просять змінити якийсь текст на сайті внаслідок знайденої помилки локалізації або завантаження нових текстів на сайт. Базова імплементація continuous localization дозволить більше ніколи не витрачати час програмістів на рутинну роботу з оновлення перекладів текстів.

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

— Маркетинг. Винесіть редагування цільових сторінок в адміністративну частину сайту, налаштуйте інструменти, які забирають маркетингову роботу з програмістів, наприклад, Google Tag manager.

— Статистика. Помилка, яку часто допускають в стартапах — спроба писати внутрішню систему статистики (ми також цим хворіли). Це дуже неефективне використання ресурсів, адже практично неможливо передбачити всі метрики/розрізи. Рішення — вигрузка всіх сирих даних в спеціальні програми бізнес-аналітики.

— Адмінка. Налаштуйте права на редагування потрібних моделей для решти команди. Особливо добре, якщо ваш фреймворк підтримує scaffolding.

Потрібно приймати рішення, чи хочете ви розвинути в собі компетенції DevOps — часто можна викинути частину технічного адміністрування проекту, скориставшись якоюсь з систем PaaS, або залучати до команди відповідних спеціалістів. В силу технічних особливостей інколи потрібно мати глибший досвід в інфраструктурі. У нашому випадку важливий контроль на кожному етапі, тому прийшлося в процесі навчитися налаштовувати Nginx і VPN, розгортати Docker на серверах та робити інші, зовсім не програмерські задачі. З одного боку, це хороша можливість «прокачати» відповідні компетенції і глибше зрозуміти сучасні технології, проте, з іншого, це займає час.

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

Перевіряйте чекліст Джоеля Сполскі і закривайте речі, які ще не імплементовані. Дискусія допускається в пунктах про тести і документацію. Слід розуміти, що стартапи — це швидкість, і написання тестів може суттєво збільшити час розробки продукту. Часом ці затрати можуть окупитися, а часом ні. Інколи краще відмовитися від ідеї на 100% покрити продукт крихкими тестами, але потім при кожній ітерації їх правити. Натомість дійсно критичні частини продукту покрити стійкими тестами і компромісно закривати ті речі, які не будуть переписуватися.

Мій досвід пов’язаний з тим, що ми досить регулярно щось дописуємо/переписуємо, і я не є фанатом TDD. Моя логіка не в тому, що не потрібне 100% покриття, а в тому, що тести потрібно писати в певний момент часу, коли на це є ресурси. Особливо важливо почати писати більше тестів в той момент, коли до команди розробки долучаються нові люди. В процесі знайомства з продуктом вони можуть писати код, який щось ламає, а тести — ефективний інструмент на рівні з код рев’ю, який дозволяє локалізувати такі проблеми.

Бізнес

Інколи хтось з команди або знайомих мене питає: «Скільки часу ви ще будете стартапом? Вам вже три роки, а ви досі піаритесь». Логіка досить проста — ми стартап, поки відхід одного з співзасновників проекту являє собою критичний ризик того, що проект закриється.

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

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

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

Натомість всім відома PayPal мафія — спільнота колишніх працівників (не тільки співзасновників) PayPal, які на свої акції option pool створили купу успішних бізнесів і стали мільйонерами. Причому є купа інших менших «мафій». Наприклад, під час нашого перебування в Берліні ми познайомилися з ранніми працівниками ZenDesk, DeliveryHero, які також за допомогою акцій option pool уже зараз інвестують і роблять власні бізнеси.

Географічно ближчий приклад — польський стартап для пошуку нянь niania.pl, вихідці з якого зараз дуже активні в інвестиціях в Східній Європі і заснували кілька успішних бізнесів.

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

Окрім складних і цікавих задач, у програмістів завжди буде рутина. На етапі переходу від стартапа до зрілого бізнесу потрібно по максимуму автоматизувати всі задачі з розробки, мати хорошу внутрішню базу знань — тоді нові люди зможуть легко ввійти до стану справ. Процеси розробки потрібно краще документувати, тестування продукту стає важливим і невідворотним процесом. Якщо раніше one-click-deployment — це вже було добре, то тепер варто більше дивитись у сторону практик immutable deployment. Адже аварійні стани системи можуть бути не такими критичними для стартапу, проте набагато більш болючими для усталеного бізнесу.

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

Замість висновків

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

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

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

— Важливо бути в курсі сучасних технологій і по можливості впроваджувати їх в проект. Але потрібно насамперед роботи мінімальний аналіз cost/benefit зі сторони бізнесу. У нашому випадку ми розглядали можливість міграції з Backbone на Angular, але часові затрати були незрівнянно більшими за плюшки, які ми могли одержати. З іншого боку, ми аналізували переїзд з self-hosted PostGreSQL на Amazon RDB, і хоча це тягло за собою суттєві витрати часу, виграш від нової технології при масштабуванні був суттєво вищим.

Буду радий почути ваші думки або запитання в коментарях.

P.S. Якщо вам цікавий наш проект — ми регулярно шукаємо досвідчених Python-програмістів. Писати можна на preply.com/ua/help/contact.