Далеким літом 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'ами.
В результаті програмувати я навчилася, а ось розвиток нашого стартапу це сильно сповільнило.
Відтоді минуло досить багато часу, щоб осмислити свій досвід і сформулювати плюси і мінуси того, щоб нетехнічний бізнес-кофаундер навчався програмуванню.
Плюси і мінуси
Почнемо з плюсів:
- Ваш стартап стане непотоплюваним - в самому крайньому і гіршому випадку ваш burn rate (сума грошей, яку стартап витрачає за певний період часу) може стати рівним витратам на життя однієї людини (в цьому, втім, є і мінус - можна займатися безперспективним проектом роками і витратити на це кращий час життя); навіть якщо ваша команда чомусь розвалиться, стартап зможе це пережити.
- На старті ви можете рухатися швидше, якщо в команді з'являється ще один програміст; хоча з урахуванням вашої недосвідченості за повноцінну бойову одиницю вас спочатку рахувати буде не можна; на більш пізніх стадіях це не має великого значення, тому що ви зможете знайти ще одного або декількох програмістів на зарплату.
- Не буде болісного періоду, коли продукт ще не готовий, а іншим членам команди начебто нічого робити. Що призводить до сумнівів, бродіння умів і депресивних настроїв. Головне - пам'ятайте: те, що вам нічого робити, - цілковита ілюзія і виправдання своєї лінки або невпевненості.
- Це, мабуть, найголовніший плюс: навіть як бізнес-кофаундер, виконуючи цілком собі бізнес-функції, ви стаєте набагато більш ефективними. Є тисяча дрібниць, для швидкого виконання яких потрібні технічні навички: швидка публікація нового контенту на сайті, додавання JavaScript цілей в Яндекс-Метріке, вивантаження даних з бази, тестування нового value proposition на лендингу. Кожна з цих дій - це навіть не програмування, іноді це пара рядків коду, але без технічних навичок самостійно з ними не впоратися. Треба хоча б знати, куди залізти, щоб цю пару рядків коду написати. А значить, без технічних навичок ви будете рухатися повільніше, ніж могли б.
- Ви зможете оцінити, скільки часу займає яка робота, а значить, зможете краще планувати і пріоритизувати різні завдання. До свого занурення в програмування іноді я навіть не висловлювала якісь пропозиції, заздалегідь припускаючи, що робити це довго і складно, хоча насправді їх впровадження зайняло б від сили годину.
- Коли закінчуються аргументи, можна швидко щось зробити самому. Так, в команді повинен бути консенсус, але якщо ви дуже вірите в якусь фічу, а кофаундера переконати ніяк не можете, в крайньому випадку можна швидко її впровадити і перевірити результат. А якщо не піде - без проблем прибрати.
Але мінуси переважують:
- Почнемо з очевидного. За той час, який потрібно, щоб по-справжньому навчитися програмувати, можна зробити багато всього корисного. Про це нижче. У крайньому випадку можна заробити грошей, які підуть на зарплату відсутнього програміста.
- Бажання навчитися програмувати, тобто все робити самому, може бути ознакою невміння або небажання делегувати і мотивувати або невпевненості в ідеї.
- У вас з'являється додатковий стимул до того, щоб працювати багато, замість того, щоб працювати з розумом (звичніше у формулюванні work hard, not smart). Якщо вважати, що мати винаходів - необхідність, то у ваших потенційних винаходів буде менше шансів народитися. У вас більше не буде необхідності придумувати швидкі експерименти. Навіщо робити щось швидке і сире, якщо можна відразу зробити красиво і правильно? До речі, така ж пастка підстерігає і ті команди, де всі фаундери спочатку програмісти.
- Якщо програмувати вам сподобається (а це здається необхідною умовою для того, щоб це взагалі виходило), то вам захочеться програмувати весь час; всі інші напрямки діяльності стартапу, наприклад customer development або маркетинг, будуть від цього сильно страждати; програмувати дуже приємно психологічно: ви створюєте продукт, в кінці дня з'являється відчутний результат і при цьому ніхто вам не говорить, що те, що ви зробили, абсолютно нікому не потрібно. Якщо ж ви спілкуєтеся з потенційними користувачами або навіть просто досліджуєте ринок, то з великою ймовірністю постійно отримуєте погані новини.
- Розуміння технічної сторони питання обмежує політ вашої фантазії. Якщо ви знаєте, що якусь фічу належить впроваджувати вам, то ви з великою ймовірністю придумаєте якийсь її варіант, який простіше в розробці, а не краще для користувачів. І це не завжди ефективно: так, ви витратите на розробку на день менше, але втрата, наприклад, конверсії за рахунок неоптимального для користувачів рішення може перекрити всю економію часу.
Чим себе зайняти
Так що ж робити нетехнічним фаундерам в смутний час, коли MVP не готовий? Варіантів безліч, а деякі справи і просто лежать на вашому «критичному шляху».
- Цілком очевидно, що можна працювати над різними паралельними розробкам завданнями. У нашому проекті якраз з цим все було просто. Оскільки продукт складається з технології та контенту, логічно було займатися створенням контенту.
- У багатьох випадках customer development можна починати до появи MVP. Можна проводити інтерв'ю з цільовою аудиторією не для того, щоб дати їм спробувати ваш продукт, а щоб зрозуміти, чим живуть ваші користувачі, як цей ринок працює зараз без вас і які у користувачів проблеми (майже точно в цьому місці я цитую чийсь чужий переказ книги Lean Startup). Інтерв'ю має бути багато. І їх результати повинні визначати, що ж, власне, ви розробляєте, або хоча б впливати на це.
- Можна зробити прототип основних інтерфейсів (в ідеалі «живий» - з активними зонами) і займатися його тестуванням з потенційними користувачами. Плюси від цього кроку здаються очевидними, але чомусь на своїх проектах ми вперто цього не робимо. Підозрюю, що таку ж помилку допускають і інші команди, в яких немає дизайнера. Важливо створити і протестувати прототип не стільки тому, що так ви відразу покращуєте usability, скільки заради того, щоб краще продумати весь продукт від початку до кінця, а також зайвий раз поспілкуватися з користувачами і оцінити їх реакцію на те, що ви робите.
- Можна перевіряти, наскільки ваша ідея цікава цільовій аудиторії, розповідаючи про неї в тематичних пабліках у соціальних мережах. Можна починати вести свій блог. Так ви можете наростити аудиторію ще до запуску продукту. А якщо вас ніхто не читає, постає питання про те, чи потрібно комусь те, що ви робите.
Резюме
Висновок тут такий: якщо ви бізнес-кофаундер стартапу і думаєте про те, щоб піти вчитися програмувати, то, швидше за все, вам не варто цього робити.
