Писати код недостатньо. Як я створював продукт

У вільний від роботи та відпочинку час я займаюся власним pet project, або точніше — pet product. Це виявилося доволі цікавою вправою, майже не пов’язаною з тим, що я робив як найманий працівник.

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

На сам продукт і його опис можна подивитись тут або тут.

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

Проблема, або Problem Statement

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

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

Крім проектування та розробки нової функціональності, одним з обов’язків окремої команди був component ownership, що, своєю чергою, охоплювало володіння кодом. Останнє включало в себе мерджі, аналіз змін, підготування релізів і підтримку кодової бази в задовільному стані. Всі перелічені активності потребували постійного перегляду коду — або того, що називається code review.

Зазвичай, я витрачав на це чверть свого робочого часу. Єдиним інструментом був git diff та різні його візуалізації, на кшталт GitHub pull requests або gitk чи SourceTree, тож на додачу до витраченого часу я отримував ще й не найприємніші відчуття. Відкритий IDE, іноді з декількома проектами, купа вкладок у браузері, полотна діфів, що потрібно було покласти на одне ціле... Коротше кажучи, страх і ненависть у Лас-Вегасі.

Я не розумів, скільки інших програмістів мали таку ж проблему, але хотів перш за все знайти рішення для себе: зменшити витрати часу та зробити роботу приємнішою. Також мене мотивувала історія про запланований продаж gitprime за $170 мільйонів. Це підтверджувало існування ринку.

Сценарії, або Use Cases

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

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

Підтвердження мерджів. Те, що називається pull/merge requests та їх code review, іноді ще не завершеної роботи. Забігаючи наперед, я вже почув багато відгуків: це ж така проста штука, ми тут зовсім не витрачаємо часу.

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

По-друге, до нашого компонента іноді вносили зміни чотири сусідні команди.

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

Аналіз змін для QA. Потрібно перевірити нову фічу або виправлення. На практиці, тікети можуть не мати достатньої інформації, а QA — щось забути чи не розібратися, де в вашому чудовому інтерфейсі є потрібна галка. Ще зміни можуть торкатися компонентів, логічно не пов’язаних з фічею, наприклад, змінений UI-компонент використовується в декількох місцях і в різних варіаціях, або зміни зачіпають умовне «ядро» системи.

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

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

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

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

Всі перелічені активності були повторюваними, пов’язаними між собою і, принаймні в мене, забирали силу-силенну часу. На той час цього було достатньо, щоб продовжити працювати над окресленою проблемою.

Відпустка та її продовження

У вересні 2019 я повернувся з Таджикистану. Наша команда якраз завершила ще одну стадію величезної фічі, що поетапно розроблялася десь півтора роки. Це був час поспілкуватися з моїм директором та... піти з компанії.

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

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

Пошук рішення

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

Щось таке:

Відмінність між строковим представленням змін та представленням на умовній архітектурі платформи

Прочитав би я тоді «Тест для мами» Роба Фітцпатріка — продовження було б інше.

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

Обговорення з друзями

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

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

Ще один мій товариш порекомендував Startup School від Y Combinator. Це були поради, що зекономили мій час та дозволили навчитися багато нового. Та найцікавішим було те, що я не очікував на такий результат.

Конференції, або Offline networking

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

На жаль, нічого не вдалося, бо почалася пандемія COVID-19. Але я не хотів здаватися. Взагалі, розробка продукту — це про подолання перешкод і продовження шляху. Тож я продовжив шукати інші канали.

Пошук клієнтів в LinkedIn

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

1. Чию проблему ти вирішуєш?
2. Хто ухвалює рішення про покупку?

Я не знав відповідей, тож користався гіпотезами.

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

Отже, я активував преміум-доступ і пішов шукати цільову аудиторію в Sales Navigator.

Зараз я розумію невдалий вибір категорії VP of Engineering, CTO або co-founder в компанії до 50 осіб, але тоді я не розумів ні цих людей, ні того, як працює LinkedIn.

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

Потім я прочитав пояснення цих відчуттів у вже згаданій книзі «Тест для мами» Роба Фітцпатріка, де було багато іншої корисної інформації про інтерв’ю. Але починав я без цих важливих знань.

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

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

Я впевнився щодо цих висновків, коли зробив те саме з вибірками позицій engineering та product manager, а згодом — і з програмістами.

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

Тож я його відклав до інших часів.

Startup School

Це безкоштовна та, без перебільшення, найкраща онлайн-програма навчання зі створення стартапів. Від Y Combinator — найкращого акселератора стартапів.

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

Саме під час участі в цій програмі я міняв стислий опис ідеї разів 30, допоки не навчився однаково добре пояснювати, що я роблю, не лише програмістам, а й хлопцям, що створювали «Uber для лікарів» в Бразилії і гадки не мали, що таке merge request.

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

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

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

Y Combinator

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

Раніше я вважав, що YC — це, перш за все, $150k за 7% майбутньої компанії. Насправді YC — це доступ до найкращих спеціалістів у галузі стартапів, робота з ними впродовж трьох місяців і підготовка до наступного раунду інвестицій, звісно, з доступом до кращих інвесторів.

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

• Чому ви робите цей продукт?
• Чому ви зробите цей продукт краще за інших?
• Як ви плануєте заробляти?
• Як ви плануєте отримувати користувачів?
• Скільки продукт може заробити?
• ...

Питань, звісно, більше, та ці були, на мою думку, найбільш важливими. Якщо ви робите або плануєте продукт — обов’язково заповніть форму на подання в Y Combinator. Після заповнення вам буде зрозуміло, треба тиснути кнопку Submit чи шукати відповіді.

Product Hunt, Hacker News та інша стартап-тусовка

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

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

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

Вам можуть підказати, як робити продукт, але як канал залучення клієнтів такі ресурси можуть працювати, лише якщо ви робите щось для стартапів, як-от відомий Stripe чи Unicorn Nest.

Мінімальний життєздатний продукт, або MVP

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

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

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

Справа в тому, що і я питав себе теж саме. Тож вирішив написати невеликий додаток з відносно свіжим стеком. Як виявилося — з програмуванням все гаразд. Нарешті, через 12 років в IT, у мене з’явився репозиторій на github, що можна показати разом з резюме. Іншою причиною було те, що я не розумів остаточно, що конкретно можна зробити.

Попередньо я планував зробити універсальний алгоритм, що відповідатиме на доволі абстрактні питання менеджерів. Наприклад, чи немає ніяких незапланованих або небезпечних змін, як-от нового public API або міграцій у базі даних. Або показувати зрозумілий для бізнесу опис змін, як-от «додали нову кнопку на екран Х». Маючи відповідний технічний досвід, я розумів серйозні ризики втілення таких ідей, але не знав, що буде насправді.

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

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

Результат виглядав так:

Landing page

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

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

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

Висновки

Підсумувати мій досвід можна переліком рекомендацій, що я би дав собі понад рік тому:

1. Постійно збільшуйте кількість дружніх стосунків! Навіть якщо ви не робите і не плануєте робити власний продукт. Знайомі завжди приділять вам увагу і поспілкуються щодо вашої проблеми, на відміну від незнайомців.
2. Прочитайте «Тест для мами»! Книга в 140 сторінок навчить вас ефективно обговорювати будь-які ваші ідеї з близькими і незнайомими людьми.
3. Не робіть презентацій, щойно у вас з’явилася ідея. Ви витратите час та будете тримати фокус на вигаданому рішенні. На початку важливо знайти реальну проблему в обраній сфері чи процесі, що гарантовано внесе зміни в концепцію. Неодноразово.
4. З тієї ж причини, не пишіть код на початку. Якщо презентація — це дні або тижні, то реальне рішення — це місяці. Можливо, ви не зможете знайти потрібну аудиторію, і доведеться займатися чимось іншим. Доволі неприємно викидати стільки часу на смітник, а це нормальна ситуація, коли виявляється, що від ідеї потрібно відмовитися.
5. Починайте з інформаційного сайту і дешевого MVP, коли ви вже знайшли реальну проблему і розумієте, як збільшувати аудиторію.
6. Спитайте ваших знайомих про процеси і проблеми, що можуть бути пов’язані з вашою гіпотезою. На цей час забудьте про ваш уявний продукт, і присвятіть увагу проблемам вашого співбесідника. Можливо, ви зробите зовсім інше рішення, але воно буде потрібним.
7. Якщо ви вже маєте ідею — візьміть участь у Startup School. Вас навчать, що робити далі.
8. Заповніть заявку в Y Combinator. Її не обов’язково відправляти, але ви будете розуміти, що вам потрібно, аби зробити це надалі. Більше того, ви зрозумієте, що є важливим для успіху вашого продукту.
9. Вчіться писати і пишіть статті. По-перше, це те, чим вам доведеться займатись, щоб пояснити, що ви робите, або залучити людей до продукту. По-друге, чим більш ви відомі, тим простіше охопити велику частину аудиторії.
10. Використовуйте Grammarly, коли пишете англійською: всього $130 на рік, щоб суттєво покращити ваші тексти. На відміну від окремого вичитування реальною людиною, це рішення дешевше і працює набагато швидше.
11. Навіть якщо ви плануєте глобальний продукт, не обов’язково спочатку запускати його в Америці. Якщо у вас будуть клієнти або користувачі в Україні, вам буде набагато простіше масштабуватися і говорити з акселераторами типу Y Combinator. Можливо, це неправильне розуміння, але AXDRAFT, судячи з портфоліо, починав саме з України, а потім вже пройшов YC W19.

Отже, навіщо я написав цю статтю?

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

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

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

В Америці це безліч сайтів, такі як Stack Overflow, Reddit, Dev.to, Medium, Techcrunch та інші. Не всюди можна самостійно розмістити статтю, а там де можна — її навряд чи побачать, якщо ви невідомі або не занесли купу грошей. До того ж треба добре розуміти специфіку кожного такого медіа, щоб визначити, що вони дають і як ними ефективно користуватись.

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

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

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

Дякую за увагу і бажаю гарного настрою!