Тогда идет прямой конфликт интересов разработчиков в разрезе того, чем они занимаются на работе.
Дежурства - навязанная сверху инициатива начальства, которая не фигурирует в основных обязанностях при заключении договоров. И если разработчик будет посвящать этому много времени, в голове рождается вопрос "а тем ли я занимаюсь, и что получаю взамен?". И ответы на эти вопросы в пользу компании рождаются лишь у людей с горизонтальными обязанностями (лиды, пм, и т.д.).
Обычный разработчик в этом плане получит замедление роста как программиста (о котором его спросят на собеседованиях с более высокой зп), но получит горизонтальный рост внутри компании.
Конфликтов не будет только в том случае, где разработчиков холят и лелеют, десятилетиями учитывая их профессиональные интересы. Судя по современным тенденциям, таких компаний везде все меньше и меньше.
Если речь идет о таких сроках дежурства, скорее всего требуется отдельная должность.
Дежурство было в разрезе команды. Сами команды делились по продуктам и стеку. Каждую неделю выделялся разработчик. До парного дежурства дело не доходило, обычно "пара" была как раз в виде тимлида или старших разработчиков, которые делали тот или иной функционал. Чаще всего лид.
Разработчик освобождался от своих непосредственных задач, и занимался только дежурствами с описанным регламентом. Смены были недельными, примерно раз в 1.5-2 месяца.
Встречался с подобным. На себе ощущал все прелести и недостатки подобных дежурств.
Из плюсов можно отметить:
1) Погружение в домен происходит быстрее. Но здесь важно понимать, что нельзя доверить дежурство человеку с малыи погружением (только если в качестве наблюдающего за работой сеньера), иначе будет отталкивающий эффект.
2) На команду в целом снижается нагрузка и наплывы вопросов (запросов) от посторонних людей
3) У людей по ту сторону разработки появляются единые каналы решения проблем, и не уходит много времени на понимание, куда именно обращаться за помощью по вопросам разработки.
Из минусов:
1) Сам дежурный, как правило, в состоянии пофиксить только самые легкие баги и ответить на простейшие вопросы. Обычно дежурный все равно редиректит поступившие обращения к более погруженным сотрудникам, т.к. на том конце провода всегда все срочно. Способных покрыть хотя бы 50% запросов дежурных я не встречал. У схемы огромный порог вхождения, который только порождает доп. bus factor на ключевых людей.
2) Передача дел между дежурными почти не осуществляется, и проблемы, которые не решились в смены дежурств, переходят другим дежурным, которые либо отвлекают предыдущих дежурных, чтобы понять статус и ход мыслей, либо просто начинают решение проблемы с чистого листа. Видел, как некоторые вопросы в результате подвисали на месяца, и каждый новый дежурный добавлял по паре сообщений в тред, который в результате невозможно было читать новому человеку.
3) Практика "релизы + техподдержка + дебаг + техдолг", как правило, не работает в полной мере. Потому что иногда какой-то из этих пунктов способен просто перекрыть остальные на все время дежурства (сложные релизы с конфликтами, под видом простенького бага оказался слоняра, на фикс которого ушло все время, срочные вопросы от клиентов или техподдержки, которые постоянно отвлекали от остальных обязанностей, недодекомпозированный техдолг, который потребовал много действий). Слишком большая нагрузка на человека, и слишком много неизвестных в планировании дежурства, т.к. в любой момент дежурство может потребовать переключения.
В целом, я так и не ощутил на себе, как можно сделать этот процесс не породив суперменов-разработчиков, которые будут на себе тащить многое, выходя за рамки своих базовых обязанностей. Это очень сильно увеличивает разрыв между старичками и новичками в команде, иногда даже порождая дедовщину. Поэтому соглашусь с комментариями выше, в которых писалось про то, что дежурства - это отдельный процесс, а погружение в домен, онбоардинги и различные повышения квалификаций - совсем другой, и они невзаимозаменяемы.
Гемба как раз чаще и встречается в компаниях с большими иерархиями. Они ее и породили.
А подход "не хочешь - увольняйся" всегда идет в ущерб его практикователям, потому что между этими шагами может быть много промежуточных для урегулирования споров. Можно еще про очередь за забором при этом упомянуть. И остаться без сотрудников.
Когда я встречал подобную практику для разработчиков, она нередко конфликтовала с реальностью:
1) Проблемы иерархии. Разработчик чаще всего имеет над собой начальство (тимлид, продукт-менеджер, проджект-менеджер, продукт-овнер, техдир), и это начальство в большинстве случаев при выдвинутых предложениях от разработчика знает за него, как делать надо, а как нет. И 90% продуктовых идей от самих разработчиков не принимаются под давлением опыта руководства, или отодвигаются в неприоритетный бэклог.
2) Проблемы фидбека. Люди искренне делятся впечатлениями в первые разы этой гембы. Дальше, видя, что после их впечатлений ситуация практически не поменялась, гембить уже и не особо хочется. Работа над фидбеком практически не ведется, т.к. клиентский фидбек оказывается приоритетнее.
3) Проблемы однобокости. Почему-то когда говорят, что разработчик должен быть погружен в бизнес, умалчивают о том, что тогда и бизнес должен быть погружен в разработку. Он же тоже станет лучше понимать процессы разработки и сможет оставить кучу фидбека про нее. Но почему-то вот никто из предлагателей погружения разработчика в бизнес не хочет сам хотя бы денек-два позакрывать простенькие баги в коде, и ему это становится резко не нужным, т.к. сразу появляется море неотложенных дел, да и вообще он не этим в компании занимается. Плюс это работает только вниз по ирерархии (почему разработчику не предлагают попробовать позаниматься продакт-овнерством, например?).
Я считаю, что подобная практика как раз хороша для людей, которые принимают решения (читай, начальников любых уровней). Рядовой разработчик к таким людям не относится, и его порывы после гембы не дают должного эффекта от данных мероприятий. Лишь небольшое расширение кругозора. И код писать он качественнее от этого точно не будет.
Когда руководством выбрана позиция доказательства своего повышения, сотрудник заранее в проигрыше. Ему нужно об этом постоянно думать, что будет отвлекать от исполнения непосредственных обязанностей, да и работа начнет выполняться только с учетом того, получит ли он повышение в итоге.
В вашем примере сотрудник мог подать резюме на hh.ru только потому, что столкнулся с несправедливостью: он сам пишет, что работает не хуже никого, никаких доказательств обратного нет, но почему-то Васе повысили, а ему нет. Значит, сама система повышений какая-то сомнительная, и он разочарован, что она отразилась на нем. Это уже сам по себе довольно весомый повод отказаться от работы в компании: она не замечает результаты работы сотрудника (что и было продемонстрировано при дальнейшем разборе ситуации), и даже более того - иногда язвит на эту тему выражениями типа low performer.
Как правило, даже если вы договорились о том, что компания начнет замечать и давать хороший обратный фидбек сотруднику (а это, как правило, ловушка, потому что если этого процесса нет, то настройка и отладка его может занять много времени), вы не упомянули о том, что стало с повышением сотрудника (додумываю, что его просто отложили на неопределенное время). И решить данный конфликт для сотрудника было бы разумным повышением зп на процент Васи процент плюс обещанием все наладить, а не только обещанием. Сотрудник остался в проигрыше, потому что поимел ряд разборов конфликтных ситуаций с выигрышем в виде данных обещаний, но не того, что он хотел изначально: повышения зп.
Всегда видел два типа компаний: где надо выбивать повышение, и где компания сама следит за твоими рабочими показателями, и повышение происходит закономерно, если работаешь добросовестно. В первом типе компаний повышение всегда стрессовый и негарантированный процесс (заведение речи о повышении -> установка правил повышения -> соблюдение правил повышения, которые могут не зависеть от тебя). Во втором типе это приятный процесс (получение сюрприза от компании в виде того, что ей не все равно на результаты твоей работы, и что она действительно заботится о тебе). Но первый тип преобладает на рынке в виду сокращения бюджетов на рабочую силу, что немного огорчает.
В больших командах это нивелируется отдельным "чатом" с ротацией ответственных, задача которых и есть отвечать на все запросы. Есть сообщение - есть ответ, т.к. есть отвественный и обязанность.
Неужели вы не встречали ситуацию, когда на один вопрос получается два противоположных ответа, и в треде этого вопроса начинают устраивать баталии на тему "как должно быть"? Зрелище так себе. Уж лучше отсутствие ответа.
Да, но кто должен писать это в чат? Все разработчики или участники чата сразу? Да нет. Писать должен отвественный. А кто им назначен - уже не столь важно. Суть в том, что когда в чате пишут "все пропало", то никогда не понятно, кто и в каком приоритете должен это решать.
В нормальной имплементации решения такой проблемы в чатах всегда есть люди, к которым непосредственно можно обратиться по проблеме, не дергая весь чат и обижаясь потом на всех, что мол "буки неразговорчивые, тут же кризис мировой назревает".
1) На молчание в чате на неработающую кнопку должен отвечать pm проекта, потому что на нем сроки и приотиризация задач. Максимум, в случае если эта кнопка приносит миллионы долларов в секунду, должны дергаться причастные к неработе, да и то через свою иерархию, а не напрямую.
2) Боссу варианты предлагают уже не разработчики, а лиды, продуктологи, архитектурный комитет или кто там еще. Когда разработчик начинает это делать самолично, он чаще всего огребет проблем, т.к. его резко перекинут реализовывать выдвинутые им варианты без нормальной детализации, т.к. "ну ты сам лучше знаешь, ты же инициативный". Разработчику будет гораздо полезнее выдвигать предложения в его команде при груминге или детализации задач, нежели при общении с боссом.
В остальных пунктах диалоги идут непосредственно не с разработчиками, а с какими-то лидами,ВП, котами.
В статье ни одного полезного примера общения с разработчиками, но начинается она с упрека в их сторону. Удивительная профдеформация написавшего эту статью БОССА.
Речь ведь не об идеальном мире. Понятное дело, что идеальных компаний очень мало и у каждого свое представление идеального мира. Речь о балансе между основными обязанностями (писать код и поддерживать функционал) и второстепеннонавязанными (погружение в доменную область, аналитика, менеджмент).
Обычно когда от разработчика начинают требовать очень много второстепенного, начинаются различные внутренние (а тем ли я в этой жизни занимаюсь?) и внешние (конфликты с навязывателями обязанностей и постоянное уточнение того, чем ты в итоге должен заниматься) разногласия, что очень усложняет жизнь.
В текущих реалиях это уже не так. Можно проявлять инициативу и быть славным скакуном, на котором будут ездить годами без плюшек и перспектив (встречался с такими - печальное зрелище), а можно не выходить за рамки своих обязанностей и через время сменить работу на более комфортную и высокооплачиваемую просто придя на собеседование в другое место.
Для разработчиков повышение сейчас иногда приобретает негативный характер. Повышают до лида, при этом повысив зарплату до среднеразработческой по рынку, но при этом начинают требовать так, будто обеспечили старость человеку беззаботную.
Почему-то такую технику осуперменивания разработчиков я встречал в компаниях, где разработчики занимались кодированием меньшую часть своего рабочего времени (2-3 часа), а остальную часть как раз и занимало это осуперменивание. Сюда входят погружение в домен, погружение в корп. культуру, море встреч разной степени полезности (которого никак не избежать, если от разработчиков требуют суперменства). Это все очень сильно выматывало эмоционально, а результат все равно получался посредственным.
Для меня наоборот является негативным моментом, если компания слишком пропитана своей продуктовостью и хочет ей пропитывать всех вплоть до уборщицы. Как правило, в таких компаниях все занимаются всем, но не тем, что у них прописано в трудовом договоре и на что они договаривались при найме. И текучка там огромная из-за постоянных осупермениваний, которые в целом приводят адским переработкам и последующему выгоранию.
Далеко не так.
Возможно, ты получаешь нематериальные блага в виде комфортной работы и становления процессов. Но на этапе этого становления у тебя будет вытрепано достаточно нервов, и потребуется разрешить очень много конфликтных ситуаций, связанных с тем, что другие участники коллектива не настроены на улучшение процессов. Далеко не все улучшаторы выдерживают такой нагрузки и в итоге выгорают.
Возможно, ты получаешь материальные блага. Но видя инициативу от сотрудника, начальство лишь нагружает его доп. обязанностями из-за своей проф. деформации в виде того, что само начальство не имеет четкого списка обязанностей. А когда заходит речь о повышении выясняется, что сменить работу для этого гораздо выгоднее. Да и обязанностей там будет поменьше при бОльшей оплате.
Я считаю, что мысли изложенные в статье подходят для людей, которые наделены управленческими лычками, но ни в коем случае для рядовых подчиненных. Как бы рядовой сотрудник ни старался делать свою работу качественно и стать заменимым, его порывы выливаются в очень конфликтные и порой невыносимые рабочие условия. И лишь небольшой процент действительно оценивается должным образом с соответсвующими материальными и нематериальными компенсациями.
Тут вопрос в том, насколько гибкими собеседования будут для компании. Например, мы задаем задачки про алгоритмы и структуры данных. Это самый низкий уровень, который не имеет отношение к специфике разработки, сфере деятельности компании, предыдущему опыту работы. Соответственно, проводить подобные собеседования может большее количество людей. Это более масштабируемая схема найма, хотя и не коррелирует с реальными навыками людей программировать серьезные проекты.
Я предполагаю, что большим корпорациям часто не столь важен специфичный опыт. Им удобна стандартизация. Вопрос про проектирование модуля очень сильно может быть привязан к специфике языка, его инструментов (у корпораций свое море внутренних библиотек), и в целом отношения к проектированию и кодированию в компании (например, в одной допустимы небольшие нарушения инкапсуляции для общения между модулями, а в другой за этим строго следят и не допускают их). Потому и задают вопросы, которые имеют отношение к программированию в целом, но не имеют отношения к реальным проектам.
И да, многие сеньоры могут не подходить большой компании именно по причине своего специфичного опыта и некоторой закостенелости в плане сформировавшегося вкуса к написанию кода, потому что им будет сложнее переучиться на иные подходы к разработке, которые сформировались в этой компании.
Чем крупнее компания, тем больше вероятность нарваться на задачки и вопросы, ответы на которые никак не расскажут о тебе как о специалисте.
С одной стороны понятно: поток резюме от разных проходимцев и людей, которые хотят войтивайти у таких компаний огромен. И для упрощения процедуры фильтрации этого потока делается эта стандартизация с однотипными вопросами и задачками, которые бессмысленны по своей сути. С другой стороны, у людей с достаточным опытом в сфере это чаще вызывает негатив, потому что они знают процессы и то, что задачки им не пригодятся в дальнейшем, а нужны лишь для прохождения собеседования.
У компаний поменьше размером такое встречается реже, но бывает. Там больше вопросов из теории и практики современных подходов к разработке. Они в целом гибче относятся к найму. И там очень много горячих предложений для сеньоров с менее изматывающим процессом найма.
Тут нужно понимать, на какую компанию нацелен кандидат. Крупные корпорации с их подходами к собеседованию могут не меняться годами. А более гибкие и шустрые не так стабильны. И если вы выбрали крупную рыбу, то будьте добры играть по ее правилам.
Да никак не записана. В большинстве случаев это просто навязывание дополнительных должностных обязанностей. Но многие программисты соглашаются на это, потому что это своего рода дополнительная ачивка на предыдущем месте работы (мол, допустили), строчка в резюме и довольно полезный опыт. Человек начинает по другому относиться к собеседованиям, если побывал с двух сторон баррикад.
Я больше сталкивался с формулировкой «на любом языке».
В любом случае, я никогда себя не чувствую комфортно при написании кода на листочке — руки под клавиатуру заточены. Даже если это элементарные sql-запросы. Вспоминаются курсы паскаля в старших классах сразу. Вот там нас за каждую пропущенную точку с запятой в тетрадке гнобили и занижали оценки :)
Самые хорошие впечатления у меня от собеседований в форме диалога. Где людям был интересен мой опыт, и где по моему опыту задавались соответствующие вопросы из разряда «А как было это реализовано? А с какими проблемами при реализации столкнулись? А как бы сейчас сделали?». И соответствующие теоретические вопросы по стеку технологий, чтобы понять, насколько глубоко я погружен в ту или иную область. Сразу понимаешь уровень специалиста, который задает тебе вопросы и рулит собеседованием. И порой из-за одних вопросов и объяснений от таких людей уже возникает желание с ними работать.
Что касаемо кода на листочках — это полный швах. Сначала я был разочарован в себе и сильно подавлен подобными задачами. Но заметил одну закономерность: туплю при решении, но по приходу домой код с решением задачи пишется как по маслу. Может, сказывается то, что я думаю о решении после фейла, и задача для меня становится не свежей. А может и то, что обстановка не та, сосредотачиваешься на форматировании кода, кривом почерке и каляках-маляках из-за того что ручку в основном используешь при схематичном отображении чего-либо или когда надо расписаться. Решил вообще не париться и никогда не решать задачи на листочках, если только это не совсем какая-то элементарщина из одной функции. Всегда перед назначением собеседования спрашиваю про его формат, и отвечаю отказом если мне говорят о паре задач на листочках.
Тестовые задания же вообще очень ненадежная вещь. Встречался с тем, что делал тестовое задание дня три, потом мне назначили собеседование, и никто на нем не знал, что тестовое задание мной было выполнено. Т.е. hr тупо проверила наличие файла с результатом, а дальше никуда тестовое мое не пошло. Встречался с тем, что не спал четыре ночи и как угорелый проектировал архитектуру, вылизывал код, покрывал его тестами, а бизнес-задачу понял немного не так, и все мои труды завернули за минут 10. Самые приемлимые тестовые задания я получал только после успешных собеседований с теоретическими и практическими вопросами. Они были небольшие, на час-два времени, но при хорошем впечатлении о фирме после собеседования всегда была мотивация их сделать.
Тогда идет прямой конфликт интересов разработчиков в разрезе того, чем они занимаются на работе.
Дежурства - навязанная сверху инициатива начальства, которая не фигурирует в основных обязанностях при заключении договоров. И если разработчик будет посвящать этому много времени, в голове рождается вопрос "а тем ли я занимаюсь, и что получаю взамен?". И ответы на эти вопросы в пользу компании рождаются лишь у людей с горизонтальными обязанностями (лиды, пм, и т.д.).
Обычный разработчик в этом плане получит замедление роста как программиста (о котором его спросят на собеседованиях с более высокой зп), но получит горизонтальный рост внутри компании.
Конфликтов не будет только в том случае, где разработчиков холят и лелеют, десятилетиями учитывая их профессиональные интересы. Судя по современным тенденциям, таких компаний везде все меньше и меньше.
Если речь идет о таких сроках дежурства, скорее всего требуется отдельная должность.
Дежурство было в разрезе команды. Сами команды делились по продуктам и стеку. Каждую неделю выделялся разработчик. До парного дежурства дело не доходило, обычно "пара" была как раз в виде тимлида или старших разработчиков, которые делали тот или иной функционал. Чаще всего лид.
Разработчик освобождался от своих непосредственных задач, и занимался только дежурствами с описанным регламентом. Смены были недельными, примерно раз в 1.5-2 месяца.
Встречался с подобным. На себе ощущал все прелести и недостатки подобных дежурств.
Из плюсов можно отметить:
1) Погружение в домен происходит быстрее. Но здесь важно понимать, что нельзя доверить дежурство человеку с малыи погружением (только если в качестве наблюдающего за работой сеньера), иначе будет отталкивающий эффект.
2) На команду в целом снижается нагрузка и наплывы вопросов (запросов) от посторонних людей
3) У людей по ту сторону разработки появляются единые каналы решения проблем, и не уходит много времени на понимание, куда именно обращаться за помощью по вопросам разработки.
Из минусов:
1) Сам дежурный, как правило, в состоянии пофиксить только самые легкие баги и ответить на простейшие вопросы. Обычно дежурный все равно редиректит поступившие обращения к более погруженным сотрудникам, т.к. на том конце провода всегда все срочно. Способных покрыть хотя бы 50% запросов дежурных я не встречал. У схемы огромный порог вхождения, который только порождает доп. bus factor на ключевых людей.
2) Передача дел между дежурными почти не осуществляется, и проблемы, которые не решились в смены дежурств, переходят другим дежурным, которые либо отвлекают предыдущих дежурных, чтобы понять статус и ход мыслей, либо просто начинают решение проблемы с чистого листа. Видел, как некоторые вопросы в результате подвисали на месяца, и каждый новый дежурный добавлял по паре сообщений в тред, который в результате невозможно было читать новому человеку.
3) Практика "релизы + техподдержка + дебаг + техдолг", как правило, не работает в полной мере. Потому что иногда какой-то из этих пунктов способен просто перекрыть остальные на все время дежурства (сложные релизы с конфликтами, под видом простенького бага оказался слоняра, на фикс которого ушло все время, срочные вопросы от клиентов или техподдержки, которые постоянно отвлекали от остальных обязанностей, недодекомпозированный техдолг, который потребовал много действий). Слишком большая нагрузка на человека, и слишком много неизвестных в планировании дежурства, т.к. в любой момент дежурство может потребовать переключения.
В целом, я так и не ощутил на себе, как можно сделать этот процесс не породив суперменов-разработчиков, которые будут на себе тащить многое, выходя за рамки своих базовых обязанностей. Это очень сильно увеличивает разрыв между старичками и новичками в команде, иногда даже порождая дедовщину. Поэтому соглашусь с комментариями выше, в которых писалось про то, что дежурства - это отдельный процесс, а погружение в домен, онбоардинги и различные повышения квалификаций - совсем другой, и они невзаимозаменяемы.
Гемба как раз чаще и встречается в компаниях с большими иерархиями. Они ее и породили.
А подход "не хочешь - увольняйся" всегда идет в ущерб его практикователям, потому что между этими шагами может быть много промежуточных для урегулирования споров. Можно еще про очередь за забором при этом упомянуть. И остаться без сотрудников.
Когда я встречал подобную практику для разработчиков, она нередко конфликтовала с реальностью:
1) Проблемы иерархии. Разработчик чаще всего имеет над собой начальство (тимлид, продукт-менеджер, проджект-менеджер, продукт-овнер, техдир), и это начальство в большинстве случаев при выдвинутых предложениях от разработчика знает за него, как делать надо, а как нет. И 90% продуктовых идей от самих разработчиков не принимаются под давлением опыта руководства, или отодвигаются в неприоритетный бэклог.
2) Проблемы фидбека. Люди искренне делятся впечатлениями в первые разы этой гембы. Дальше, видя, что после их впечатлений ситуация практически не поменялась, гембить уже и не особо хочется. Работа над фидбеком практически не ведется, т.к. клиентский фидбек оказывается приоритетнее.
3) Проблемы однобокости. Почему-то когда говорят, что разработчик должен быть погружен в бизнес, умалчивают о том, что тогда и бизнес должен быть погружен в разработку. Он же тоже станет лучше понимать процессы разработки и сможет оставить кучу фидбека про нее. Но почему-то вот никто из предлагателей погружения разработчика в бизнес не хочет сам хотя бы денек-два позакрывать простенькие баги в коде, и ему это становится резко не нужным, т.к. сразу появляется море неотложенных дел, да и вообще он не этим в компании занимается. Плюс это работает только вниз по ирерархии (почему разработчику не предлагают попробовать позаниматься продакт-овнерством, например?).
Я считаю, что подобная практика как раз хороша для людей, которые принимают решения (читай, начальников любых уровней). Рядовой разработчик к таким людям не относится, и его порывы после гембы не дают должного эффекта от данных мероприятий. Лишь небольшое расширение кругозора. И код писать он качественнее от этого точно не будет.
Вайтбоард вполне себе заменяется созвоном с шарингом экрана + открытой рисовалкой какой-нибудь. Jamboard, draw.io и т.д.
Когда руководством выбрана позиция доказательства своего повышения, сотрудник заранее в проигрыше. Ему нужно об этом постоянно думать, что будет отвлекать от исполнения непосредственных обязанностей, да и работа начнет выполняться только с учетом того, получит ли он повышение в итоге.
В вашем примере сотрудник мог подать резюме на hh.ru только потому, что столкнулся с несправедливостью: он сам пишет, что работает не хуже никого, никаких доказательств обратного нет, но почему-то Васе повысили, а ему нет. Значит, сама система повышений какая-то сомнительная, и он разочарован, что она отразилась на нем. Это уже сам по себе довольно весомый повод отказаться от работы в компании: она не замечает результаты работы сотрудника (что и было продемонстрировано при дальнейшем разборе ситуации), и даже более того - иногда язвит на эту тему выражениями типа low performer.
Как правило, даже если вы договорились о том, что компания начнет замечать и давать хороший обратный фидбек сотруднику (а это, как правило, ловушка, потому что если этого процесса нет, то настройка и отладка его может занять много времени), вы не упомянули о том, что стало с повышением сотрудника (додумываю, что его просто отложили на неопределенное время). И решить данный конфликт для сотрудника было бы разумным повышением зп на процент Васи процент плюс обещанием все наладить, а не только обещанием. Сотрудник остался в проигрыше, потому что поимел ряд разборов конфликтных ситуаций с выигрышем в виде данных обещаний, но не того, что он хотел изначально: повышения зп.
Всегда видел два типа компаний: где надо выбивать повышение, и где компания сама следит за твоими рабочими показателями, и повышение происходит закономерно, если работаешь добросовестно. В первом типе компаний повышение всегда стрессовый и негарантированный процесс (заведение речи о повышении -> установка правил повышения -> соблюдение правил повышения, которые могут не зависеть от тебя). Во втором типе это приятный процесс (получение сюрприза от компании в виде того, что ей не все равно на результаты твоей работы, и что она действительно заботится о тебе). Но первый тип преобладает на рынке в виду сокращения бюджетов на рабочую силу, что немного огорчает.
В больших командах это нивелируется отдельным "чатом" с ротацией ответственных, задача которых и есть отвечать на все запросы. Есть сообщение - есть ответ, т.к. есть отвественный и обязанность.
Неужели вы не встречали ситуацию, когда на один вопрос получается два противоположных ответа, и в треде этого вопроса начинают устраивать баталии на тему "как должно быть"? Зрелище так себе. Уж лучше отсутствие ответа.
Да, но кто должен писать это в чат? Все разработчики или участники чата сразу? Да нет. Писать должен отвественный. А кто им назначен - уже не столь важно. Суть в том, что когда в чате пишут "все пропало", то никогда не понятно, кто и в каком приоритете должен это решать.
В нормальной имплементации решения такой проблемы в чатах всегда есть люди, к которым непосредственно можно обратиться по проблеме, не дергая весь чат и обижаясь потом на всех, что мол "буки неразговорчивые, тут же кризис мировой назревает".
Описанные ситуации ведь не касаются разработчика.
1) На молчание в чате на неработающую кнопку должен отвечать pm проекта, потому что на нем сроки и приотиризация задач. Максимум, в случае если эта кнопка приносит миллионы долларов в секунду, должны дергаться причастные к неработе, да и то через свою иерархию, а не напрямую.
2) Боссу варианты предлагают уже не разработчики, а лиды, продуктологи, архитектурный комитет или кто там еще. Когда разработчик начинает это делать самолично, он чаще всего огребет проблем, т.к. его резко перекинут реализовывать выдвинутые им варианты без нормальной детализации, т.к. "ну ты сам лучше знаешь, ты же инициативный". Разработчику будет гораздо полезнее выдвигать предложения в его команде при груминге или детализации задач, нежели при общении с боссом.
В остальных пунктах диалоги идут непосредственно не с разработчиками, а с какими-то лидами,ВП, котами.
В статье ни одного полезного примера общения с разработчиками, но начинается она с упрека в их сторону. Удивительная профдеформация написавшего эту статью БОССА.
Речь ведь не об идеальном мире. Понятное дело, что идеальных компаний очень мало и у каждого свое представление идеального мира. Речь о балансе между основными обязанностями (писать код и поддерживать функционал) и второстепеннонавязанными (погружение в доменную область, аналитика, менеджмент).
Обычно когда от разработчика начинают требовать очень много второстепенного, начинаются различные внутренние (а тем ли я в этой жизни занимаюсь?) и внешние (конфликты с навязывателями обязанностей и постоянное уточнение того, чем ты в итоге должен заниматься) разногласия, что очень усложняет жизнь.
В текущих реалиях это уже не так. Можно проявлять инициативу и быть славным скакуном, на котором будут ездить годами без плюшек и перспектив (встречался с такими - печальное зрелище), а можно не выходить за рамки своих обязанностей и через время сменить работу на более комфортную и высокооплачиваемую просто придя на собеседование в другое место.
Для разработчиков повышение сейчас иногда приобретает негативный характер. Повышают до лида, при этом повысив зарплату до среднеразработческой по рынку, но при этом начинают требовать так, будто обеспечили старость человеку беззаботную.
Почему-то такую технику осуперменивания разработчиков я встречал в компаниях, где разработчики занимались кодированием меньшую часть своего рабочего времени (2-3 часа), а остальную часть как раз и занимало это осуперменивание. Сюда входят погружение в домен, погружение в корп. культуру, море встреч разной степени полезности (которого никак не избежать, если от разработчиков требуют суперменства). Это все очень сильно выматывало эмоционально, а результат все равно получался посредственным.
Для меня наоборот является негативным моментом, если компания слишком пропитана своей продуктовостью и хочет ей пропитывать всех вплоть до уборщицы. Как правило, в таких компаниях все занимаются всем, но не тем, что у них прописано в трудовом договоре и на что они договаривались при найме. И текучка там огромная из-за постоянных осупермениваний, которые в целом приводят адским переработкам и последующему выгоранию.
Возможно, ты получаешь нематериальные блага в виде комфортной работы и становления процессов. Но на этапе этого становления у тебя будет вытрепано достаточно нервов, и потребуется разрешить очень много конфликтных ситуаций, связанных с тем, что другие участники коллектива не настроены на улучшение процессов. Далеко не все улучшаторы выдерживают такой нагрузки и в итоге выгорают.
Возможно, ты получаешь материальные блага. Но видя инициативу от сотрудника, начальство лишь нагружает его доп. обязанностями из-за своей проф. деформации в виде того, что само начальство не имеет четкого списка обязанностей. А когда заходит речь о повышении выясняется, что сменить работу для этого гораздо выгоднее. Да и обязанностей там будет поменьше при бОльшей оплате.
Я считаю, что мысли изложенные в статье подходят для людей, которые наделены управленческими лычками, но ни в коем случае для рядовых подчиненных. Как бы рядовой сотрудник ни старался делать свою работу качественно и стать заменимым, его порывы выливаются в очень конфликтные и порой невыносимые рабочие условия. И лишь небольшой процент действительно оценивается должным образом с соответсвующими материальными и нематериальными компенсациями.
Я предполагаю, что большим корпорациям часто не столь важен специфичный опыт. Им удобна стандартизация. Вопрос про проектирование модуля очень сильно может быть привязан к специфике языка, его инструментов (у корпораций свое море внутренних библиотек), и в целом отношения к проектированию и кодированию в компании (например, в одной допустимы небольшие нарушения инкапсуляции для общения между модулями, а в другой за этим строго следят и не допускают их). Потому и задают вопросы, которые имеют отношение к программированию в целом, но не имеют отношения к реальным проектам.
И да, многие сеньоры могут не подходить большой компании именно по причине своего специфичного опыта и некоторой закостенелости в плане сформировавшегося вкуса к написанию кода, потому что им будет сложнее переучиться на иные подходы к разработке, которые сформировались в этой компании.
С одной стороны понятно: поток резюме от разных проходимцев и людей, которые хотят войтивайти у таких компаний огромен. И для упрощения процедуры фильтрации этого потока делается эта стандартизация с однотипными вопросами и задачками, которые бессмысленны по своей сути. С другой стороны, у людей с достаточным опытом в сфере это чаще вызывает негатив, потому что они знают процессы и то, что задачки им не пригодятся в дальнейшем, а нужны лишь для прохождения собеседования.
У компаний поменьше размером такое встречается реже, но бывает. Там больше вопросов из теории и практики современных подходов к разработке. Они в целом гибче относятся к найму. И там очень много горячих предложений для сеньоров с менее изматывающим процессом найма.
Тут нужно понимать, на какую компанию нацелен кандидат. Крупные корпорации с их подходами к собеседованию могут не меняться годами. А более гибкие и шустрые не так стабильны. И если вы выбрали крупную рыбу, то будьте добры играть по ее правилам.
В любом случае, я никогда себя не чувствую комфортно при написании кода на листочке — руки под клавиатуру заточены. Даже если это элементарные sql-запросы. Вспоминаются курсы паскаля в старших классах сразу. Вот там нас за каждую пропущенную точку с запятой в тетрадке гнобили и занижали оценки :)
Что касаемо кода на листочках — это полный швах. Сначала я был разочарован в себе и сильно подавлен подобными задачами. Но заметил одну закономерность: туплю при решении, но по приходу домой код с решением задачи пишется как по маслу. Может, сказывается то, что я думаю о решении после фейла, и задача для меня становится не свежей. А может и то, что обстановка не та, сосредотачиваешься на форматировании кода, кривом почерке и каляках-маляках из-за того что ручку в основном используешь при схематичном отображении чего-либо или когда надо расписаться. Решил вообще не париться и никогда не решать задачи на листочках, если только это не совсем какая-то элементарщина из одной функции. Всегда перед назначением собеседования спрашиваю про его формат, и отвечаю отказом если мне говорят о паре задач на листочках.
Тестовые задания же вообще очень ненадежная вещь. Встречался с тем, что делал тестовое задание дня три, потом мне назначили собеседование, и никто на нем не знал, что тестовое задание мной было выполнено. Т.е. hr тупо проверила наличие файла с результатом, а дальше никуда тестовое мое не пошло. Встречался с тем, что не спал четыре ночи и как угорелый проектировал архитектуру, вылизывал код, покрывал его тестами, а бизнес-задачу понял немного не так, и все мои труды завернули за минут 10. Самые приемлимые тестовые задания я получал только после успешных собеседований с теоретическими и практическими вопросами. Они были небольшие, на час-два времени, но при хорошем впечатлении о фирме после собеседования всегда была мотивация их сделать.