Є різні шляхи розвитку програміста, я випробував їх все на собі, тому все, що буде написано нижче, взято з реального досвіду. Я був експертом – доходив до рівня архітектора. Був керівником — доходив до рівня проєкт менеджера. І зараз я йду третім із можливих шляхів — зараз я засновник власної компанії. Я часто проводжу кар’єрні консультації і бачу, що у багатьох немає чіткого розуміння, куди ж можна розвиватися програмістам, коли вони вже досягли високого рівня сеньйорності.
Три дороги для програміста
Є дуже багато доріг, якими може піти людина у своєму професійному розвитку. Це стосується будь-якої сфери, але я говоритиму конкретно про програмістів і тільки про три найпростіші і зрозумілі шляхи, що логічно випливають з діяльності розробника. Зрозуміло, що можна кардинально змінити спеціальність та стати чиновником, але ж це зовсім не очевидний шлях. Три найочевидніші дороги: дорога експерта, дорога керівника та дорога засновника.
У кожний момент часу ви повинні розуміти, якою з доріг ви йдете. Ви не можете йти відразу двома дорогами. Залежно від обраного шляху дії будуть абсолютно різними. Але це не означає, що ви все життя маєте присвятити якійсь одній дорозі. Ні, ви можете перемикатися, змінювати свої плани та цілі. Але ви повинні розуміти, в який момент часу якою дорогою йдете. Від цього залежатимуть ваші рішення.
До чого приводить кожна дорога
ЕКСПЕРТ. Цей шлях закінчується міжнародно-визнаним експертом у якійсь галузі. Такий фахівець читає лекції, приїжджає як експерт-консультант в інші компанії, легко вирішує складні архітектурні питання тощо. Наприклад, Роберт Мартін — він дійшов до піку дорогою Експерта.
КЕРІВНИК. Цей шлях закінчується виконавчим директором великої міжнародної компанії. Так, це все ще наймана посада, але при цьому ви керуєте величезною корпорацією.
ЗАСНОВНИК. Цей шлях веде до створення власної крутої компанії та закінчується десь у списку Forbes та мільйонами на рахунках 🙂
З чого починати?
Завжди все починається із дороги Експерта. Ви приходите на свою першу роботу і потихеньку починаєте розвивати свою експертність. Звичайно, бувають і інші ситуації, коли на першу роботу ви якось потрапили як керівник. Але це виняток, зазвичай все ж таки починають з дороги експерта. У якийсь момент ви можете задуматися, що хочете бути керівником або заснувати власну компанію, і тоді ви зміните дорогу Експерта на якусь іншу. Поговоримо про кожну з них докладніше.
Що принесе більше грошей?
Тут немає конкретної відповіді. Дуже часто трапляється ситуація, коли найманий програміст заробляє більше, ніж засновник власної компанії. Компанія може бути маленькою і не розвиватися, а хороший програміст отримує дуже високу зарплату. Крім того, якщо ви власник компанії, це не означає, що ви взагалі хоч щось заробите. Може, ви взагалі підете в мінус і доведеться докладати свої гроші, щоб компанія вижила.
Чи керівники заробляють більше, ніж експерти? Теж ні. Керівники низької ланки можуть заробляти менше, ніж їхні підлеглі. У ІТ це теж типова ситуація, де програмісти часто заробляють більше, ніж їх менеджери. Але це не означає, що дорога експерта приносить найбільше коштів. Керівник високої ланки заробляє дуже добре. Тобто, все залежить від того, яку позицію займаєте ви на своєму шляху. Але скажемо так, на дорозі експерта заробити дуже багато грошей складніше, ніж на дорозі керівника та засновника.
Але ви повинні розуміти, що дорога вибирається не через гроші, а з покликання, ваше бажання цим займатися.
Дорога Експерта
Дорога складається з досить простих кроків: джуніор -> мідл -> сеньйор девелопер. А що далі? У цьому місці більшість сеньйорних програмістів зависає. Один з варіантів — ви можете залишитися на цій позиції і спокійно продовжити працювати, якщо вас це влаштовує. Це варіант для тих, хто, крім роботи, має насичене життя і купу хобі, а робота просто для заробляння грошей. Ви можете спокійно залишатися на позиції сеньйора до самої пенсії — це нормально, головне, щоб вас все влаштовувало. Не потрібно ганятися за чужими мріями, ставати керівником або відкривати свій бізнес, якщо вам це не цікаво.
Якщо ж ви хочете розвиватися та розвиватися саме в експертній галузі, то наступний крок – техлід. Техлід – це найголовніший, провідний розробник у команді. Він приймає найважливіші технічні рішення (наприклад, який фреймворк використовувати), встановлює технічні правила проєкту (в т.ч. вимоги щодо чистоти коду), робить код ревью тощо. Техлід відповідає за технічний стан команди. Однак у багатьох компаніях посади техлід взагалі не існує, а його обов’язки змушують виконувати тімліда. Хоча спочатку до обов’язків тімліда входить розподіляти завдання та навантаження між членами команди.
Наступний крок дорогою Експерта – архітектор. Але й тут все не так просто. У кожній компанії посада архітектора може відрізнятися за обов’язками. Ви не можете, будучи архітектором в одній компанії, перейти архітектором в іншу компанію. Найчастіше це так не працює. У кожній компанії дуже сильно відрізняються вимоги та очікування від архітектора. У деяких компаніях є не один, а безліч всяких архітекторів — soft архітектор, solution архітектор та ін. .
Які скіли потрібно прокачувати, щоб розвиватися як Експерт
- НАДІЙНІСТЬ
Вміння правильно ставити естімейти і дотримуватися їх. Про це я говорив уже багато разів.
- РОЗУМІННЯ BUSINESS VALUE
Розуміння чого хоче бізнес. Для техліда це дуже важливо, бо на вас будуть орієнтуватися інші розробники команди. Якщо техлід хоче рости до архітектора, йому треба розуміти, як технічно вирішувати проблеми бізнесу. Інші співробітники реалізують рішення, але саме техлід чи архітектор вигадує, яке рішення буде використано.
- ПУБЛІЧНИЙ ВИСТУП
Будучи техлідом, ви зобов’язані доносити до команди свої технічні рішення, зміни політики щодо коду рев’ю, з інженерних практик та інших моментів. І ви повинні вміти обґрунтувати всі ці зміни. Ви не повинні керувати командою, ви повинні їх вести як найсильніший розробник у команді. Те саме, але значно більше вам знадобиться, коли ви перейдете на позицію архітектора. Бо архітектор пояснює щось не команді, а замовнику. Тому я дуже раджу, як тільки ви досягли рівня техліду, починайте активно качати свою навичку публічних виступів. Виступайте на конференціях, влаштовуйте нетворкінги, тому що архітекторів зазвичай беруть за знайомством.
- ЗНАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ
Архітектор повинен ідеально розуміти предметну область, знати, як її автоматизувати, які проблеми і як вирішуються з допомогою технічних засобів. Така людина може ходити разом із sales на зустрічі з клієнтами, пояснювати технічну частину та як вирішуються проблеми клієнта. Ідеальний архітектор – той, який розбирається в архітектурі з прив’язкою до предметної області.
- ЗНАННЯ АРХІТЕКТУРИ
Це фахівці, які можуть читати лекції з приводу того, як правильно будувати мікросервіси, як виконувати інжинірингові практики, як будувати делівері, як усе це працюватиме та ін.
Добре, якщо архітектор знає добре і предметну область, і архітектуру. Проте на чомусь потрібно спеціалізуватися. Тому фахівець може більше йти в одну чи іншу із цих областей. Куди направляти основні зусилля? Я порадив би на знання предметної області, але це питання неоднозначне, тому що знати добре архітектуру архітектор теж зобов’язаний.
Є окрема категорія експертів – людина, яка досконало знає якийсь фреймворк. Це також дуже цінний експерт, якого люблять кликати в різні компанії. Таких експертів теж часто називають архітекторами, але це все ж таки трохи з іншої області. Однак цю експертність складно продавати замовникам, тому досить низька стеля зарплат, на відміну від архітекторів, які добре знаються на предметній галузі.
Ви повинні розуміти, що якщо ви йдете дорогою Експерта і думаєте, що це чисто про технології — ні, рано чи пізно все одно доведеться занурюватися в якусь предметну область.
Дорога Керівника
Спочатку важливо прояснити один момент, який я часто зустрічаю в різних програмістських спільнотах — мовляв, навіщо нами керувати ми самі все зробимо. Що ж, на це можу сказати лише одне – так не працює. Все, крапка. Будемо чесні — навіть якщо ви зберете команду з дуже крутих експертних людей, вони нічого путнього разом не зроблять, якщо ними не керувати. Якщо вони все ж таки щось зробили, це означає лише одне — хтось із них узяв на себе обов’язки лідера. Професія керівника виникла одна з найперших у цьому світі. Завжди були якісь вожді, ті, хто керував армією та ін. Якщо іншим не говорити, що робити, кожен робитиме що йому спаде на думку і піде нескінченна кількість часу на обговорення що ж робити. Завжди має бути одна відповідальна людина. Тому програмістами треба керувати. З мого особистого досвіду — якщо у проєкта хороший менеджер і погані програмісти, проєкт з великою ймовірністю буде жити і все з ним буде добре. У команді з дуже хорошими програмістами, але з поганим ПМ проєкт, швидше за все, провалиться.
Як вирішити, що хочеш бути керівником?
У кожного по-різному приходить розуміння, що він хоче бути керівником. У мене таке відчуття прийшло, коли я побачив, як багато помилок допускає мій керівник. Я дивився, як він керує нашим проєктом, розумів, що він веде проєкт до провалу, у мене свербіли руки влізти в керівництво і все виправити, я з ним лаявся, показував очевидні речі, але мене особливо не слухали, і зрештою проєкт провалився . Після цього я зрозумів, що хочу керувати сам, не хочу щоб наші проєкти так бездарно провалювалися. Якщо ви хочете бути відповідальними за успіх проєкту, подумайте про те, щоб рухатися по дорозі керівника. Насправді таке рішення ухвалюється практично автоматично.
Після того як ви кілька років пропрацювали Senior девелопером, якщо у вас високий рівень відповідальності і ви хочете йти дорогою керівника, тоді наступний крок стати тімлідом. Тімлід – посада, яка знаходиться на стику технічної та менеджерської роботи. Саме перебуваючи на цій посаді, ви можете подивитися, який із половини ваших обов’язків вам ближчий — обов’язки з керівництва або обов’язки з розробки. Я в цей момент і виявив, що мені подобається керівництво більше.
Важливо розуміти аспекти керівництва. У нашій культурі мається на увазі, що ви керуєте своїми співробітниками. Тут фокус на процесі – керівництво людьми. В американській культурі швидше розуміється, що ви відповідальні за щось (responsible person), при цьому немає жодного слова про підлеглих. Responsible person може взагалі не мати підлеглих, він просто відповідає за щось. У цьому випадку фокус на цілі. Я радив би вам розглядати себе в ролі керівника саме як responsible person. Тобто, ви керуєте іншими людьми не тому що ви любите командувати, ви ними керуєте щоб досягти мети та завдання у вас спільне.
Відмінності Team Lead від Project Manager (PM)
PM відповідає за успіх проекту загалом. Він відповідає за бюджет проєкту, за ризики, за роботу команди загалом тощо. Якщо брати футбольну аналогію, то PM – це тренер, він керує діями команди, але полем не бігає. Team Lead – це капітан команди, він теж бігає по полю, бере участь у грі, при цьому несе відповідальність за саму команду і спостерігає, як поводиться кожен учасник. PM ніколи не зможе визначити ефективність кожного розробника, а ось тімлід може. Це потрібно, щоб розуміти, які завдання комусь давати для більш ефективної роботи команди. Можливо, у людини є схильність до завдань якогось типу, тоді такі завдання можна передавати йому. Або людина зав’язає на своїх завданнях і їй потрібно дати щось інше, щоб вона передихнула і переключила мізки. Все це PM зробити не зможе. Взагалі досить часто PM не має технічного бекграунду, він мислить категоріями, чи справляється людина взагалі зі своїми обов’язками, чи ні, якщо ні — її потрібно замінити для успіху проєкту. Тімлід роздає завдання, стежить за атмосферою в команді, щоб у всіх була робота і щоб не було перенавантаження. Якщо людина перевантажена, вона йде лаятися з PM, інакше це може призвести до вигоряння.
Відмінності Team Lead від Senior Developer
Коли ви сеньйор, ви також можете керувати своєю маленькою командою (наприклад, вам дали у підпорядкування джунів або мідлів). Це досить поширена історія. Все це дуже схоже на роботу тімліда, тільки ви керуєте не всією командою, а її частиною. Виходячи з того, наскільки вам вдалося керувати цією маленькою командою, вже і визначають, чи варто вас розглядати як тімліда в майбутньому. Але все ж таки у Senior Developer керівництво — побічний обов’язок, за бажанням він взагалі може нікого не брати в підпорядкування. Його основний обов’язок — працювати над проєктом та брати на себе складні та критичні технічні завдання. Зазвичай критичними завданнями займається архітектор або техлід, але якщо його немає, їх виконує сеньйор девелопер. Тімлід ніколи не може ставити на себе критичні завдання, тому що половину свого робочого часу він зайнятий менеджерськими обов’язками, його можуть відірвати на наради з керівництвом, замовником, з PM. Тому тімлід ставить на себе завдання не вище medium priority, а ідеалі low priority. Тому що якщо ви тімлід і поставили на себе критичне завдання, яке блокує роботу решти команди, а вас раптом викликали на нараду, ви гальмуйте всю роботу.
Team Lead та Tech Lead
Тімлід пояснює техліду, чого від нього чекає, наприклад, робити код ревью і стежити за якістю коду в команді, стежити за відсотком покриття тестами, стежити, щоб команда дотримувалася обраних технічних аспектів тощо. Також пояснює, чим займатиметеся ви як тімлід: стежитимете за навантаженням, за передачею завдань, аналізом, хто з чим справляється краще, будете буфером між PM, якщо той намагається надто завантажити або, навпаки, дає недостатньо завдань. Техлід для тімліду найбільша опора. Розділіть з ним чітко сферу обов’язків та співпрацюйте, не лізьте у його рішення. Нагадую, що тімлід – наполовину менеджер, наполовину програміст, а техлід – це найсильніший сеньйорний програміст.
Як ставитися до програмістів
Пам’ятайте про те, що програмісти: а) розумні; б) хитрі; в) добре всі помічають. Тому будьте адекватною людиною. Ви повинні вести команду до якоїсь мети. Саме це пояснити програмістам — навіщо ви і що буде у вашій компетенції. Один із головних інструментів тімліду – щоденні status meeting.
Як роздавати завдання
Коли вас тільки призначили тімлідом, вам, швидше за все, не вдасться призначати завдання. Ви, найімовірніше, не зрозумієте, кому які завдання роздавати, тож обговоріть зі своєю командою, щоб вони брали завдання за пріоритетом. Слідкуйте за тим, як вони справляються, запам’ятовуйте, хто і як виконує свої завдання. Якщо ви побачите, що команда не бере критичне завдання, пінгуйте їх. З мого досвіду не буває такого, щоб усі відмовилися. По-перше, програмісти люблять свою роботу, по-друге, вони розуміють, що працюють для бізнесу і якщо якесь завдання потрібно зробити, то його все одно комусь доведеться взяти. Зазвичай хтось поводиться рішуче. У цьому випадку людина не відчуває, що їй нав’язали щось, і відчуває, що вона працює на благо команди. Мені подобається така «добровільна» схема, але ви можете спробувати іншу.
Поради тімлідам
-
ПОРАДА 1. ГОВОРИТЕ ПРАВДУ
Я пропрацював тімлідом більше 10 років і найважливіша порада, яку я дам тімлідам — не обманювати своїх програмістів. Так, буває так, що іноді вам немає сенсу щось говорити команді. Наприклад, замовник сказав PM (а PM передав вам), що він думає закрити проєкт, тому що команда якась ненадійна. Якщо ви скажете це своїм розробникам, то вони, швидше за все, працюватимуть ще гірше. Тому доносьте до команди лише найважливішу думку, мовляв, давайте подумаємо, як зробити те, що ми пообіцяли замовнику, інакше він буде незадоволений (хоча ви знаєте, що він уже незадоволений). Але в жодному разі не обманюйте. Якщо підлеглі запитують — відповідайте чесно. Наприклад, чи буде премія по ітогам проєкту, а вам уже сказали, що її не буде — не кажіть, що премія буде. Інакше ви геть-чисто вб’єте довіру своєї команди і ніколи більше її не відновите. Тому щось не говорити, притримувати інформацію — можна, але ні в якому разі не обманювати.
-
ПОРАДА 2. ВИЗНАВАЙТЕ СВОЇ ПОМИЛКИ
Це один із найпростіших способів завоювати повагу своєї команди. Найлегший в результаті, але найскладніший у виконанні. Програмісти вашої команди чудово розуміють, коли ви накосячили. І якщо ви намагаєтеся якось викрутитись чи звалити провину на когось іншого — до вас буде нульова повага. Краще скажіть прямо — я накосячив, я думав, що буде ось так, а вийшло ось так, перепрошую, зараз робимо наступне… Повага команди зросте дуже сильно.
У Project Manager зарплата нижча ніж у Team Lead
Наступна сходинка після Team Lead – Project Manager. Дуже часто від розробників чую, що йти в PM немає сенсу, адже у них менша зарплата, ніж у тімлідів. Але тут слід пам’ятати, що є велика різниця між PM з технічним бекграундом та PM без нього. PM без технічного бекграунду одержують нижчу зарплату, а PM з технічним бекграундом, яким ви і будете – це зовсім інша історія. Однак у різних компаніях вигадують різні назви посадам – delivery manager, technical PM та інші, аби якось відрізнити вас від інших PM та дати більше грошей. Зарплата проджект менеджера з технічним бекграундом буде більшою, ніж у тімліда. Не хвилюйтесь. Дорога керівника починається саме з цього я і веде вона аж до директора компанії.
Дорога Засновника
Велика кількість розробників має «вологі мрії» про створення власної класної великої компанії, бути там директором і гребти гроші лопатою. При цьому більшість із них не мають жодного розуміння, як працює бізнес.
Прибуток нижчий, ніж у програміста
Почнемо із головного. Дорога засновника дуже болісна з погляду грошей. Перші три роки ви дуже ймовірно не вийдете на свою зарплату розробника. Це за умови, якщо все у компанії йде добре. Усвідомте це — на свою зарплату програміста ви вийдете лише через +/- три роки. А може, й не вийдете взагалі, таке теж часто буває. Тобто, ви гарантовано 3 роки отримуватимете дохід менше, ніж звикли. Перші півроку доходу може бути зовсім. А іноді ви навіть можете піти у мінус. І це боляче. Тому, якщо ви не можете урізати свої витрати, то ви повинні відкласти собі подушку безпеки на термін 3 роки.
Тепер ви розумієте, чому не так багато компаній, заснованих розробниками. Дуже багато хто кидає такий бізнес і йде назад у найм, тому що своя компанія — це довго, складно і боляче по грошах.
Високий рівень стресу
Якщо ви ніколи не були засновником компанії, ви навіть приблизно не можете уявити, який рівень стресу на цій посаді. Засновник безперервно відповідає за свою компанію і постійно переживає за неї. Найманий співробітник працює собі та працює, отримує фіксовану зарплату. А ось засновник постійно несе витрати і на початку ці витрати можуть перевищувати доходи. Він постійно думає, де взяти гроші, щоб розплатитися з субпідрядниками тощо. Є таке поняття, як касовий розрив — дуже «приємна» для власника компанії штука. Це коли дохід менший, ніж вам потрібно заплатити (податки, зарплати та інші витрати).
Так, потім, якщо ваша компанія вистрілить, ми можете добре заробляти. Але це згодом. А на початку буде складно, стресово і не дуже добре по грошах. Тому вирішивши створити компанію, подумайте, наскільки вам справді хочеться цим займатися. Тому що без ентузіазму та великої любові до своєї справи ви не витримаєте.
Два способи стати підприємцем
-
СПОСІБ 1. ВЗЯТИ ІНВЕСТИЦІЇ.
Ви знаходите інвестора і потім за рахунок його грошей будуєте компанію. Але якщо у вас немає досвіду створення компанії, зі 100% ймовірністю ви ці гроші втратите. Без варіантів. Просто тому, що ви не розумієте, як працюють гроші в бізнесі. Поняття про гроші у найманого співробітника та у підприємця дуже різняться. Якщо у найманого співробітника — це двомірний об’єкт (ось зараз є стільки грошей), то у підприємця гроші — це багатомірна сутність (якісь гроші є, якісь прийдуть, якісь плануються, якісь у боргах, різних напрямках та ін.). Це зовсім інший рівень відносин із грошима. Розпоряджатися грошима складно навіть у маленькій компанії. Поки ви у всьому розберетеся, ви втратите всі гроші, які вам дали як інвестиції.
Однак, якщо у вас є досвід PM, можна стати співзасновником компанії. Тобто, у вас є партнер, який має гроші та досвід у побудові компаній, а у вас є досвід ведення проєктів. Так, вам доведеться доучуватись, але це не смертельно. Але тут потрібно дуже довіряти співзасновнику вашої компанії і це не завжди закінчується добре.
-
СПОСІБ 2. ПОЧИНАТИ З ФРІЛАНСУ
Знаходьте на фрілансі замовлення, в ідеалі таке, яке ви можете зробити самі або за допомогою однієї людини, та реалізуєте його. Перші замовлення завжди реалізовуються максимально якісно. Краще, якщо воно буде зроблено не на максимум, а вище, ніж максимум. Тому що наступне замовлення, найімовірніше, ви отримаєте по сарафанному радіо. Ваш дуже задоволений клієнт розповість про вас своїм друзям, які швидше за все займаються схожим бізнесом. Другий проєкт також робиться ідеально. Перший рік ви не маєте права завалити жоден проєкт. Можете йти в мінус, робити власними коштами, залазити в борги, але замовлення повинні бути зроблені ідеально, щоб ваші клієнти привели вам наступних клієнтів. Поки ви не знаєтеся на маркетингу та продажах, це буде єдиним способом залучення наступних клієнтів.
Якщо ви відчуваєте, що ви самі з проєктом не справляєтеся або у вас занадто багато проєктів, починайте винаймати людей. Можна взяти людей у співзасновники, але я украй не раджу це робити. По-перше, із співзасновником дуже складно розлучитися, тим часом як співробітника можна звільнити, із субпідрядником просто завершити співпрацю. А співзасновник – це практично як одружитися. Тому співзасновника вибирайте дуже ретельно. Я рекомендую спочатку попрацювати з людиною кілька років, а вже потім піднімати її до співзасновника.
Що потрібно знати засновнику компанії
Важливий аспект, який потрібно знати. Для того, щоб створити ІТ-компанію, вам потрібно 2 групи знань.
- РОБОТА З РИНКОМ. Сюди відносяться маркетинг та продажі. Розуміння того, як виходити на ринок, що там робити, як спілкуватися зі своїм потенційним покупцем/замовником тощо. Ці знання абсолютно необхідні.
- ВМІННЯ БУДУВАТИ ПРОЄКТ. Це не програмістські знання, а менеджерські.
Якщо ви просто програміст і ніколи не були PM – у вас немає першої, ні другої групи необхідних знань. Відповідно, ви не готові для того, щоб будувати компанію. Вам потрібно отримати або одну групу знань, або другу, в ідеалі обидві. Можна добре розбиратися в одній із цих груп, все інше закрити найманими співробітниками. Перехід безпосередньо від Експерта до Засновника компанії відбувається дуже болісно.
Тут ви могли б сказати, що є третій спосіб — ви благополучно самі робите проєкт, потім виходите на ринок і чекаєте, що там вас заберуть з руками та ногами. Це вже про інвестування.
Дорога Інвестора
На мою думку для програміста дорога Інвестора фактично не існує, але багато програмістів приходять до мене з ідеєю побудувати свій стартап. За великим рахунком, це і є дорога інвестора, а не дорога засновника.
У чому різниця між засновником та інвестором? Інвестор вкладає гроші у якийсь бізнес, з розрахунку, що цей бізнес принесе йому гроші. Інвестор може спостерігати за бізнесом, може керувати ним, але основна особливість у тому, що інвестор вкладає свої гроші. Засновник будує компанію, у тому числі за чужі гроші. Якщо ви хочете інвестувати свої гроші та/або свій час у власну компанію, то, фактично, ви є інвестором. Це дуже ризиковано. Набагато більш ризиковано, ніж дорога засновника. Якщо ви ніколи не займалися інвестиціями, майже 100% ймовірність, що ви втратите свій час і гроші. Ви повинні розуміти, що таке бізнес-план, як будується бізнес, скільки він може принести вам грошей і коли, скільки ви вклали сил, скільки це коштувало (у перерахунку час на гроші) та багато інших нюансів. Дуже важливо зрозуміти, що безкоштовного часу взагалі не буває. Ви його забираєте у своєї роботи, сім’ї та інших важливих справ, якими могли б займатися. Але вкласти лише час недостатньо, вам у будь-якому випадку знадобиться вкласти ще й гроші.
Крім усього іншого, подумайте ось про що. Якщо у вас немає експертизи у маркетингу, чому ви взагалі вважаєте, що ваш проєкт комусь потрібен? Як ви це зрозуміли? Ви зробили маркетингове дослідження? Самі? Це дуже складна штука і в мене для вас погана новина – швидше за все ви зробили його погано.
Зараз можна сказати, що хтось там зробив свій проєкт і він вистрілив. Так, таке буває, але ж ви розумієте, що це помилка того, хто вижив? А скільки людей прогоріло цим шляхом? Ви маєте шанс, але він мінімальний. У більшості випадків ви просто спускаєте в унітаз свій час та свої гроші.
Вибирайте простіші, адекватніші шляхи, які з більшою ймовірністю приведуть вас до бажаного результату: беріть замовлення, виконуйте його, отримуйте гроші та навчайтесь на цьому як будувати фірму. Ось коли ваша розробна фірма вже запрацювала, ви можете будувати стартап усередині своєї компанії. У вас вже будуть програмісти, ви навчетесь організовувати та матимете дохід, який ви можете інвестувати у цей стартап. Саме так і створюються успішні стартапи.
Інвестування у нерухомість
Ще одна «волога мрія» розробників — купити нерухомість, здавати її та отримувати пасивний дохід. Пасивний дохід взагалі у топі бажань програмістів. Лише одне Але. Нерухомість – це не пасивний дохід. Ви повинні розуміти та розбиратися в нерухомості. Ви повинні розумітися на ремонтах, в HoReCa (якщо здаєте квартири подобово). Тобто, це бізнес, на якому треба розумітися. Так, може це і не full time, але все ж таки туди потрібно вкладати час і досить багато. Ви можете заперечити, мовляв, досить просто найняти когось, хто стежитиме за житлом і здаватиме його (або надаватиме інші послуги). Навіть у цьому випадку це вимагатиме вашого часу та уваги+ще потрібно платити зарплату цій людині. Здавати квартири в оренду, або купувати і продавати квартири – це окремі типи бізнесу і потрібно займатися ними.
Порахуйте, скільки часу ви витрачатимете на це, перерахуйте його в гроші і подумайте, чи можливо вигідніше просто покласти гроші в банк і отримувати відсотки?
Дорогу інвестора я категорично не раджу, доки ви детально не розібралися, як це працює. Залишається три найпопулярніші дороги: Експерт, Керівник та Засновник.
Завжди ваш Сергій Немчинський.
