×

Где ответственность, или кто такой Senior Software Engineer

Всем привет! Тема специалистов в CIS мне близка: за 10 лет в IT-индустрии я прошел путь от молодого разработчика до руководителя направления и был по обе стороны «баррикад». Потому предлагаю обсудить вопрос исключительно в формате «проблема-решение».

Наш рынок относительно молодой и развивается преимущественно эмпирическим путем: методом проб и ошибок. С одной стороны, это звучит гордо: без толкового профильного образования мы пробились через асфальт. Но в реальности мы теряем огромный потенциал времени. Почему? IT не настолько творческая деятельность, как считают многие, оправдывая свое нежелание брать существующие практики и, тем более, отстаивать их жизнеспособность. Большинство подходов и методов описаны и применялись кем-либо в прошлом или настоящем (пропускаем инновации). Такие проблемы, как отсутствие понимания Delivery Management, использования существующих практик и отсутствие профильных академических знаний заметны не сразу, так как спрос на специалистов по-прежнему превышает их количество на рынке.

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

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

«Seniority»

Сама тема ответственности и распределения обязанностей в производственном цикле разработки проекта широкая, и, видимо, не просто так книжные полки ломятся от профильной литературы. Примечание: проект может быть любого характера, производства ПО можно заменить на производство сарделек. Мы же разберем насущную проблему: «Кто такой Senior Software Engineer?»

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

Лично я — за баланс и отказ от резких суждений и штампов. Менеджменту нужны люди для роста продукта, проекта или организации (карьеристы не в счет), и у специалиста, чей потенциал был замечен, меняется система метрик его труда. В большинстве случаев осознание Senior-специалистом масштабов и зон ответственности диаметрально меняет его отношение к работе менеджерского состава, учит мыслить целостно, а не частями. Те, кто не справляется, возвращаются обратно и больше не затрагивают тему несправедливости. Но их пример мы опустим. Данный материал нацелен на достижение результата, а не попытку.

1. Результативность

Итак, мы определились с героем рассказа — это Senior специалист. Теперь, войдя в его «шкуру», что мы видим? Ему в той или иной мере присущ нарциссизм. Недостаточное внимание к собственной персоне — мысль, на которой он часто себя ловит (как и все мы, собственно). Мысль эта стимулирует негодование и недовольство текущей средой и ключевыми фигурами. Не нужно ерничать, каждый этого хочет, иначе бы мы не стремились все иметь и рассказать об этом как можно более широкой массе людей про новое авто, гаджет, квартиру и остальное.

Теперь посмотрим на ситуацию глазами взрослого человека. Если у вас есть прибыльное производство, и вы планируете увеличить доходность предприятия, вам нужен заместитель, которые уделит определенному вопросу больше времени, чем вы, и сможет решить его эффективнее, чем вы. Конечно, вы не пожелаете взять на ответственную задачу сомнительного «Senior» специалиста. Не нужно себя обманывать, что кроме вас это никто не сможет сделать лучше. Жизненный цикл растущего предприятия требует смены управленческой модели и структуры для удержания положительной динамики при смене переменных показателей. Это продиктовано здравым смыслом.

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

2. Поиск возможностей

Теперь у большинства людей включится череда комментариев-оправданий типа: «я пробовал — не получилось», «не все так просто», «у меня совершенно другая ситуация» и им подобных. Оправдания — мощнейший инструмент людей, которые не добиваются результатов. С помощью оправданий они могут обосновать связь между голодом в Африке и решением начальника не давать ему «заслуженного» повышения. За мою карьеру я видел немало гениальных людей, которые могли обосновать все, лишь бы не приступить к делу. Как у них обстоят дела сейчас? Они по-прежнему занимают место рядовых разработчиков и, вероятно, пробудут там до IT-пенсии.

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

Простой пример: вы только что закончили мучительно-сложный проект. Со стороны пессимиста вы проклинаете этот прецедент в вашей жизни и с опаской смотрите на каждый последующий. При рассмотрении глазами оптимиста данный прецедент заставляет задуматься над «подводными камнями» (другими словами, извлечь опыт) и выработать модель работы с последующими проектами, не опасаясь, но будучи во всеоружии. Вероятно, этому будут способствовать общения с более опытным специалистом, пройдя тренинг или прочитав профильную литературу. Правило № 2: рассматривать новое как возможность, отдавая отчет окупаемости инвестиций.

3. Самостоятельность

Представим, что наш Senior специалист как минимум не пессимист, но как быть в ситуации, когда ты просто специалист (пешка), а над тобой нависает несколько кругов ада, которые ограничивают тебя в правах и действиях (достаточно распространенное суждение)? На самом деле, ограничения существуют только в голове. Продолжая думать в таком контексте, наш Senior неосознанно начинает искать «уютное» и «стабильное» место, какой-нибудь идеальный проект, в котором все построено по книжкам и царит всеобщее счастье и взаимопонимание.

Давайте договоримся: «уют» и «стабильность» — гибкие и относительные понятия, для постоянного наличия которых нужно много действовать самостоятельно, не ожидая мессии со стороны. Оставаясь в зоне комфорта, человек попадает в ловушку времени и плавно перетекает из состояния динамики в состояние стагнации по принципу лягушки в кипящей воде. Я не встречал ни одну личность, вышедшую из идеальной, рафинированной среды. Любой достойный человек, с которым нам хочется общаться и работать, имеет результаты за спиной и тернистый профессиональный путь.

Возьмем, к примеру, «Senior» специалиста, который не построил процессы, а просто попал в благоприятную среду, и поместим его на новый проект, в котором конь не валялся, а клиент в придачу и не хочет, чтобы он вообще там валялся: 95% специалистов не смогут показать в этой ситуации результат на предыдущем уровне (5% оставляем под потенциально сильных и целеустремленных людей). Проблема в отсутствии должных навыков, которыми казалось бы наш специалист должен обладать.

Senior скажет: «Меня ограничивают!», а теперь побудим спросить его самого себя «Что я уже попытался сделать?». Ответ не поразит своей новизной, список сведется максимум к одной или двум попыткам. Скорее всего, наш специалисты поднимал беспокоящий его вопрос, но:
— он был адресован не тому человеку, который в состоянии его решить или помочь;
— информация не была донесена должным (то есть, ясным) образом;
— предложение поступило в сухой форме, без каких-либо предварительных попыток повлиять на ситуацию или желания самого Senior взять ответственность за результат.

С каждой минутой просветления наш Senior будет перемещать ответственность за результат из зоны внешней среды в поле своего влияния. Правило № 3: хороший проект — проект сделанный своими руками.

4. Hard и Soft навыки

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

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

Кто всему виной? Конечно, Project Manager, Project Coordinator или Scrum Master. Это их задача — контролировать процесс и обеспечивать эффективное взаимодействие между отделами. «Виноват кто угодно из эшелона менеджмента, только не я — простой и честный трудяга», — думает наш Senior. Давайте рассмотрим роль этих менеджеров. Каждый из вышеперечисленных, может исполнять обязанности без наличия профильных глубинных навыков в технологии. Методологии разработки, такие как RUP, Scrum, Waterfal и другие, служат лишь инструментами, позволяющими абстрагироваться от конечной среды и визуализировать процесс. Исходя из этого, все риски связанные с процессами Risk Management, Change Management, Release Management, Requirements Gathering, Planning, Estimation и остальными требуют вовлеченности и проактивности ключевых специалистов на проекте.

Очередной пример: Senior-специалист, работая над проектом, знает о вероятных последствиях при возникновении конкретных рисков. Он считает свои долгом проинформировать о них и пишет короткое сообщение в общем чате проекта. Долг перед отечеством исполнен — можно спать спокойно. Чем ближе день Икс, тем вероятность возникновения риска выше, и, в конце концов, он «выстреливает». Работа кипит, фаза «ASAP». Ситуацию улаживают, страдает репутация, компания, возможно, терпит издержки в виде штрафов. Никого не интересует, что о проблеме все знали, интересует, почему она не была услышана ключевым составом проекта и не были предприняты действия.

Комментарий из зала: «Так, а почему PM некачественно исполняет свою роль? Мог бы потрудиться и прочитать весь словесный поток в поисках нюансов». Может PM был неправ, а может информация была истолковано некорректно, тем не менее, факт остается фактом: проблема возникла.

Причина в том, что исполнитель, потративший последние 5-7 лет своей жизни, чтобы занять должность Senior, не смог осознать, что с каждой ролью у него появлялись новые обязанности — большей степени не технического, а организационного характера, в связке с персональными навыками. Правило № 4: Senior на 50% состоит из Hard Skills и на 50% из Soft и Management Skills.

5. Качество, проверенное временем

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

Вопрос из зала: «Зачем обучать людей, если они уйдут?» Давайте представим, что мы не инвестируем в людей, и они остаются. Картина получится ужасающая. Senior становится реальной ключевой персоной и логично предположить, что в параллели этой активности будет запущен какой-то Knowledge Management процесс.

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

К сожалению, негативные штампы управленческой модели до сих пор живут в сердцах многих людей. Таким кадрам сложно принять, что воспитанные, молодые и амбициозные специалисты могут занять их место. Сказывается незрелость личности. В подобных случаях компания и специалист становятся узниками друг друга, и, с течением времени, эксперт плавно превращается в партизана в динамично меняющейся организации. Правило № 5: результат труда должен простоять не один год.


Тема ответственности за общий результат достигает колоссальных масштабов. Но даже если остановиться сейчас и представить Senior специалиста, который соответствует всем этим пунктам, мы увидим не простого исполнителя, а зрелого и ответственного Senior Software Engineer, который может преодолеть любое испытание в виде поставленных перед ним задач. Такого специалиста хотела бы видеть каждая компания и клиент. Реально ли это? Конечно, реально, и я думаю, что практически каждый знает человека из своего окружения, который вышел за рамки собственных ограничений.

Буду рад услышать ваши конструктивные комментарии, всем хорошего дня!

P.S. Спасибо Михаилу Сидоренко и Олесе Ковалевой за подготовку иллюстраций.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Очередные сказки. Реальность к сожалению очень далека.

Обычное менеджерское завывание о том, что на разработчиков нельзя скинуть еще пару-тройку собственных задач. Вы еще полы после работы заставьте мыть в рамках ответственности за «общий результат».

Слабый менеджмент будет нанимать и растить слабых сеньоров.

219 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Колосс на глиняных ногах
Автор сразу берет за постулат заведомо фальшивые основы, потом на них старается базировать свой вывод, надеясь, что о том факте что само основание было ложным, к концу уже все забудут..
В итоге имеем то, что имеем.
В первых же фразах автор выдает какой-то абсурд, приправляя эту чушь словом «каждый» — "Не нужно ерничать, каждый этого хочет, иначе бы мы не стремились все иметь и рассказать об этом как можно более широкой массе людей про новое авто, гаджет, квартиру и остальное.«©
В реале наоборот — стараешься внимание не привлекать и чтобы как можно меньше людей на это обратили внимание ибо хвастаться покупками несколько стыдно. Об этом не то, что не «стремятся рассказать», а напротив — стараются чтобы это ничьего внимание не привлекло.
И так вся статья — чушь на чуши..

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

проблема в том, что в ряде организаций (которые не столь mature) понятия размываются и народ начинает переводить стрелки. Ну тут или преодолеть или умереть.

Superstar — это качественный Senior ;)

А я думал, это Senior с изначально завышенной самооценкой ))

Если Superstar исходит из уст компании — предполагается, что предвидится hard core работа

Если Superstar исходит из уст специалиста — это про завышенную самооценку :)

Если человек говорит с богом — у него православие
Если бог говорит с человеком — у него шизофрения

ну, это все правильно. да, таким и должен быть идеальный Senior.
а чем тогда занимается ПМ (кроме серфинга почты) и прочие талантливые руководители скрам-мастера?

а чем тогда занимается ПМ (кроме серфинга почты) и прочие талантливые руководители скрам-мастера?
Они будут заниматься более важными вещами — решать, по чём продать сеньёра заказчику, и какую маржу поиметь. :)

CIS це шо таке — це есенґє, да?

так то ж на рассєє сеньйор і в нас — це ж зовсім різні сутності. там же ж гримуча суміш камсамольскава задора і підручників адама сміта... це ж як пародія або навить сатира їх сеньорізм...

Нет разницы между Senior в Украине, Беларуси, России и т.д. Проблемы везде одинаковые. Я сужу не по сатирическим сценкам, а по реальному опыту работы со специалистами из разных стран.

Не можу погодитися, бо також маю досвід. А, можливо немає різниці сеньйорів єпама.

Хорошие и псевдо- Senior специалисты есть везде.

А, можливо немає різниці сеньйорів єпама.
Я смотрю для части читателей это служит мощнейшим оправданием: “это про другую компанию, у меня все иначе” :) Не обольщайтесь ;)

Очень правильная статья. Насколько я понял центральная идея этого всего — человек который понимает не только свою задачу и кусок кода,к ней относящийся, а и соседние куски кода, задачи, проект, его направление движения, возможные противоречия в самих задачах, потенциальные риски и достигает прозрачности для себя касательно всех этих уровней беря ответственность — это и есть must have привычки senior-специалиста. Работая не только в рамках своей песочницы а и удерживая в голове весь проект и процессы — минимизируются риски.

именно резиновая, именно это и есть ответственность

можно изощряться в словоблудии но суть-то не поменяется, задача чтобы на вас заработали c минимум рисков — сможете просоответсвовать — вот вам и грейд.

вы описали функциональные обязанности миддла. Конечно бывают разные компании и проекты и уровни ответственности разные.

что б клиент был доволен, методом делания работы, если клиент не доволен а вы довольны — вы не правы

мы говорим о синьерском подходе — в таких случаях чаще люди напрямую с клиентом решают вопросы.

Как по мне в статье неправильное используется термин Старший Специалист (Senior) и речь идёт о специалисте, ответственном за техническую сторону проекта, который не выполняет, а только дополняет роль ПМ-а.
Ведь должность Старший Специалист только говорит об уровне опыта, но не говорит о роли на проекте. Например есть простой проект, на котором Специалист (Middle) делает 80% объёма, а Старший Специалист привлекается только для нескольких задач. Тогда логичней сделать ответственным за проект Специалиста, который уже должен будет доносить до ПМ-а информацию о возможных проблемах технического характера.
Другой вопрос как растить ребят, готовых принять на себя ответственность за техническую сторону проекта, как минимум, за выполняемые ими задачи.

Роман, согласен, что трактование немного запутывает некоторых людей. И тем не менее в контексте Старший Специалист (Senior) мы говорим не только про опыт, нам важно что такой специалист будет понимать риски и ответственность за вверенную ему задачу.

Хотелось бы обсудить Вашу фразу:

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

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

Определение введено рынком и не только на просторах CIS. Я в прошлом разработчик и понимаю значимость изложенного в статье. Что касается вчерашнего студента, они не пройдут под требования enterprise клиентов.

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

Вчерашний студент не пройдет как минимум ни по академическим знаниям, ни по практическому опыту :)

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

я столкнулся с задачей за несколько месяцев создать команду и процессы по уровню эфективности с вебстудиями с 10летним стажем.

Сайты по-моему у всех одинаковые
на вид. внешне. да и по коду, если нажать ^U

«В ковре с утками не видать иглы, вышившей ковер» — китайская пословица

Просто опытным людям
...проще написать скипт, который сделает часть работы.

«Мудрость делает человека быстрее опытным , чем опытность мудрым»

О том и статья.
Обсуждение читаю почти сразу — получилось супер.

Кто понял суть статьи (с нюансами и я не согласен) — «ржет до коликов». там же и об этом написано. ну про несогласных.

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

вы как-то унижаете...
я столкнулся с задачей за несколько месяцев создать команду и процессы по уровню эфективности с вебстудиями с 10летним стажем.
ну и как? какие проблемы увидели и кто вам в команде понадобился? я на самом то деле неочень то кого-то хотел обидеть.
Сайты по-моему у всех одинаковые
на вид. внешне. да и по коду, если нажать ^U
«В ковре с утками не видать иглы, вышившей ковер» — китайская пословица
вот хотел бы услышать что вы имеете ввиду. вот специально глянул сайт эппл. навигационное меню сверху и снизу, слайдер, тексты, ссылки с картинками. Думаю там не будет ничего сильно необычного со стороны фронтэнда. Да у них есть аналитика, интеграции и очень много другого со стороны джаваскрипта но 95 процентов заказчиков не эппл и платить за это все будут не согласны
вот специально глянул сайт эппл
глянули сервер сайд?
Думаю там не будет ничего сильно необычного со стороны фронтэнда
да, ну ковер, ну утки на нем...
глянули сервер сайд?
а разве он показателен для веб студий? сайтов с подобной нагрузкой и проблематикой на самом то деле не много
да, ну ковер, ну утки на нем...
ничего не могу сказать. слаб я в коврово-утином искусстве

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

--- слаб я в коврово-утином искусстве
Пословица не о коврах и утках. И не об игле. А о недалекости ума, который видит результат и имеет весьма смутное знание о том как он был получен.

А о недалекости ума
грубо и некультурно. С технической стороны фронтэнд не сложный. точка. дизайн является продуктом творческим и направлен на создание привлекательного продукта. Если вы не согласны то прямые оскорбления предлагаю оставить при себе.
Пословица не о коврах и утках. И не об игле. А о недалекости ума, который видит результат и имеет весьма смутное знание о том как он был получен.
 я не творческий человек и далек от индустрии красоты, моды и стиля. Да не понимаю дизайнеры это делают и не считаю что это недостаток для меня как разработчика. Единственное что могу сказать что работал с неплохими ребятами
грубо и некультурно.
то есть вы не согласны что скажем у трехлетнего ребенка ум недалекий, в сравнении с человеком 20+?
С технической стороны фронтэнд
вот и я об том. да собственно и топик о том — синьор уже знает что чтобы достичь результата, технического(!) - нужны не только технические действия. «трехлетний» — этого еще не знает.
я не творческий человек и далек от индустрии красоты, моды и стиля.
я тоже.

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

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

но вот странно, смотришь на один сайт, и даже когда он не очень нравится — видишь что мышка дизайнера к нему приложилась.
смотришь на другой, удобный, и «дизайнера у них не было. хотя, ладно, не противен и функционален — и то хорошо. бывает еще хуже»

но я говорил не о дизайне и дизайнерах. а о команде создавшей сайт.

Если вы не согласны то прямые оскорбления предлагаю оставить при себе.
если вы не согласны с тем что не поняли о чем речь, а заметили только оскорбления — то можете так же остаться при своей недалекости :)
если вы не согласны с тем что не поняли о чем речь, а заметили только оскорбления — то можете так же остаться при своей недалекости :)
ух какие мы обидчивые. Ну простите был не прав, унизил вас абсолютно незаслужено
ух какие мы обидчивые.
????
грубо и некультурно.
...Если вы не согласны то прямые оскорбления предлагаю оставить при себе.
разве это была моя реакция, а не ваша?
унизил вас абсолютно незаслужено
????????????????????

точно ум трехлетнего, даже в общении. :)

Вчерашний студент может лабать сайты за 15 дней
вы как-то унижаете...
я столкнулся с задачей за несколько месяцев создать команду и процессы по уровню эфективности с вебстудиями с 10летним стажем.
философ-доминант-вебмастер должен простить 3х летнего

за что прощать?

обычно прощают за нанесенные обиды, или что-то подобное.

ЧТО мне такого сделал «3летний»? ничего.
так за ЧТО прощать?

Предлагаю закончить дискуссию потому что выслушивать ваши оскорбления я не хочу. Нуда хорошая мина при плохой игре

Предлагаю закончить дискуссию
ее не получилось :)

потому что вы решили оскорбиться.

у вас вполне получилось :D

Нуда хорошая мина при плохой игре
оскробление состоит из двух обязательных частей

создание одним и приятие другим.

я не помню такого своего мотива в ваш адрес, потому минимум мы не знакомы. не заметил и в свой адрес ничего от вас, даже если что там и было.

вы уже несколько раз отметили что оскроблены.

думайте сами в чем причина.
я не психотерапевт.

Да возможно я что-то не так понял. Конфликт исчерпан?

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

И ты тут подруга? Я надеялся это закончилось

єто вы считаете, что во фронтенде ничего сложного, а не я, наверное вы можете такой сайт за пол дня на коленке осилить : suissemania.ch Там же ничего сложного, правда ;)

та ладно, чего напрягаетесь-то?

я не напрягаюсь, я за справедливость и уважение.

С технической стороны фронтэнд не сложный. точка.
как и бекенд.
тоже мне сложность — наконфигурить CRUD поверх ORM

Увы, на данный момент мой опыт говорит что человек или ответственный, или нет. И это не зависит ни от опыта, ни от чего-то ещё. Причём видно эту ответственность во всём, начиная от банального «позвонить, если опаздываешь на встречу».

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

Интересно, вот допустим, Senior Software Engineer будет именно таким как Вы описываете, тогда возникает вполне логичный вопрос: а зачем, в таком случае, вообще нужны PM? Разработчик сам принимает решения, взвешивает риски и создает продукт, по сути задача PM сводится к лайканию котиков в фейсбуке с умным видом? Замечательная идея. Только давайте не забывать, что уровень компесации PM сейчас в основном не хуже чем у разрабочика и эту компенсацию нужно за что-то получать. Вряд ли лайкание котиков принесет компании много пользы.

Алексей, согласен, вопрос совершенно правомерный в контексте жесткого распределения обязанностей на проекте. И к подобному вопросу безусловно подталкивает форма изложения статьи. На самом деле речь идет не о распределении обязанностей, а о навыках, которыми должен обладать каждый уважающий себя высококвалифицированный специалист в любой отрасли. Роль проектного менеджера ни в коем случая не упраздняется, а конечный результат delivery точно становится лучше. Мы же всегда хотим чтобы каждый член нашей команды был ответственный, ориентированный на качественный результат и с конструктивным мышлением.

речь идет не о распределении обязанностей, а о навыках
я думаю что все же речь о штуке под затасканным терминами — проактивность, само-мотивированность(self-made mind), «осознанка», как обратная более употребляемому — «несознанка»

т.е. статья для тех, у кого сии штуки проявились («зубы прорезались», «стал клыки показывать»), но кто еще не понял что с ним случилось, и как это себе И другим на пользу употребить.

одним из вариантов подзаголовка я бы дал
как дорасти до синьора, и не стать д’Артаньяном.

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

ИМХО — толковые реперы обозначены.

Для ответа на этот вопрос необходимо написать такую же статью,но о менеджерах.

Буду думать над серией статей по всем роям :)

Если переделать статью из «сейчас расскажу вам что такое абстрактный сеньйор», в «История одного проекта. Программисты которые называются сеньйорами: ожидание и реальность» — то станет хорошая статья, и срач бы не зародился.
Спорить о понимании абстрактного термина сеньйористости не продуктивно; больше пользы говорить о сеньйоре в узком контексте (проекта или компании).

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

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

Данная статья показывает ваше нынешнее отношение, как менеджера, к специалистам и такой уровень я нахожу печальным, но таки да, я вижу, что у вас есть конкретные основания считать именно так. Но если вы действительно хотите изменить своё отношение и состояние дел внутри фирмы, а не продвигаете какие-то личные мотивы или корпоративные цели, то то.

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

У человека должна быть подходящая ему индивидуальная мотивация и отсутствие страха. Селекция дело небыстрое и кропотливое.

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

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

Люди не стремятся к переменам, не удаётся их переубедить сходу, а рубить головы не рационально? Возможно, стоит это компенсировать иными технологиями и инструментами, доступными на данный момент?

Senior Software Engineer — это специалист, который в состоянии разработать весь проект самостоятельно, в рамках своей и части смежных специализаций, если поставлена адекватная его профилю задача, выделены соответствующие поставленной задаче ресурсы и достигнуто взаимопонимание с руководством и заказчиком.

Смена менталитета и жизненных ценностей работника государством/корпорацией/начальником/супругом ведёт к последствиям, которые влияют на человека в целом, от чего после периода адаптации результат может быть отличным от того, на который рассчитывали.
Хотим сделать проход в стене? А не несущая ли она? А можно ли тут вообще трогать стены? Может проще здание новое построить?

Можно «радикального» технического специалиста сдвинуть в сторону повышения коммуникабельности, но чем в данном случае придётся пожертвовать?
А компенсируют ли ему такую перемену над собой, если нагрузка повысилась, а снизят ли требования к старым задачам с добавлением новых, если не будет компенсации?

Каждый человек в работе старается найти соответствие к его мировоззрению и зоны комфорта, приемлемей выдать эти задачи конкретному человеку, который уже ближе по необходимым параметрам не слишком нарушая глубину рабочего процесса, а потом, создав необходимые рычаги и остальных подтянуть, не забывая о том, чем жертвуем и ради чего. Ему, из-за его близости к «радикалам», будет легче найти общий язык, ибо он в достаточной степени «свой человек» и ближе к пониманию заказчика + не так сильно погружён в задачу, требующего умственного напряжения, располагающей обстановки для её решения и которым удовлетворятся все участники процесса.

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

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

Андрей, спасибо за столько детальный комментарий. Пройдусь по частям (если что упустил, поправьте меня):

Данная статья показывает ваше нынешнее отношение, как менеджера, к специалистам и такой уровень я нахожу печальным, но таки да, я вижу, что у вас есть конкретные основания считать именно так.
Не буду цитировать все, а то получается громоздкий ответ :) Вероятно, статья была воспринята через призму моей ненависти, отнюдь, я очень люблю людей и очень много вкладываюсь в их рост помимо моих непосредственных обязанностей. Можете спросить абсолютно любого человека, кто работал со мной на протяжении всего моего профессионального пути. Для примера на текущий момент в моей команде свыше 50 людей помимо своих непосредственных обязанностей вкладываются в развитие community и внутренних процессов, за счет которого растут они (по всем фронтам) и новые ребята и девочки.

Попробуйте рассмотреть предложенные рекомендации как мысли на подумать, а не критику. Буду рад разобрать каждый пункт, если в том есть необходимость (Skype: Dmytro_Zinoviev).

Современный сегмент IT индустрии далеко не пенсионного возраста, поэтому да, тут большинство мальчики и девочки :)

TL;DR заголовок не соответствует содержанию.

кто такой Senior Software Engineer
Это такой работник занимающий должность Senior Software Engineer. Его права и обязанности (должны быть) описаны в должностной инструкции компании/подразделения. Пожалуй все.

«Какими мы хотим видеть обязанности SSE в EPAM». Возможно как то так должна была называться эта статья.

Опять таки, автор за епам говорить не может, а максимум за свой unit.

Коллеги, сама тема Senior Software Engineer масштабнее одной компании. На рынке нет прецедентов когда один и тот же человек в топовых компаниях проходит на разные уровни (Junior, Middle, Senior, Manager, Director, etc.). Есть только небольшие погрешности, т.е. Middle в одной компании, который стал Senior в другой. Я могу утверждать за большую часть EPAM, и брать другие компании (SoftServe, GlobalLogic, Eleks, Intetics, Grid Dynamics, etc.) для примера. Тема появилась не просто так, это анализ рынка, общение с ключевыми специалистами и менеджерами других компаний.

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

На рынке нет прецедентов когда один и тот же человек в топовых компаниях проходит на разные уровни (Junior, Middle, Senior, Manager, Director, etc.).
Просто не хочет он обратно на зарплату джуна. Посидит такой пару лет и просится на мидла. Новому человеку долго въезжать да и искать головняк, вот и подымают. Потом на синьора таким же макаром. Потом сходит на собеседование к аналогичному спецу, получит аналогичный тайтл и уже сам себя убеждает что крут. До первого внятного собеседования. Там где чуть ответственнее подходят. И смотришь на синьора, а он бы мог на трэйни потянуть. Но не тянет — мотивации нет, задора. Привык сидеть на попе ровно — не оторвать... Только о таких собеседованиях он не расскажет, вот и прецедентов нет...

Виктор, все верно, такие прецеденты есть, а значит есть и профиль Senior специалиста которого хочется видеть (знания, навыки, ответственность, ориентация на качественный результат и т.д.), и цель здесь не увеличивать подобных бегунов по компаниям, а направить хороших специалистов по пути качественного профессионального роста.

Статья противоречивая.
Картинки мне жутко не понравились.

Обычное менеджерское завывание о том, что на разработчиков нельзя скинуть еще пару-тройку собственных задач. Вы еще полы после работы заставьте мыть в рамках ответственности за «общий результат».

Обычное менеджерское завывание о том, что на разработчиков нельзя скинуть еще пару-тройку собственных задач
Да, бытует такое мнение :) особенно среди молодых специалистов, и тем не менее последние хотят постоянный рост ЗП — где-то тут есть связь ;) Помним, что:
Оправдания — мощнейший инструмент людей, которые не добиваются результатов
Попробуйте предложить свои варианты решения, я с удовольствием их разберу и даже буду рад взять на вооружение.
Да, бытует такое мнение :) особенно среди молодых специалистов, и тем не менее последние хотят постоянный рост ЗП — где-то тут есть связь ;) Помним, что:
Да, бытует такое мнение среди хитрожопых менеджеров.

Нет у меня никакого своего мнения и его не может быть. Senior Software Engineer — это как видно из тайтла в первую очередь engineer, то есть технический специалист. Да, он опытный, но в тоже время он всего лишь технический специалист.

Те задачи, которые вы выше описали — это задачи Team lead’а или PM. Уровень зарплат сеньоров кстати никак не корректирует с влажными желаниями менеджмента сильнее его запрячь. Уровень зарплат — это рынок.

Senior — это большой шаг в профессиональном росте Software Engineer специалиста, к которому он идет дольше всего в своей профессиональной карьере. Lead — это всего лишь промежуточный этап и не заслуживает отдельного внимания. Senior уже на своем уровне может работать с командой над общей задачей.

Что касается комментариев:

бытует такое мнение среди хитрожопых менеджеров
больше похоже на травму, если так сложно сдерживать эмоции.
Уровень зарплат сеньоров кстати никак не корректирует с влажными желаниями менеджмента сильнее его запрячь
Очень спорный вопрос, и вариант решения не обязательно должен лежать в плоскости бегатни между компаниями.
Нет у меня никакого своего мнения и его не может быть
Интенсивность комментариев говорит об обратном.
Senior — это большой шаг в профессиональном росте Software Engineer специалиста, к которому он идет дольше всего в своей профессиональной карьере.
Это личное дело самого сеньора сколько он идет, как и что в итоге получается. Только рынок может оценить это.
Lead — это всего лишь промежуточный этап и не заслуживает отдельного внимания.
Заслуживает.
Senior уже на своем уровне может работать с командой над общей задачей.
Влажные мечты эффективных манагеров.
больше похоже на травму, если так сложно сдерживать эмоции.

У кого еще травма? У меня, написавшего пару комментариев или у вас, родившегося статью полную боли?
Очень спорный вопрос, и вариант решения не обязательно должен лежать в плоскости бегатни между компаниями.
Попытка демонтировать нормальные рыночные отношения.

Юрий, предлагаю вернуться к статье через некоторое время, исходя из Вашего богатого профессионального опыта на LinkedIn. Буду рад обсудить детали (Skype: Dmytro_Zinoviev).

Слабый менеджмент будет нанимать и растить слабых сеньоров.

Я не сторонник жалоб
объем текста говорит об обратном

Жалоба — это предложенная проблема без предложенных вариантов ее решения. В данном случает это ближе к Root Cause Analysis с несколькими вариантами решения.

Senior скажет: «Меня ограничивают!», а теперь побудим спросить его самого себя «Что я уже попытался сделать?»
Если вовлечен политический момент, то менеджер просто даст п***ов такому синьору который лезет к те вещи в которые ему нельзя лезть.
лезет к те вещи в которые ему нельзя лезть.
а тут надо понимать ситуацию

Крайности. Первая крайность — не делать ничего. Вторая крайность — партизанщина и отсутствие субординации. Если политический момент действительно критичен, хорошо если Senior это понимает (сумел извлечь необходимую информацию) и программировать ожидание молодой части своей команды. Чаще можно встретить обратное: Senior ничего не понял, обиделся на весь мир (генератор оправданий в такой момент зашкаливает) и начинает разлагать обстановку в команде.

программировать ожидание молодой части своей команды
) Это как ?

Если у Senior специалиста есть вопросы по проект, то у Junior и Middle специалистов в его команде на проекте они есть еще в большем объеме (из-за нехватки информации) или же нет и они скоро появятся. Senior посредник в этом информационном потоке.

А причем здесь

программировать ожидание
.Можете описать как это происходит?

К примеру продукт разрабатывается 5 лет. Ваша команда выросла до 15 специалистов, где вы тот самый Senior он же Key Developer. Компанию покупает другой более крупный холдинг. Начинается процесс интеграции длительностью до года. Ваши люди начинают роптать из-за непонимания происходящего, планов и где они будут дальше. Менеджмент вовлечен в тяжеловесный процесс. Задача Senior специалиста получить необходимую информацию по каждому срезу времени и донести до ведома людей ту информацию, которая сохранит их мотивацию — программируя их ожидания (чего они боятся и что для них важно).

Вы только что свалили на технического специалиста задачи менеджмента, который сопли где-то там жует.

Все верно, и такое мнение бытует :) Согласен, сваливать задачи менеджера на технического специалиста — грех. Снимаем с него эти обязанности. Забираем команду, потому что есть риски. Работаем в формате есть задача в Jira, пусть будет любезен выполнить и не роптать лишний раз. И вроде бы справедливость, а специалист стал еще более недоволен. Все таки есть тонка грань. Наверное схожа с гранью между Middle и Senior. Давайте уйдем от критических суждений и рассмотрим Ваши варианты :) с целью найти оптимальную стратегию.

Есть нормально описанная BA задача в Jira, выполнил её и нормально. Это правильный процесс. Никакой сеньор не будет обижаться на такое.

Девелоперы еще и рады будут. А то разленились, BA, бл**ь, не то что SRS, а даже user story им лень описать.

Ну так я про это и говорю. Есть процессы, только это ж надо манагерам попу отрывать от стула. А ой как не хочется.

Есть нормально описанная BA задача в Jira, выполнил её и нормально
Такие специалисты особо и не парятся Senior они или нет и могут работать в таком состоянии хоть все 20 лет. Те кого это волнует, хотят чтобы их слышали, им хочется влиять на Product Roadmap, хочется быть архитекторами, хочется чтобы остальные разработчики в команде прислушивались.

Что касается перечисленных навыков в статье, тут нет связи с конкретной позицией IT специалиста. Этими навыками должны обладать все: Engineer, BA, SA, PM, DM, RM, DevOps, DBA, Tester, etc.

Те кого это волнует, хотят чтобы их слышали, им хочется влиять на Product Roadmap, хочется быть архитекторами, хочется чтобы остальные разработчики в команде прислушивались.
Ну вообще мидлы и юниоры и так прислушиваются к сеньорам. Это как бы нормально.

Влиять на Product Roadmap?
Мне кажется, это плохая идея, когда исполнитель влияет на набор задач. Это как было бы если бы правительство влияло на парламент. Это нарушение принципа разделения властей.

Этими навыками должны обладать все: Engineer, BA, SA, PM, DM, RM, DevOps, DBA, Tester, etc.
Пока вы будете набирать команду, где такими навыками обладают все, вас обойдут на рынке команды, где зоны ответственности четко поделены.
Мне кажется, это плохая идея, когда исполнитель влияет на набор задач.
как вы относитесь к покраске травы, например?
или покраске стены — но во время пожара?

А какая мне разница? Я своё мнение озвучу, если покраска стен кажется владельцам здания важнее, то пусть платят, я покрашу.

А какая мне разница?
то есть, вам безразлично.
а небезразличие других, по-вашему
плохая идея, когда исполнитель влияет на набор задач
?

откуда такая категоричность?

Мне не безразлично, это просто не моя зона ответственности. Человек, который занимается приоритезацией задач знаком с состоянием рынка и обладает большими знаниями, что нужно рынку.

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

Человек, который занимается приоритезацией задач знаком с состоянием рынка и обладает большими знаниями, что нужно рынку.
только вот приоретиты в самой разработке обычно не совпадают с приоритетами рынка.
и если технический специалист не донес до «знатока рынка» эту информацию, отказался от планирования работ, то будет он и команда переделывать фундамент когда закончен пентхаус.

и потом начинается страшный вой.

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

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

для — выбора стратегии: убухать все средства на покупку лотерейных билетов.

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

В разработке будет куча аналогичных ситуаций, если разработчики будет на роадмап влиять
ой. да. ну. ладно.

вы различаете «влиять на» и «игнорировать»?

А как вы отнесетесь к тому, что вы попросили полы поменять, а вам стены покрасили, потому что исполнителю это интересней?
Скорее вы попросили полы поменять, а исполнитель вам объясняет, что в текущей ситуации логичнее было бы начать со стен — дешевле/быстрее/больше импакт с его технической точки зрения. А дальше уже вместе приходите к консенсусу и исполнитель красит то, что решили.
Пока вы будете набирать команду, где такими навыками обладают все
А в чем уникальность качеств: результат, качество, ответственность и других? Какие из них нужно разделять? Разве мы приемлем безответственного программиста недописывающего некачественный код? :)

Проблема в коллективной ответственности за результат, которую вы продвигаете. Это не работает.

Юрий, фраза:

Это не работает
не менее громкая, чем статья :)

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

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

На лицо отсутствие опыта работы с большой командой в кризисной ситуации :) Если бы все специалисты получали прямой feedback от конечного клиента или руководителя компании, волна суицид захлестнула бы IT ;)

Что вы тогда хотите от других? Если пропагандируете обман и перекладываете ответственность на других. Никакие правила тут не помогут.

Я хочу чтобы каждый был компетентным специалистом в рамках той роли, которую он занимает :)

Касательно фразы:

пропагандируете обман и перекладываете ответственность на других
Откуда эта крайность? То есть стать программисту чуть ответственней за свой код это нонсенс?

Все резкие высказывания связаны с найденной связью между статьей и читателем. Можем разобрать конкретно Ваш случай и найти варианты решения (в очередной раз, мой Skype: Dmytro_Zinoviev).

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

и то что по вашему они должны делать.

Задача Senior
программируя их ожидания
Откуда эта крайность?
На основе Вашего примера. Который состоит из перекладывания ответственности и обмана

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

Не хотел Вас обидеть. Если что
Ни в коем случае :) Просто хочу свести диалог в конструктивное русло. Возможно вы имеете насыщенный опыт работы и Вам есть чем поделиться, что можно было бы рассмотреть и обсудить как case.

Потому что надо четко объяснить проблему, а то насмотрелись подковерной борьбы в украинской политике и туда же.

Senior — в первую очередь козел отпущения и в последнюю — разработчик. Даже если девелоперы со стороны заказчика в последний день перед деплоем полезли в код и все поломали, все равно он виноват.

Результат — как горизонт, по факту достичь его нельзя, потому что он не выражается в количественных критериях. Make customer happy — прекрасная формулировка.
Пример (отзыв с AppStore): «Игра — хорошая, но я уронил свой iPhone в ванну, он стал глючить, поэтому 4».

Секретарша — слать отчеты, письма, переписка, занимает уйму времени, а трекать его некуда, чаще всего размазывается по таскам, в итоге сравнительная производительность страдает.

BA — понимать желания заказчика из 3-х букв (в лучшем случае слов). Например: «Integrate YYY», где YYY — название стороннего тула. И тут же готов дать точный эстимейт в часах.

Та ладно — у него есть еще шанс спихнуть проблему еще на кого-то помельче.

Объективно козлами отпущения можно сделать каждого, от Junior до CTO.

Что касается «результата», для Senior фраза «Make customer happy» должна декомпозироваться на конкретные шаги (он не Junior, которому может не хватать опыта): наладить канал обратной связи, определить KPI, проверить список задач и уточнить детали, оценить задачи, проверить требования, создать или описать инфраструктуру или архитектуру, подобрать или подготовить команду, создать процессы способствующие качественной разработке по необходимости (CI/CD, testing, code review, etc.), подключение необходимых инструментов (Ant, Maven, Lint, etc.) и разворачивание рабочей среды, приоритизировать задачи для первых спринтов, обсудить с командой, стартовать работу, контроль разработки, демо и т.д.

Если Senior специалиста приходится самостоятельно дергать и объяснять, то есть сомнения в его Seniority.

А его зарплата увеличивается на величину зарплаты PM после таких подвигов?

на самом деле можно вычеркнуть

наладить канал обратной связи
определить KPI
проверить список задач и уточнить детали
приоритизировать задачи для первых спринтов
Не видел пока, чтобы сеньоры подобное делали.
создать процессы способствующие качественной разработке по необходимости (CI/CD, testing, code review, etc.)
да это тоже как-то необязательно. Выбирать софт и хард для серверов разработчики не обязаны ровно как и настраивать весь стек. И это не говоря уже о процессе тестирования. С таким успехом разработчик должен обладать еще квалификацией в сетях и железе на уровне CCNP причем хотя бы 3х направлений сразу

Так никто и не обязывает, не хочешь — не берешься. Просто остаемся посредственным разработчиком.

Ну это как я понимаю у вас люди берутся за работу в которой не компетентны и что-то идет не так? CCNP это вообще-то не высшая квалификация а настоящие профи стоят денег и учатся годами

Пример с CCNP это утрирование ;) не стоит перекручивать общую картину, чтобы оправдать чьи-то поступки :)

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

Выходит и швец, и жнец, и на дуде игрец. Только вот возникает вопрос, зачем еще иметь кучу других должностей, если синьор может все сам?

Только вот возникает вопрос, зачем еще иметь кучу других должностей, если синьор может все сам?

Маржа у галеры больше :)

Мне лично тоже это не нравится, но тем не менее за ежедневное решение именно таких проблем в западных компаниях дают звание Senior.
Да, куча вопросов не относятся к коду. Да, производительность труда падает. Да, от сениоров хотят естимейтов и т.п. но если хочешь 200к — подстраивайся.

Все верно, бизнесу нужна прибыль и технические навыки становятся мощным подспорьем и козырем, а не единственным инструментом труда.

Вот это замечательно:

Оправдания — мощнейший инструмент людей, которые не добиваются результатов.

1)

за 10 лет в IT-индустрии я прошел путь от молодого разработчика до руководителя направления

2)

Менеджменту нужны люди для роста продукта, проекта или организации (карьеристы не в счет)

Улыбнуло :)

Правило № 5: результат труда должен простоять не один год.

Еще раз улыбнуло. (В контексте первой цитаты)

Очередные сказки. Реальность к сожалению очень далека.

Мысль на подумать: «Два человека закончили ВУЗ и имеют общую базу и фундамент для роста. Один через 10-15 лет руководит крупной компанией или продуктом. Второй остается простым разработчиком последующие 10-15 лет. Где кроется проблема?». Причина видимо не в том, что у одного реальности было меньше чем у другого ;)

Проблемы, как таковой, может и не быть.

«В огороде бузина»...В условии задачи вы не указали, что оба человека стремятся к карьерному росту или даже к карьерному росту любой ценой. Билл Гейтс вообще бросил ВУЗ и стал миллиардером, может и нам тоже стоило ?

Причина в том, что один сидел на одном и том жеиместе и думал о продукте, строил на века, пытался улучшить процессы, а второму было насрать на качество продукта, он рисовал красивые репорты и прыгал каждый год в другую контору, напуская вида и завышая свою стоимость на собеседованиях :)

Причина в том, что один сидел на одном и том жеиместе и думал о продукте, строил на века, пытался улучшить процессы
Это крайность, хороший специалист просто делает качественный результат, а не сидит 5 лет на одном месте с чувством собственного достоинства, что он привносит какой-то вклад. Чаще это иллюзия, которая разбивается о «камни», как только специалист вынужден менять проект или компанию.
а второму было насрать на качество продукта, он рисовал красивые репорты и прыгал каждый год в другую контору, напуская вида и завышая свою стоимость на собеседованиях
Вторая крайность. Я наблюдал свыше десятка прецедентов, когда подобная стратегия разрушалась спустя года три. IT рынок как маленькая итальянская семейка, плохую репутацию сложно отмыть :)

В рамках бодишопа, типа EPAM Poland второй — самый выигрышный вариант. Главное — правильно репортить кастомеру и всегда прикрывать свой зад письмами от вышестоящих менеджеров. И никакого личного мнения по поводу проекта и процессов не озвучивать в письменном виде. Мы же профессионалы, высказываться только о том, что просит менеджер и оплачивает кастомер. Ну и отсиживать 8 часов, потому что кастомер платит бодишопу за человеко-часы.
А потом на ревью через год зарежут повышение, или же повысят на символические 100$. И выход один: менять работу. Так что через год прыгать на новое место работы — лучший вариант, если не предполагается карьерного роста внутри бодишопа, что бывает нечасто

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

Целиком согласен. Пример приведенный выше для специалистов, которые находятся в фазе постоянного профессионального роста, что выводит человека на уровень более сложных задач. Те, кто находиться в этих 70%, не должны резко реагировать на статью, у них пока и так все хорошо. Негодование в комментариях провоцируется желанием быть Senior и оставаться в группе 70% :) И пока человек не признается себе в самообмане, он будет писать громкие комментарии о несправедливости бытия и постоянном ущимлении, коего вовсе нет ;)

Не могу. Senior — это не просто позиция в контексте какой-то компании, это уровень компетентностей, которые позволяют решать комплексные задачи. Рынок хочет видеть (и платить хорошую ЗП) именно компетентному Senior, а не подобию специалиста.

Так я не только свое мнение или мнение одной компании высказываю. Я не хочу заводить диалог в глухой «угол» и тем более кого-то обидеть. У Вас большой опыт судя по LinkedIn, могу я узнать приходится ли Вам по роду ваших занятий работать и руководить разработкой большой команды с сбалансированной пирамидой Seniority?

Согласен с вами -навязывание «Лидерства» для работников — что каждый должен быть свадебным генералом или стремиться к этому- это прерогатива относительно небольших компаний. Но разделение труда намного эффективнее для большого бизнеса и для людей..

Для чого водяться люди з тайтлами типу «Software Architect»?

Для того чтобы систему проектировать, но реальность такова, что это требуют большие проекты

маю на увазі не взагалі, а в конесті статті: від сейньора вимагають відповідальності при тому щоб він виконував купу обовязків (від бізнес аналізу до проектування системи та розподілу задач на команду). Виходить описаний сейньор для маленького проекту/стартапу але при цьому використовується купа слів з «великих проектів» (

Project Manager, Project Coordinator, Scrum Master, Risk Management, Change Management, Release Management, Requirements Gathering, Planning, Estimation
). Відповідно не дуже зрозуміло чому сейньора роблять «козлом отпущения».

мабуть доцільно ввести додаткову градацію. Типу Big Co Senior, Startup Senior ітп.

Многа букофф; с четырьмя правилами согласен на 100%, но вот это: «Правило № 3: хороший проект — проект сделанный своими руками» вызывает недопонимание. Если это попытка перефразировать Порше — «Если хочешь сделать что-то хорошо, сделай это сам» — ну дапустим... Если надо понимать в лоб — давно неправда. И у самого синьора за 10 лет, и у коллег, и в компании вообще есть куча наработок и опытных товарищей, которые возможно уже сталкивались с подобной проблемой. Есть наверняка 3-party решения, которым ты доверяешь, и не использовать тэкскэть коллективный разум во имя пардон тренировок самостоятельности — ?! а как же правило 4-е? 50-ю процентами софт-и-менеджерских скилзов синьор-то должен понимать, где место самостоятельным решениям, а где оно должно быть обязательно согласовано с заказчиком, ПМ-ом, непосредственным исполнителем и др. стейкхолдерами.
Т.е. я бы сказал «...нужно много действовать», а вот слово «самостоятельно» тут ИМХО не вполне подходит; скорее: «действовать, в том числе что-то делать самому, а не только говорить» :)

Спасибо за комментарий, соглашусь с утверждением:

действовать, в том числе что-то делать самому, а не только говорить
Цель статьи — подтолкнуть к самостоятельности, а не ожидать, что кто-то всегда будет водить за ручку. Senior не должен все время ждать указаний, он достаточно опытный чтобы самостоятельно решать ситуации и поставленные или возникшие задачи.
достаточно опытный чтобы самостоятельно решать
см. «микроменеджмент».

ЗЫ: даже на ДОУ уже есть ничосси 10 лет как!
dou.ua/...es/micromanagement-hurts

Все верно, речь как раз и идет об уходе от микроменеджмента и появление самостоятельных специалистов

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

senior software engineer/developer это всего лишь зарплатная градация.
обычно под этим понимают опытного разработчика (более 3-х лет, хотя тут нет жестких критериев), знакомого с полным циклом разработки, и способного выполнять некоторые административные задачи кроме сугубо технических.
мне как представителю данной касты пожирателей дорогого сыра, приходилось заниматься время от времени вот этим: (это не исчерпывающий список)
-уточнение требований от заказчика, частичная работа бизнес-аналитика (на проекте где они не предусмотрены штатом)
-планирование итераций в скраме
-code review
-демо-сессии для кастомеров
-продакшн деплоймент, от планирования до физической реализации
-саппорт (L3)
в принципе любой разработчик может делать все вышеописанное, но особо критичные задачи (кодинг к ним обычно не относится) лучше если выполнит синьор. например анализ особо критичных или непонятных багов.
а вообще хороший синьор умеет делегировать задачи другим членам команды. и со спокойной совестью идет играть в теннис :-)

программирование — малая часть айсберга под названием «разработка программного обеспечения»
тот кто это понимает, уже может считать себя синьором . или находится на пути к seniority

Должностные обязанности можно увидеть в хорошем описании вакансии на проект или в компанию. Проблем больше относится к delivery конечных решений, которыми занимается высококвалифицированный специалист. Senior — это лишь должность (метрики для которой могут варьироваться от компании к компании) и не несет в себе конечного места прибывания. Дальше Senior хочет большего: Lead/Chief/Solution Architect позицию и принимать участие в более масштабных задачах, relocation в известную продуктовую компанию и т.д. Он может быть вечно классным Senior, но как Вы и сказали выше это лишь зарплатная градация, и не стоит ожидать большего, если на большее ты не подходишь.

к delivery конечных решений, которыми занимается высококвалифицированный специалист
Это не так delivery должен заниматься процесс см. обратно «микроменеджмент» оттуда все уши торчат.
метрики для которой могут варьироваться от компании к компании
Это не так то что всякая компания включая отдельные проекты большого бодишопа «додумывает своё мнение в метриках синьора» см. обратно «микроменеджмент» оттуда все уши торчат. «Я насяльника». (к) (тм)
может быть вечно классным Senior, но как Вы и сказали выше это лишь зарплатная градация
Обратно таки не так это градация конкретно должностных обязанностей уровня принятия решений и ответственности под которой традиционный отечественный насяльника понимает именно с позиции каким образом насяльника стал он сам но на самом деле это не так исходя а) из эффекта Даннинга-Крюгера; б) из неудачных попыток описать этот и подвести базу под необходимость повышения уровня компетенции но неудачных именно в том что всё сводится к замыканию всё того же эффекта на себе самом исходя из некомпетенции личной и основываясь исключительно на «Я насяльника». (к) (тм)

ЗЫ: последнее не следует считать строго отечественным изобретением либо «наследием совка» либо чем-либо ещё уникальным исключительно для советского народа это не так это довольно популярно везде включая аж самые Развитые Страны Запады кстати одна из причин их любви к атсорсингу как отличнейшей возможности конкретным индивидам таки реализовать то самое личное «Я насяльника». (к) (тм)

Спасибо за комментарий ) Согласен касательно совка, внесли правку в статью.

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

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

Это все хорошо, но код существует не в вакууме. Он решает конкретные бизнес-проблемы, и хорошо бы уметь транслировать «бизнес-пожелания» в код, минуя 100500 прокси. Типа «нам надо вот это» — «не, так не получится, но если вот так — то можно» — «это не совсем то, а можно тогда еще как-то так» — «да, это вообще без проблем» — желательно в рамках одного разговора, без десятков часов проведенных на исследования, когда менеджеры перепуганные носятся и не знают обернется это потерей времени или все будет хорошо. Для этого в голову надо засунуть иногда просто очень много всякой domain-specific нетехнической лабуды, и это то о чем мечтают компании когда описывают «идеальных синьйоров».

При этом идеал — идеалом, но это вовсе не обязательно. Можно и без этого, процессы в основном поставлены так чтобы можно было без идеалов обойтись. Но если попадается — будут юзать по полной, потому что всякие межведомственные бриджевания сильно упрощают жизнь.

Но есть проблема: за пределами не то что конкретной компании, а даже за пределами проекта(если смотреть на аутсорс), с точки зрения дальнейшего трудоустройства, это имеет нулевую ценность. Когда вы попадаете на собеседование в другую компанию, вопрос «расскажите про прошлый опыт работы» — формальный, чисто для начала разговора, и всех в основном интересует пересечение стека технологий, а не то как вы круто договаривались. А дальше будет час допроса, с которым не так просто справится если голова на половину забита domain-specific лабудой.

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

Спасибо за обильный и интересный комментарий. Теперь последовательно (скажите если что-то упустил):

1. Проблема избыточных посредников для небольших изменений. От куда берутся корни? Специалисты часто (всегда) уверены на 100%, что технические изменения принесут только пользу. Сама же проблема всплывает, когда данные изменения повлияли на производственную среду и привели к издержкам и штрафам со стороны вендора или продукта. Такой fail подрывает кредит доверия. Часто бывает, что один нелепый псевдо-Senior года два назад испортил репутацию программистов на проекте и все изменения проходят все круги ада до конечной реализации. Ситуация как по мне прозрачна (поправьте меня если я не прав). То что мир полон проблем мы все прекрасно информированны. Давайте подумаем над решениями: (1) восстановить кредит доверия и лично нести ответственность за принятые решения, (2) находить людей, которые в прави принимать такие решения, и не тратить время на людей, кто этими полномочиями не наделен (хотябы минимизировать), (3) организовывать митинги в конструктивном ключе и уметь их вести, а не превращать на балаган и т.д. Все это рабочие схемы, которые абстрагировали руководящие посты от принятия технических решений. Это то что ценится от профессионала.

2. Формуликовка:

Поведешься на булщит про бизнес и софт скиллс — за пределами конкретного проекта будешь неинтересен даже той же компании, которая этот булщит тебе на уши навесила.
Безусловно технический аспект критически важен, и будет важен всегда. И чем дальше, тем знания должны быть глубже и шире в той отрасли с которой вы работаете. Что касается бизнеса — он оплачивает вашу комфортную жизнь, нет бизнеса — вы просто IT бомж (так же как компания котороя не приносит доход — благотворительная организация). Не думаю что спрос на IT был столь бы большим до сих пор. Вопрос с Soft Skills всегда актуален, развитие этих навыков требуется для решения множества вопросов, например: (1) успешно пройти собеседование в компанию или проект, которые вам нравятся (есть множество случаев когда матерые технари месяцами проваливали интервью, по причине что конечный работодатель или клиент не видел в них этой матерости, у него нет как у нас опыта работы с этим человеком), (2) обьяснить команде в 20 человек (где до этого момента был другой Tech Lead) мочему мы ложны сейчас поменять ряд процессов и ввести определенные правила, обьяснить так, чтобы люди это действительно использовали, (3) отстоять свое мнение в переговорах с руководством или клиентом (хотябы на ту же тему, что вы готовы взять на себя ответственность за принятия решений, на основании ваших прошлых достижений, и хотите получить полномочия) и т.д.

Мир слишком динамичен и есть варианты: (1) двигаться и оставаться на месте или (2) бежать и двигаться вперед.


1. Проблема избыточных посредников для небольших изменений. От куда берутся корни?

Извиняюсь если не точно сформулировал. Проекты в наших реалиях часто строятся вокруг/с учетом посредников. В основном по естественным причинам: сидеть с людьми «с той стороны» на одном аудио или даже видео-звонке, или в одном чате — это не тоже самое что сидеть с ними же в одной комнате. Хотя бы потому что в одной комнате в обсуждении может принимать участие вся команда, без особых трудностей, если перенести это в телефон — 10 одновременно разговаривающих друг с другом людей — это каша. Плюс трудности с языком. Плюс, иногда, всякие варианты неравенства, когда мнение джуна «там» авторитетней мнения синьйора «здесь». Поэтому административным(специально назначенный ПМ, например, или тим лид) или естественным(кто-то из команды, кому больше всех надо) путем появляются посредники, через которых по-сути и происходит 70+ % общения. Причем роль посредника — это прежде всего нормально говорить/нормально доносить информацию до обоих сторон. (Да, есть варианты без посредников, признаться, не видел удачных, видел несколько неудачных).

Эта схема, by design, устроена так, что даже в самых фиговых вариантах: e.g. команда читает по английски через google translate, ПМ — студент(ка)-филолог последнего курса — все-равно остаются шансы на успех предприятия. А вот если в качестве одного из тех самых посредников оказывается технарь с продуктовыми знаниями — это может сгладить много углов и ускорить движения, даже в рамках тех же самых процессов(в том числе и за счет перечисленных вами пунктов: доверие, правильные контакты, возможность выдать сию минуту любого уровня инсайт по состоянию задач). В этом варианте есть и минусы(например, человек вовлеченный в процесс не может быть всегда 100% адекватным в его обсуждении), но плюсов часто сильно больше, поэтому если есть возможность — пользуются. И поскольку один-два таких примера точно на компанию наберется(а скорее всего гораздо больше), то смотря на такие success stories и рисуют образы идеальных синьйоров, квалифицированных технических специалистов, которых всегда не хватает, итп.

Ну и как я уже сказал: это создает определенные трудности для того кто в это влезет. Потому что 1) ты все равно остаешься всего лишь разработчиком, и рост дальше/в стороны, несколько не выгоден самой компании: ты интересен как раз совмещением hard и soft навыков, сложно и не быстро заменить: новому специалисту придется долго въезжать в предметную область, даже если он это захочет делать. 2) если у тебя 50/50 hard/soft, то это таки значит что на следующем собеседовании будет представлена только половина синьйора, та которая hard. на soft навыки не собеседуют, да и собсно: то что получилось в прошлой компании, не факт что получится в этой, кот в мешке. А так код хотя бы писать сможешь :)

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

Очень субъективное мнение.

Буду рад услышать детали по вопросу субъективности, так как работаю с огромным количеством людей и непосредственно сталкиваюсь с проблемами нашего рынка.

Причина в том, что исполнитель, потративший последние 5-7 лет своей жизни, чтобы занять должность Senior, не смог осознать, что с каждой ролью у него появлялись новые обязанности — большей степени не технического, а организационного характера
Нет, что Senior Software Engineer, что просто Software Engineer — люди, работающие за зарплату, чей контракт может быть терминирован за 1 день. И в их обязанности руководящие задачи не включены, и прав руководящих у них нет (поэтому никто его и не услышал). Поэтому в целом, им хоть и не должно быть насрать на проект (всё-таки если провалится — то точно новую работу искать, а так может быть и нет), но рвать ж*пу и пытаться донести истину до неслышащего руководства тоже не обязаны.

Рвать пятую точку — это крайность, которой можно оправдать непрофессионализм. Не стоит такого специалиста называть Senior, давайте оставим ему должность простого Software Engineer, который делает свою работу хорошо и не выходит за рамки, по причине незрелости.

А что по-вашему должен делать профессионал, я не понимаю? Ты сказал, тебя проигнорировали. Что дальше? Если нет права принятия решений или решение «вне твоей юрисдикции».

Профессионал должен уметь довести задачу до заключительной точки. Такой точкой может быть не только: «нам удалось поменять все устои и архитектуру устаревшего программного продукта», но и варианты: (1) формализовать процессы и подготовить достойную замену, чтобы спокойно выйти из проекта, (2) найти альтернативные способы эскалации, чтобы сообщить о надвигающихся рисках и возможных вариантов, (3) взять на себя ответственность за решение проблемы и проинформировать всех для прозрачности процесса, (4) сделать что-то самостоятельно и прийти с готовым решением, (5) подумать что не хватает, чтобы твое решение купили в эмоциональном плане (подумать над местами где ты упускаешь прозрачность выгоды твоего предложения) и т.д. Я слышу эту фразу очень часто: «это не в моей юрисдикции», и всегда находится выход. Я за свою карьеру только и сталкивался с задачами, которые не были в моей юрисдикции или стратегиями развития, которые не были никому интересны. Всегда есть множество вариантов развития ситуации, но мы часто ограничиваем себя лишь удобной фразой, которая снимает с нас ответственность. Сам вопрос достаточно абстрактный, мы можем детальней разобрать конкретную проблему (мой Skype: Dmytro Zinoviev).

А как быть с «заказчик сказал суслики — значит суслики»? Как перебороть? К примеру — есть банковская секурити — и все тут — девелопить придется в ее рамках.

Не совсем понятно за что именно его уволили.

Крайность. «Взять ответственность на себя» требует навыков и дипломатии. Речь не о прямой финансовой ответственности. Если человек хочет реализовать задуманное и считает, что это привнесет пользу продукту, то он должен заручиться поддержкой ключевых людей. Тут нет места эмоциям (героизму), это хладнокровный расчет. Change Management — хорошая тема для новой статьи.

Так про это и речь. И чем специалист компетентнее, тем здравый смысл преобладает над эмоциями (полезный навык — en.wikipedia.org/...i/Emotional_intelligence.

Подобные высказывания требуют доказательства
Предположим есть клиент, на проекте работает команда, специалист уровня Senior играет ключевую роль. Его опыт и результаты труда дают некую гарантию встретить обозначенный deadline. Случается форс мажор, например: очередная версия продукта падает в production у одного из клиентов. Специалист об этом был в курсе и сообщал, но видимо его замечания небыли услышаны. Пошла волна эскалаций, в ней варятся весь менеджерский состав (и поверьте там не сладко). Теперь варианты исхода для эмоционального и конструктивного Senior специалиста. Эмоциональный: «меня это все достало! я же говорил! го..но-проект, я увольняюсь!» (реальный пример). Конструктивный: пишет RCA, пользуясь ситуацией меняет процесс коммуникации и вес своего слова как технического специалиста на всем проекте во избежания подобных проблем в будущем (реальный пример). С кем бы вы хотели работать в команде? Позволю предположить не с истеричкой :) Конструктив появляется не по причине постоянных соскоков с ответственности, а на основании каких-то реальных достижений.
Имхо компетентность и эмоциональность — ортогональные понятия.
В контексте результата оба понятия играют роль.
Именно по этому я минимально пользуюсь всмякими Скайпами и т.п., где позволено устное общение и предпочитаю почту.
Это здорово, полностью поддерживаю.
Даже, если ты прекрасно видишь, к чему приведет очередной заскок манагера, то лучше подождать того момента, когда он отгребет по полной и только после этого предлагать уже что-то.
Согласитесь, что это звучит ужасно? Хотя и в такой ситуации можно прийти к решению проблемы до того как она появится. Да, то факт что проблема миновала, и никто ее даже не заметил, это может кого-то демотивировать, но в этом и кроется профессионализм.
Часто первым отрубают голову тому, кто принес плохую весть.
Если бы отрубали, Вы бы уже давно просто поставили like этой статье, т.к. она как раз нацелена на качественный delivery.
Нет, конечно можно верить, что менеджеры какают бабочками и летают на единорогах, но по факту это обычные люди, причем куча из них не справляется с «медными трубами» и действует по принципу «я начальник, ты дурак».
Как и в ситуации с разработчиками, это касается любой роли.
Факт в том, что если ты порешаешь проблему после скандала, то с большой вероятностью тебе и зарплату подымут и разные другие плюшки будут. А вот если зараненее и тихо, то тебя просто не заметят, а вот манагеру, которого ты спас будут плюшки.
В итоге мы приходим к ситуациям, когда специалист скачет с проекта на проект, из компании в компанию и хает всех, лишь бы только не признавать, что он не смог ничего добиться и довести до результата. В какой-то момент это вызывает подозрение. И совсем не обязательно, что за этот период он приумножил свою ЗП.

Пожалуй дальше обсуждать бессмысленно, картина в корне все равно не изменится. Спасибо за высказанную точку зрения :)

Специалист об этом был в курсе и сообщал, но видимо его замечания небыли услышаны... Теперь варианты исхода для эмоционального и конструктивного Senior специалиста. С кем бы вы хотели работать в команде?

Другой вопрос: вы бы предпочли чтобы эмоциональный Senior зашел с ноги на самый-последний-митинг-перед-релизом, на котором принято весело кивать, держа в кармане скрещенные пальцы, с воплями «тут все понимают шо это го..но завалится?». Тем самым возможно подставив того кто «не услышал» замечаний, но остановив заранее обреченное предприятие. Или все-таки пусть «конструктивный» пост-фактум что-то предлагает, спокойнее. Не так однозначно, да? Но...

Конструктив появляется не по причине постоянных соскоков с ответственности, а на основании каких-то реальных достижений.
такой «эмоциональный конструктив» вы таки в достижения не запишите. :-) Хотя ваша жо..а будет относительно спасена(решение проблемы можно перенести в конструктивное русло), и единственный кто себе испортит карму в компании — будет тот самый Senior, который таки сделал все чтобы донести информацию до нужных ушей.
Senior скажет: «Меня ограничивают!», а теперь побудим спросить его самого себя «Что я уже попытался сделать?».
и
он должен заручиться поддержкой ключевых людей.

я бы так устранил рационально кажущееся противоречие (менеджмент полон иррациональных моментов, которые не получается формализовать и в книгах от метров):

Senior должен постараться заручиться поддержкой ключевых людей.
потому что без этой поддержки, все его усилия по реализации «Что я уже попытался сделать?» пойдут прахом. хотя, себе, конечно он навык приобретет.

Бытовая аналогия — когда человек потерял доверие, что он не делает, в глазах тех кто ему не доверяет это все выглядит плохим, неправильным — «хитрит, прикидывается! знаем мы его суть!»

Когда Мидл дорастает до Синьора, и начинает брать описываемую ответственность — он вполне может столкнуться с обстоятельствами в виде отсутствия поддержки, даже просто понимания «ключевых людей».
и тогда, происходит обычнейшее дело — Мидл уходит в другую компанию, где не знают истории его становления, и не отягощены восприятием его как мидла.

впрочем, так и с джунами. Они правда часто ориентированы всего лишь на увеличение ЗП. но «почему-то» частенько могут ее увеличить только уйдя в другую компанию.
а потом начинаются менеджерские жалобы — не хотим тратиться на взращивание джунов, они потом уходят...

то есть

В НЛП есть понятия фрейминга — рамок, определяющих позиции восприятия.
применимо и с самим ключевым фигурам :)
Ты сказал, тебя проигнорировали.
у меня было один раз было такое. в итоге пошел всех теребить о рисках. в итоге деливери таймлайн был увеличен, и получил в итоге от всех заинтересованных сторон со стороны клиента письма что они знают о рисках.

а теперь на секунды, как вы думаете что бы было, если бы я не говорил о рисках по окончанию естимейта?

Ну это хорошо, что вы говорили. Для проекта, наверное для вас. Но вы не обязаны были.

С одной стороны да, а с другой стороны, не все обязанности можно четко прописать и предусмотреть. Иногда возникают ситуации, когда надо садиться и разруливать, обсуждать, что-то менять или наоборот, не давать менять. Можно самоустраниться, но выгребать в итоге придется всем.

Я против перевода желательного в обязательное и соотеветсвенно против статей, которые это пропагандируют. Вот, сеньор обязательно должен всех на уши поднять. А я говорю не должен. Да, желательно. Да, большинство это сделает, так как сложно вообще относиться к работе пофигистически. Но никто никому не должен.
В конце-концов, а чем тогда должен заниматься архитектор или техлид? Продакт овнер, пмы? Зачем тогда куча должностей, если оказывается должен всем сеньор?

Так никто не говорит об обязательном. От размеры команды и заказчика сильно зависит. Если есть отдельный архитектор и т.д., большая доля ответственности на них.

Да, большинство это сделает, так как сложно вообще относиться к работе пофигистически
Вот это тоже вполне себе признак профессионализма. Не обязательно сеньорности, но умение вовремя включиться и взять на себя ответственность ого как важно

Вот кстати да, несколько раз было похожее. Плюс масштабирование команды и работа с ожиданиями клиента.

что бы было, если бы я не говорил
Практика показывает чаще всего ничего.

Спорно, это «ничего» часто конвертируется в: регрессии, проблемы спустя год-два, выпуск пакетов «hot fix», штрафы, испорченная репутация и т.д.

Практика показывает что ели «пошёл теребить» не есть лицо прямо облечённое властью принять решение о рисках то успешность кейза следует относить к случайности конкретных обстоятельств в более же общем случае существует целый ряд других рисков так или иначе не учтённых «лицами прямо облечёнными властью принять решение» и решение «продлить таймлайн» принятое на основание «чужого теребления» просто покрывает их именно в случайном порядке но чаще таки не покрывает именно в виду нарастающей энтропии «о таймлайн продлили всё чуваки выдыхаем наш факап не заметят пошли пиво пить» (к) (тм) Традиционно это решается упорными овертаймами по факту дедлайна.

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

«о таймлайн продлили всё чуваки выдыхаем наш факап не заметят пошли пиво пить» (к) (тм) Традиционно это решается упорными овертаймами по факту дедлайна.
не знаю как вы обычно делаете, но в том кейсе у нас появилось больше времени на тестирования, что дало возможность выкатить более стабильно работающую feature. а то что все были извещены о рисках, закрыло нас от наездов, какого хера оно так через одно место работает. ибо все знали на что шли.
Спорно, это «ничего» часто конвертируется в
Практика показывает что таки ничего — весь этот наработанный опыт никак не во что не конвертируется никакой реальной технической и экспертной капитализации нет в лучшем случае есть «корпоративный скрам-коуч» раз за разом рассказывающий одну и ту же базовую методичку и никак не включая в неё реальный опыт по уже реализованным проектам компании равно как и не включая этот опыт обратно в реализацию новых проектов (читай: экспертная капитализация).

Справедливости ради вынужден признать что здесь я противоречу сам себе в моменте «взяли готовую методику и тупо действуют в рамках» (к) Готового решения у меня увы всё ещё нет пока идёт «стадия накопления тумана» (к)

Что сказать-то хотел такой простынёй?

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

Это про вашу статью в том числе, про введение особенно www.linkedin.com/...y-when-things-tom-gardner
Всё плохо, все тупые и далее по тексту.

Ось тут ще пакован інформації по темі
www.kitchensoap.com/...-being-a-senior-engineer

вот это хорошее философское чтиво, не на один раз (если время есть все читать

Підписатись на коментарі