Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 102
Я уже проходил этот этап. Тут есть один тонкий момент. Навыки и опыт успешного предпринимателя строго перпендикулярны навыкам и опыту хорошего разработчика. Поэтому ваш технический скилл вам в этом начинании ничем не поможет. Скорее будет мешать, создавая иллюзию компетентности.
Согласен. Поэтому при первых попытках разработчики допускают довольно банальные ошибки — берут топовые технологии, закладывают архитектуру под миллион пользователей, делают идеальный продукт с точки зрения кода. А кто-то годами сидит что-то пилит и никому не показывает. При этом избегают самого главного — валидации потребности, общения с потенциальными пользователями и конечно продаж.
Но все равно с чего-то нужно начинать, и большинство учится на таких ошибках, и такой этап вероятно даже нужно пройти всем
Поэтому при первых попытках разработчики допускают довольно банальные ошибки — берут топовые технологии, закладывают архитектуру под миллион пользователей, делают идеальный продукт с точки зрения кода.
Вы видимо не про тимлидов, тимлиды обычно разрабов ровно за это ругают
и тут вдруг приходит озарение, что продакты и проджекты не такие уж плохие идеи предлагали)
Навыки и опыт успешного предпринимателя строго перпендикулярны навыкам и опыту хорошего разработчика
А список этой пресловутой «перпендикулярщины» не затруднит привести?
Так ровно тот же, что в статье:
Вместо кода вы отвечаете за атмосферу, процессы, сроки и удовлетворённость людей. Соответственно, для этого нужны совсем другие компетенции, к которым новички часто не готовы.
Только в разделе про тимлидов это про начальство и разработчиков, а у предпринимателя - про клиентов. Ну и еще добавляется умение продавать, а не просто нравиться. Вон на соседней вкладке про ТеилВинд - нас любят, но не платят.
Я всё ещё жду список ✌️строго-перпендикулярных✌️ навыков и опыта… Более того — там по тексту одни должны как-то мешать другим «создавая иллюзию компетентности» — что уже даёт понять, что тут использование термина «перпендикулярных» концептуально неверно — перпендикулярные не мешают по определению. Перпендикулярность это независимость. Если кому-то мешают независимые скиллы, ну, как говорится, может дело в чём-то другом вообще? Мешать могут коррелирующие или конфликтующие навыки, но не ортогональные.
Неужели это настолько неочевидно? Вспомнить хотя бы почему все mvp по качеству кода полная шляпа. У разрабов одна болезнь - технический перфекционизм, пока они строят абстракции и пишут эффективный код, время уходит, а кривущий кусок гавнакода уже проверяет бизнес идею на проде. Это что касается мешает. При этом так же не понятно как навык настройки кубернетиса может помочь в привлечении клиентов на продукт и построении воронки
А что тут должно быть очевидно, кроме того, что это — какой-то суповой набор из клише, а не реальных вдумчивых доводов? Как, например, «болезнь разрабов — перфекционизм». В жизни немало разрабов делают откровенный х-к-х-к-в-продакшн™ — мемас про это дело оформлен, но не оказывается, «Перфекционизм — болезнь разрабов», лол. Перфекционизм это отдельно стоящее личное качество, встречающееся у части разработчиков, отнюдь не у всех.
как навык настройки кубернетиса может помочь в привлечении клиентов на продукт и построении воронки
Я так полагаю, что если попросить пояснить как этот навык помешает, то аргументы придётся вытаскивать тоже из какой-нибудь воронки. Выковыривать даже, точнее сказать. :)
Так что мешает отнюдь не опыт, а ошибки мышления — ваш комментарий это ярко иллюстрирует. ;)
P. S. И я бы понял, речь изначально была бы о неких свойствах личности — вот тут да, другое дело, наверняка будет что-то, что действительно конфликтует у этих двух ипостасей. Но сказано-то было «навыки и опыт» — и не «конфликтуют», а «строго перпендикулярны» — то есть ровно обратное — «нулевая взаимная проекция», друг-другу не мешают.
Ты просишь реально вдумчивых доводов, упрекнул меня в том что я тебе выдал суповой набор клише, а сам аргументируешь свое мнение мемасами? Серьёзно? Я не вижу смысла дальше вести диалог.
Мем тут был не аргументом, а иллюстрацией — как раз к тому, что ты называешь очевидным, но что в реальности уже давно высмеяно даже самими разработчиками. А вот поскольку аргумента против логической каши изначального тезиса так и не прозвучало, то смысла не то что дальше, но и ближе раньше тоже не было.
Может в этом, конечно, внезапно виноват «навык настройки кубера», но чё-т сомнительно мне как-то. ;)
Я не вижу смысла дальше вести диалог.
Вы приняли правильное решение. Вашему собеседнику диалог не нужен. Ему нужен конфликт. Он свой внутренний страх и тревогу пытается выплеснуть через агрессию. Помочь ему вы ничем не сможете. Можно только посочувствовать.
У разрабов одна болезнь - технический перфекционизм
Потому что разработчики и архитекторы единственные, кто мыслит как поддерживать продукт через 5 лет: им же самим с говнокодом жить потом. У менеджеров горизонт планирования до годовой премии максимум, чаще до квартальной.
Product owner ещё может мыслить на большой горизонт, но ему все мешают.
через 5 лет может и проекта этого уже не будет, и состав команды сменится не один раз, а может быть вообще сменится вектор роста проекта и вся ваша дорогая архитектура улетит в трубу. И останутся только довольные разработчики с чистой совестью и инвестор с дыркой от бублика вместо бюджета. но зато в гите будет дорогой и идеально спроектированный код
Перпендикулярные скиллы не мешают, а обычно отсутствуют. Так как человек развивается обычно хорошо в одной области и ее окрестностях. На примере института - ребята, хорошо понимавшие дискретку, численные методы и программирование плыли в функциональном анализе и наоборот. А это вроде почти одно направление - математика.
Запоминание кучи несвязных (не выводящихся из аксиом по цепочке утверждений) фактов у них шло еще хуже, а юристы и биологи это умеют хорошо, но они хуже строят алгоритмы.
Чувствовать людей это опять же ортогональное направление. У меня перед глазами пример как джун программист вместо мидла отпрыгнул в сторону и сейчас рулит международными проектами как продакт (пред глазами - так как департамент он не поменял).
Перфекционизм разрабов, а так же херак херак - это проявления одного и того же. Так как перфекционизм он тоже внутри кода а не снаружи пользовательского опыта. Это человек решает техническую задачу и в рамках своих компетенций или считает, что решение обладает недостаточно чистой архитектурой, или считает, что он знает как бежит внутри поток данных, и тесты не обязательны, он все продумал.
А как там будет пользователю в голову не приходит в обоих случаях.
Да, полностью с Вами согласен. Так и есть. Просто все люди разные. У всех свои таланты и свои слабости.
Если у вас нет навыка «издать ноту ля», но есть — её услышать — это значит, что они перпендикулярны? Или нет? :) Я изначально просил список этой самой «строгой перпендикулярщины», но «программист на платформе Java», вместо того, чтобы тезисно подкрепить мысль начал бегать по веткам оппонентов, напялив уже то ли белое пальто, то ли белый халат, чтобы про мой «внутренний страх и тревогу» вещать — позабыв, как водится, не то что про список, но даже и про собственную перпендо-теорию :)
юристы и биологи это умеют хорошо, но они хуже строят алгоритмы.
Да, когнитивные стили разные. Как отсюда вывести, что понимание алгоритмов мешает продажам? Никак.
А как там будет пользователю в голову не приходит в обоих случаях.
Типа, не бывает программистов, которые делают качественное ПО, где «как там будет пользователю» в голову приходит?
В общем, я смотрю тут веселая веточка выросла, ахха, «своя атмосфера». :)
Поскольку сказано о строго ортогональных векторах, то сами по себе ортогональные навыки друг другу не мешают. Мешать друг другу могут например параллельные векторы, направленные в противоположные стороны.
Но при этом не стоит забывать про фактор ограниченности времени. Если я потратил время на изучение менеджерских технологий (всякие матрицы рисков, аджайлы и план-графики работ), то это автоматически уменьшило мой временной ресурс на изучение новых трендов у моего любимого фреймворка или ЯП. Т.е. по сути помешало мне оставаться специалистом, разбирающимся в современных технологиях.
Ну если честно, то любая альтернатива роста из статьи, так же отходит от технических скилов в сторону. Желание стать тимлидом, наставником, блогером - так же требует наличие других навыков. Так что, при прочих равных, развивать свой продукт, кажется, не самым плохим вариантом!
Да, согласен. Когда упираешься в стеклянный потолок, то любой шаг "выше" или в "сторону" приводит к тому, что приходится выходить из уютной ниши технаря в совершенно другой мир. И если уж выбирать между карьерным ростом и собственным бизнесом, то собственный бизнес выглядит привлекательнее. Но в него и вкладываться нужно больше, чем в карьерный рост. И рисков там больше.
Лично я попробовал все варианты - и карьеру и бизнес. Чисто карьерный рост мне сильно не понравился а запустить бизнес у меня не получилось. Поэтому вернулся в нишу пресловутого Staff Engineer.
Но это не значит, что не нужно даже пытаться вырваться из стеклянного пузыря. У меня не получилось - у кого то другого получится. От всей души желаю ему удачи.
Если не тимлидстве работы становится на 50% больше, а зп только на 20%, то получается, вас успешно налюбили
Под дополнительными 50% работы я имею в виду в том числе дополнительную когнитивную нагрузку. Когда ты разработчик, ты закрыл задачи и пошёл заниматься своими делами. А у тимлида много разношерстной ответственности — за людей, за проекты, в итоге ты думаешь об этом и перед сном, и сразу после пробуждения
Не нужно сказок, тимлид существует только для того чтобы доделывать работу за мидлов и синьор разработчиков, которые ведут себя как дети, причем ведут так они себя всегда. Поэтому у Лида ответственности - х1000, а работы - хРазработчиков в команде. Один за всех как говорится, не работа, а цирк
тимлид существует только для того чтобы доделывать работу за мидлов и синьор разработчиков
очень плохой тимлид значит, не сумел заставить доработать до конца, не настоял на замене "детей", и так далее
>на замене "детей"
и какова же процедура смены ленивого-долбоёба-который-делает-ровно-минимум по ТК РФ?
Легко. Просишь заменить на проекте или уйти по собственному. 99% не изображают из себя жертвы репрессий и уходят.
Наблюдал за историей коллеги, которая и перформила не очень, и конфликтовала - под неё четыре месяца копали CTO и HR, но в итоге договорились на увольнение с тремя окладами.
Не противоречит высказыванию @Arm79 - он же не сказал, что 100% уходят без борьбы)
Дополню @Newbilius, три оклада это разумная компенсация за увольнение человека с работы по желанию работодателя.
Если компания хочет неудобного человека сократить другими способами, то вопросы к компании. Либо не увидели проблему на этапе найма/испытательного срока, либо компания излишне жадная, либо какая-то личная неприязнь в коллективе
>99% не изображают
хахаха
>А что значит вот это "делает-ровно-минимум по ТК РФ" ?
приходит на работу вовремя. закрывает тикеты со скоростью черепахи. почитывает в "свободное время" ТК РФ. ну давай, удачи уволить такого по СЖ
Вообще не вижу проблем. На планировании давать самые сложные задачи, установить на компьютер трекер активности со скринами, каждую невыполненную задачу фиксировать со служебной запиской, при оценке стабильно выставлять низкую. Варианты воздействия есть всегда.
Но это, согласитесь, идиотизм. И так вести себя - просто противно. Проще договориться и дать время на поиск работы (месяц, два), или выплатить компенсацию и по соглашению сторон.
В конце концов, рынок ИТ не такой большой, при устройстве на работу все равно пробивают человека (по крайней мере в крупных компаниях). Полюбовно расстаться, если не сработались, в интересах всех участников
приходит на работу вовремя.
У-у-у, гад какой.
А вообще как нанимать на должностную инструкцию "разработчик должен разрабатывать" так легко, а как потом метрики нормальные мерять, так начинается скорость черепахи. Надо скорость кролика, пишите метрики про кролика. Не удивляйтесь правда потом что будут делать что меряете.
Если бизнесс так устроен что важно чтобы тикеты закрывались на сверхзвуке, но это должно быть специфицировано, а когда специфицированно, то можно уже обвесить вознаграждениями и штрафами, глядишь никого и увольнять не придется. А вот если специфицировать не получается, то это уже не разработчика проблемы, возможно кого-то другого надо в конторе увольнять.
А что значит вот это "делает-ровно-минимум по ТК РФ" ?
То, что не лезет вон из кожи с постоянными бессмысленными переработками или что?
Малопродуктивный разработчик не равно глупый человек. Чтобы обосновать необходимость замены нужно предъявить его реальные косяки, но сотрудник будет избегать их совершения
Да ладно) По моим ощущениям, в тимлиды идут (либо их продвигают) те, кто к написанию кода не сильно предрасположен в принципе. Уж точно не тимлиду доделывать за мидлами и уж тем более сеньорами их программерскую работу. Это ещё вопрос, кто за кем что доделывать должен. Техлиду (если это не вторая, совмещённая роль тимлида) - ещё куда ни шло. Вот когда от тимлида раз в сто лет прилетает PR, сразу понятно, что лучше бы он код вообще без лишней надобности не трогал.
Не нужно сказок, тимлид существует только для того чтобы доделывать работу за мидлов и синьор разработчиков,
Это не так, тимлид как раз таки должен сделать так, чтобы эти мидлы и сеньоры доделывали сами свою работу, обеспечив им для этого всё необходимое, если нужно, то выбив стенд для разработки/тестирования, договорившись с соседним отделом и т. д.
Интересная статья. Я не IT специалист, но проблемы схожие. После повышения во всей красе ощутил все прелести пребывания между молотом и наковальней по сути за небольшую прибавку, ясно увидел потолок, понял, что трачу остатки здоровых лет на гонку за деньгами, которые мне даже некогда тратить.... Бросил все подработки, остался на той работе где платят потолок и жизнь снова наполнилась красками.
Тимлидом хорошо быть, т.к. вы можете выстроить свое время так, чтобы было время заниматься разработкой, но при этом брать на себя действительно сложные и интересные задачи, а все остальное скидывать на разрабов. И для кого-то это наоборот интереснее чем быть просто разработчиком, более разнообразные задания, вы и код интересный пишите и решаете проблемы команды.
Про тимлида тимлидов довольно странное у вас отношение, вы говорите что ими становятся только долго проработав на одном месте, т.е. вы не готовы к этому, но при этом развивать свой продукт годами и по-сути в начале в нем становится тимлидом тимлидов вас не пугает и при этом таких навыков для своего продукта нет, но они нужны будут
вы можете выстроить свое время так, чтобы было время заниматься разработкой, но при этом брать на себя действительно сложные и интересные задачи, а все остальное скидывать на разрабов.
Это возможно только в двух случаях:
Вы недонагружены как тимлид из-за неправильных процессов в компании, так как в идеале одного из нескольких тимлидов надо понизить, а его обязанностями донагрузить остальных.
Вы пытаетесь усидеть между двух стульев делая свою работу абы как.
В любом случае вы - кошмар для вашей команды. Я работал с такими и врагу не пожелаю:
Хватаются за сложную / интересную / важную задачу, из-за недостатка времени и деградировавшего опыта делают абы как не учитывая все требования и крайние случаи, а потом этот шлак приходится чинить. Иногда ночью в выходные.
Пытаются тянуть какой-то проект или прототип с нужной / полезной технологией, но из-за невозможности сконцентрироваться растягивают это на месяцы, пока остальная команда чертыхаясь штопает легаси.
Загребают себе важный проект в надежде на плюшки, пролюблювают отпущенные сроки, в потом скидывают это на кого-то, чтобы он отгреб за недоделанный продукт.
Забивают на встречи или передачу информации, в результате опять же недопонимание со смежными командами, срыв сроков или технических соглашений касательно требований,API, спецификаций и т.д.
Скидывают часть тимлидской работы (совещания, отчёты) на сотрудников, а потом выставляют претензии: ты на том совещания не то сказал или почему ты просидев под дня на совещаниях мало кода написал.
Хватаются за сложную / интересную / важную задачу, из-за недостатка времени и деградировавшего опыта делают абы как не учитывая все требования и крайние случаи, а потом этот шлак приходится чинить. Иногда ночью в выходные.
Вы действительно думаете, что тимлид с постоянным опытом в разработчик с 15+ лет, не учитывает требования и крайние случаи и ещё при этом делает откровенный шлак? Интересно зачем такого человека повышать с разраба до тимлида
Загребают себе важный проект в надежде на плюшки
Мне жаль что вам в профессии не попались люди которым нравится их работа не за плюшки, а просто потому что это интересно
Вы действительно думаете, что тимлид с постоянным опытом в разработчик с 15+ лет, не учитывает требования и крайние случаи и ещё при этом делает откровенный шлак?
Я не думаю, я видел, причем неоднократно.
Интересно зачем такого человека повышать с разраба до тимлида
Потому что из кожи вон лезет, чтобы попасть на такую позицию, говорит только то, что совпадает с мнением начальства, не может сказать "нет" откровенно лишней или ненужной работе, раздает обещания без оглядки на реальные возможности, все проблемы и ответственность за провалы заранее перекладывает на других.
Видимо мне повезло и мне не попадаются люди которые не на своем месте.
говорит только то, что совпадает с мнением начальства, не может сказать "нет"
Зачем вообще такого звать на совещание, если и так понятно что он скажет
раздает обещания без оглядки на реальные возможности, все проблемы и ответственность за провалы заранее перекладывает на других.
Тут вопрос к тем кто принимает решение кого делать тимлидом. Как вообще человек который не может брать на себя ответственность, дошел до руководящей должности, с него же первого должны спросить почему не смогли сделать обещанного и ответ что он молодец, а команда косячная, мягко говоря должен насторожить
Вот этот случай
Загребают себе важный проект в надежде на плюшки, пролюблювают отпущенные сроки, в потом скидывают это на кого-то, чтобы он отгреб за недоделанный продукт.
Был случай, тимлид взял задачу, легаси код, несколько месяцев делал ее, а итоге не справился и решил скинуть за 2 недели до дэдлайна, мне, получил закономерный отказ, задача явно не на две недели с учетом кучи легаси. Обозлился и после этого пытался всячески поднасрать по работе
Про тимлида тимлидов довольно странное у вас отношение, вы говорите что ими становятся только долго проработав на одном месте, т.е. вы не готовы к этому, но при этом развивать свой продукт годами и по-сути в начале в нем становится тимлидом тимлидов вас не пугает
Вообще абсолютно разные компетенции. Тимлид / тимлид тимлидов - это проджект-менеджер. Он не отвечает за продукт. Он отвечает за людей. При разработке своего продукта у вас людей практически нет на начальном этапе. Вам нужны навыки продакт-менеджера, сейлза, маркетолога, ну и разработчика чтоб MVP запилить.
Свой продукт - это здорово. Но, это - путь "не только лишь для всех, мало кто может":
Понять, что именно требуется и кто именно будет покупать. И по какой цене.
Понять как это оформить так, чтоб потом не было проблем с законом
Чётко выстроить работу техподдержки (учитывая, что этот проект - не основная работа). Люди покупают не просто продукт, а и поддержку тоже (её возможность, если что-то не работает)
Странно, что не рассмотрен вариант повышения з\п - смена работодателя: либо текущий захочет повысить, чтоб ты не ушёл (но, это - редкость). Либо находишь место, где больше платят. Заодно и смена специфики - есть возможность набрать новых компетенций на новом месте. Упёрся в потолок - не беда: снова ищешь другого работодателя. Не подходит только для людей, которые психологически не готовы менять работу (либо из-за опасений неизвестного, либо разочаровываются из-за неудачи на собесах, после которых развивается\усиливается комплекс неуверенности в себе, неполноценности).
В целом с идеей изложенной в статье согласен.
Пришел к аналогичным выводам для себя некоторое время назад.
Сейчас я тех.лид в крупной компании. Ровно год веду свой проект.
Из хорошего, это интересно и мне дало дополнительную мотивацию заниматься любимым делом.
Из плохого это не так легко, я упираюсь в ограничение времени и своих мыслительных ресурсов и здоровья. Постоянно болит голова и все мысли в работе и проекте.
За год собралась команда из 3 человек и мы дошли до рабочего прототипа. Буквально на днях заработал первые 100$. Что будет дальше покажет время, энтузиазм пока не угасает, даже скорее разгорается сильнее.)
Сделал свой продукт, теперь учусь продавать, что чревато просадкой по техническим скиллам. Но не первый день замужем! и своё же продавать, так что держусь. Но если можете не делать своего, то не делайте!
Продажа и маркетинг - просто главная боль! Есть продукт, но трудно без этого привести пользователей.
Свой продукт - это мощно
Привет, Петр! я про него тебе точно рассказывал - монолитик на go + react pwa (deloset.ru, а лендинг туда переедет с pro.deloset.ru). По теме статьи - мотив был очень сильный к написанию. К идее уже было видение "как надо" + опыт в недвижке и управлении - нельзя было не написать. И это захватывающе, но "очень тяжело продавать" для интроверта. Делаю отдельные вылазки, общаюсь, потом отдыхаю ;)
Немного не в тему поста, но в некоторых странах и компаниях есть еще и дискриминация. Например, я работаю в японской корпорахе в японии и у нас есть неофициальное полиси: иностранцам в менеджмент нельзя, при этом на паспорт не смотрят. Есть кейсы когда люди вообще всю жизнь прожили в японии и имеют японский паспорт с рождения, но они хафу (один из родителей не японец) и таким в менеджмент путь тоже закрыт. Кстати, как и полностью чистокровным японцам кто вырос не в японии (поэтому им реально важно знать при трудоустройстве в какие школы ходил и в каком универе учился с кем).
Конечно, тут есть много международных компаний и филиалов всяких FAANGов где такого нет. Но во многих чисто японских компаниях это дефолт.
По поводу своего продукта - как только готов минимальный функционал, сразу в прод =)
Иначе начнется бесконечная работа по доведению до идеала.
Переходите в бигтех, там над вашим синьор грейдом будет возможность еще на 3 грейда вырасти, причем это будут актуальные знания, а не "эксперт в легаси". Эффект масшиаба работает, сложность систем выше, возможностей изучать новое больше.
На мой взгляд, очень странные выводы: я не хочу быть тимлидом, и поэтому буду делать свой продукт. Но постойте-ка, ведь в своем продукте ты и разраб, и тимлид, и даже, о ужас, даже продажник. Что может быть хуже для технаря, чем продажник?
Часто люди думают, что если сделают крутой продукт, то его сразу будут покупать. Вообще нет, его надо ещё продавать и раскручивать. Многие разрабы на этом погорели. "из 5 долларов на создание продукта 3 я потрачу на рекламу" Г. Форд
Путь ... архитектора выглядит заманчиво: вы остаетесь в коде
это большое заблуждение. Архитектор - это встречи, встречи и ещё раз встречи... И ещё "кубики", как же без них.
Задумывался о том, чтобы делать какую-то медийку, но вот проблема в том чтобы выбрать тематику, писать что-то полезное, а не банальное, ну и регулярно поддерживать эту активность.
Свой проект имеет смысл для B2B, как кирпичик (SDK, фреймворк, тулза) в большом продукте. Я в нескольких таких копаниях работал и это намного эффективнее чем аналогичные команды в больших компаниях.
Свой проект в виде B2C имеет большой минус - ты навсегда привязываешься к этому проекту. Хочешь делать что-то другое и снова сидишь без денег, потому что конкуренты быстро сделают аналог и накинут новых фичей. А поддержка проекта и развитие проекта отнимает все время, еще нужно нанимать чтобы самому не тестировать и не фиксить примитивные баги. Когда ИИ сможет избавить от такой рутины, тогда станет намного проще запускать проекты.
«делай свой продукт» - это из разряда «не переживай, у тебя все получится, главное верить и стараться». нахрен твой продукт кому нужен?
я лет 15 мечтаю о своем продукте, не просто это все))
А не рассматривали путь развития как бизнес внутри бизнеса, вроде как он проще, правда награда меньше но шанс вырасти больше да и ресурсы компании помогают, так как не надо пилить всё в одиночку. В одном из своих коментов я описывал его на модели Адизеса.
https://habr.com/ru/articles/964470/comments/#comment_29097458
Свой продукт это не ступень карьеры после тимлида (или после синьера), это реально пет-проект. Если есть идеи, силы и желание - можно его запускать в любое время (даже не войдя в IT)
Вопрос в другом, если толк от этого пет-проекта, сколько сил он требует (ага, продвигаем без денег за счет контент-менеджмента, то бишь статьи пишем.. А статьи видимо сами из воздуха берутся, их писать не надо, контент-план прилетает откуда-то свыше), плюс все проблемы компании (менеджмент, бух-учет, налоги, хостинг, ddos, исполнители (если нанимаете кого-то) и прочее) - это все действительно перпендикулярно работе разраба (петы - это скорее к проджектам.. Они понимают как вообще бизнес функционирует и могут даже навайбкодить что-то)
Про свой продукт без вложений оптимистично вы конечно) Время сеньора стоит денег. Если вы тратите на пет-проект 20 часов в неделю, то по рыночной ставке это $50-100/час упущенной выгоды. За год набегает сумма, которую можно было бы вложить в ETF и получить гарантированный доход, а не лотерейный билет стартапа
Но с точки зрения самореализации - бесценно
Ну не знаю, к концу рабочего дня переключаться на подрадбоку меня не сильно тянет, на пета - конечно не с топовой производительностью, но довольно легко. То есть этих 50-100 мне не получить.
А с учетом нерегулярности занятий петом - это срывы сроков для готовых платить 100 за вечернее время и вот они уже не готовы платить 100.
Это на бумаге час равен 100$. Но в реальности появляется куча проблем вроде кому продать этот час за 100$, будет ли этот час так же продуктивен после утомительного рабочего дня и т.д. Это область фриланса, кому-то легко дается, кому-то тяжко, особенно в сочетании с основной работой
В целом статья понравилась, отражает реалии. Но про свой продукт - тут упс) Сильно мимо, и по ответам на комментарии это также чувствуется. Самое простое - создать продукт, а вот продать - это самое сложное. Невыжившие 99% стартеров - это не про вайб-кодеров или отсутствие экспертизы. Вообще предпринимательство это не про инженерию. Это про страсть, авантюризм, шарлатанство, бюрократию, маркетинг и т.д.
Очень странное ощущение.
Успешные проекты которые я видел (я правда в системном программировании) - это забег на порядка 3 лет на максимально возможной скорости крайне профессиональной команды.
Что можно сделать "по вечерам, нерегулярно, без бюджета и привлечения сильной команды" (с шансом выше, чем выиграть в лотерею) - даже близко не представляю.
Сколько из 400+ млн репозиториев на github начали приносить деньги через год после создания на отметке 30KLoC?
Советую для симметрии первую картинку вставить еще раз в конце статьи:
1. Делаешь свой продукт
2. ???
3. Profit
С выводом по тимлидству полностью согласен.
Сам из своих 15 лет опыта пробыл лидом 5+ лет и это реально ловушка для разработчиков, которым никто не объясняет что ты из синьора в одном направлении резко превращаешься в джуна в другом. Многие в этой ловушке живут годами постепенно выгорая.
С выводом про развитие по техническому треку в корне не согласен, т.к. даже в отечественном it много где отросли роли и должности техлида команды / продукта / направления. Эти роли и должности не исключают менеджмента как такового, откровенно говоря менеджмент начинается у разработчика с синьорского грейда и чем выше даже по техническому треку, тем менеджмента больше, но на этом треке все равно главное это техническая экспертиза, которую разработчик качал предыдущие 10+ лет.
свой продукт — это единственный путь
В некотором смысле, так. Особенно, когда твою любимую фирму ликвидировали, а новую найти – проблема.
Только бы хотелось больше информации о «своём продукте», его продвижению, развитию и т.п.
Например, продемонстрировать, допустим, стратегию: «Написать свою программу, опубликовать её бесплатно на бесплатном сайте, на «Хабре» сделать ей рекламу, а, когда проект выйдет на уровень рабочего прототипа, попросить донатов». Вот, лично я, иду по этому пути. Мой пет-проект уже выходит на уровень стартапа, но, каких-то дельных советов со стороны, я пока не видел. До всего приходится доходить своим умом, даже ИИ («Искусственный Идиот») помогает слабо.
Работаю все время (с 13го года) фрилансе и свои проекты, без понятия что такое ваши тимлиды, милды, джуны и сеньоры, с выгоранием никогда не сталкивался. Что со мной не так?
Смысл пахать за копейки 300-500к на чужие компании, когда в своём бизнесе можно кратно повысить себе зарплату? А потом ещё и продать его за миллиард?
Потому что в своем бизнесе деньги не будут капать на карточку 5 и 20 числа каждого месяца. А вероятнее всего и вообще никогда не будут. Бизнес так и разорится не выйдя в прибыль.
Да смысл вообще мести улицы, продавать булки и быть аптекарем за копейки, если можно просто быть бизнесменом и зарабатывать миллиард?
У меня был обратный путь.
Я в 21 год создал свой продукт и к 25 заработал себе на квартиру в своем регионе. Однако, айтишечка штука динамичная, и мой продукт начал умирать. Я пробовал разные стратегии реаниманиции, но никак. В итоге, начал расти в найме.
В какой-то момент мой годовой доход с найма начал приносить больше продукта, а сейчас на 95% мой доход зависит от найма. Я пытался запускать другие продукты, но все оказывались невостребованыными.
Естественно, я чувствовал лучше всего себя, когда у меня условно 30% дохода было от найма, а 70% от личного продукта. Пробовал ли я это воспроизвести? Конечно! Но рынок изменился, интернет изменился, я не могу повторить успех продукта.
На стройке есть аналог тимлида - прораб. А у прораба, как известно, ответственности много, а власти мало. Ступень прораба либо быстро проскакивают, либо остаются на ней навсегда. Незря говорят: лучше дочь проститутка, чем сын прораб
Такое ощущение, что у автора представление о развитии карьеры менеджера или архитектора такое же, как в примере про тимлидов.
Кажется вполне естественным тот факт, что, когда вы достигаете уровня архитектора или руководителя руководителей, количество вакансий сильно сокращается (как и количество кандидатов на такие вакансии). Вы ещё напишите, что при росте до уровня топ менеджмента, работу приходится искать не на хедхантере.
Но это не значит, что надо обязательно делать свой продукт. Это значит, что надо менять подход к поиску работы и прохождению собеседований. Например, большая часть вакансий архитекторов и СТО закрывается через знакомства, а не по откликам. Топовых вакансий в больших компаниях, а не СТО в "Рога и копыта" на 15 человек штата, разумеется. Собственно, расширением своего набора полезных контактов надо заниматься, а не кодерством своего продукта.
И, кстати.
Например, я бы не сказал, что был плохим тимлидом. Но как бы я ни старался, я никогда не получал столько негативной обратной связи, как в период, когда работал тимлидом продуктовой команды в Профи: потерял фокус на проекте, затянул сроки...
Вы бы не сказали, но, похоже, вы были плохим тимлидом и обратную связь игнорировали. Если, конечно, основными приоритетом вашего бизнеса не была атмосфера в команде, из которой никто не увольняется.
Не всякий продукт может приносить бесконечный доход. Когда я просчитывал некоторые области, ёмкость рынка оказывалась такова, что стартап с его рисками приносил лишь немногим больше найма.
"Возможно, со временем появится похожий тренд и для разработчиков, которые ведут экспертные каналы и пишут статьи, учитывая, насколько жёстким стал найм и как сильно снизился уровень доверия."
Вот не понимаю двух моментов. Если писать в телеграмме и сделать канал, то надо, чтобы на него как-то попали, то есть один фиг нужна реклама какая-то. Второй момент - если даже на канал твой попали, то телега для поиска информации - это очень плохой инструмент. Зашедший на канал должен по сути либо по тегам, либо сам полностью ознакомится с твоим материалом в канале и желательно ещё не уйти.
И опять же - а про что писать и кому это нужно? Я на гитхаб пишу в Github Pages типа мини блога, но что попадает в поиске Яндекса/Гугла, то и находится - опять же надо мутить какое-то SEO и обновлять проход страниц в поисковом боте.
Это как в видео у "волчистых":
Видео на Youtube
Личный бренд вроде бы играет роль, но один фиг тебя будут гонять по вопросам или вообще никто о твоих сайд проектах не знает. Ну и все помнят статью про собеседования - https://habr.com/ru/articles/926214/ Цитата из статьи:
Интервьюер сказал, что был на моем докладе на DotNext, и помнит меня. Круто, уже второй, кто узнал меня, в процессе этих собеседований. В целом он понимал, что я вроде не самозванец, поэтому пробежались с ним довольно быстро, и часть времени я позадавал вопросы о работе в компании.
Вон на Карьерном фесте Хабра была презентация и там была фраза:
Не все компании одобряют активное построение личного бренда, но все компании рады, когда сотрудник им помогает
Тут и начинаешь задумываться - а имеет ли это всё выхлоп, что стоит ли оно твоего времени?
Привет!
Любой энтузиазм угасает рано или поздно. Особенно, если продукт не приносит денег.
Скорее всего в описанной ситуации мы имеем дело с «эскапизмом» – мы убегаем от реальных «вызывающих» проблем туда, где нам кажется, мы уверенны в своих силах и в своем пути. Но это именно убегание, в том числе и от трезвого осознания окружения.
Совершенно точно, что скиллы разработчика и предпринимателя – перпендикулярны. Да, можно развить и применить скиллы предпринимателя, но чтобы развить реально прибыльный продукт – шансы меньше, чем выиграть в лотерею. Не нужно иллюзий – в мире сотни тысяч подобных разработчиков, делающих что-то в надежде на то, что оно как-то (как? когда?) продастся.
Бизнес – это не работу в одиночку.
Начните с правильного, но более сложного и «вызывающего» шага – попробуйте собрать, организовать минимальную команду, без какой-либо оплаты.
Если сможете – есть харизма и дар убеждения, можно идти дальше.
В принципе если многого не ожидать любой из вышеперечисленных путей вполне жизнеспособен
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Карьерный потолок в IT: почему я перестал стремиться в менеджмент и начал делать свой продукт