Чем совершеннее в компании отлажены процессы — тем больше они напоминают конвейер вне зависимости от её профиля
Team Lead, особенно в небольших командах — это универсальный солдат, который и таски по команде раскидает, и сам за станок может встать, чтобы показать, как надо работать или закрыть собой дыру в ресурсах. В общем, тимлид он во всём тимлид — батя команды разработки.
Однако если в вашей компании имеются Software Engineering Manager, «семы» — то они тоже будут руководить командами разработчиков или инженеров, контролируя и обеспечивая работоспособность команды, и поддерживая рабочий контакт с «соседними» отделами разработки. Так в чём же разница с тимлидами? Мы попросили VP of Technical Product Management компании Aurea Software Максима Винникова помочь внести нам ясности в деталях.
Максим Винников — одна из жемчужин хантинга «Кроссовера». Мы пригласили его в компанию Aurea Software, одну из «дочек» техасского конгломерата ESW Capital, совсем не так давно, в январе прошлого года — и тогда ещё на позицию Technical Product Manager. Но уже в июле 2017-го Максим пересел в (виртуальное) кресло вице-президента.
На предыдущем месте, в компании AT Consulting, он проработал почти два года как раз-таки в качестве Senior Software Engineering Manager. В общем, практически вся его карьера вела его к моменту, когда он смог помочь нам написать эту статью на Хабр :)
Узкий специалист vs специалист широкого профиля
Разница между Team Lead и Software Engineering Manager — как между терапевтом и пульманологом. В наших широтах Team Lead обычно руководит многопрофильными командами и сам может быть многостаночником. «Семы» же, при должной компетентности в применяемых технологиях и методах, не принимают участия в написании кода, тестов и так далее, и ориентированы на конкретный фронт работ или операцию. Да, некоторым может показаться спорным подобный подход, однако он отлично укладывается в парадигму Factory-разработки. Software Engineering Manager – это специалист в своей области, причем специалист высокого класса, который выполняет функции руководителя и организатора, оставляя работу с кодом линейным программистам своей команды.
Впрочем, до такого уровня специализации дорасти должен не только SEM, но и компания как таковая. На ранних порах большинству бизнесов нужнее универсальные солдаты. Но как только начинается рост — специализация сотрудников и «механизация» процессов необходимы, чтобы суметь перешагнуть на следующую ступеньку развития.
Для самих специалистов, сужение их профиля несёт издержки, к которым надо быть готовым. Когда нагрузка по непосредственной работе с кодом осталась в прошлом, уступив исключительно менеджерским обязанностям, его деятельность становится более понятной и прозрачной окружающим — а значит, менее подходящей людям, склонным эмулировать ощущение собственной занятости, закопавшись в ворохе разноплановых задач.
Крутой SEM должен быть мощным специалистом, в котором победил управленец. Ещё одна проблема для любителей антагонизировать эти роли. При этом «ржаветь» и останавливаться в собственной грамотности SEM не имеет права: он должен от начала и до конца понимать, с какими технологиями работает его команда и с легкостью отслеживать возможные проблемы.
Как коммуникатор, Software Engineering Manager всегда должен контролировать входные и выходные точки выполняемых задач своей команды. Чтобы компания качала продукт как «Северный поток» качает газ, каждый сегмент трубы должен совпадать с соседними по толщине, диаметру и положению в пространстве по меньшей мере. На «входе» SEM обязан отчетливо понимать, что требуется от его подчиненных, а на выходе качественно передать готовый продукт (в виде части кода, тестов и так далее) следующему SEM и уже его «бойцам», которые примут его в дальнейшую работу. Особенно, когда речь идёт не о первичной разработке продукта, а постоянной поддержке, скажем, SaaS-решения — поток задач становится непрерывным, а цикл разработки стремительно закругляется — малейший сбой в этом процессе грозит последствиями разболтавшейся гайки в колесе при выезде на автобан.
Но и налаженные процессы не повод для расслабления. Отладив процессы — их надо начинать чистить. Банальный пример: повышение числа коммитов – это хорошо, однако если в итоге 50% и более из них в последующем правятся, то это не повышение производительности, а бег на месте с отягощением. Отлаживая процессы, SEM увеличивает объём выполняемой работы, чистя их — уменьшая затраты на выполнение конкретных её элементов, получая в результате постоянно растущее соотношение результата к усилиям. То есть ту самую производительность труда.
Карьера окончена, да здравствует карьера
Многие senior-девелоперы уворачиваются от навязываемых им позиций тимлидов, опасаясь профессиональной ямы — каким ты окажешься руководителем, это ещё узнать придётся — а вот хватка, навыки и актуальность опыта разработчика гарантированно просядут.
Но этот выбор стоит риска. Даже если всего себя посвятить совершенствованию кодерского мастерства, ты лишь отполируешь стеклянный потолок над своей головой. На каком-то этапе зарплаты просто перестают расти — остаётся разве что менять локацию, переезжая из краёв посуровее, с условной пятёркой $ в месяц, в края более солнечные, где и по 15 заплатят — но где и жизнь несопоставимо дороже, и налоги кусаются больше. В общем, если к старости вы хотите накопить не только почёт и уважение, этот потолок не заметить не получится — Хаттори Ханзо мог делать лучшие катаны в Японии, но если бы он открыл свой заводик вместо мастерской, то стал бы ещё и гораздо богаче.
И переход из «мастеров» в управленцы — самый очевидный и распространённый путь по ту сторону застеколья. Хороший спец получает больше посредственного менеджера, но гордый джуниор, задирающий нос перед другом-«менеджером» в какой-нибудь «Евросети» загоняет себя в ловушку: топ-менеджеры всегда будут зарабатывать больше специалистов, а владельцы и партнёры — больше работающих по найму.
И если вы на этот шаг решились, то позиция SEM станет отличной испытательной платформой. В отличие от того же тимлида, который в таком случае только навредит: в режиме человека-оркестра, постоянно отвлекаясь на код и сопутствующие задачи, легко будет самому себе заморочить голову — и тяжело непредвзято оценить свой реальный потенциал для перехода в касту управленцев.
Software Engineering Manager — это место, куда приходят умирать разработчики, чтобы вырасти из собственного праха уже руководителями. Дальше, впрочем, цепочка во многих компаниях не слишком длинная. В дочерних компаниях холдинга ESW Capital, например, SEM отчитываются перед VP, которые, в свою очередь, рапортуют уже напрямую CEO компании. Но зато каковы размахом эти шаги: с зарплаты «сениора», скажем, $5K в месяц — к $8K у «семы» в компаниях наших клиентов. А на следующей ступени уже пресловутый миллион рублей в месяц на позиции VP. Можно оговориться, что и этот рост тоже не безграничен, но ваши будущие стеклянные потолки будут уже стеклянными куполами. И вид оттуда открывается уже совсем иной.
Другая оговорка — зарплаты, принятые в компаниях группы ESW Capital, в которую входит и, собственно, Crossover, отличаются от рынка, причём сильно и в лучшую сторону. $8000 — это позитивная флуктуация в нашем случае. В среднем же, в столицах Software Engineering Manager могут рассчитывать на заработок от $2500-3500 в месяц. В общем, выбирать между завтраком и поездкой на метро не потребуется. Так что игра всё равно стоит свеч — попробовать себя в роли управленца стоило бы многим разработчикам.
Турнир стеклянного потолка
Начать можно прямо 10 марта, записавшись на участие в организуемый нами Hiring Tournament. Пусть вас не смущает «турнир» в названии — это не игра и мы не распределяем места среди пришедших, а оцениваем результаты участников по объективной шкале — теоретически, выше заданной планки могут оказаться и почти все, и совсем никто.
Вести турнир и делиться опытом на месте будут действующие SEM, работающие в компаниях ESW Capital. А по скайпу общаться с участниками будет VP of Engineering компании Aurea Software SlavaKulakov, к которому, мы надеемся, сможет присоединиться и соавтор этого поста Максим Винников. Мы считаем очень важным участие специалистов такого уровня в Hiring Days — потому что считаем, что самое ценное знание о вашей будущей работе — не как на неё попасть, а как на ней не застрять. В этом смысле нашим VP точно есть, чем поделиться с SEM как будущими, так и действующими, если кто-то из них вдруг нацелился на смену места работы сейчас. Ну а пользователям Хабра доступна привилегия задавать им вопросы в комментариях в течение всей недели. Как обычно, отвечать наши коллеги будут по возможности, но обещают уделить время хотя бы самым интересным вопросам.
Комментарии (53)
zenkz
07.03.2018 01:53Так и не понял приципиальной разницы между SEM и тимлидом, разве что кроме того, что тимлид — разработчик с обязанностями мереджера, а SEM — менеджер со знанием о технологиях. Не понятно зачем вообще нужна эта роль в команде?! Интеграция между частями команды осуществяется либо руководителем проекта (если менеджерский вопрос), либо архитектором/консилиумом тимлидов. А кроме этого ничего толком и не сказано, а только изображают тимлида в виде хватающегося за всё подряд и вечно-занятого недоменеджера. К тому же став SEMом вместо уважения в своём отделе, ты получаешь место джуниора в иерархии менеджеров и тебя не будет пинать только ленивый…
Получается что в SEM-ы стоит идти только карьеристам или в погоне за высокой зарплаты…
andorro
07.03.2018 07:15-2Перечитав ваш комментарий дважды, я понял, что не только «разницы между SEM и тимлидом» не поняли)
тимлид — разработчик с обязанностями мереджера
100% мимо. Тимлид — это менеджер над разработчиками. В словах team lead вообще нет корня dev. Да, обычно тимлиды вырастают из девов — потому что приведи за разработкой смотреть человека вообще без этого бэкграунда, получится первая серия The IT Crowd. А «разработчик с обязанностями мереджера» и вовсе чудище обло, озорно, огромно, стозевно и лаяй. Меня аж кринжит, хотя я сам не разработчик, но ситуации такие наблюдал не раз.
SEM — менеджер со знанием о технологиях
50/50. В статье про бэкграунд SEM'oв ничего не говорится, и, теоретически, такое может быть — но где у нас, интересно, учат на «менеджеров со знанием о технологиях»? Всё равно в 99% случаев это будет чувак с девелоперским бэкграундом.
Не понятно зачем вообще нужна эта роль в команде
Наверное, потому что менеджеры без «знаний о технологиях» гораздо хуже?
Интеграция между частями команды осуществяется либо руководителем проекта (если менеджерский вопрос), либо архитектором/консилиумом тимлидов
Мне сперва показалось, что вы предлагаете решать все управленческие вопросы в команде, видимо, любого размера, только силами руководителя и тимлидов… Даже хотел задать вопрос, до какого же предельного размера, по вашему опыту, может вырасти команда, в которой вообще все «менеджерские вопросы» решаются только тимлидами и главой компании? Но потом перечитал, и увидел, что «менеджерские вопросы» вообще все безраздельно относятся к компетенции единственного руководителя. Даже язвить расхотелось. Скажу серьёзно: в этой вашей воображаемой структуре тимлиды бы сами вскоре взбунтовались и насильно скинулись руководителю на пару-тройку захудалых менеджеров среднего звена, например.
К тому же став SEMом вместо уважения в своём отделе, ты получаешь место джуниора в иерархии менеджеров и тебя не будет пинать только ленивый…
О, а здесь можно поподробнее? Это из личного опыта что-то?
Получается что в SEM-ы стоит идти только карьеристам или в погоне за высокой зарплаты…
Всё-таки мне интересно, где и сколько вы успели поработать, если у вас даже карьеристов с высокой зарплатой запинывали?c4boomb
07.03.2018 11:59Невероятно но факт у Software Engineer тоже нету корня dev.
Если менеджеру без "знаний о технологиях" гораздо хуже, зачем они вообще нужны?
Человек написал про "интеграцию между частями команды", а вы ему про "все менеджерские вопросы"
VulvarisMagistralis
07.03.2018 07:51-4Так и не понял приципиальной разницы между SEM и тимлидом, разве что кроме того, что тимлид — разработчик с обязанностями мереджера, а SEM — менеджер со знанием о технологиях
Это очень разные вещи.
Вы произносите слово менеджер так, будто бы эти люди ничего не делают.
ToSHiC
07.03.2018 01:59Если у вас технические специалисты не могут получать больше, чем менеджеры, то действительно сильных технических специалистов у вас никогда не будет.
andorro
07.03.2018 06:54Если у вас технические специалисты не могут получать больше, чем менеджеры
Какого уровня должен быть технический специалист в России, чтобы получать под $18000 в месяц, мне интересно? Нет, правда интересно: что делают в том же вашем «Яндексе» чисто технические специалисты, получающие на руки миллион рублей в месяц?
И если разложить весь «Яндекс» на этажи по уровням дохода сотрудников — с увеличением «этажа» % технических специалистов на нём будет расти или уменьшаться относительно «менеджеров»?ToSHiC
07.03.2018 14:27А давно ли менеджеры типа тимлидов и SEM получают в РФ под $18000 в месяц?
Про Яндекс могу сказать так: можно расти как технический специалист и получать столько же, сколько при росте менеджером/управленцем. И не только на уровне руководителей групп.
SlavaKulakov
07.03.2018 11:20Если у вас технические специалисты не могут получать больше, чем менеджеры, то действительно сильных технических специалистов у вас никогда не будет.
Вот купили мы в июне прошлого года JiveSoftware — компанию, которая базируется в Портлэнде — считайте та же Силиконовая долина. Для девелоперов там были созданы все условия — высокие зарплаты, отличный офис в центре города, 5 сортов разливного пива(!!!) в офисе, не говоря уже о еде, треннингах, массажистах и так далее. То есть инженеры у них работали очень даже квалифицированные (могли себе позволить заманить). Так вот — после покупки этой компании мы стали ставить своих иженеров ($50/час которые) в пары с Джайверами — всего за 3 месяца мы наняли 100 новых сотрудников через Кроссовер. И знаете что? Все Джайверы сказали, что наши ребята очень сильные и с ними здорово работать. Я специально постоянно всех спрашивал, так как самому было интересно сравнить наших ребят с коллегами из крутой компанией в Силиконовой долине.ToSHiC
07.03.2018 14:29Ваши то девелоперы получают больше, чем ваши же менеджеры, или нет? Если меньше, то какой им резон развиваться профессионально, если выгоднее стать руководителем?
mad_nazgul
07.03.2018 07:30+1Зачем перед началом «крысиных гонок» заниматься «всякой фигней» в виде программирования?
Не лучше ли, да эффективнее, сразу включиться в «крысиную гонку», чтобы обогнать на старте?Crossover Автор
07.03.2018 09:51+1Зачем перед началом «крысиных гонок» заниматься «всякой фигней» в виде программирования?
Кому лучше? Вы бы предпочли, чтобы у вас был начальник, вообще не имеющий представления о вашей работе? Включившийся в «крысиную гонку», как вы говорите. Я не думаю, что вам это правда нужно.
Не лучше ли, да эффективнее, сразу включиться в «крысиную гонку», чтобы обогнать на старте?
Зависит от ваших критериев эффективности. Скажем, про трудоустройство в любую из компаний нашего холдинга можно было бы сразу забыть. Наши тесты написаны не в шутку. Пожалуйста, почитайте Славин пост — там он хорошо описывает, как проходил наше тестирование при трудоустройстве в Aurea. В его случае это было удалённо, чаще мы всё же проводим тесты в формате мероприятия — как наш субботний турнир. Суть одна: «крысиные гонщики» к нам, нашим процессам, нашим разработчикам и на пушечный выстрел не попадут.
Так что нет, не лучше. Не эффективнее. Никого он так не обгонит ни на каком старте. В общем, не зашла нам ваша идея :)mad_nazgul
07.03.2018 11:35Т.к. в статье говориться
1) О карьере
2) О «бесконечном» повышении заработка
то я делаю вывод, что мне, как специалисту, предлагают поучаствовать в «крысиных гонках».
Т.к. «Даже если всего себя посвятить совершенствованию кодерского мастерства, ты лишь отполируешь стеклянный потолок над своей головой.»
Поэтому зачем тратить время и усилия по «совершенствованию кодерского мастерства», когда можно сразу выбрать путь «крысиных гонок».
Это проще и эффективнее.
(см., например, Б.Гейтс, С. Джобс )
Ну и не забываем про «принцип Питера».
Рано или поздно во всех узлах иерархии будут находится некомпетентные сотрудники.
:-)
GrigoryPerepechko
07.03.2018 10:33+1«Статья» от кроссовер.
Жонглирование субъективными тайтлами и ЗП.
igorp1024
07.03.2018 10:46+3Работал я у вас какое-то время и могу с уверенностью сказать, что единственное преимущество компании Crossover for Work — это конкурентная ЗП, выплачиваемая без проволОчек. На этом — всё. Тебе дают какой-то легаси-проект (там по всей Aurea сплошь виндовое легаси), снимают на веб-камеру, фоткают экран (это же дикость, объяснять что это remmina — это приложение, которым ты ходишь по RDP и что это разрешённая аппликуха) и обвешивают кучей метрик производительности. И ты деградируешь в техническом плане, пытаясь как дрессированная обезьяна при этом соотвествовать этим метрикам. Хорошо хоть повезло с менеджером, она была одной из лучших, которых я встречал.
Ну и как маркетинговый ход — создать шоу, чтобы поднять желанность позиции в глазах претендентов.
eyeless_watcher
07.03.2018 12:14Счастливый человек. Мне ни одного приличного менеджера там встретить так и не удалось. Ну или занимаются они чем-то своим, не включающим взаимодействие с разработчиками. Какое там «раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием», банальный ответ на вопрос в слаке можно было по полдня ждать.
novikovag
07.03.2018 12:49Какой ужас, и вы терпели такое унижение?
igorp1024
07.03.2018 12:57Если это не сарказм, то да, вынужденно и ушёл при первой возможности. У меня была сложная ситуация с работой на тот момент. Если очень интересно, могу в личке рассказать, но не думаю, что это будет интересно.
Bringoff
07.03.2018 14:37Почему же, интересно. Нужны реальные подробности от реальных людей. Может, пост напишите?
igorp1024
07.03.2018 16:28Ну, я не уверен, что материала хватит на целый постинг. Да и излагаю мысли достаточно сумбурно. Очень не хочется чтобы это выглядело как критика ради критики. Альтернативой была бы "личка", но это будет выглядеть, будто я прячусь опасаясь ответной критики.
Можете почитать тут (нашёл случайно) или тут (это уже мой отзыв). Ну, и присовокупить то, что я написал в топ-комменте этого треда.
Fandorin
07.03.2018 11:21+1SEM — это технический менеджер? Не понял из статьи, за что он все-таки отвечает?
SlavaKulakov
07.03.2018 11:28У нас в компании есть 2 типа СЕМов — ПродактСЕМ и КорСЕМ.
ПродактСЕМ больше ориентированы на классический Project Management: scope management, release management, timelines, risks/issues management, очень много общения с «братскими» организациями — SaaSOps, Product Management, Support, Professional Services. ПродактСЕМы заказывают выполнение работы у КорСЕМов.
КорСЕМы больше ориентированы на то, что бы поставить процессы и натренировать людей в команде таким образом, чтобы на выходе было хорошее качество и производительность команды постоянно росла. То есть это более технический человек, который хорошо разбирается в технологиях и инженерных практиках. Я там выше расписал чуть подробнее.
relgames
07.03.2018 11:56Так в чем разница между тимлидом и SEM? Судя по комментариям, это многим не ясно. Что мешает сделать тимлида ответственным за узкое направление? Надуманная разница
mad_nazgul
07.03.2018 13:20Почему?
Разница есть… В условной иерархии.
А так, какая разница teamlead или SEM, главное чтобы он работал и за менеджера, и за программиста, и за ментора для юниоров.
По мне teamlead это первый среди равных.
Чтобы споры о красоте того или иного решения не превращались в холивар.
Тот кто будет говорить, что делать надо так и никак иначе.
При этом все остальные программисты с этим согласны.
Ну и по возможности передавать опыт.
Т.е. сплав опыта и авторитета.
Остальное, это просто ленивые/ушлые менеджеры перекладывают свою работу на него.hippoage
07.03.2018 15:05В компании из статьи нет тимлидов, а СЕМы не программируют (хотя в каких-то подразделениях по час в день в виде парного программирования, как было в комментарии выше). Откуда про условные иерархии? SEM — менеджер, сотрудники его команды — исполнители. Вроде де бы все просто.
gavrilovm
07.03.2018 16:54Это вроде как главный конструктор главного КБ страны перейдет в главного завхоза главного КБ страны. Не глупо?
Не понимаю я такие статьи.
Как рост у манагера? Не перешел ли лид от «своей верхней планки» которую тут назвали тупиком в настоящий тупик где манагер останется манагером?
И самый важный вопрос: «почему обязателен рост? Книжек начитались?».
Почему нельзя наслаждаться работой сеньёра девелопера ?!
Не думаю что есть чего-то значащие ответы на эти вопросы…
velvetcat
08.03.2018 23:46когда нагрузка по непосредственной работе с кодом осталась в прошлом, уступив исключительно менеджерским обязанностям,… деятельность становится более понятной и прозрачной окружающим
Весьма спорно...
VolCh
Получается основная мотивация попробовать себя как EM — деньги? И то с проседанием пока растешь от джуна до, минимум, миддла? А как же радость созидания, радость от решения сложных технических задач?
Второй вопрос: как оставаться подкованным технически, если перестать писать код? Есть, конечно, Хабр, есть ченжлоги и т. п., но как-то сомнительно…
Третий, наверное, главный — чем отличается от ПМ, если смотреть для простоты одна компания-один проект-одна команда. Или от тимлида в команде, где есть техлид, а сам тимлид только управленческими вопросами занимается?
KoCMoHaBT61
Менеджеры размножаются почкованием. Так как по вертикали размножаться трудно, то они размножаются в пределах горизонтали. Были тимлиды и техлид, стали тимлиды, техлид, лайн менеджер. Потом добавился SEM. Следующий шаг это технический заместитель SEM.
andorro
Вот и мне теперь интересно стало. Я бы заслушал
начальника транспортного цехагоспод VP of something something :-) Но что тут сомнительного-то? Как будто не было никогда такого, а тут опять. Марк Цукерберг давно не разработчик, но вряд ли его представления о технологиях так и остались в 2006 году.Мне в голову приходит масса вариантов: во-первых, в случае того же Цукерберга, ему точно не даёт окостенеть регулярное вдумчивое общение с одними из сильнейших в мире разработчиков.
Во-вторых, если зайти чуть шире — не обязательно вообще всё знать, чтобы быть на коне. Ни мне, отвечающему на этот комментарий. Ни бывшему разрабу, перешедшему в топ-менеджмент. Потом что, как говорил Гельвеций…
А в-третьих, если вы боитесь перестать совсем писать код — не переставайте совсем писать код. Никто вам пальцы при переходе в управленцы не сломает и контрактом этого не запретит.
lair
Просто свободного рабочего времени у вас на это не останется.
andorro
I see what you did there.
Ну ок: если вы на руководящей должности уровня хотя бы SEM, и вы уверены, что для сохранения адекватности принятия решений вам надо регулярно освежать актуальность своей базы знаний — то, думаю, вы будете в состоянии этот вопрос обсудить с начальством, выделить какое-то время недели на это, и даже бюджет (особенно когда мы смотрим на зарплаты в Aurea). То есть, если вы этот вопрос не сумеете решить полюбовно, то либо лидер вы (пока) так себе, либо начальство у вас не очень. В обоих случаях причина потери квалификации тут лежит не в самом факте смены специализации.
…и всё же мне не даёт покоя это ваше свободного рабочего времени у вас на это не останется. А другое время, кроме рабочего, у вас будет? На него как-то распространяется воля вашего начальства? Ваша ситуация кажется мне чересчур умозрительной: люди, которые готовы повышать квалификацию только в рабочее время за счёт работодателя, выкидывающие все мысли о делах за пределами офиса — ну, во-первых, их вряд ли вообще посещают мысли о потере квалификации. Во-вторых, они вряд часто оказываются в жизни перед выбором: «Так, остаться ли на моей зарплате $5K, развиваясь как крутой специалист, или перейти в управленцы на $8К, но рискуя просто растерять скиллы? Ой, уже 6 часов. Так, рабочий день окончился, пятница — это святое. Подумаю об этом в понедельник. О работе только в рабочее время.»
lair
Ну то есть мы двигаем позицию из изначально описанной в какую-то другую (потому что изначальная позиция работу с кодом не подразумевала).
А поддержание рабочей квалификации в нерабочее время дорого обходится для жизни.
Если вы выделяете на это немного времени (скажем, 4-6 часов в неделю) — вам его может и не хватить; а если выделять много времени (ну хотя бы часов 10-16), то у вас в неделе пропали выходные. Нет, некоторых людей это устраивает. Просто совсем не всех.
andorro
Вот именно что не подразумевала. Человека взяли на работу, на которой в его должностные обязанности не входит кодить. А он боится растерять квалификацию, и не найти нормально уже следующую работу. Это и есть момент, когда позиция поехала куда-то не туда, потому что это уже сугубо личные переживания человека — на работу-то он устраивался, зная свои должностные обязанности. Это как качок устроится на работу в библиотеку, а потом начнёт переживать, что сдуется и станет требовать поставить ему скамью и разрешит жрать грудки на рабочем месте 3 раза в день.
Нет, теоретически, договориться с руководством можно и в такой ситуации, о чём был мой предыдущий коммент. Но это не отменяет персональной ответственности человека за добровольный выбор. Которая внезапно переехала в зону ответственности работодателя: «А в рабочее время мне почему-то заниматься тем, чего в моей работе изначально и не подразумевалось даже, не дают!»
Вы продолжаете так проталкивать сквозь все ваши примеры странную ситуацию, которую вам навязывают: не дают на работе повышать квалификацию для другой должности — это ок. Но теперь получается, что вам уже и за рамками работы прямо график ставят: потрать 10-16 часов! Только кто вам это говорит? Ну, кроме вас? Если вы решили устроиться на одну работу, но хотите быть в форме для другой, и вам на это нужно не меньше 16 часов в неделю… — вы уверены, что кто-то ещё кроме вас в ответе за эту ситуацию?
c4boomb
Некорректный пример с качком. Библиотекаря не требуют разбираться как накачать трицепс, а вот SEM должен прекрасно владеть современными технологиями и т.д. и т.п.
andorro
Ваш тоже ситуацию не исправил) Если в библиотеке есть секция спортивной литературы, библиотекарь будет прекрасно подкован в теории, описанной в этих книжках. Как в любом, кстати, магазине спортпита, пузатые продавцы отлично знают все нюансы правильного питания. И могут чему-то научить даже — только пример подать не смогут.
Если повышение квалификации будет критично для выполнения его работы, то я сомневаюсь, что ему будет в нём отказано. Вы просто моделируете каких-то фантомных работодателей, которые требуют от вас того, чем якобы сами же запрещают заниматься. Зачем? Зачем это работодателю? И зачем эти фантазии вам?
c4boomb
Некорректный пример, в случае библиотеке вам надо прочитать книги и вы будете отлично в них ориентироваться. А вот не попробовав технологии и не сравнив их в кое каких задачах в современном ИТ мире вы просто утонете
lair
Конечно… нет. Библиотекарь не читает (все) книги, находящиеся в библиотеке, это невозможно.
lair
Э нет. Речь шла о том, что для работы SEM нужна техническая квалификация, для поддержания которой нужно самому иногда разрабатывать ("как оставаться подкованным технически, если перестать писать код?"). Мы можем спорить с этим тезисом, это одно дело. Но если мы с ним согласились — и это другое дело, — тогда как раз встает вопрос, как же это поддерживать.
Поэтому все ваши тезисы о другой работе — они немножко мимо, извините.
Обратите внимание, кстати, что в комментах ниже SlavaKulakov пишет "мы от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием". Видимо, они не считают, что это повышение/сохранение квалификации идет для другой должности.
c4boomb
Чаще всего людям с большими семьями уже не хватает времени в НЕ рабочее время заниматся развитием рабочих скилов.
Тем не менее специалистом можно быть хорошим.
andorro
Уже которого комментатора затянуло в воронку обсуждения выходов из вымышленной ситуации, вместо того, чтобы задаться вопросом: «А как наш герой в ней оказался-то? Зачем он устроился работать по специальности, которая будет ему только мешать держать форму для работы, на которую он на самом деле нацелен?»
c4boomb
Вы понимаете, что от SEM требуют знания технологий. При чем тут вообще на что нацелен человек.
carebellum
это ваше предположение, или данность на рынке?
в каком объеме необходимы знания технологий менеджеру?
VolCh
Это тезис поста.
carebellum
да? прочитал еще раз, не нашел это утверждение в качестве тезиса
c4boomb
carebellum
для этого не обязательно глубокое погружение в стэк
достаточно крепкого высокоуровнего понимания и слаженного взаимодействия с архитектором
Crossover Автор
Можно мы просто процитируем комментарий выше? С небольшими сокращениями :)
Обсуждаемая в этой ветке история действительно скорее про «фантомных работодателей, которые требуют от вас того, чем якобы сами же запрещают заниматься». Плохие работы бывают, неадекватное начальство встречается. Но если это не системная проблема, то подобные рассуждения будут просто уводить диалог в пустоту.
SlavaKulakov
Всем привет!
Пришел начальник транспортного цеха. Вопрос понравился.
У нас в компании каждый СЕМ должен хорошо разбираться не только в ProjectManagement'е, но и иметь сильные знания в технологиях и инженерных практиках: как правильно организовать код-ревью, continuous integration, test driven development, branching strategy, deployment automation, environment provisioning automation, и так далее.
Ну а поддерживать/улучшать свои технические знания ему помогает одна из его прямых обязанностей, которую мы называем «Gemba Walk», а Toyota — «Walk the line»: чтобы менеджер имел возможность грамотно улучшить процесс — он должен видеть этот процесс вживую. В Toyota менеджеров посылают на заводы, где они ходят за рабочими и смотрят что и как они делают. Мы же от своих менеджеров ожидаем, что раз в день минимум час они с каким-то их своих разработчиков/тестеров занимаются парным программированием. Это позволяет им разобраться почему top-performers работают так быстро, научиться у них, а потом изменять процессы/тулы/подходы/практики соответственно и обучать уже всю команду.
А еще, так как один СЕМ обычно поддерживает несколько продуктов (от 5 до 10), то у него есть возможность выучить и разные технологии, увидеть в деле и сравнить различные архитектурные подходы. В общем, поле для профессионального роста просто огромное.
lair
vs