- неимоверные
- титанические
- сверх

усилия...

и прочие восхваляющие эпитеты с нечто называемым "калибровка" в рамках перформанс ревью (гуглите сами).

У вас есть такая тема?

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

#management

Про ящики в тестировании и не только, в пятничных #it_memes
Картинки из далекого прошлого.

McKinsey Gets Developer Productivity Wrong

I know exactly what happens when you have people focus on their individual output. I’ve measured the outcomes. I can only assume that McKinsey doesn’t understand “systems thinking.” The outcome is what I call a “pandemonium of developers.” You have a group of people all working on the same backlog but not acting as a team. Code review suffers, mentoring sufferers, pairing is impossible, work decomposition suffers, etc. Anything that requires more than one person, including helping someone get unstuck, will be deprioritized. Never measure individual output: ever.

🤝

As for “if a quality assurance tester has enough work to do,” tell me you don’t understand what QA should be doing on a team without telling me. Their job isn’t to test. Their job is to improve how testing is done.

🤝

For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.

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

Как определить компанию, где может работать продуктивность по МакКинзи - картинка в комментах.

#metrics

Leadership isn't just about implementing solutions; it's about steering the team through the discomfort of change - and creating and growing a culture where teams can solve any problem they face.

Why you can't solve every problem with the same hammer

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

К сожалению, не всегда это учитывается...

#management

Про даты в граните...

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

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

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

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

И вы понятия не имеете, почему.
А ответ прямо здесь: вы больше не двигаетесь быстро из-за ВАШЕЙ коммуникации.

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

Что вы могли сделать вместо этого?
Когда команда не уложилась в дату релиза, вы могли бы поддержать ее вместо того, чтобы наказывать лидеров команды.
Можно использовать эту возможность, для создания и поддержки культуры решения амбициозных задач с вызовом.
Вы могли бы сказать:
"Я понимаю, почему вы не попали в обозначенную дату релиза.
Но я бы предпочел, чтобы вы оставались амбициозными и иногда не укладывались в дату, чем были консервативными и всегда попадали.
Я не хочу, чтобы вы перестали быть амбициозными по умолчанию.
И мы хотим, чтобы больше команд были такими, как вы".

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

Тем не менее, давайте объясню:
1. Большинство дат запусков не должны быть зафиксированы внешними обязательствами.
2. Но для каких-то запусков все же требуются внешние обязательства (перед клиентами, или регулирующими органами, или партнерами и тдтп)
3. Для запусков из п2 определите консервативную дату, которую вы почти наверняка достигнете.
4. Но даже для них попросите команду проработать амбициозную внутреннюю дату. Ничего страшного, если они не уложатся в эту дату. Но важно иметь эту цель.

Почему? Потому что помните закон Паркинсона: "Работа заполняет все время, отпущенное на неё..."

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

Хотя, если вы все еще хотите сохранить свою увлеченность достижением всех дат, я не уверен, что смогу (или даже хочу) убедить вас в обратном.

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

PS я уже слишком ленив написать такое сам, поэтому это просто вольный перевод, но подписываюсь под каждым словом
#management

Никогда такого не было и вот опять февральская релизная пятница в #it_memes

Эмоции и менеджмент...

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

Кажется тут речь про "человеколюбивые" эмоции, но может и про эмоции в принципе...

#management

А давайте об интересном феномене...
Почему люди работают в одной компании 10, 15, 20 😱 лет?
Что их удерживает от смены того, что происходит вокруг?

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

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

В то же время, я не понимаю, что и как успевают сделать полезного люди уровнем выше обычного разработчика (и тем более CTO), если потратили в компании меньше 3 лет. Ты даже не сможешь увидеть результаты своего труда.
Эмм, не, ну результаты то все же можно увидеть, но не факт, хорошие.

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

#мысли_вслух

Тут прилетела напоминалочка про "гастроль" 10-летней давности. Улыбнулся, смахнул скупую слезу, поехал на работу.
Болтали тогда про технический долг, много веселых картинок (ссылка на pdf).
Идеи и решения остались те же, но уже кажутся наивной банальностью.

#байки

И снова релизно-пятничные #it_memes, потому что релизы в самом разгаре...

Как рождаются лиды в командах:
"И среди команды (разработки) обычно находятся люди, с мутациями..."

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

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

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

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

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

#мысли_вслух про #management за чашкой утреннего кофе

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

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

Полезно для нервного здоровья. И важно, даже когда ваши тесты еще не до конца стабильно окрасились в позитивно-зеленый.

#байки #test_automation

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

На этой неделе было мало заметок, на полноценные пятничные #it_memes не наработали. Поэтому - философия.

PS пишите в комментах #ваши_вопросы, у меня кризис жанра, при котором тянет на философию, от которой все разбегаются 😃

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

Для тех, кто еще уважает и помнит, что такое dynamic_cast: первый день С++ Russia 2025 13 марта - бесплатный Community Day.

От МойОфис в программе ребята, с которыми мы плотно пересекаемся каждый спринт на проверках наших сервисов в рамках SSDLC.

PS слава Байту, С++ кода в командах Облака немного 🫠
PS2 а было время... Можете заценить то, что было в программе 2016. Сейчас она стала более прикладной.

Кстати, C++ Russia в этом году 10 лет. И я застал ее еще "в пеленках", когда ее организовывал и проводил 1 человек, Сергей Платонов. Я до сих поражаюсь его тогдашнему упорству и энтузиазму.

А какой менеджер ты?

• Motivator/Team Builder
• Role model/Expert
• Teacher/Mentor/Coach
• Champion/Sponsor
• Go-between/Shield
• Process designer/Organizer
• Goal setter/Driver

#management

О риск-менеджменте.
Часто если не бесполезное, но где-то рядом (сугубо на моем персональном опыте, может мне не везло). А самое ценное там - это процесс, а не артефакты. Тот риск, который кажется более вероятным, скорее всего никогда не сработает. Но сработает тот, про который никто и не думал (здравствуй, черный лебедь).

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

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

На фото из далекого прошлого матчасть одной из встреч по категоризации и приоритезации рисков.

#процессы

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

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

Интересно, а разработчикам отказывают с такой мотивировкой или это только менеджерские приколы? Ну не только же мои? 🤔

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

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

#собеседования #management

Простой пробельчик, а сколько нюансов, эмоций и ощущений.

Целеполагание в пятничных #it_memes

Есть ведь тут джависты?
PS кстати, канал в целом прикольный :)

Друзья джависты и сочувствующие, очень нужна ваша помощь!

Мы тут в JUG хотим сделать доклад про тренды Java-мира в РФ. Это будет просто дичайший результат, если мы коллективными коммьюнити усилиями соберем хорошее количество ответов для нашего техрадара. И мне очень нужна ваша помощь: пожалуйста, пройдите опрос, чтобы мы могли сделать из этого уникальный, прикольный и клевый доклад.

И большая просьба, если у вас есть свой канал, помогите сообществу и сделайте репост, это правда важно нам для того, чтобы не тухнуть ♥️🙏