Варто бізнес кофаундеру IT-стартапу вчитися програмувати?

Далеким влітку 2014 року моя відповідь на це питання була ствердною. Це змінило моє життя. А ось в яку сторону — питання відкрите. У будь-якому випадку я з радістю (і болем) ділюся вистражданими і вичитані думками та власним досвідом.

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

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

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

Моя історія
У 2014 році наша команда з 4 осіб (4 кофаундера, з яких лише один був розробником) працювала над сайтом для підготовки до ЄДІ bitclass.ru. Все йшло відносно добре, але до кінця навчального року нам здалося нецікавим робити сайт, на якому, нехай і в інтерактивній формі і з геймификацией, ми просто публікуємо завдання. Ми затіяли досить радикальний півот. Ця історія ще не закінчилася, і про те, що вийшло в результаті, я ще напишу (вийшла lampa.io — соціальна освітня платформа, де публікувати навчальні матеріали може не тільки наша редакція, але і всі бажаючі). Так от, під час цього півот у мене склалося (помилкове) враження, що єдиний цінний на даний момент вклад, який можна зробити у загальну справу, – це програмування. Я відчувала пекучу заздрість до нашого єдиного розробнику, дивлячись на безліч кольорових літер на його чорному екрані. Він один був зайнятий справжньою справою.

Після двох або навіть трьох місяців недозволено розслабленої для wannabe стартаперів життя і одного онлайн-курсу з основ програмування я випадково зайшла на сайт однієї очної школи розробників, прочитала опис концепції і подумала, що по-справжньому навчитися програмувати — хороша ідея. Потім я вибрала самий інтенсивний і хардкорний курс по JavaScript + Node.js, який змогла знайти, і з головою занурилася в програмування на 3-3.5 місяця. Це був чудовий час, і програмувати майже без вихідних (офіційно 6 днів в тиждень по 11 годин на день + ще 3-5 годин після занять), з перервами лише на сон і їжу, в компанії людей, які проходять через той же досвід, було дуже здорово. З одного боку, ми багато працювали. З іншого боку, після року роботи над власне стартапом, в якому основною трудністю була постійна невизначеність, така структурована життя сприймалося як відпустка. 80-90% моїх однокласників стали працювати програмістами, причому навіть не junior'ами.

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

Плюси і мінуси
Почнемо з плюсів:

  1. Ваш стартап стане непотоплюваним — в самому крайньому і гіршому випадку ваш burn rate (сума грошей, яку стартап витрачає за певний період часу) може стати рівним витратам на життя однієї людини (у цьому, втім, є і мінус — можна займатися безперспективним проектом роками і витратити на це найкращий час життя); навіть якщо ваша команда чомусь розвалиться, стартап зможе це пережити.

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

  3. Не буде болісного періоду, коли продукт ще не готовий, а іншим членам команди начебто нічого робити. Що призводить до сумнівів, бродіння умів і депресивним настроям. Головне – пам'ятайте: те, що вам нема чого робити, – цілковита ілюзія і виправдання своєї ліні або невпевненості.

  4. Це, мабуть, самий головний плюс: навіть як бізнес-кофаундер, виконуючи цілком собі бізнес-функції, ви стаєте набагато більш ефективними. Є тисяча дрібниць, для швидкого виконання яких потрібні технічні навички: швидка публікація нового контенту на сайті, додавання JavaScript цілей в Яндекс-Метриці, вивантаження даних з бази, тестування нового value proposition на лендинге. Кожна з цих дій – це навіть не програмування, іноді це пара рядків коду, але без технічних навичок самостійно з ними впоратися. Треба хоча б знати, куди залізти, щоб цю пару рядків коду написати. А значить, без технічних навичок ви будете рухатися повільніше, ніж могли б.

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

  6. Коли закінчуються аргументи, можна швидко щось зробити самому. Так, в команді повинен бути консенсус, але якщо ви вірите в якусь фічу, а кофаундера переконати ніяк не можете, в крайньому випадку можна швидко впровадити її і перевірити результат. А якщо не піде – без проблем прибрати.
Але переважують мінуси:

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

  2. Бажання навчитися програмувати, тобто все робити самому, може бути ознакою невміння або небажання делегувати і мотивувати або невпевненості в ідеї.

  3. У вас з'являється додатковий стимул до того, щоб працювати багато, замість того, щоб працювати з розумом (звичніше у формулюванні work hard, not smart). Якщо вважати, що мати винаходів – необхідність, то у ваших потенційних винаходів буде менше шансів народитися. У вас більше не буде необхідності придумувати швидкі експерименти. Навіщо робити щось швидке і сире, якщо можна відразу зробити красиво і правильно? До речі, така ж підстерігає пастка і ті команди, де всі фаундеры спочатку програмісти.

  4. Якщо програмувати вам сподобається (а це здається необхідною умовою для того, щоб це взагалі виходило), то вам захочеться програмувати весь час; усі інші напрямки діяльності стартапу, наприклад customer development або маркетинг, від цього сильно страждати; програмувати дуже приємно психологічно: ви створюєте продукт, в кінці дня з'являється відчутний результат і при цьому ніхто вам не каже, що-те, що ви зробили, абсолютно нікому не потрібно. Якщо ж ви спілкуєтеся з потенційними користувачами або навіть просто досліджуєте ринок, то з великою ймовірністю постійно отримуєте погані новини.

  5. Розуміння технічної сторони питання обмежує політ вашої фантазії. Якщо ви знаєте, що якусь фічу належить впроваджувати вам, то ви з великою ймовірністю придумаєте якусь її варіант, який простіше в розробці, а не краще для користувачів. І це не завжди ефективно: так, ви витратите на розробку на день менше, але втрата, наприклад, конверсії за рахунок неоптимального рішення для користувачів може перекрити всю економію часу.
Чим себе зайняти
Так що ж робити нетехнічних фаундерам в смутний час, коли MVP не готовий? Варіантів безліч, а деякі справи і просто лежать на вашому «критичному шляху».

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

  • У багатьох випадках customer development можна починати до появи MVP. Можна проводити інтерв'ю з цільовою аудиторією не для того, щоб дати їм спробувати ваш продукт, а щоб зрозуміти, чим живуть ваші користувачі, як цей ринок працює зараз без вас і які проблеми у користувачів (майже точно в цьому місці я цитую чийсь чужий переказ книги Lean Startup). Інтерв'ю повинно бути багато. І їх результати повинні визначати, що ж, власне, ви розробляєте, або хоча б впливати на це.

  • Можна зробити прототип основних інтерфейсів (в ідеалі «живий» — з активними зонами) і займатися його тестуванням c потенційними користувачами. Плюси від цього кроку здаються очевидними, але чомусь на своїх проектах ми вперто цього не робимо. Підозрюю, що таку ж помилку допускають і інші команди, в яких немає дизайнера. Важливо створити і протестувати прототип не стільки тому, що так ви відразу покращуєте usability, скільки заради того, щоб краще продумати весь продукт від початку до кінця, а також зайвий раз поспілкуватися з користувачами і оцінити їхню реакцію на те, що ви робите.

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.