Минутка злоупотребления служебным положением в канале.

У меня в командах открыто 2 позиции:

Джун DevOps - имхо отличная тема для тех, кто хочет из техподдержки перейти в разработку или только вливается в тему. Пока основной фокус на тестировании и поддержке установки нашего продукта, но вообще девопс задач у нас море, скучно точно не будет. Так как джун, то гибрид в Питере.

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

Если есть вопросы - велком ✍️
Заходите сами, советуйте друзьям 🙂

Немного кофейного сумбура в попытке помусолить вопрос в комментах: “Agile часто превращается в формальность, когда бизнес давит. Как думаешь, можно ли вернуть реальную гибкость?”
Можно, вопрос на каком уровне?
Хорошо получалось там, где все остальные процессы вокруг (или до/после) разработки тоже на Agile-рельсах. Я про собственно бизнес/организацию.
Но чаще всего разработка играла в agile, а вокруг был или суровый энтерпрайз или просто бардак (хотя со стороны того же бизнеса и в разработке бардак, всегда 😃).
В общем, нюанс в том, на каком уровне этот Agile начинался и заканчивался.
Ну и степень вовлеченности сотрудников во все это действо влияла. Увлеченных людей в принципе немного, по жизни, и когда компания хочет расти приходится выбирать между "качеством" людей и скоростью роста. И в этом месте начинается трение в одном из пунктов манифеста про "людей и процессы".
В целом, если посмотреть на пункты манифеста, то в каждом можно найти моменты, которые своими понятийными нюансами уже больше 20 лет будоражат “общественность”.

“Люди и взаимодействие важнее процессов и инструментов” - в этом месте как раз сильно влияет вовлеченность.
“Работающий продукт важнее исчерпывающей документации” - уже избитое “это что же, мы не описываем как принимали решение” и даже архитектуру не прорабатываем?
“Сотрудничество с заказчиком важнее согласования условий контракта” - ага, скажи это заказчику у которого заявленная функциональность не работает, а у него от сроков внедрения премия зависит или штраф за нецелевое использование средств, потому что продукт в эксплуатацию не введен.
“Готовность к изменениям важнее следования плану” - и рядом “стратегия на 7 лет” или “годовой роадмап с объяснительными в случае отклонения”.

Или, слышал недавно такую гипотезу, Agile был придуман для заказной разработки, когда мы делаем типовую работу, которую понятно, как оценивать. При этом же именно при продуктовой разработке “проще” вовлечь команды в работу: ты видишь, как влияют принимаемые тобой/командой решения на то, как продукт живет, развивается и продается.
Ахаха, ага, а продается он сейлами, которые любят продавать привычные для себя вещи и то, что нужно заказчикам (даже если этого еще нет в продукте). Че ты там в продажах увидишь - хз.

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

#процессы #ваши_вопросы

Не умирайте, везде важен баланс 🙂

Следует ли при разработке программного обеспечения действовать реактивно или проактивно?
Стоит ли взять за основу YAGNI или Hammock Driven Development? Стоит ли использовать только Agile или водопадную методологию?

Ответ: Это всегда смесь умеренного количества того и другого. Лучший способ сбить проект с рельсов — идеологически требовать приверженности той или иной стороне.

Мудрые команды проведут какое-то время «в гамаке», обдумывая все как следует; но не настолько, чтобы упустить возможность отреагировать на динамичную среду, которая доминирует практически во всех программных проектах.

Если вы не планируете - вы умрете.
Если вы не отреагируете - вы умрете.

(с) отсюда от дяди Боба

#процессы

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

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

Как часто вы слышите фразу "нужно выделить время"?
Теперь, благодаря пятничным #it_memes, у вас будет возможность ее визуализировать.

Как связаны стратегия и васаби?

The 5C Strategy Framework: Why Most Companies Suck at Strategy

ЗЫ ответ: они оба чрезвычайно редки
#strategy

И снова про наши мои любимые специализации и "профессии". Одну из самых любимых...

We should have just said: “Hey, developers should deploy their own code.” More than that—they should also be responsible for keeping it running. They should monitor it, respond to issues, and use their programming skills to automate deployments so they’re safe, repeatable, and easy for the team to use. Production-minded developers (who are part of the team!) should do a little extra work to make things better for everyone. This was the correct mindset—a necessary shift away from isolated ops teams managing production without developer participation.

When cloud services arrived, this shift became even more natural. Spinning up a server was no different than calling an API. Infrastructure could be programmed. It could be versioned. It could be tested.

But then we made a terrible mistake: we gave it a name—DevOps.

Suddenly, developers who were good at working with production systems were given a new title. And as soon as “DevOps engineer”

...

Originally, DevOps was about trusting developers with production. But modern DevOps teams operate on the belief that developers can’t be trusted with production

...

So what did creating a “DevOps” role actually get us?

It pulled production-minded engineers off their teams and stripped those teams of both the interest and the permission to manage their own production environments. We ruined the idea of DevOps by formalizing it.

P.S. Platform Engineering is the same story. In the words of Yogi Berra, “It's déjà vu all over again.”

Спиралька...

In retrospect, DevOps was a bad idea.

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

Интересно, что нас ждет дальше?
Какие новые специальности уже наклевываются?

#holywar

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

"Багофикс в свежем деплое" в пятничных #it_memes

PS все совпадения с реальностью являются лишь плодом вашей фантазии

И снова про микроменеджмент.
Интересно про то, что это на самом деле не всегда плохо.
Но понятно, что это "это" у всех разное (см. прошлые мысли)

I’m not a micromanager, but I’m microinterested

Лучшие менеджеры умеют «подглядывать» — они знают, что происходит на поверхностном уровне, но углубляются в отдельные инициативы.

#management

Прикольненько...
Ох уж эти AI-инновации в продуктах :)

Храните пароли/ключи в записной книжке на столе 😂

Любишь нанимать, умей и увольнять…

#менеджерские_пословицы #management

Начинаем неделю “с ноги”

Есть 3 большие категории технических менеджеров:
1 - те, для кого в управлении техничка первична и остальное можно игнорировать
2 - те, кто верят в правильные процессы
3 - те, кто во главу угла ставят людей

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

Без технички в принципе не очень работает. Это база. Но тут речь про возможность менеджера понимать “язык” технарей и говорить на нем, а не про то, что “только на лида вся надежда, щас он все спроектирует и решит“ (это как раз “микроскоп”).

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

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

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

ЗЫ Есть еще 4я категория, те кто верят, что умеют, в какой-то из способов. А на самом деле ни в какой не умеют.

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

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

И важно скорее не то, знаешь ли ты его дословно, а как понимаешь суть.

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

Спонсор заметки: "новостная лента соцсетей" и определение "оракулы тестирования" (это была первая из прочитанных мной статей по теме ).
Тестировщики конечно в курсе (правда ведь? "мем с падме"), а остальным может быть интересно, добавить себе энциклопедических знаний 🙂

ЗЫ у меня есть универсальное определение на все, что не знаю: это "опыт и чуйка". Но не советую им пользоваться на регулярной основе.

#testing

Неожиданно (нет), но часто все, что вы думали придали сами, может быть придумано задолго до вас.

Here we deliberately alter the development team's organization structure to encourage the desired software architecture, an approach referred to as the Inverse Conway Maneuver

И вот это интересно

While the inverse Conway maneuver is a useful tool, it isn't all-powerful. If you have an existing system with a rigid architecture that you want to change, changing the development organization isn't going to be an instant fix. Instead it's more likely to result in a mismatch between developers and code that adds friction to further enhancement. With an existing system like this, the point of Conway's Law is that we need to take into account its presence while changing both organization and code base. And as usual, I'd recommend taking small steps while being vigilant for feedback.

ЗЫ но приятно, что ты однажды шлепая к метро, формулируешь, один в один, как Martin Fowler (ну ок, почти 😉)

ЗЫ2 но, обычно, никто про архитектуру не думает, а просто реструктурирует команды 🪄🙂

#it_философия

Когда инженер стал менеджером. Начало...

в пятничных #it_memes

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

Почему вообще появился канал?
Х-виттер стал угасать, да и мыслей больше пары предложений туда удобно не напишешь (а сейчас он превратился вообще непонятно во что). В блог писать все так же лень, да и заметки на пару предложений бессмысленны.
А мысли и полезные (чужие) статьи, которыми иногда хочется делиться, есть.
В телеге получается нечто среднее и временами можно несколько постов из телеги объединить в одну блог-заметку.

Наблюдения:
- Когда нет постов (пока, например, в отпуске) - 0 просмотров (старое в телеге никто не читает, уважаемый КО), но никто и не отписывается, как после некоторых постов 😃
- Индексируемый же гуглом блог регулярно продолжает посещаться с 3к (иногда до 7к) заходов в месяц (ох уж эти боты 😃)
- Приблизительно половина подписчиков тут регулярно читает посты, когда они появляются.
- Мне стало проще/удобнее доносить некоторые свои идеи на работе, правда я уже даже сам забываю, что уже писал про что-то
- Да, около четверти подписчиков - это старые знакомые и коллеги
Спасибо и сердечко всем кто читает, комментирует, ставит говняшки (вру конечно, никто никогда не ставил) и пересылает посты дальше. Отдельное спасибо тем, кто у себя в каналах рекомендует мой канал.

Заходите больше с вопросами, потому что случается иногда, что идей для постов нет, а отвечать на вопросы интересно 🙂

Ну и едем дальше, не спеша, без расписания и планирования (все как я люблю)
ЗЫ напоминаю, что в закрепах есть теги, которыми я пытаюсь маркировать посты

#байки

Пока я шлю мемы, Женя пишет полезные заметки про обучение лидству.

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

И потому все получается, ну как получается. Наверняка вы все это можете наблюдать вокруг себя (как в меме).

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

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

Самое сложное - это пипл-менеджмент, с ним тяжело "на кошках" тренироваться.

#management #развитие

Ничто меня так не радует в пятничное утро, как отмененная встреча, которая сразу казалась странной.

Спасибо вам, коллеги 🤝

#it_memes по пятницам

PS раньше писал про встречи и календари (раз и два). Ну и пусть будет три

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

Не мое, но похоже на мое...😏 из тредика в X

#metrics

А что все же делать с этими метриками?

The golden rule of metrics is this: any metric you maintain should directly drive action if outside expected bounds.

The reason this is an important rule is:

• Metrics are expensive to set up, so if you don’t use them, you’re wasting effort
• Metrics are expensive to maintain, so if you don’t use them, you’re wasting effort
• A metric that doesn’t drive action is a waste of time

#metrics