Либо я плохо выразился, либо вы не так поняли. Я потексту указывал именно не хочет ИЛИ не может, а тут была контраста предыдущего комментатора.
Я могу представить себе такую ситуацию (и даже знаю примеры), когда хорошо получается управлять, но это отнимает слишком много сил, времени и т.д. + если ты ПМ, а твой заказчик в другом часовом поясе, то приходится подстраиваться под него, а переработки не оплачиваются.
Не являясь ПМом могу сказать, что это самая неблагодарная работа — на него давит и команда и клиент и работодатель. И плох тот менеджер, котррый это давление просто передает дальше поцепочке.
Потому что у него hard-skill жёстко прибит гвоздями к конкретному фреймворку
Предлагаю перечитать статью еще раз и комментарий к ней, а потом уже «нерадоваться»
Автор специально ввел понятие tech-skills для того, чтобы убрать из hard-skills фреймворки, библиотеки и прочее, а оставить именно опыт и фундаментальные знания.
Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),
Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.
Автор решил не акцентировать на этом внимание в данной статье по той причнине, что если разобраться, то Team/Teach не выбивается из общей концепции, а еще и техлидов не хотелось бы обижать.
Но если появился такой вопрос, то могу на него ответить исходя из опыта и наблюдения как за одними, так и за другими.
TeamLead — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин
Он ближе к разработчикам и может их адекватно оценивать
Разработчики к нему относятся лучше, чем к проектному менеджеру
Можно убрать из проекта или снизить роль проектного менеджера (а он не приносит прямой доход)
Он может общаться с клиентом с точки зрения бизнесса, а не технологий.
Совещает в себе роли TechLead и PM
TechLead — техническй специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли. почему конкретный человек именно TechLead, а не TeamLead:
Он может быть технически очень сильным и отвлекать его не стоит, например, может участвовать в большем количестве проектов
Он интроверт или мизантроп, ему очень сложно общаться с людьми, а им с ним
Он очень сильно любит программировать, а управленческие задачи ему не интересны
PM не хочет делиться с ним обязанностями
В компании нет необходимости в TeamLead и больше требуется технические специалисты
Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца и об этом было упоминание в заключении, однако, при отсутствии очень сложных проектов он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за универсальности.
У меня 2003-2006 годы — Pascal, Delphi, C++.
с 2006 по 2016 годы основным ЯП был PHP (c 2008 фуллтайм)+jQuery+фреймворки Symfony, Laravel, Bitrix, YII. Но при этом писал плагины для jQuery, на Java, C++ и прочем. Были проекты с использованием Perl, были и корп. порталы и всякий e-commerce. В качестве тимлида продавал проекты, участвовал в разработке ТЗ, управлял командой разработчиков и проводил сдачу проекта заказчику.
В 2015 я и мои товарищи слышали фразу: ваш стек технологий устарел, это слышать было довольно тяжело.
В 2016 году с переходом в студию освоил React + Angular 1.5/2+ + NodeJS — скажу честно, что временами было очень тяжело. Но стал Mean фуллстеком.
Что помогало?
Глубокое знание веба (в свое время занимался разбором пакетов в wireshark)
Опыт работы с БД
Опыт работы и администрирования Linux. (сейчас приходится DevOpsить при необходимости)
Опыт разработки многопоточных приложений, межпроцессного взаимодействия, тестирования безопасности, нагрузочного тестирования, разработки высоконагруженных систем.
Опыт работы с кучей языков программирования (больше половины я не указывал в этом комментарии)
Опыт работы в качестве тимлида (уделять внимание мелочам, развивать младших товарищей, общаться с клиентом, не давать необдуманных обещаний, проактивность и клиентоориентированность)
Привычка работать в режиме постоянного стресса
Привычка разбираться в том, что ты делаешь, а не скакать по вершкам
Возможно, что-то еще.
Могу сказать, что смена стека технологий прошла тяжело, однако, относительно быстро, за 1.5+ года nodeJS знаю больше, чем среднестатистический молодой nodeJS разработчик, который пишет 3 года в резюме (переходы были без понижения ЗП)
На текущий момент именно программированием занимаюсь только при необходимости (когда надо, а людей нет), но основная проблема с кодированием — постоянные задачи, которые надо решать, делегировать, контролировать.
В ряде сфер есть привязка в выслуге лет. В IT я про такое не слышал и программировать можно хоть до победного. Я знаю и знал специалистов, которые были очень сильны именно как технари, но при этом в плане общения были очень тяжелы. Правильный руководитель создаст для такого сотрудника условия, при которых он сможет комфортно для себя и других выполнять свои обязанности (при условии, что такая возможность есть).
Я долго ждал подобного комментария и был удивлен, что он долго не появлялся.
Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.
Я бы с радостью построил математическую модель и проверил бы ее на основе каких-либо исследований, но дать объективную оценку скилам практически невозможно. Даже сам поиск способа оценки может вылиться в нехилое исследование. Даже технические скилы, например, тесты на апворке не всегда отражают объективной ситуации и могу как минимум быть набиты с N попытки.
Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
Из комментария следует, что заключение верно на все 100%: пересиливаешь себя — лучше сразу остановиться и не мучать себя. Не хочешь менеджерить и кодить — попробуй обучать.
• ну так в пермом случае главному герою было лет 20-22 и он смотрит на тимлида, как на старика.
• лет через 5 он уже разницу не так сильно ощущает, да и разрыв в возрасте и опыте уже не такой большой.
• еще через 5 лет он смотрит на молодое поколение и начинает чувствовать себя старым
Все относительно…
По крайней мере у меня были именно такие мысли во всех IT компаниях города, где мне довелось поработать.
Я так понимаю, что вместе с этим комментарием прилетел и — в карму ;-)
Интроверту искать проекты с минимальной коммуникацией и там, где софтскилы не так важны.
Это достойно отдельной статьи и обсуждения.
Если он меняет компании и проекты потому, что не может нормально работать, то это один вопрос, но если ему дали 1-2 мелких проекта (например он + более опытный напарник) и он их выполнил, потом до полугода его подсадили на крупный и долгий проект для помощи и роста + ему подкинули внутреннюю штуку сделать, то тут уже совершенно другой разговор идет.
Тут есть один нюанс: В классическом разделении есть только soft-skills и hard-skills.
Я же разделил hard-skills на 2 части
hard-skills — это фундаментальные знания и опыт
tech-skills — это знания именно в конкретной технологии, надстройка, как вы говорите
Например, 10 лет назад я писал десктопные приложение в одной очень известной RAD и что у меня из этого осталось? Ну общие подходы и опыт работы с многопоточностью.
Если выучить веб фреймворк, то технические знания увеличатся, но если при этом не разбираться в его работе, на задумываться о безопасности, и.т.д. то `hard-skills` будут минимальными.
Если взять формулу, то получится примерно следующее
value = ( 0.5 * <знание фреймворка> + 1,0 * <знание принципов программирования> + 1,5 * <умение работать в коллективе>) / 3
Еще помогает интерактивность, например, показ конкретного значения на графике при наведении указателя, чем, собственно, страдает «печатная» инфографика
Либо я плохо выразился, либо вы не так поняли. Я потексту указывал именно не хочет ИЛИ не может, а тут была контраста предыдущего комментатора.
Я могу представить себе такую ситуацию (и даже знаю примеры), когда хорошо получается управлять, но это отнимает слишком много сил, времени и т.д. + если ты ПМ, а твой заказчик в другом часовом поясе, то приходится подстраиваться под него, а переработки не оплачиваются.
Не являясь ПМом могу сказать, что это самая неблагодарная работа — на него давит и команда и клиент и работодатель. И плох тот менеджер, котррый это давление просто передает дальше поцепочке.
Нежелание может быть не так выражено, либо они еще не решили, что ему будет лучше, но они же уходят в программисты со словами «не мое это»?
Предлагаю перечитать статью еще раз и комментарий к ней, а потом уже «нерадоваться»
Автор специально ввел понятие tech-skills для того, чтобы убрать из hard-skills фреймворки, библиотеки и прочее, а оставить именно опыт и фундаментальные знания.
Автор решил не акцентировать на этом внимание в данной статье по той причнине, что если разобраться, то Team/Teach не выбивается из общей концепции, а еще и техлидов не хотелось бы обижать.
Но если появился такой вопрос, то могу на него ответить исходя из опыта и наблюдения как за одними, так и за другими.
TeamLead — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин
TechLead — техническй специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли. почему конкретный человек именно TechLead, а не TeamLead:
Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца и об этом было упоминание в заключении, однако, при отсутствии очень сложных проектов он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за универсальности.
с 2006 по 2016 годы основным ЯП был PHP (c 2008 фуллтайм)+jQuery+фреймворки Symfony, Laravel, Bitrix, YII. Но при этом писал плагины для jQuery, на Java, C++ и прочем. Были проекты с использованием Perl, были и корп. порталы и всякий e-commerce. В качестве тимлида продавал проекты, участвовал в разработке ТЗ, управлял командой разработчиков и проводил сдачу проекта заказчику.
В 2015 я и мои товарищи слышали фразу: ваш стек технологий устарел, это слышать было довольно тяжело.
В 2016 году с переходом в студию освоил React + Angular 1.5/2+ + NodeJS — скажу честно, что временами было очень тяжело. Но стал Mean фуллстеком.
Что помогало?
Возможно, что-то еще.
Могу сказать, что смена стека технологий прошла тяжело, однако, относительно быстро, за 1.5+ года nodeJS знаю больше, чем среднестатистический молодой nodeJS разработчик, который пишет 3 года в резюме (переходы были без понижения ЗП)
На текущий момент именно программированием занимаюсь только при необходимости (когда надо, а людей нет), но основная проблема с кодированием — постоянные задачи, которые надо решать, делегировать, контролировать.
Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.
Я бы с радостью построил математическую модель и проверил бы ее на основе каких-либо исследований, но дать объективную оценку скилам практически невозможно. Даже сам поиск способа оценки может вылиться в нехилое исследование. Даже технические скилы, например, тесты на апворке не всегда отражают объективной ситуации и могу как минимум быть набиты с N попытки.
Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
Никогда не считал себя гуманитарием
• лет через 5 он уже разницу не так сильно ощущает, да и разрыв в возрасте и опыте уже не такой большой.
• еще через 5 лет он смотрит на молодое поколение и начинает чувствовать себя старым
Все относительно…
По крайней мере у меня были именно такие мысли во всех IT компаниях города, где мне довелось поработать.
Интроверту искать проекты с минимальной коммуникацией и там, где софтскилы не так важны.
Если он меняет компании и проекты потому, что не может нормально работать, то это один вопрос, но если ему дали 1-2 мелких проекта (например он + более опытный напарник) и он их выполнил, потом до полугода его подсадили на крупный и долгий проект для помощи и роста + ему подкинули внутреннюю штуку сделать, то тут уже совершенно другой разговор идет.
Я же разделил hard-skills на 2 части
Например, 10 лет назад я писал десктопные приложение в одной очень известной RAD и что у меня из этого осталось? Ну общие подходы и опыт работы с многопоточностью.
Если выучить веб фреймворк, то технические знания увеличатся, но если при этом не разбираться в его работе, на задумываться о безопасности, и.т.д. то `hard-skills` будут минимальными.
Если взять формулу, то получится примерно следующее
Будущее k8s неотвратимо. Я (как ярый сомневающийся) сейчас уже почти точно решил их попробовать. Спасибо за статью.