16.12.2022

Сергей Немчинский: Пути развития программиста: эксперт, руководитель, основатель

Сергей Немчинский
60 минут просмотра
<strong>Сергей Немчинский: Пути развития программиста: эксперт, руководитель, основатель</strong>

Есть разные пути развития программиста, я испытал их все на себе, поэтому все что будет написано ниже взято с реального опыта. Я был экспертом — доходил до уровня архитектор. Был руководителем — доходил до уровня проджект менеджера. И сейчас я иду по третьему из возможных путей — сейчас я основатель собственной компании. Я часто провожу карьерные консультации и вижу, что у многих нет четкого понимания, куда же можно развиваться программистам, когда они уже достигли высокого уровня синьорности..

 

Три дороги для программиста

 

Есть очень много дорог, по которым может пойти человек в своем профессиональном развитии. Это относится к любой сфере, но я буду говорить конкретно о программистах и только о трех самых простых и понятных путях, логически вытекающих из деятельности разработчика. Понятно, что можно кардинально изменить специальность и стать чиновником, но это совсем не очевидный путь. Три самые очевидные дороги: дорога эксперта, дорога руководителя и дорога основателя.

 

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

 

К чему приводит каждая из дорог

 

ЭКСПЕРТ. Этот путь заканчивается международно-признанным экспертом в какой-то области. Такой специалист читает лекции, приезжает в качестве эксперта-консультанта в другие компании, легко решает сложные архитектурные вопросы и пр. Например, Роберт Мартин — он дошел до пика по дороге Эксперта.

 

РУКОВОДИТЕЛЬ. Этот путь заканчивается исполнительным директором крупной международной компании. Да, это все еще наемная должность, но при этом вы руководите огромной корпорацией.

 

ОСНОВАТЕЛЬ. Этот путь ведет к созданию собственной крутой компании и заканчивается где-то в списке Forbes и миллионами на счетах 🙂

 

С чего начинать?

 

Всегда все начинается с дороги Эксперта. Вы приходите на свою первую работу и потихоньку начинаете качать свою экспертность. Конечно, бывают и другие ситуации, когда на первую работу вы как-то попали в качестве руководителя. Но это исключение, обычно все же начинают с дороги эксперта. В какой-то момент вы можете задуматься, что хотите быть руководителем или основать собственную компанию и тогда вы смените дорогу Эксперта на какую-то другую. Поговорим о каждой из них детальнее.

 

Что принесет больше денег?

 

Тут нет конкретного ответа. Очень часто встречается ситуация, когда наемный программист зарабатывает больше, чем основатель собственной компании. Компания может быть маленькой и не развиваться, а хороший программист получает очень даже высокую зарплату. Кроме того, если вы владелец компании, это не значит, что вы вообще хоть что-то заработаете. Может вы вообще уйдете в минус и придется докладывать свои деньги, чтобы компания выжила.

 

Зарабатывают ли руководители больше, чем эксперты? Тоже нет. Руководители низкого звена могут зарабатывать меньше, чем их подчиненные. В ИТ это тоже типичная ситуация, где программисты часто зарабатывают больше, чем их проджект менеджеры. Но это не значит, что дорога эксперта самая денежная. Руководитель высокого звена зарабатывает очень хорошо. Т.е. все зависит от того, какую позицию вы занимаете на своем пути. Но скажем так, на дороге эксперта заработать очень много денег сложнее, чем на дороге руководителя и основателя.

 

Но вы должны понимать, что дорога выбирается не из-за денег, а из призвания, из вашего желания этим заниматься.

 

Дорога Эксперта

 

Дорога состоит из довольно простых шагов: джуниор —> мидл —> синьор девелопер. А вот что дальше? В этом месте большинство синьорных программистов зависает. Один из вариантов — вы просто можете остаться на этой позиции и спокойно продолжить работать, если вас это устраивает. Это вариант для тех, кто помимо работы имеет насыщенную жизнь и кучу хобби, а работа просто для зарабатывания денег. Вы спокойно можете оставаться на позиции синьора до самой пенсии — это нормально, главное, чтобы вас все устраивало. Не нужно гоняться за чужими мечтами, становиться руководителем или открывать свой бизнес, если вам это чуждо.

 

Если же вы хотите развиваться и развиваться именно в экспертной области, то следующий шаг — техлид. Техлид — это самый главный, ведущий разработчик в команде. Он принимает самые важные технические решения (например, какой фреймворк использовать), устанавливает технические правила проекта (в т.ч. требования по чистоте кода), делает код ревью и т.д. Техлид отвечает за техническое состояние команды. Однако во многих компаниях должности техлида вообще не существует, а его обязанности заставляют выполнять тимлида. Хотя изначально в обязанности тимлида входит распределять задачи и нагрузку между членами команды.

 

Следующий шаг по дороге Эксперта — архитектор. Но и тут все не так просто. В каждой компании должность архитектора может сильно отличаться по обязанностям. Вы не можете будучи архитектором в одной компании, перейти архитектором в другую компанию. В большинстве случаев так не работает. В каждой компаний очень сильно отличаются требования и ожидания от архитектора. В некоторых компаниях есть не один, а множество всяких архитекторов — soft архитектор, solution архитектор и пр. Поэтому когда у меня спрашивают, как стать архитектором, я отвечаю, что стать архитектором в общем нельзя, можно стать архитектором только в какой-то конкретной компании. 

 

Какие скиллы нужно прокачивать, чтобы развиваться как Эксперт

 

  • НАДЕЖНОСТЬ

Умение правильно ставить эстимейты и соблюдать их. Об этом я говорил уже много-много раз.

 

  • ПОНИМАНИЕ BUSINESS VALUE

Понимание, чего хочет бизнес. Для техлида — это очень важно, ибо на вас будут ориентироваться другие разработчики команды. Если техлид хочет расти до архитектора, то ему нужно понимать, как технически решать проблемы бизнеса. Остальные сотрудники реализуют решение, но именно техлид или архитектор придумывает, какое решение будет использовано.

 

  • ПУБЛИЧНЫЕ ВЫСТУПЛЕНИЯ

Будучи техлидом, вы обязаны доносить до команды свои технические решения, изменения политики по код ревью, по инженерным практикам и другим моментам. И вы должны уметь обосновать все эти изменения. Вы не должны управлять командой, вы должны их вести как наиболее сильный разработчик в команде. Тоже самое, но в гораздо большей степени вам понадобится, когда вы перейдете на позицию архитектора. Потому что архитектор объясняет что-то уже не команде, а заказчику. Поэтому я очень советую, как только вы достигли уровня техлида, начинайте активно качать свой навык публичных выступлений. Выступайте на конференциях, устраивайте нетворкинг, потому что архитекторов как правило берут по знакомству.

  • ЗНАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

Архитектор должен идеально понимать предметную область, знать, как ее автоматизировать, какие у нее проблемы и как они решаются при помощи технических средств. Такой человек может ходить вместе с sales на встречи с клиентами, объяснять техническую часть и как решаются проблемы клиента. Идеальный архитектор — тот который разбирается в архитектуре с привязкой к предметной области.

  • ЗНАНИЯ АРХИТЕКТУРЫ

Это специалисты, которые могут читать лекции по поводу того, как правильно строить микросервисы, как выполнять инжиниринговые практики, как строить деливери, как все это будет работать и пр.

 

Хорошо, если архитектор знает отлично и предметную область, и архитектуру. Однако все равно на чем-то нужно специализироваться. Поэтому специалист может больше уходить в одну или другую из этих областей. Куда делать упор? Я бы посоветовал на знание предметной области, но это вопрос неоднозначный, так как знать хорошо архитектуру архитектор тоже обязан.

 

Есть отдельная категория экспертов — человек, который досконально знает какой-то фреймворк. Это тоже очень ценный эксперт, которого любят звать в разные компании. Таких экспертов тоже часто называют архитекторами, но это все же немного из другой области. Однако эту экспертность сложно продавать заказчикам, поэтому довольно низкий потолок зарплат, в отличие от архитекторов, которые хорошо разбираются в предметной области.

 

Вы должны понимать, что если вы идете по дороге Эксперта и думаете, что это чисто про технологии — нет, рано или поздно все равно придется погружаться в какую-то предметную область.

 

Дорога Руководителя

 

Сперва важно прояснить один момент, который я часто встречаю в различных программистских сообществах — мол, зачем нами руководить, мы сами все сделаем. Что ж, на это могу сказать только одно — так не работает. Все, точка. Будем честны — даже если вы соберете команду из очень крутых экспертных ребят, они ничего путного вместе не сделают, если ими не руководить. Если они все же что-то сделали, это значит только одно — кто-то из них взял на себя обязанности лидера. Профессия руководителя возникла одна из самых первых в этом мире. Всегда были какие-то вожди, те, кто руководил армией и пр. Если другим не говорить, что делать, каждый будет делать что ему придет в голову и уйдет бесконечное количество времени на обсуждение что же все-таки делать. Всегда должен быть один ответственный человек. Поэтому программистами руководить нужно. Из моего личного опыта — если у проекта хороший проджект менеджер и плохие программисты, проект с большой вероятностью будет жить и все с ним будет хорошо. В команде с очень хорошими программистами, но с плохим проджект менеджером, проект, скорее всего, провалится.

 

Как решить, что ты хочешь быть руководителем?

 

У каждого по-разному приходит понимание, что он хочет быть руководителем. У меня такое ощущение пришло, когда я увидел, как сильно косячит мой руководитель. Я смотрел, как он управляет нашим проектом, понимал, что он ведет проект к провалу, у меня чесались руки влезть в руководство и все исправить, я с ним ругался, показывал очевидные вещи, но меня особо не слушали, и в конечном итоге проект провалился. После этого я понял, что хочу руководить сам, не хочу, чтобы наши проекты так бездарно проваливались. Если вы сами хотите быть ответственными за успех проекта, подумайте о том, чтобы двигаться по дороге руководителя. На самом деле такое решение принимается практически автоматически.

 

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

 

Важно понимать аспекты руководства. В нашей культуре подразумевается, что вы руководите кем-то, какими-то сотрудниками. Тут фокус на процессе — руководство людьми. В американской культуре скорее понимается, что вы ответственны за что-то (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 группы знаний.

 

  1. РАБОТА С РЫНКОМ. Сюда относятся маркетинг и продажи. Понимание того, как выходить на рынок, что там делать, как общаться со своим потенциальным покупателем/заказчиком и так далее. Эти знания абсолютно необходимы.

 

  1. УМЕНИЕ СТРОИТЬ ПРОЕКТ. Это не программистские знания, а менеджерские.

Если вы просто программист и никогда не были PM — у вас нет ни первой, ни второй группы необходимых знаний. Соответственно, вы не готовы для того чтобы строить компанию. Вам нужно получить или одну группу знаний, или вторую, в идеале — обе. Можно хорошо разбираться в одной из этих групп, все остальное закрыть наемными сотрудниками. Переход напрямую от Эксперта к Основателю компании происходит очень болезненно.

 

Тут вы бы могли сказать, что есть третий способ — вы благополучно сами делаете проект, потом выходите на рынок и ждете, что там вас заберут с руками и ногами. Это уже про инвестирование.

 

Дорога Инвестора

 

С моей точки зрения для программиста дорога Инвестора фактически не существует, но многие программисты приходят ко мне с идеей построить свой стартап. По большому счету это и есть дорога инвестора, а не дорога основателя.

 

В чем разница между основателем и инвестором? Инвестор вкладывает деньги в какой-то бизнес, в расчете, что этот бизнес принесет ему деньги. Инвестор может наблюдать за бизнесом, может руководить им, но основная особенность в том, что инвестор вкладывает свои деньги. Основатель же строит компанию, в том числе за чужие деньги. Если вы хотите инвестировать своими деньгами и/или своим временем в собственную компанию, то, фактически, вы являетесь инвестором. Это очень-очень рискованно. Гораздо более рискованно чем дорога основателя. Если вы никогда не занимались инвестициями, почти 100% вероятность что вы потеряете свои время и деньги. Вы должны понимать, что такое бизнес-план, как строится бизнес, сколько он может принести вам денег и когда, сколько вы вложили сил, сколько это стоило (в пересчете время на деньги) и много других нюансов. Очень важно понять, что бесплатного времени не бывает вообще. Вы его забираете у своей работы, семьи, других важных дел, которыми могли бы заниматься. Но вложить только время недостаточно, вам в любом случае понадобится вложить еще и деньги.

 

Кроме всего прочего, задумайтесь вот о чем. Если у вас нет экспертизы в маркетинге, почему вы вообще считаете, что ваш проект кому-то нужен? Как вы это поняли? Вы сделали маркетинговое исследование? Сами? Это очень сложная штука и у меня для вас плохая новость — скорее всего вы сделали его плохо.

 

Сейчас можно сказать, что вот такой-то сделал свой проект и он выстрелил. Да, такое бывает, но вы ведь понимаете, что это ошибка выжившего? А сколько людей прогорело на этом пути? У вас есть шанс, но он минимален. В большинстве случаев вы просто спускаете в унитаз свое время и свои деньги.

 

Выбирайте более простые, адекватные пути, которые с большей вероятностью приведут вас к желаемому результату: берете заказ, выполняете его, получаете деньги и учитесь на этом как строить фирму. Вот когда ваша разработческая фирма уже заработала, вы можете строить стартап внутри своей компании. У вас уже будут программисты, вы умеете организовывать и у вас есть доход, который вы можете инвестировать в этот стартап. Именно так и создаются успешные стартапы.

 

Инвестирование в недвижимость

 

Еще одна «влажная мечта» разработчиков — купить недвижимость, сдавать ее и получать пассивный доход. Пассивный доход вообще в топе желаний программистов. Только одно Но. Недвижимость — это не пассивный доход. Вы должны понимать и разбираться в недвижимости. Вы должны понимать и разбираться в ремонтах, в HoReCa (если сдаете квартиры посуточно). Т.е. это бизнес, в котором нужно разбираться. Да, может это не требует full time, но все же туда нужно вкладывать время и довольно много. Вы можете возразить, мол достаточно просто нанять кого-то, кто будет следить за жильем и сдавать его (или какие-то другие услуги). Даже в этом случае это будет требовать вашего времени и внимания+еще платить зарплату этому человеку. Сдавать квартиры в аренду, или покупать и продавать квартиры — это отдельные типы бизнеса и ими нужно заниматься. 

 

Посчитайте, сколько времени вы будете тратить на это, пересчитайте его в деньги и подумайте, возможно выгоднее просто положить деньги в банк и получать проценты?

 

Дорогу инвестора я категорически не советую, пока вы детально не разобрались, как это работает. Остается три самые популярные дороги: Эксперт, Руководитель и Основатель.

 

Всегда ваш Сергей Немчинский.