Есть мнение к одному из моих комментов:

Ой да всё намного проще. Айти расходник-ресурс для бизнеса, работаешь над направлением, а его закрыли, или косты режут, или команда меняется, или проект доделали и пока

и такая точка зрения тоже есть :)

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

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

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

И снова #it_memes про любимую всеми #оценка за авторством Макса Дорофеева

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

New Hires: Learn How The System Breaks

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

И всяко это лучше, чем подход "на собеседовании мы просим запускать ракеты в космос, а потом они приходят работать и картошку копают" из кулуаров HeisenbugConf
#management #собеседования

грустный мем Лайфхак для тех, кого утомили рекрутеры. Работает не только в LinkedIn, но есть нюансы.

#байки

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

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

#мысли_вслух #развитие

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

#it_философия

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

Всех с 29 февраля.

#байки

Когда ты "починил" баг и отдал на проверку тестировщику...

традиционно-пятничные #it_memes

Большое эго и недостаток самосознания — проклятие хорошего лидера...

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

Таки да.

#management

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

ЗЫ из моего раннего
#анафора #мысли_вслух

Что интересно, OKR часто рекомендуют к использованию.
Но еще чаще вокруг него возникают надстройки, помогающие его использовать.
Получается, что сам по себе метод неудобный или сложный?
POMKRA
Understand the Goal - (PO)
Build an Operational Plan (MKRA)
• Problems
• Objectives
• Milestones
• Key Results
• Activities

#management

What if everybody did everything right?

Интересный совет для осмысления причин инцидента:

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

Рассмотрение инцидента с этой точки зрения приведет к совершенно разным выводам, поскольку порождает разные типы вопросов, например:
• Какую информацию знали люди в данный момент?
• В каких условиях действовали люди?

#процессы #management

И пока мы еще не определились, что лучше микросервисы или монолит, давайте посмотрим подробнее на эти самые μServices.

At the heart of microservices
• we're told we'll find...
• we find...
• we should find...
• we often find...
• we need... to start rethinking what we really need.
You Want Modules, Not Microservices

#tech_read

Есть такой способ передачи знаний, очень популярный в IT: фольклорный...

пятничные #it_memes

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

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

"...
Test Automation in 2024
Short story - it still sucks. In the last ten years, I’ve worked with a lot of development teams on improving velocity, and in every single case I’ve found that developers owning all test automation results in better tests, more testable code, faster deliver, and higher overall quality. Some of these teams don’t have dedicated testers, but on teams with dedicated testers, those folks do not write automated tests. They write tools to assist in testing or debugging, or work with the development team in order to improve testing knowledge across the team.
..."

(с) The "A" Word...revisited Alan Page

PS мои пару слов (10-летней давности) про The "A" Word

#test_automation #holywar

А кто-то у себя использует Zero Bug Policy?
Отличный подход, который позволяет сохранить беклог и голову в порядке. Меньше страданий от постоянно растущего количества багов, которые никто не фиксит, но которые постоянно фигурируют в отчетности, как "показатель зрелости продукта".

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

А ведь там все просто: если баг есть и мы оценили его как критичный - значит мы его берем и чиним, а не маринуем в беклоге. Если некритичный (или кажется таковым в настоящее время) - значит просто фиксируем проблему, обозначаем его как “won’t fix” и забываем про него до того момента, когда его критичность меняется (похожий запрос от клиента, новый сценарий эксплуатации проблемы и тдтп).

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

Статья по этой теме с рекомендациями по переходу на ZBP

#testing #процессы

А давайте еще про "законы/закономерности/принципы" в IT.

Самый популярный - это закон Конвея (Conway's law):

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

Иногда звучит в такой интерпретации:

"Don’t ship the org chart!"

Похоже на то, что у вас?

Подробнее по теме:
• The Most Powerful Law in Software
• Conway’s Law in Team Topolgies: Did you really get it? (кстати, там упоминается прикольный "лайфхак": "we should design our teams (not the software yet) to “match” the required software architecture. That means reconfiguring the team intercommunications before the software is finished.")

#it_философия

Продолжая тему "менеджер и техника".

Еще несколько советов оставаться в технике будучи менеджером: Should you Stay Technical as an Engineering Manager?

PS жаль, что мои самые любимые - самые неэффективные 😒
PS2 кстати, вопросы поддержания необходимого тонуса в технике касаются не только менеджеров 😉

#management #развитие

IT Global Meetup #16
23 марта в Питере. Молодцы, оживили.
Даже интересно, сколько участников будет.
PS я тот еще социофобушек теперь, но все может быть...

Философское пятничное #it_memes ное от Макса Дорофеева

#it_философия

Пересмотрел еще раз спустя 9 лет.
Он все так же хорош. Но тогда был прямо в ❤️
Очень рекомендую.

Вадим Макишвили, доклад "36"

Следующий его доклад ("42") мне не так хорошо зашел, но думаю и он нашел свою аудиторию.

#it_философия