В IT чудес не бывает

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

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

 PS Цитата про тесты - до слез 😹

Хорошие инженеры могут воспринимать тесты, особенно — интеграционные тесты, как особый вид документации. Преимущество тестов перед документами в Word/docx в том, что их можно запустить и мгновенно получить ответ — выполняются требования или нет. По крайней мере, такова мечта. Об этом рассказывают на конференциях, строят умные модели и рисуют пирамидки. По факту, тесты мало у кого есть. Либо они проверяют какую-то ерунду. Докладчики, возвращаясь с позёрских QA-конференций, на работе видят пустоту и разруху.

 #tech_read

Ну, за приоритет Ы

The word “priority” came into the English language in the 1400s, and it was singular, meaning the very first thing, the thing that came before all others. It stayed singular for the next five hundred years.

Only in the 1900s did we pluralise the term and start talking about “priorities.”

...

Think about your own organisation for a moment.

• How many parallel roadmaps and subroadmaps exist, with engineers smeared fractionally across all of them? For example, does your security roadmap fight with your product roadmap and your performance roadmap?

• How many teams have their own backlog of P0 items, with each saying they need more people to work on them?

• How many initiatives are all happening at once, each with their own sponsor claiming that theirs is the most important, leading to silos and politics?

Here’s the rub: the plural form of the word has given us permission to avoid the hard work of truly deciding what comes first.

...

Take ten minutes and try this exercise:

• List everything. Write down every project and initiative currently in flight for your team or department. Don’t filter or categorise yet, just get them all down.

• Force a ranking. Put them in order from one to n. Not tiers, not categories: a single ordered list. No ties allowed.

• Notice the hesitation. Where do you want to create exceptions? Where does it feel impossible to choose? That hesitation is where the real prioritisation work lives.

• Identify who decides. Can you make these choices on your own, or do you need input from your team and peers? If it’s the latter, that conversation is the one you’ve been avoiding.

...

it’s priority, not priorities: you should just have one single list.

One list to rule them all. A simple list can make all of the hard decisions happen.

#management #process

The most dangerous teams aren’t toxic.They’re polite, busy, and very good at explaining why nothing is anyone’s fault.

(с) Alan Page
чужие #мысли_вслух

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

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

В общем не теряйте, надеюсь, нам еще будет где пообщаться 🤞
ЗЫ традиционно, в периоды "стопора чистого листа" я рад видеть #ваши_вопросы в личке.

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

#байки #мысли_вслух

Prior era’s good leaders are often bad leaders in the following era

"Good engineering management" is a fad
Management skills:
• Execution
• Team
• Ownership
• Alignment
• Taste
• Clarity
• Navigating Ambiguity
• Operating Across Timescales

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

ЗЫ "всякому овощу своё время" - русская народная мудрость...

#management

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

#не_реклама :)

Очередная полезняха из ленты.
System Design Space - ресурс для изучения системного дизайна и подготовки к собесам по нему от Александра Поломодова, который часто про сисдиз рассказывает и пишет.

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

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

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

#мысли_вслух от одного из моих бывших крутых технарей, который вступил на менеджерскую тропу.
Жаль, что у меня не получилось дать ему возможность расти в менеджменте рядом со мной. Остается только надеяться, что он запомнил что-то хорошее.
А то надо мной было категорически мало руководителей, у которых можно было учиться чему-то хорошему. Но было много примеров, как делать не надо. И это тоже полезно: если не делать, как не нужно, но при этом что-то делать, сильно больше шансов, сделать как надо, особенно если ты, как и многие, менеджер-самоучка 🙂

#management

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

Про сами ревью писал тутъ и тутъ. И про сопутствующие калибровки тоже.

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

The Goal of Compensation is to Create the Most Talented, Enthusiastic Team That Your Budget Allows

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

Ваша цель — не сделать людей счастливыми.

Ваша цель — не удержать свою команду любой ценой (хотя удержание — часть уравнения).

Ваша цель — не получить «выгодную» цену за оплату труда сотрудников.

Ваша цель — не соответствовать рыночным условиям.

Ваша цель — не соответствовать тому, что платит <другая компания>.

Ваша цель — не соответствовать ожиданиям сотрудников.

Ваша цель — не платить одинаково (хотя часть вашей цели — обеспечить справедливость).

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

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

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

Кстати, около года назад уже была заметка про "алгоритмы промоута".

А 10 лет назад был доступен хороший доклад про премирование в IT. Сейчас только слайды остались :(
В премии для инженеров, на самом деле, мало кто умеет, ровно потому что не соблюдаются условия прозрачности и своевременности. Ну и премии за KPI/MBO для менеджеров приводят к тому, что все вместо работы начинают всё тащить к этим буквам. Но это уже совсем другая история... :)

#management

Architecture Intent Checks try to do this same thing, and they work on the principle that most decisions make perfect sense to anyone with the same context. They’re non-blocking because the default assumption is that it’ll be the right decision (or at least right enough!). When we get it wrong, we learn fast, course-correct, and move on. The cost of occasional mistakes is far lower than the cost of making everyone wait for permission.

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

Много вопросов, мало ответов. Но сам подход нравится.

Letting Teams Make Occasional Mistakes Costs Less Than Waiting for Permission

ЗЫ Architecture Intent Checks - это что-то типа RFC/ADR, для фиксации принимаемых решений, но их обсуждение не блокирует дальнейшие работы.

#management

В ленте пролетела рекомендация этого бесплатного курса по фаззинг-тестированию на базе книги "The Fuzzing Book. Tools and Techniques for Generating Software Tests".

Как говорится "не смотрел, но одобряю" (но книга действительно рекомендательная).

#test_automation #testing #tech_read

Ну че, мой онбординг в пятничных #it_memes

После последнего поста в комментах дружно набросали вариантов того, как можно жить и с оценкой багов, и без нее, и даже с zbp в самом его “жестком” варианте (что готовы чинить - чиним сразу, что не готовы - даже не фиксируем).

Давайте уйдем немного в сторону. Не очень люблю аналогии, но в медицине тоже есть свой механизм сортировки (пациентов): Manchester Triage System. Возможно там есть на что посмотреть и довернуть для сортировки багов.
Ключевая идея этой системы заключается в том, что вместо «насколько важен этот пациент?», определяется «как долго этот пациент может безопасно ждать?». Клиническая потребность определяется по степени срочности, а не по важности (суровости?).
У себя мы тоже обычно пытаемся понять: «насколько это важно?». А что если думать над вопросом «как долго мы можем не чинить этот баг?», ну или хотя включить его в список вопросов, на которые пытаемся ответить при сортировке багов.

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

Почему нельзя сделать так же и для себя?

Определяем типы проблем (вертикаль) и формируем диапазоны пользователей (горизонталь) с точки зрения вероятности наступания в эту проблему (вероятность — самый скользкий момент, иногда ее сложно определить объективно). Получаем матрицу heatmap, где в местах пересечения фиксируем приоритет, с которым проблема должна решаться. То есть суровость, как и предлагали в комментах, становится понятным источником определения приоритета, а не просто одним из свойств бага.
Прозрачно, понятно, единообразно.

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

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

#testing

А давненько ничего не было про тестирование.
И сегодня хочется запустить тред про то, как вы оцениваете баги на критичность.
Я не тестировщик, istqb-ов не сдавал, поэтому мне можно рассуждать не как на собесе, а тестировщики приходите в комменты и говорите, где я ошибаюсь.
Все давно знают, что у бага есть его приоритет и суровость (нравится мне такое определение severity от Алексея Лупана).
И если с каждой из этих характеристик по отдельности +/- все понятно, то как они между собой связаны (или не связаны) - вопросов может быть немало.
Означает ли приоритет "критичный", что надо брать в работу "бегом" и если означает, то зачем тогда нам еще и "суровость" в принципе? А может баг быть мегасуровым, но с минорным приоритетом? Надо ли его тогда чинить в принципе (все же помнят про ZBP)?
Можно ли багу ставить приоритет повыше, чтобы команда взяла его в работу быстрее, ну или хотя бы просто когда-то взяла?
И в какой момент, и кто решает, что это крит или мажор? И, главное, почему тот баг крит, а этот мажор?

Как много вопросов по такой простой(?) теме.

Продолжение

#testing

2025 заканчивается.
Год, а особенно его финиш, был очень насыщенным на эмоции, и на работе, и дома.
Пусть в следующем году у вас все получается, а ваше сердце и разум придадут вам смелости в своих решениях.
Ваш Айтиболит 🎄🎅🏻

Подводя итоги года.
5-ка лучших самописов по комбинации просмотров/реакций/пересылок.
Всеми любимые #it_memes и посты про поиск работы вне конкурса 🙂.
• Про автоматизацию тестирования (хотя согласен, картинка там мемная, чит)
• Кейс “команда предложила решение, но оно кажется вам неправильным - что будете делать?”
• Про серебрянные пули
• Про документирование принятых технических решений
• Про переработки
Если аннулировать результаты для первого поста за чит-картинку, то в топ попала, чему я рад, история болотной сосны.

Вот прям весь я в 6 постах, прикольно получилось. Не добавить/не отнять.

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

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

#мысли_вслух #байки

Стремление к предсказуемости

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

Наиболее распространенное решение — больше внимания уделять планированию.

Более подробные дорожные карты. Больше отслеживаемых зависимостей. Часто больше встреч, просто чтобы «подстраховаться».

И почему-то предсказуемость все равно не улучшается.

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

В результате они получают лишь показную игру.

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

Это не так.

Меня раздражают команды, которые делают частые релизы целью, а не результатом работающего процесса.

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

Не «когда это будет сделано», а «на какую дату вы уверены на 50 процентов».

Это число имеет значение.

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

При 90-процентной уверенности команды перепланируют. Они затягивают. Они откладывают обучение во имя безопасности.

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

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

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

Эти действия направлены на то, чтобы успокоить, а не на достижение результатов.

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

#процессы #management

Ох уж эти декабрьские мошенники в пятничных #it_memes