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

"Садись к огоньку, юный манагер. Я расскажу тебе историю. Она будет в меру поучительна, если ты уловишь смысл. Если не уловишь, то хотя бы развлечешься. Тебе понадобиться хорошее настроение, юный манагер. Твой путь будет сложен. На нем тебе встретятся странные люди. Ты даже потеряешь веру в либеральные принципы управления. Все, юный манагер, чему тебя учили, окажется лажей. Жизнь проще и жестче. Поэтому садись, садись рядом. Выкини ты эти книги. Выброси конспекты. Я расскажу тебе как будет. Всю правду, без прикрас. И начнем мы с «человека под фонарем». Что, ты не знаешь кто это? Не удивительно. Хотя это будет твоим первым и главным испытанием. Пройдешь «человека под фонарем» – станешь настоящим манагером. Может быть..."

Читайте дальше

Какая чудесная метафора: "человек под фонарем".
У меня тоже есть похожая, но сильно грубее. Как-нибудь попозже расскажу.
ЗЫ вообще Дмитрий очень красиво пишет, завидую. Были мысли попробовать писать так же, но лень победила :)
#management

Сегодня не традиционно-разгрузочный пятничный мем, а философский.
Картина называется "Подводя итоги..."
#it_memes

Меня тут иногда спрашивают вопросы формата "а что делать если..."
Хорошо, когда в статье, уже есть готовая инструкция о сложном:
How To Fix Broken Teams

#management

“Хороший тестировщик имеет сердце разработчика…”
...
“…в банке на своем столе”

Старая, но интересная статья пропитанная вечной историей "борьбы" "создателей" и "разрушителей". И про то, как из этого выруливать.

#testing

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

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

Вопросы из комментов:
• Что делать с "человеком под фонарем"?

1. Сделать эту проблему (если вы ее видите, как проблему) прозрачной и понятной для сотрудника
2. Убедиться в том, что он разделяет твою точку зрения
3. 95% сделано ✅
4. Дальше работаем по хештегу #развитие и совместно с сотрудником "делаем фонарь встроенным в его голову"

• "А как убедиться, что проблема действительно прозрачна и понятна для сотрудника, а не он просто дакает, что понимает её, чтобы от него отстали?
И второй вопрос: а если дакает, но не разделяет?"

Если он продолжает делать то, что обсуждалось, как желаемое к исправлению, то это повод к дальнейшему обсуждению. Скорее всего неоднократному. 🙂

И если он снова "да"-кает, то ты оцениваешь риски, взвешиваешь +/- и принимаешь решение по формуле "менять людей нельзя надо менять людей" 😏
Допускаю, что звучит очень прямолинейно и жестко.
Но все дело в волшебных пузырьках в рисках и +/-.
Это и есть основная работа менеджера: получить информацию, собрать контекст, его обработать и принимать решения.
Риски всегда будут разные и иногда приходится принимать компромиссные решения. Не всегда они будут правильными и помогут на периоде времени. Но у всех же есть право на ошибку. Важно уметь ее признавать и идти исправлять.

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

#ваши_вопросы #management #развитие

Не мемный пост, хотя и пятничный.
Я человек обычно достаточно прямолинейный и честный. Иногда (часто?) это выходит боком, но какой есть.
И афоризмы у меня такие же обычно. Те кто со мной уже давно по работе могут помнить знаменитые “натянуть презерватив на кактус” как пример выполненной, но бесполезной работы или “нога в навозе”, которая у меня заменяет красивое “человек под фонарем”.

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

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

- А давайте добавим еще один спринт к релизу?
- Давайте, но только вам итоговую сборку надо отдать за неделю до релиза
- 🤝
.... так начинался запуск натурного эксперимента "Первый закон Паркинсона* в IT". Эксперимент признан успешным, закономерность подтверждена.

* "Работа заполняет время, отпущенное на неё."
PS любые совпадения с реальностью являются плодом вашего воображения
#байки

Want Better and Faster Results? Increase Team Size and Reduce WIP
Кажущаяся логичной история: взяли в работу N фичей одновременно (где N - количество разрабов в команде), нет проблем с синхронизацией, нет необходимости декомпозировать задачи для параллельной разработки, каждый пилит свою историю и тп, на самом деле ловушка.
Ловушка, которая приводит к тому, что высок риск получить все N задач невыполненными (недоделанными, непротестированными, несогласованными).
Меньше одновременно выполняемых задач - быстрее движение вперед.

#процессы

А вы знаете про такую практику, как Manager's ReadMe?
Это когда менеджер в коротком общедоступном виде описывает свои ожидания, формат работы и взаимодействия с ним в рабочих процессах.
Практика далеко не новая, а ее популярность то растет, то снова затихает.
Полезно или нет, не знаю. Отношусь двояко, и хотя в своей работе я никогда так не формализовывал эту информацию, но что-то подобное в виде презентации было, под названием “Встреча про GTO (для новичков)” (привет прошлой компании).
А недавно подумал, что этот канал тоже можно воспринимать как ReadMe (правда в неудобном long read и спонтанном формате), особенно на фоне того, что в подписчиках стало больше коллег.
Еще вариант такого ReadMe (от человека, которого я уважаю).

Сталкивался ли кто-то с таким в реале (делал сам или такое было у его руководителя)?

#management

Приквел к ADR (которые мы уже обсуждали): а как принимать архитектурные решения?

Architecture Principles: An approach to effective decision making in software architecture

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

#tech_read

В каждом вопросе есть половина ответа...
"сколько времени вам нужно, чтобы зарелизить нечто похожее на то, что дока описывает, к концу следующего года?" (с) М.Шульга
#байки #мысли_вслух

Вовремя сданный релиз - это всегда чья-то недоработка...
#мысли_вслух

Короткий трейлер к сериалу "Релиз".

пятничные #it_memes

Thoughts And Reasons Behind Dysfunctional Software Engineering Teams
•Believers in “self-commenting code”.
•Code review drama.
•Nobody questions the status quo.
•No bond with your boss.
•Too many cooks in the kitchen for every single thing.
•Layers and layers of useless managers.
•Backlog clusterfuck.
•The release process is only theoretical.
•Product planning is apparently against “agile”.
•Team balance doesn’t exist.
•Glorification of overworking.
•Blame culture and silos.
•Last-minute vacations (unexpected absence is common).
•Tasks & tickets are as clear as Covid lockdown rules.
•Your Slack chanelofobia becomes a real thing.
•Only key players are allowed to participate in discussions.
•The feedback loop is the thing when you hear yourself on Zoom calls.
•Trust no one!

#процессы

The 300% Production Problem

The definition of the 300% problem is:

To successfully get an application into production, you need to be an expert in the application itself, the deployment target and the deployment methodology.
Each of these expertise layers is a full-time job or undertaking. If you’re lucky, you have more than one person who needs to be an expert on all these 3 layers. If you’re unlucky, you might read this and think, “holy shit, no wonder I’m burned out”.
...
People have been writing about keeping “Keep it simple stupid” for a long time. The problem is that the “simplicity” is often defined by the people building the system, and those people are experts already in the system they’re building.

Все хорошо в этой статье, но предпоследний абзац (тот что с "what is often overlooked") сломал мне мозг. Или там инверсия написана к тому, что в последнем абзаце.
Или я его неправильно перевожу :)

#it_философия

Testing Strategies in a Microservice Architecture
Хорошая выжимка по возможным видов автотестов для микросервисов.
Статье уже 10 лет, а наблюдаемые мной проблемы понимания того, что и как может тестироваться не меняются: большинство все так же используют только end2end тесты и даже не сервисов, а всей системы. Лишь иногда "декларируя" наличие юнит-тестов.
#test_automation

"Если сделать кое-как, потом исправим - получится фигня, которую мы перепишем, если нас не уволят" (с) из древних интернетов

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

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

Сложный пятничный ребус: расставь картинки в правильном порядке 😏
#it_memes

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

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

Мощная серия статей "Bottlenecks of Scaleups".
Я зацепился за онбординг, а там целая пачка полезностей.

• Accumulation of tech debt; experiments and shortcuts are core components
• Constrained by talent and struggling to attract top technologists
• Friction Between Product and Engineering; Lack of trust and collaboration slowing down product growth
• Surging cloud and managed services costs outpacing customer growth
• Service disruptions; production incidents reduce reputation and revenue
• Onboarding; Too long for new hires to reach full effectiveness

#management #процессы