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

Че-то я как-то излишне серьезно и по-менеджерски жестко начал эту неделю.
Отдыхаем... Наслаждаемся классикой, но... читаем между строк.

"Никакой учености тут нет, сударь. У моего кума была кошка, которая, извините, огурцы ела. Недели две полосовал кнутищем, покудова выучил. Заяц, ежели его бить, спички может зажигать. Чему вы удивляетесь? Очень просто! Возьмет в рот спичку и — чирк! Животное то же, что и человек. Человек от битья умней бывает, так и тварь".

Антоша Чехонте (1883)

А вы говорите, разработчик не может тестировать…

#мысли_вслух #байки #testing #настроение_дня

Микроменеджемент
Мои наблюдения:
1. Никто (ок, мало кто) из менеджеров, которые активно влезают в жизнь команд и фактически микроменеджерят, не считает себя “микроменеджером”.
2. Менеджеры микроменеджеров часто считают последних очень эффективными менеджерами.
3. Команды, которые вынуждают использовать с ними микроменеджмент, сильнее всего “кричат” про недопустимость этого.
4. Чем сильнее используешь инструменты микроменеджмента, тем сложнее от него избавиться в дальнейшем. Более того, чем дальше, тем больше ты будешь склоняться к тому, что это единственный рабочий вариант.
5. Различие между “доверяй, но проверяй” (правильно) и “я не верю, что вы сделаете правильно и поэтому буду проверять” (неправильно) в разных ситуациях/контекстах/головах может размываться до состояния “одно и то же”.

Выводы:
1. Для команд: не любите микроменеджмент - спросите у менеджера, что ему нужно, чтобы обеспечить доверие и прозрачность между вами и им. Ну и меньше “играйте” в “дайте нам приватное пространство для общения”.
2. Для менеджеров: не давайте повода к мыслям об отсутствии доверия и подбирайте команду тщательнее. Самая сложная история - это команда в “наследство” или “приданое”. Там установка доверительных отношений - это то, с чем надо начинать.

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

Что еще посмотреть:
1. Accused of Being a Micromanager? Here’s How to Change It
2. The Anxious Micromanager

продолжение...

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

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

Навеяно, даже когда-то разделяемыми мною, мыслями вида "не надо боятся нанимать тех, в ком сомневаешься, ведь с ними легко можно попрощаться, пока идет ИС".

Да, но нет.
Оставим пока в стороне тему "если есть сомнения, то трактуйте их не в пользу кандидата", если интересно, то потом можно ее повертеть.
А сегодня про то, что уволить с ИС не так просто, как кажется.

Немного юридической казуистики для тех, кто думает, что это просто.
Дальше речь про РФ. Это действительно просто, если расставание происходит по взаимному согласию.
Если же сотрудник считает, что у него все хорошо и он не согласен уходить, то начинается юридическое веселье (немного подробностей про возможные сложности тут).

И только в этот момент все дружно вспоминают про отсутствующее вообще или формально незафиксированное задание на ИС.
Почему его нет? Потому что "мы все адекватные люди и сможем договориться", "нельзя/сложно придумать задания на 3 месяца испыталовки".

Часто в качестве работающего варианта предлагают "сделать выговоры и уволить". Остается неясным, за что выговоры делать :)
Уверяю вас, обычно люди, которые готовы на подобную конфронтацию строго соблюдают режим дня, фиксируя время прихода/ухода и тп.

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

Еще есть вариант "никто не будет судиться с корпорациями". Ну, во-первых мало кто из нас работает в корпорациях, а во-вторых можно и без суда устроить веселье в кадровом отделе просто написав жалобу в трудовую инспекцию.

Часто ли такое происходит?
У меня за >15 лет менеджерской работы было 4 раза, когда испытуемый не был согласен с результатами ИС. Последний раз было в 2020, то есть это не ретрослучаи.

Можно ли на это забить? Можно, но осторожно. Но проще не нанимать тех, кто вызывает сомнения.

Кстати, задание на ИС - это не формальная бесполезная фигня. Это хороший артефакт для успешного онбординга. Новый сотрудник должен понимать ожидания от него, критерии прохождения ИС.

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

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

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

А вообще пусть у всех такое случается реже :)

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

Фиксы в прод... Изи... Погнали 🎉

Тесты? Какие такие тесты?

пятничные немного грустные #it_memes #тесты_в_проде

Ideal middle manager is one who understands both what happens below and what happens above

(не мое)

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

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

ЗЫ начало истории пост 1
ЗЫ2 ссылка на статью с заглавной цитатой

#management

Продолжаем про "средних".
"The manager’s job is less to tell them what to do, but more to inspire them."

The Middle Manager of the Future: More Coaching, Less Commanding

Прям на базе исследования (для фанатов пруфов).

продолжение...

#management

Часто обсуждают переходить ли на темную менеджерскую сторону карьерной лестницы или ну его нафиг.

Реже встречаются обсуждения "а что там дальше, на менеджерском пути?"

Прямо скажем, в топ-директора и прочие топы ведь мало кто попадет (совсем мало). И большая часть тех, кто не вернется в разработчики, подрастут на уровень выше лида и останутся "вечными майорами" middle manager-ами (менеджерами среднего звена). Это ни хорошо, ни плохо. Это жизнь.

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

А что по ожиданиям от менеджеров среднего звена?

"Middle managers as *critical thinkers* are an indispensable part of today's organisations. They are responsible to create pictures of possible futures for those who report to them." (с) Dr Zahira Jaser

На этой неделе будет серия статей по этой теме. По ссылке в день, все равно больше никто не прочитает :)

"The Real Value of Middle Managers"

продолжение...

#management

Аналитики подсчитали, что четверть от общего числа веб-страниц, которые существовали в период с 2013 года по 2023 годы, по состоянию на октябрь 2023 года уже недоступны. В большинстве случаев это связано с тем, что с течением времени страницы сайтов радикально корректируются или же попросту удаляются. Для более старого контента эта тенденция также актуальна. Около 38% веб-страниц, существовавших в 2013 году, недоступны в настоящее время. Если же рассматривать веб-страницы, существовавшие в 2023 году, то показатель недоступных в настоящее время составит 8%.

Давно заметил, что много страниц, на которые ссылался в первых статьях блога перестали открываться. Ненадежная история...
When Online Content Disappears и перевод на 3dnews

#байки

признавайтесь, кто-то так делал? 🫣

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

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

Это #классика с "много букв", так уже никто не пишет, и она прекрасная..

Про автоматизацию, тестировщиков, качество и вот это все…

“Good enough” так “good enough” (https://testitquickly.com/2013/06/03/good-enough/)

PS Кстати, пошарьтесь по статьям Алексея, это самые "вкусные" статьи на русском про то, что можно назвать "теорией тестирования".

#quality

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

М.Болтон 2016

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

Напомню, про возможные причины ошибок было тут:
- сделали, но ошибка в коде (или настройках среды и тд)
- сделали, но не то, что ожидалось
- даже не делали, так как этот сценарий не предусмотрели
- ошибка во “внешнем” коде (open-source)

#quality

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

чужие #мысли_вслух

А ведь что-то в этом есть...
И это правда еще и потому, что начинать что-то менять, если сейчас типа все неплохо - это капец, как трудно. Типа "а нафига?"

С другой стороны, "и так хреново, еще и эти изменения...". Можно и не вытянуть. В этом месте и времени важна поддержка команды, руководителя.

ЗЫ я вот иногда(?) занудничаю в последнее время(только ли?) в таких ситуациях и может даже мешаю...

#рефлексия_без_гуглежа и чудес

No Wrong Doors.
Про культуру коммуникации и направление/корректирование информационных потоков.
Очень часто наблюдаю истории аналогичные первому примеру из статьи.

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

#процессы

Примерно так выглядит Confluence любой конторы старше 5 лет. (сперто)

#it_memes

Тимлидам непросто: требуется строить отношения с коллективом, постоянно учиться, терпеть относительно невысокую зп.
Есть только одно чувство, которое способно скрепить всё это вместе и помочь работать эффективно: искренне полюбить свою работу.
Ты должен стать солнцем для всех.

#мысли_вслух из древних и забытых интернетов

Что думаете?
Имхо, лиды - самая геморройная работа из всех, с которой мне приходилось сталкиваться лично. Но самая интересная :)
Какие могут быть ожидания?

#management

Есть тут менеджеры с хай-перформерами? Как вы их, менеджите или не менеджите?

OK, but how do I manage high performers?” The answer is simple — you don’t!

These types of people need rock-solid communication, a good framework of rules and boundaries and your trust, a lot of trust. They will manage themselves as long as they understand the expectations.

vs

Manage Them!

Weak managers let high performing reports do whatever they want.

PS на самом деле статьи пересекаются по идеям, вопрос лишь в том, что понимать под "менеджментом".
PS2

there’s no such thing as a “high performer”, only people who are high performing at a given time. “High performer” is used as a shorthand for “people who are currently performing exceptionally well in their role.”

#management

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

#мысли_вслух из древних интернетов...

Сначала не поймет, а потом как пойме-е-е-т. Но это неточно. И потом это будет уже совсем другая история.

Хотя есть и другая версия, версия тех, кто верит, что с тестами быстрее и в каком-то смысле дешевле.

#test_automation

What we talk about when we talk about ‘root cause’

Автор пытается ответить на вопрос о причине использования этого термина? Почему мы применяем его только в случае проблем, но не успеха?

“There is no root cause. The problem with this term isn't just that it's singular or that the word root is misleading: there's more. Trying to find causes at all is problematic...looking for causes to explain an incident limits what you'll find and learn. And the irony is that root cause analysis is built on this idea that incidents can be fully comprehended. They can't. We already have a better phrase for this, and it sounds way cooler: it's called a perfect storm. In this way, separating out causes and breaking down incidents into their multiple contributing factors, we're able to see that the things that led to an incident are either always or transiently present. An incident is just the first time they combined into a perfect storm of normal things that went wrong at the same time.”

....

A challenge for readers and listeners
I’ll offer a few questions to consider the next time you read or hear the term ‘root cause’:

• What is the author (or speaker) trying to convey by using the term?

• What agenda(s) might the author (or speaker) have in their version of the story, other than providing the richest description they can?

• What else can you imagine is influencing the outcome of the story being told, besides what is deemed the ‘root cause’?

• What details seem to be noticeably absent in the story you’re being told?

• What questions can you imagine being dismissed or discounted by the storyteller, if you had the chance to ask them?

Questions like these are garden-variety critical thinking exercises. But they might help us explore what the story doesn’t tell us, or what might be missing in the story.

#процессы #it_философия

И вроде уже далеко не в первый раз, но каждый раз он удивляет...

#it_memes в картине "Релиз - ты умеешь удивлять"

Интересный пример (подходом) трансформации достаточно традиционной "лестницы" в разработке. Обратите внимание на то, что убрали техлидов.

Ожидания по обоим треками в комментах.

#management