А зачем тогда разработчику нужен заказчик, если он сам прекрасно знает, как развивать продукт? Сделал бы свой да занимался им.
Вы описали роли продуктолога и аналитика, но никак не разработчика. Из-за такого смешения ответственности и осуперменивания разработчиков и происходит описанное в статье. Это уже не разработка, а хаос. Разработка это как раз воплощение идей в коде и архитектуре приложения.
Замечал, что чем больше хаоса в процессах компании, тем меньше удается писать код. Основное время начинает занимать варево в этом хаосе либо попытках его упорядочить. И упорядочивание хаоса в рамках команды довольно реально, если все понимают свои роли и цели. Но на межкомандном взаимодействии часто идет просадка и давление. А частое межкомандное взаимодействие нередко порождает расплывчатая изначальная цель функционала, который хочет инициатор.
Подобная статистика майкрософта лишь говорит о довольно посредственных процессах и отсутствии понимания ключевых результатов при разработке.
Для себя считаю идеальным 50/50 после примерно 15 лет в разработке. В периоды джуномиддловости эта пропорция была скорее в 80/20 в сторону кода. И важно, чтобы время было гармонично распределено: полдня - углубленный код, полдня - созвоны. Когда ты раз в час меняешь деятельность и переключаешься из кода в созвоны, ничего хорошего не получается. Помню, даже был инициатором dnd-времени в одной компании, где договорились разработку не тревожить в первую половину рабочего дня. Конечно, не всегда это срабатывало, но в целом, было поспокойнее.
Да, себестоимость комплектующих раза в 2-3 ниже стоимости устройства в магазинах.
Но тут еще нужно учитывать поддержку экосистемы, в разработку которой эппл вкладывается. У них далеко не бесплатный софт - его разработка и поддержка просто входит в стоимость товаров. Плюс пользователь оплачивает работу других отделов компании: маркетинга, логистики, r&d и т.д. Так что считать по себестоимости комплектующих в данном случае не совсем справедливо.
А младшие модели с худой комплектацией делаются в качестве завлекающего товара, чтобы в рекламе красивую цифру в "от" написать и скоординировать пользователя на средних или более дорогих моделях. Это давно известный маркетинговый ход, который много где применяется.
Apple были провидцами, потому так долго не отказывались от 8GB-ноутбуков :)
А если серьезно, то 8GB уже совсем ни на что не хватает и улетают только в путь с прожорливостью современного софта уже как несколько лет. Наверное, производители с таким подходом останутся без продаж.
Обычно представители бизнеса видят результат, и считают его приемлимым для продажи. А результат для них - это часто обложка приложения, которая всегда красивая и вылизанная. А тот факт, что за обложкой скрывается неподдерживаемое нечто обычно пропускается, т.к. у бизнеса нет в этом экспертизы, а деньги за обложку можно получить уже сегодня.
Бизнес сам ограничен коротким жизненным циклом продукта, и его цели чаще из себя представляют "сделать вчера и желательно бесплатно, чтобы завтра продать за миллионы". Такие условия диктует нестабильная экономика во всем мире.
И когда на этапе MVP разработчики говорят про то, что этот MVP нужно выкинуть и переписать, бизнес переключает их на другие более прибыльные проекты, а на доработку этого MVP ищет уже новую команду поддержки, которая посговорчивее, и еще не насытилась наследием. Таким образом и старые разработчики вроде как заняты и приносят прибыль на новых проектах, и новые разработчики пока не так сильно токсичат ковыряясь в MVP-наследии. А дальше уже исходя из того, какие MVP выстрелили, принимаются решения из разряда от "так уж и быть, выделим бюджет на прическу этого MVP, которое стало нести золотые яйца" до "ну не выстрелило, давайте забудем этот проект как страшный сон".
Самое страшное где-то посередине: когда проект полудохлый и приносит малый доход, бизнес рогом упирается и только пилит фичи, которые не нужны пользователю, а разработка уже эмоционально не выносит внутреннее состояние кода.
Да, талант вежливо нести чепуху всегда был в цене у людей. Послушаешь, и на душе легче становится. Особенно когда в теме плохо разбираешься, но слышишь складную речь.
Всегда старался обходить стороной подобных людей, т.к. чаще всего это мошенники или продажники. Причем, почти одинаковый эффект что от первых, что от вторых.
Наконец-то картинка складывается: "ИИ" - это автоматизированные скамеры, которые вежливо несут чушь, и берут за это деньги в виде подписок :)
Кажется, люди со "стратегическим нетворкингом" в любой сфере будут получать жирные места. Зумеры изобрели блат и кумовство?
Люди, которые вкладываются в подобное, как правило, уходят далеко от изначальных своих целей быть хорошим специалистом. Скорее, даже как-то так: пока прокачиваются скиллы охоты за большим куском, по пути базовые софты и харды начинают теряться, и только охота становится смыслом жизни.
1) Нейминг и однотипная структурированность важны практически везде. Будь то код, таблицы в БД, названия очередей или классов в коде. Чем однотипнее, тем меньше разборов полетов на тему "как назвать", и тем легче разбираться, т.к. глаза начинают привыкать к шаблону.
2) Только сериализация DTO не всегда спасает. Бывает, из сообщения удаляется важная часть этого DTO, или нужно, чтобы разобралась часть старых сообщений старым механизмом обработки, а новый алгоритм применился к новым сообщениям. И промежуток времени разбора может быть большим. Здесь помимо сериализации помогает выработка подхода к версионированию сообщений в очередях и в целом согласование содержимого сообщений: иногда из сообщения важен только id, а код уже по нему дальше восстанавливает необходимые данные из других источников при обработке. Или некоторые сложные типы данных могут иметь проблемы сериализации, если не уследить.
4) При увеличении фоновых задач появляются взаимосвязи между ними. Помимо id message рекомендую сохранять базовый request-id и parent-id, которые породили сообщение в очереди. Можно использовать для этого тот же трейсинг. Тогда будет легче контролировать путь процесса и понимать путь запроса пользователя, который привел к разбираемому случаю.
Лучше перебдеть, чем недобтеть, когда нанимаешь кого-то с зарплатой в 10 МРОТ и выше, а не чела, который будет на складе товары пикать и его "онбординг" займет полдня (при всем уважении к работникам складов и другим, без них не было бы у нас таких зарплат и работы)
А на это отвечу отдельно. Если ваша компания держится на человеке, который потребляет 10 МРОТ и не может посчитать, сколько ресурсов тратится на найм такого человека (а оно больше его 10 МРОТ в месяц), и какие убытки компания несет из-за недостатка этого человека (а тут уже могут из-за перенагрузки расформировываться отделы, если вовремя дыры по ресурсам в них не латать), то наличие вопросов из статьи лишь подчеркивает огромные пробелы в ее процессах.
Если создалась вакансия на большую зп, и компания из-за того, что на нее выйдет человек, с которым не срастется, понесет большие убытки, значит у компании что-то не так с распределением обязанностей.
Лучше заложиться на испытательный срок и подобрать другого кандидата по упрощенному процессу найма, чем по усложненному процессу найма пытаться процедить бриллианты. Потому что усложненный процесс найма в итоге сломан, и не гарантирует те самые бриллианты судя по ситуации в бигтехе.
Да не экономят они время тех, кто проводит тех. интервью, а скорее, создают дополнительную нагрузку на кадидатов. И усложняют процесс найма из-за появившейся многоэтапности собеседований. И увеличивают риск отвала кандидатов, потому что по своим личным фильтрам могут отсеивать людей, которых с руками отрывают другие компании, а в своей компании вакансии могут висеть по полгода. Из-за этих висящих по полгода вакансий нагрузка на проводящих тех. интервью только увеличивается, правда, с другой стороны: у них в команде перестает хватать ресурсов, пока hr-отдел в носу этими фильтрами ковыряет.
Мое имхо, эти вопросы - лишний слой абстракции, который только вредит процессу найма.
На самом деле, тех. интервью говорит и о софтах человека. Видна реакция на вопросы, подходы к ответам, отношения к тем или иным вещам при обсуждении технических деталей, эмоциональность, амбиции.
И даже на тех. интервью часто задаются вопросы к лиду и команде, т.к. он знает гораздо больше про сам процесс, чем hr. И это не абстрактные вопросы из разряда "кто вы из сериала друзья?", а прямые и конкретные про то, как дела в команде ведутся и что она из себя представляет.
Всегда hr-скую часть оценивал только для базового матча по вакансии: подходит ли стек, форма трудоустройства, размер команды и компании. Более серьезные вопросы задавал уже непосредственно тем, с кем предстояло работать в дальнейшем. Считаю кринжем, когда hr пытается играть в психолога и пропустить через свои фильтры вопросов, ответы на которые, как правило, не расскажут о тебе ровным счетом ничего, и которые можно выдумать на лету.
Все-таки довольно сложно перестраиваться с режима удаленки на офис и обратно.
Как я считал в доковидные времена: в офисе работа кипит, другие форматы - экзотика. В командах можно эффективнее выстраивать коммуникацию. Необходимое жилье - это место для отдыха, желательно поближе к офису, в квадратах можно поужаться.
Как мое мнение поменялось с ковидом: коммуникации успешно заменяются онлайном, а у компаний, которые это не осилили и до ковида были так себе процессы. На удаленке работа кипит порой сильнее, чем в офисе. География команд изменилась на корню. Необходимое жилье - это как минимум плюс отдельная комната-офис, местоположение уже каждый выбирает исходя из своих предпочтений: инфраструктура мегаполиса или больше квадратов в регионах.
И попадая в ситуацию, когда переводили на удаленку, человек настроил свою жизнь под нее, а потом его обратно зазывают в офис, люди попадают не просто в смену рабочего режима, а смену своего стиля жизни. Потому и идет такое сопротивление к ней у сотрудников. Они могли потратить очень много денег и сильно изменить свою жизнь в некоторых аспектах, чтобы согласиться с удаленкой, а тут к ним приходят и говорят: вертайте обратно.
И в доковидные времена я тратил на работу с учетом добирательств в офис по 10-14 часов в некоторых случаях. Я стал меньше болеть, стало меньше раздражения из-за посторонних звуков, запахов, ремонтов и прочих прелестей опенспейсов. Потому для меня возврат в офис будет очень печальной картиной, как бы работодатели этого не хотели. Буду до последнего искать удаленку в случае необходимости. Надеюсь, жизнь не заставит вернуться в офисный формат.
Под стыком интересов в данном случае подразумеваются противоречия между целями участников команды.
Пм может хотеть сдать все в срок или отчитаться за огромный объем работ, плюя на отношение к этому команды.
Лид может иметь хорошего исполнителя и не поручать ему более сложных задач, потому что не хочет терять хороший темп разработки.
Разработчик может хотеть в серьезные рефакторинги или отклонения в более интересные смежные темы, превращая простые задачи в сложные со множеством изменений и отклонением сроков.
Тестировщик может находить кейсы под микроскопом, шанс выпадения которых 1 из миллиона и они не сильно влияют на общую работу системы, потому что ему нравится такое мировосприятие, и он мотивируется такими тест-кейсами.
Владелец бизнеса может вообще считать, что это все сделается за день работы, и продаст эту идею инвесторам, не посоветовавшись с командой.
Так или иначе, у всех свои цели, и когда начинается столкновение и их усреднение в целях настройки антивыгорания, нужно понимать, что это приведет скорее к дисбалансу отношения к работе у участников коллектива, чем к устранению выгораний. Да, возможны улучшения "в среднем по больнице", когда компания запрещает переработки или другие факторы, влияющие на перегорание на уровне всех отделов, но даже в таких случаях всегда найдутся люди, которые начнут перегорать даже больше, потому что, например, привыкли работать в другой атмосфере, и текущая для них становится губительной.
Потому считаю, что борьба с выгораниями - это зачастую самодисциплина и выработанные горьким опытом упражнения отстаивания личных границ внутри участников коллектива, а не борьба с трендом в рамках целой компании.
Так заметно проще копить ресурсы. Любые переработки или срывы этого графика просишь согласовывать заранее. И отказываешься, если тебя это не устраивает. На самом деле, ни разу ко мне за это не применяли санкции. Бывала пара угроз в стиле "у таких людей обычно замедленный рост в компании" от начальства, но ты сам решаешь, что тебе важно: сгореть дотла за месяц с возможным повышением или стабильная работа в долгую, когда важна длительность.
Обычно срочность эмоциональна, и на самом деле не так важна. Мы редко в it спасаем жизни людей напрямую. Бывало, во время субботних просьб поработать говорил, что не у компьютера, а компьютер в другом городе. И находили других людей, которые согласились поработать. По итогу ту срочную субботнюю работу других людей не могли протестировать спустя месяц. Это один из многих пример, когда "тушение пожаров" было не обязательным. Напоминание всепропальщикам про такие случаи их нередко отрезвляет, и они начинают уже не так резко реагировать на подобное. Если же не помогает - переадресовать проблему руководству вспропальщика, который нагнетает атмосферу.
2) Отключение уведомлений рабочих каналов мессенджеров во внерабочее время.
Даже не установка корпоративных мессенджеров на телефон. Избавляет от возможности резко прервать свое время восстановления, и отваживает от соблазна ворваться в какое-либо обсуждение.
Однажды перед сном получил сообщение в стиле 1-то-1 от лида, который решил проанализировать мое поведение, и вылил на меня гору претензий. Сон был отложен на часа 2, получен дикий стресс с непредвиденными day off в течение пары дней, лид был на эмоциях послан куда подальше и уволился в течение месяца после инцидента. Считаю, ситуацию можно было спасти запланированным 1-to-1 с адекватным разбором ситуации, когда эмоции поутихли. Всему свое время.
3) Сокращение встреч с коллегами во внерабочее время.
Бывало, слишком сильно пересекалось личное и рабочее. Когда вы становитесь друзьями и границы смешиваются. Это влияет на восполнение ресурсов, т.к. ты не сменяешь свою активность, и в любой момент может возникнуть обсуждение рабочей ситуации, которое потребует анализа, разборов и снова работы. А на работе такое неформальное общение часто приводит к сбоям в процессах, потому что ты уже не воспринимаешь коллег как коллег, и начинаются элементы кумовства в ту или иную сторону.
Я согласен, что иногда тимбилдинги необходимы. Но когда доходит до "давай по несколько раз в неделю собираться и обсуждать в том числе и работу" - уже перебор. Даже более раза в две недели, наверное, слишком.
Что касаемо самой атмосферы в компании, чаще всего она не налаживается в рамках одной команды, и внешние факторы перевешивают весь радостный настрой сделать для всех хорошую атмосферу. Даже если начинаются порывы в эту сторону, обычно идет столкновение о том, что всем не угодишь: кому-то нет возможности дать интересные задачи, где-то ФОТ компании порезали, где-то диаметральнопротивоположные мнения у коллег не дают играть в продуктивную и невыгорающую настройку коллектива, где-то пожары - это и есть работа команды, и без них ее расформируют к чертям и т.д. Чем больше коллектив, тем сложнее угодить всем, и выгорания чаще всего встречаются на стыке интересов коллег.
Там от hr ловушка в сторону "Ну вы же общались наверняка с другой командой, а команд у нас много, и может с этой срастется, и все будет иначе". И в больших компаниях это часто так. Бывает, в разрезе одной компании существует несколько миров.
Понятно. Сеанс психологии по комментариям. Ок, удачи вам.
К слову, я почти всегда проводил собеседования с кем-то. Это были, например, hr, тимлид другой команды, cto, начальник компании. И корректировал собеседования по обратной связи в том числе и напарников. И ни разу за много команд и опыта работы мне никто не сказал, что я кого-то валю или предвзято к кому-то отношусь на собеседовании. Видимо, вы лучше знаете.
Никогда не было настроя "завалить лоха" на собеседовании. Всегда задаю практически одни и те же вопросы. Копаю вглубь ответвлениями, но это скорее шанс получить доп. баллы в виде бонусной части, и эти ответвления подключаю только когда вижу, что человек хорошо ответил на первичный вопрос.
Я прекрасно знаю, что иногда у талантов довольно куцые резюме. Ни разу не отсеял человека по стилю оформления опыта. Говорю лишь о личной статистике. Чем обоснованы ваши предположения, что я ехидствую, да еще и самоутверждаюсь при проведении собеседования мне совсем не понятно.
А зачем тогда разработчику нужен заказчик, если он сам прекрасно знает, как развивать продукт? Сделал бы свой да занимался им.
Вы описали роли продуктолога и аналитика, но никак не разработчика. Из-за такого смешения ответственности и осуперменивания разработчиков и происходит описанное в статье. Это уже не разработка, а хаос. Разработка это как раз воплощение идей в коде и архитектуре приложения.
Замечал, что чем больше хаоса в процессах компании, тем меньше удается писать код. Основное время начинает занимать варево в этом хаосе либо попытках его упорядочить. И упорядочивание хаоса в рамках команды довольно реально, если все понимают свои роли и цели. Но на межкомандном взаимодействии часто идет просадка и давление. А частое межкомандное взаимодействие нередко порождает расплывчатая изначальная цель функционала, который хочет инициатор.
Подобная статистика майкрософта лишь говорит о довольно посредственных процессах и отсутствии понимания ключевых результатов при разработке.
Для себя считаю идеальным 50/50 после примерно 15 лет в разработке. В периоды джуномиддловости эта пропорция была скорее в 80/20 в сторону кода. И важно, чтобы время было гармонично распределено: полдня - углубленный код, полдня - созвоны. Когда ты раз в час меняешь деятельность и переключаешься из кода в созвоны, ничего хорошего не получается. Помню, даже был инициатором dnd-времени в одной компании, где договорились разработку не тревожить в первую половину рабочего дня. Конечно, не всегда это срабатывало, но в целом, было поспокойнее.
Эххх, а я думал таки найду соответствие заголовка с содержимым в статье :(
Так когда закончатся сокращения?
Да, себестоимость комплектующих раза в 2-3 ниже стоимости устройства в магазинах.
Но тут еще нужно учитывать поддержку экосистемы, в разработку которой эппл вкладывается. У них далеко не бесплатный софт - его разработка и поддержка просто входит в стоимость товаров. Плюс пользователь оплачивает работу других отделов компании: маркетинга, логистики, r&d и т.д. Так что считать по себестоимости комплектующих в данном случае не совсем справедливо.
А младшие модели с худой комплектацией делаются в качестве завлекающего товара, чтобы в рекламе красивую цифру в "от" написать и скоординировать пользователя на средних или более дорогих моделях. Это давно известный маркетинговый ход, который много где применяется.
Странный у вас обычный пользователь.
Почта, что-нибудь офисное для простых документов, мессенджер, фотки, заметки, мультимедия, торренты, впн. Это без углубления в проф. софт.
Вот и набежало желающих забить все.
Apple были провидцами, потому так долго не отказывались от 8GB-ноутбуков :)
А если серьезно, то 8GB уже совсем ни на что не хватает и улетают только в путь с прожорливостью современного софта уже как несколько лет. Наверное, производители с таким подходом останутся без продаж.
Обычно представители бизнеса видят результат, и считают его приемлимым для продажи. А результат для них - это часто обложка приложения, которая всегда красивая и вылизанная. А тот факт, что за обложкой скрывается неподдерживаемое нечто обычно пропускается, т.к. у бизнеса нет в этом экспертизы, а деньги за обложку можно получить уже сегодня.
Бизнес сам ограничен коротким жизненным циклом продукта, и его цели чаще из себя представляют "сделать вчера и желательно бесплатно, чтобы завтра продать за миллионы". Такие условия диктует нестабильная экономика во всем мире.
И когда на этапе MVP разработчики говорят про то, что этот MVP нужно выкинуть и переписать, бизнес переключает их на другие более прибыльные проекты, а на доработку этого MVP ищет уже новую команду поддержки, которая посговорчивее, и еще не насытилась наследием. Таким образом и старые разработчики вроде как заняты и приносят прибыль на новых проектах, и новые разработчики пока не так сильно токсичат ковыряясь в MVP-наследии. А дальше уже исходя из того, какие MVP выстрелили, принимаются решения из разряда от "так уж и быть, выделим бюджет на прическу этого MVP, которое стало нести золотые яйца" до "ну не выстрелило, давайте забудем этот проект как страшный сон".
Самое страшное где-то посередине: когда проект полудохлый и приносит малый доход, бизнес рогом упирается и только пилит фичи, которые не нужны пользователю, а разработка уже эмоционально не выносит внутреннее состояние кода.
Да, талант вежливо нести чепуху всегда был в цене у людей. Послушаешь, и на душе легче становится. Особенно когда в теме плохо разбираешься, но слышишь складную речь.
Всегда старался обходить стороной подобных людей, т.к. чаще всего это мошенники или продажники. Причем, почти одинаковый эффект что от первых, что от вторых.
Наконец-то картинка складывается: "ИИ" - это автоматизированные скамеры, которые вежливо несут чушь, и берут за это деньги в виде подписок :)
Кажется, люди со "стратегическим нетворкингом" в любой сфере будут получать жирные места. Зумеры изобрели блат и кумовство?
Люди, которые вкладываются в подобное, как правило, уходят далеко от изначальных своих целей быть хорошим специалистом. Скорее, даже как-то так: пока прокачиваются скиллы охоты за большим куском, по пути базовые софты и харды начинают теряться, и только охота становится смыслом жизни.
Немного дополню
1) Нейминг и однотипная структурированность важны практически везде. Будь то код, таблицы в БД, названия очередей или классов в коде. Чем однотипнее, тем меньше разборов полетов на тему "как назвать", и тем легче разбираться, т.к. глаза начинают привыкать к шаблону.
2) Только сериализация DTO не всегда спасает. Бывает, из сообщения удаляется важная часть этого DTO, или нужно, чтобы разобралась часть старых сообщений старым механизмом обработки, а новый алгоритм применился к новым сообщениям. И промежуток времени разбора может быть большим. Здесь помимо сериализации помогает выработка подхода к версионированию сообщений в очередях и в целом согласование содержимого сообщений: иногда из сообщения важен только id, а код уже по нему дальше восстанавливает необходимые данные из других источников при обработке. Или некоторые сложные типы данных могут иметь проблемы сериализации, если не уследить.
4) При увеличении фоновых задач появляются взаимосвязи между ними. Помимо id message рекомендую сохранять базовый request-id и parent-id, которые породили сообщение в очереди. Можно использовать для этого тот же трейсинг. Тогда будет легче контролировать путь процесса и понимать путь запроса пользователя, который привел к разбираемому случаю.
А на это отвечу отдельно. Если ваша компания держится на человеке, который потребляет 10 МРОТ и не может посчитать, сколько ресурсов тратится на найм такого человека (а оно больше его 10 МРОТ в месяц), и какие убытки компания несет из-за недостатка этого человека (а тут уже могут из-за перенагрузки расформировываться отделы, если вовремя дыры по ресурсам в них не латать), то наличие вопросов из статьи лишь подчеркивает огромные пробелы в ее процессах.
Если создалась вакансия на большую зп, и компания из-за того, что на нее выйдет человек, с которым не срастется, понесет большие убытки, значит у компании что-то не так с распределением обязанностей.
Лучше заложиться на испытательный срок и подобрать другого кандидата по упрощенному процессу найма, чем по усложненному процессу найма пытаться процедить бриллианты. Потому что усложненный процесс найма в итоге сломан, и не гарантирует те самые бриллианты судя по ситуации в бигтехе.
Да не экономят они время тех, кто проводит тех. интервью, а скорее, создают дополнительную нагрузку на кадидатов. И усложняют процесс найма из-за появившейся многоэтапности собеседований. И увеличивают риск отвала кандидатов, потому что по своим личным фильтрам могут отсеивать людей, которых с руками отрывают другие компании, а в своей компании вакансии могут висеть по полгода. Из-за этих висящих по полгода вакансий нагрузка на проводящих тех. интервью только увеличивается, правда, с другой стороны: у них в команде перестает хватать ресурсов, пока hr-отдел в носу этими фильтрами ковыряет.
Мое имхо, эти вопросы - лишний слой абстракции, который только вредит процессу найма.
На самом деле, тех. интервью говорит и о софтах человека. Видна реакция на вопросы, подходы к ответам, отношения к тем или иным вещам при обсуждении технических деталей, эмоциональность, амбиции.
И даже на тех. интервью часто задаются вопросы к лиду и команде, т.к. он знает гораздо больше про сам процесс, чем hr. И это не абстрактные вопросы из разряда "кто вы из сериала друзья?", а прямые и конкретные про то, как дела в команде ведутся и что она из себя представляет.
Всегда hr-скую часть оценивал только для базового матча по вакансии: подходит ли стек, форма трудоустройства, размер команды и компании. Более серьезные вопросы задавал уже непосредственно тем, с кем предстояло работать в дальнейшем. Считаю кринжем, когда hr пытается играть в психолога и пропустить через свои фильтры вопросов, ответы на которые, как правило, не расскажут о тебе ровным счетом ничего, и которые можно выдумать на лету.
Все-таки довольно сложно перестраиваться с режима удаленки на офис и обратно.
Как я считал в доковидные времена: в офисе работа кипит, другие форматы - экзотика. В командах можно эффективнее выстраивать коммуникацию. Необходимое жилье - это место для отдыха, желательно поближе к офису, в квадратах можно поужаться.
Как мое мнение поменялось с ковидом: коммуникации успешно заменяются онлайном, а у компаний, которые это не осилили и до ковида были так себе процессы. На удаленке работа кипит порой сильнее, чем в офисе. География команд изменилась на корню. Необходимое жилье - это как минимум плюс отдельная комната-офис, местоположение уже каждый выбирает исходя из своих предпочтений: инфраструктура мегаполиса или больше квадратов в регионах.
И попадая в ситуацию, когда переводили на удаленку, человек настроил свою жизнь под нее, а потом его обратно зазывают в офис, люди попадают не просто в смену рабочего режима, а смену своего стиля жизни. Потому и идет такое сопротивление к ней у сотрудников. Они могли потратить очень много денег и сильно изменить свою жизнь в некоторых аспектах, чтобы согласиться с удаленкой, а тут к ним приходят и говорят: вертайте обратно.
И в доковидные времена я тратил на работу с учетом добирательств в офис по 10-14 часов в некоторых случаях. Я стал меньше болеть, стало меньше раздражения из-за посторонних звуков, запахов, ремонтов и прочих прелестей опенспейсов. Потому для меня возврат в офис будет очень печальной картиной, как бы работодатели этого не хотели. Буду до последнего искать удаленку в случае необходимости. Надеюсь, жизнь не заставит вернуться в офисный формат.
Под стыком интересов в данном случае подразумеваются противоречия между целями участников команды.
Пм может хотеть сдать все в срок или отчитаться за огромный объем работ, плюя на отношение к этому команды.
Лид может иметь хорошего исполнителя и не поручать ему более сложных задач, потому что не хочет терять хороший темп разработки.
Разработчик может хотеть в серьезные рефакторинги или отклонения в более интересные смежные темы, превращая простые задачи в сложные со множеством изменений и отклонением сроков.
Тестировщик может находить кейсы под микроскопом, шанс выпадения которых 1 из миллиона и они не сильно влияют на общую работу системы, потому что ему нравится такое мировосприятие, и он мотивируется такими тест-кейсами.
Владелец бизнеса может вообще считать, что это все сделается за день работы, и продаст эту идею инвесторам, не посоветовавшись с командой.
Так или иначе, у всех свои цели, и когда начинается столкновение и их усреднение в целях настройки антивыгорания, нужно понимать, что это приведет скорее к дисбалансу отношения к работе у участников коллектива, чем к устранению выгораний. Да, возможны улучшения "в среднем по больнице", когда компания запрещает переработки или другие факторы, влияющие на перегорание на уровне всех отделов, но даже в таких случаях всегда найдутся люди, которые начнут перегорать даже больше, потому что, например, привыкли работать в другой атмосфере, и текущая для них становится губительной.
Потому считаю, что борьба с выгораниями - это зачастую самодисциплина и выработанные горьким опытом упражнения отстаивания личных границ внутри участников коллектива, а не борьба с трендом в рамках целой компании.
Приемы, которые я выработал для себя лично:
1) Работа в четком постоянном графике.
Так заметно проще копить ресурсы. Любые переработки или срывы этого графика просишь согласовывать заранее. И отказываешься, если тебя это не устраивает. На самом деле, ни разу ко мне за это не применяли санкции. Бывала пара угроз в стиле "у таких людей обычно замедленный рост в компании" от начальства, но ты сам решаешь, что тебе важно: сгореть дотла за месяц с возможным повышением или стабильная работа в долгую, когда важна длительность.
Обычно срочность эмоциональна, и на самом деле не так важна. Мы редко в it спасаем жизни людей напрямую. Бывало, во время субботних просьб поработать говорил, что не у компьютера, а компьютер в другом городе. И находили других людей, которые согласились поработать. По итогу ту срочную субботнюю работу других людей не могли протестировать спустя месяц. Это один из многих пример, когда "тушение пожаров" было не обязательным. Напоминание всепропальщикам про такие случаи их нередко отрезвляет, и они начинают уже не так резко реагировать на подобное. Если же не помогает - переадресовать проблему руководству вспропальщика, который нагнетает атмосферу.
2) Отключение уведомлений рабочих каналов мессенджеров во внерабочее время.
Даже не установка корпоративных мессенджеров на телефон. Избавляет от возможности резко прервать свое время восстановления, и отваживает от соблазна ворваться в какое-либо обсуждение.
Однажды перед сном получил сообщение в стиле 1-то-1 от лида, который решил проанализировать мое поведение, и вылил на меня гору претензий. Сон был отложен на часа 2, получен дикий стресс с непредвиденными day off в течение пары дней, лид был на эмоциях послан куда подальше и уволился в течение месяца после инцидента. Считаю, ситуацию можно было спасти запланированным 1-to-1 с адекватным разбором ситуации, когда эмоции поутихли. Всему свое время.
3) Сокращение встреч с коллегами во внерабочее время.
Бывало, слишком сильно пересекалось личное и рабочее. Когда вы становитесь друзьями и границы смешиваются. Это влияет на восполнение ресурсов, т.к. ты не сменяешь свою активность, и в любой момент может возникнуть обсуждение рабочей ситуации, которое потребует анализа, разборов и снова работы. А на работе такое неформальное общение часто приводит к сбоям в процессах, потому что ты уже не воспринимаешь коллег как коллег, и начинаются элементы кумовства в ту или иную сторону.
Я согласен, что иногда тимбилдинги необходимы. Но когда доходит до "давай по несколько раз в неделю собираться и обсуждать в том числе и работу" - уже перебор. Даже более раза в две недели, наверное, слишком.
Что касаемо самой атмосферы в компании, чаще всего она не налаживается в рамках одной команды, и внешние факторы перевешивают весь радостный настрой сделать для всех хорошую атмосферу. Даже если начинаются порывы в эту сторону, обычно идет столкновение о том, что всем не угодишь: кому-то нет возможности дать интересные задачи, где-то ФОТ компании порезали, где-то диаметральнопротивоположные мнения у коллег не дают играть в продуктивную и невыгорающую настройку коллектива, где-то пожары - это и есть работа команды, и без них ее расформируют к чертям и т.д. Чем больше коллектив, тем сложнее угодить всем, и выгорания чаще всего встречаются на стыке интересов коллег.
Там от hr ловушка в сторону "Ну вы же общались наверняка с другой командой, а команд у нас много, и может с этой срастется, и все будет иначе". И в больших компаниях это часто так. Бывает, в разрезе одной компании существует несколько миров.
Понятно. Сеанс психологии по комментариям. Ок, удачи вам.
К слову, я почти всегда проводил собеседования с кем-то. Это были, например, hr, тимлид другой команды, cto, начальник компании. И корректировал собеседования по обратной связи в том числе и напарников. И ни разу за много команд и опыта работы мне никто не сказал, что я кого-то валю или предвзято к кому-то отношусь на собеседовании. Видимо, вы лучше знаете.
Никогда не было настроя "завалить лоха" на собеседовании. Всегда задаю практически одни и те же вопросы. Копаю вглубь ответвлениями, но это скорее шанс получить доп. баллы в виде бонусной части, и эти ответвления подключаю только когда вижу, что человек хорошо ответил на первичный вопрос.
Я прекрасно знаю, что иногда у талантов довольно куцые резюме. Ни разу не отсеял человека по стилю оформления опыта. Говорю лишь о личной статистике. Чем обоснованы ваши предположения, что я ехидствую, да еще и самоутверждаюсь при проведении собеседования мне совсем не понятно.