Pull to refresh
4
0
Send message

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

Разный опыт, разное отношение.

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

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

Очень рад ошибаться, если ваш опыт корпоративных плюшек более распространен в мире.

Делали без ADR, более упрощенно:

1) Выработали план, по которому принимаем соглашения на уровне стека

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

3) Раз в неделю собирались стеком и шли по плану.

4) В ходе обсуждений задавались конкретные вопросы и фиксировались результаты обсуждений в виде рекомендаций или обязательных правил. Фиксировались на странице вики в формате markdown, об изменениях оповещались участники процесса.

5) В параллеле с вопросами стека применили похожую схему к процессам в команде (git-flow, ревью, детализация, тестирование, практика релизов).

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

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

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

9) Запустили таким образом кросс-командные соглашения.

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

Конечно останавливало. И заставляло выплачивать n-ое количество окладов при увольнении не просто так. По личным ощущениям, я встречал людей, которые говорили "нас сократили и выдали оклады" примерно в одинаковом количестве с людьми, которые говорили "обещали опцион, но в итоге не взлетело и ничего не дали". Чувствуете разницу?

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

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

В период активного роста (junior -> middle или middle -> senior) такие случаи встречаются чаще. Дальше уже да, с опытом уходит азарт играть в такие игры, и просишь оставлять одинаковые цифры до и после испытательного.

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

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

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

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

Причем, сейчас даже "своя" доставка заведения нередко пользуется услугами яндекса для доставки. При этом, стоимость все равно меньше, чем заказ через сервис.

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

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

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

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

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

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

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

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

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

И какова текучка с таким подходом? Просто, сколько не видел продуктовых компаний, которые изрядно проповедовали T-shape и различные мантры в духе "наш разработчик - нечто большее, чем просто кодер", там в основном лиды это все активно слушали, и им это было действительно полезно и интересно. Рядовые разработчики же либо холодно игнорировали такие посылы, либо открыто конфликтовали с наводящими запросами на тему должностных обязанностей и перенагрузки на одного человека. Как следствие, из-за несбалансированной нагрузки некоторые либо сидели без отпусков, либо выгорали, либо уходили в компании c I, награждая T-компанию постоянной текучкой кадров.

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

Тогда идет прямой конфликт интересов разработчиков в разрезе того, чем они занимаются на работе.

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

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

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

Если речь идет о таких сроках дежурства, скорее всего требуется отдельная должность.

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

Разработчик освобождался от своих непосредственных задач, и занимался только дежурствами с описанным регламентом. Смены были недельными, примерно раз в 1.5-2 месяца.

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

Из плюсов можно отметить:

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

2) На команду в целом снижается нагрузка и наплывы вопросов (запросов) от посторонних людей

3) У людей по ту сторону разработки появляются единые каналы решения проблем, и не уходит много времени на понимание, куда именно обращаться за помощью по вопросам разработки.

Из минусов:

1) Сам дежурный, как правило, в состоянии пофиксить только самые легкие баги и ответить на простейшие вопросы. Обычно дежурный все равно редиректит поступившие обращения к более погруженным сотрудникам, т.к. на том конце провода всегда все срочно. Способных покрыть хотя бы 50% запросов дежурных я не встречал. У схемы огромный порог вхождения, который только порождает доп. bus factor на ключевых людей.

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

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

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

Гемба как раз чаще и встречается в компаниях с большими иерархиями. Они ее и породили.

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

Когда я встречал подобную практику для разработчиков, она нередко конфликтовала с реальностью:

1) Проблемы иерархии. Разработчик чаще всего имеет над собой начальство (тимлид, продукт-менеджер, проджект-менеджер, продукт-овнер, техдир), и это начальство в большинстве случаев при выдвинутых предложениях от разработчика знает за него, как делать надо, а как нет. И 90% продуктовых идей от самих разработчиков не принимаются под давлением опыта руководства, или отодвигаются в неприоритетный бэклог.

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

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

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

Вайтбоард вполне себе заменяется созвоном с шарингом экрана + открытой рисовалкой какой-нибудь. Jamboard, draw.io и т.д.

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

В вашем примере сотрудник мог подать резюме на hh.ru только потому, что столкнулся с несправедливостью: он сам пишет, что работает не хуже никого, никаких доказательств обратного нет, но почему-то Васе повысили, а ему нет. Значит, сама система повышений какая-то сомнительная, и он разочарован, что она отразилась на нем. Это уже сам по себе довольно весомый повод отказаться от работы в компании: она не замечает результаты работы сотрудника (что и было продемонстрировано при дальнейшем разборе ситуации), и даже более того - иногда язвит на эту тему выражениями типа low performer.

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

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

Information

Rating
Does not participate
Registered
Activity