Робота в стартапах: міфи та реальність (перевірено на власному досвіді)

Привіт, мене звати Андрій, я Engineering Lead в компанії Uptech.

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

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

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

Але я ризикнув і прийняв офер. Я пропрацював на п’яти проєктах у командах по 2–5 людей з ідеями, які ще тільки мали стати продуктами. Доводилося виконувати досить незвичні завдання. Наприклад, якось ми інтегрували React Native в наявний Android-застосунок. Це був новий і далеко не простий досвід, де треба було водночас розуміти потребу продукту в такій технологічній зміні, а також реалізувати інтеграцію, яку взагалі рідко хто робив у світі.

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

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

Почнемо з найпоширеніших стереотипів щодо роботи в стартапах.

Міф 1. «Стартапи з’їдають гроші інвесторів і не приносять цінності»

Пам’ятаєте іконічні фейли Кремнієвої долини — надтехнологічний соковитискач Juicero або нікому не зрозумілі Google Glass? Такі кейси залишили від стартапів враження «пустишок», що народжуються лише для того, щоб зібрати гроші з інвесторів та мирно померти під викривальний галас журналістів.

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

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

Міф 2. «Стартапи — ненадійні, і можуть вмить втратити гроші»

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

В Uptech ми вивчаємо історію та робимо оцінку кожного потенційного клієнта. При цьому ми керуємося наступними критеріями:

Чи є клієнт платоспроможним?

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

Чи сам клієнт зацікавлений у розвитку свого продукту?

Фаундера стартапу за звичкою уявляють як активного «хастлера» який «носиться» з власним продуктом як із дитям. У реальності це не завжди так. Не всі стартапери серйозно ставляться до своїх ідей або недостатньо в них вірять.

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

  • Як у клієнта з’явилася ідея такого продукту?
  • Яка в нього/неї мета?
  • Чи досліджували вони ринок?
  • Чи орієнтується він/вона в домені, в якому працює?
  • Чи цікавився клієнт нашою студією?
  • Оцінюємо, чи клієнт відкритий до спілкування.

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

Міф 3. «Стартапи — це про постійні овертайми»

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

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

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

Чому ж інженерам слід працювати в стартапах

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

Проєкт з нуля

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

Більша залученість на проєкті

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

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

Більш челенджові таски

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

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

Відчуття того, що ти робиш щось суттєве

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

Дух стартапу

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

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

Недоліки роботи в стартапі

Попри переваги роботи в стартапі, тут також є певні складності. Буде справедливо зазначити і їх. Особисто я б виділив такі:

Часта зміна вимог

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

Дійсно багато роботи

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

Велика відповідальність

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

Які скіли необхідні інженеру, щоб працювати в стартапі

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

  • Впевнені хард скіли. Як правило час розробки стартапу (особливо якщо мова йде про базову версію продукту (Minimum Viable Product) значно обмежений (3–4 місяці). Не завжди є час на прокачування скілів програмування на ходу. Отже джун не завжди підійде на такий проєкт.
  • Високий рівень самомотивації. У стартапах справи не завжди йдуть за планом. Іноді проєкт просто не злітає, чи MVP-тести свідчать про те, що на ринку немає потреби в твоєму продукті. Sad but true. Особливо якщо ти дійсно вкладався у цей проєкт, як у власний. Але важливо прийняти, що в цій грі такі правила, і кожен провал вчить чомусь новому. Головне не здаватись і робити висновки.
  • Простий підхід до роботи. Робити ідеально — це не завжди добре, тим більше коли маєш купу обмежень по часу і ресурсах. У процесі розробки стартапів немає часу на «шліфування» коду. Натомість код має просто працювати та виконувати базові функції продукту. Це я і вкладаю в слово «простий» — не заморочений до деталей. У стартапах overengineering — головний ворог.

Які скіли я розвинув, працюючи в стартапах

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

  • Прокачав технічні навички. Звісно, прокачується вміння швидко та якісно кодити. Крім того, я багато дізнався про продуктову розробку, дизайн, менеджмент і т.п.
  • Навчився працювати в крос-функціональній команді. В стартапах усі учасники команди (дизайнери, програмісти, продакт-менеджери) працюють над продуктовою розробкою. Такий підхід називається крос-функціональна команда.
  • Став пріоритезувати завдання. Пріоритезація — це надувний круг, що рятує тебе в потоці нескінченних тасків. Це особливо складно, коли ніби всі таски однаково важливі. Доводиться розставляти їх по терміновості.
  • Навчився оцінювати час на виконання завдань. Вміння розраховувати час на виконання кожного таска виходить на автоматичний рівень. І чим більше я працюю, тим більш наближені до реальності такі розрахунки. Цей фактор дуже сильно впливає на професіоналізм розробника.
  • Брав участь у наймі нових членів команди. Коли працюєш на невеликому вузькоспеціалізованому проєкті, то входиш у невелику групу людей, які можуть пояснити, що взагалі на ньому відбувається. Тому в певний момент ти стаєш частиною процесу найму й час від часу спілкуєшся з потенційними кандидатами.
  • Продуктовий підхід. Яку архітектуру треба закласти в застосунок, щоб потім можна було його масштабувати? Працюючи зі стартапом, починаєш думати не тільки про те, як знайти рішення свого завдання. Ти думаєш про те, як таке рішення відобразиться на продукті в цілому.

Висновок

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

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

к сожалению, все 3 мифа — не мифы, а статистически отображают сущность.

Недоліки роботи в стартапі

Ты не написал про невозможность расти вширь — три года ковыряться в одном и том же коде означает деградировать по другим направлениям.

Коментар порушує правила спільноти і видалений модераторами.

На каждый товар есть свой покупатель.

Підписатись на коментарі