Сегодня тоже про стратегию, но нескучно, потому что автор не я.
"В жизни каждой организации неизбежно наступает период когда менеджеры в ней превращаются в стратегов.
Менеджер становится стратегом не сразу, не в один день.
Менеджер делает какое-то дело, его люди делают это дело.
Дело даже получается, так может повторится даже несколько раз.
Люди у менеджера учатся, проявляют инициативу.
И в какой-то момент менеджер понимает, что ему больше не нужно делать менеджерскую рутину. Что он может подумать о ней… о стратегии.
Стратегия, сука, непонятная.
Она вроде бы и есть, а вроде бы и нет. Вот с тактикой все просто - взял кусок работы, нарезал на спринты, ходишь на стендапы, решаешь проблемы команды, получаешь результаты и обратную связь.
А со стратегией все сложно - ты ее подумал, обсудил, проговорил с людьми. Может быть даже записал на бумажку и придал ей официальный статус.
Но ее нет. Физически ее нет.
Поэтому стратегу нужно, конечно, подумать эту вот самую стратегию, обсудить ее, проговорить ее и ... идти выполнять. Самому.
И тут собственно и наступает тот самый критичный для менеджера момент - кто-то может отвернуться (пусть и на время) от этой бездны стратегии, и пойти обратно в окопы, а кого-то засасывает эта метафизическая бездна.
Это конечно идеализированная картина мира, где только черное и белое, но (!!!)- конченых стратегов нужно отстреливать!" (с) Никита Макаров
#it_философия #стратегия

Ну и стратегично-пятничное, знаменитый анекдот про стратегов
#it_memes #it_философия #стратегия

Закончим страт-рефлексию одной из лучших подборок материалов по технической стратегии.
Если уж кому повезет ею заниматься, будьте готовы.
https://lethain.com/strategy-notes/
Ну а дальше, весьма традиционно: "пни вперед - комбинация придет".
#management #стратегия

У меня в блоге было немного техники, даже когда я еще был, как говорят hands on в этой технике. Сейчас уж и подавно.
Только посты в английской версии блога (да-да была и такая) были техническими.
Но писал про то, что было интересно: готовишь например бюджет на следующий год для конференций, смотришь что-где-как, пишешь статью. Съездил/сходил на конфу - описал впечатления. Некоторые до буквально до недавнего времени были в топе поиска, потому что название конференции и статьи очень понравилось поисковым движкам, а контент они игнорировали.

Аншлаговые были статьи с точки зрения трафика. HR-ы (не мои) рассылали своим сотрудникам, для планирований 😄

А сейчас сдув пыль, можно посмотреть, какие они были эти конференции 10 лет назад...
Летопись конференц-движения 😂

#байки

Давно ничего не было про тестирование.
Слышал кто-нибудь про принципы "Современного тестирования"?
Да, Алан пишет, что это не совсем про тестирование, как его многие понимают, и не про "современное", а скорее про поставку ценности.
У меня очень откликается.
Самим принципам (первой их версии) уже больше 5 лет.

Принципы Modern Testing 2.0 (бета):
• Наш приоритет – развитие бизнеса.
• Мы используем такие модели, как бережливое мышление (Lean Thinking) и теорию ограничений (Theory of Constraints), которые помогают выявить, расставить приоритеты и устранить узкие места в системе.
• Мы являемся движущей силой постоянного совершенствования, адаптируем и оптимизируем наши практики, чтобы добиться успеха, вместо того, чтобы быть системой для выявления наших неудач.
• Мы глубоко заботимся о культуре качества в нашей команде: обучаем, руководим и воспитываем друг друга в направлении более зрелой культуры качества.
• Мы считаем, что только клиент может судить и оценивать качество нашего продукта.
• Мы активно используем данные, чтобы глубже понять, как клиенты используют наш продукт, а затем устранить разрыв между гипотезами о продукте и влиянием на бизнес.
• Мы расширяем возможности и экспертизу всей команды; понимая при этом, что эти действия могут уменьшить (или даже устранить) потребность в специализированных специалистах.
Тут можно почитать про принципы подробнее.
Еще интересно: Alan Page on Testing: From Past to Future

#testing #it_философия

"Независимо от того, руководите ли вы менеджером или отдельным мега-разработчиком, ваша задача одна: вы всегда держите руку на пульсе и контролируете, какова их цель. Однако детали того, как достигается эта цель, являются деталями реализации, которые вы им делегируете" отсюда
🤝 очень откликается
#management

Му-Му — говорит коровка.
Гав-Гав — говорит собачка.
Еще два дня и релизим — говорят разработчики третий месяц.

А потом на ретро релиза...

Картинка (с) Maxim Dorofeev, ей недавно исполнилось 10 лет...
#it_memes

"The Definitive Guide to API Test Automation With Playwright"
Большой цикл статей про автоматизацию тестирования API с помощью Playwright.
#test_automation #tech_read

"Интересно, сколько раз это должно повториться, прежде чем мы наконец запомним, что «сделано» от разработчика может означать «работа только начинается». Надо чаще с ними общаться" (с) чье-то из древних интернетов
#мысли_вслух

Сегодня пост с опозданием, простите, кто читает меня за утренним кофе. Болеть - плохо, не болейте.

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

Идеально на эту тему от Никиты Сергеевича.

Или вот лекция Сергея Мартыненко по этому вопросу (академический подход).

#test_automation

"Программисты — оптимисты.
Поговорка «хороший инженер – параноик» только объясняет, почему программист — не инженер. С опытом прогрессирует паранойя и уходит вера в магию — поэтому старых программистов мало.
В России их практически нет. Любой HR знает, что программист «за 35», не ушедший в бизнес, менеджмент, или тестирование — или бракованный, или и так нарасхват." (с) Стас Фомин "Ищу Программиста" 2016
#it_философия

Ко вчерашнему посту про возраст, нарасхват и "бракованных" программистов.
ЗЫ хочу в понедельник что-то про возраст еще добавить :)
#it_memes

И еще немного про возраст
“Is software development really a dead-end job after age 35-40?”

А тут в тви байка, что после 50 уволили кого-то. За что - непонятно. Но многие цепляются за возраст, потому что это единственный факт.

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

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

Итого: Каким-то “молодым” тяжело с "возрастными", каким-то “возрастным” тяжело с "молодыми".
Что такое “молодой” и “возрастной”? Без контекста - вопрос без ответа. Многим людям просто с другими людьми тяжело работать в принципе, постоянно.

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

Рассказали мне недавно, что ожил сайт Piter-United. А на днях было был 10-летний юбилей той встречи, где я в первый раз участвовал в IT Global Meetup (ITGM), в шикарном зале музея связи имени А.С. Попова.
Даже не знаю, живо ли по-настоящему хоть одно из тех IT-сообществ, которые принимали участие в ITGM (раньше их было около 20).
Интересная была инициатива, которая благодаря энтузиазму и драйву организаторов, в первую очередь Миши Рыжикова, собирала в максимуме до 1000 человек.
Благодаря "дневничку" можно снова вспомнить интересные моменты, знакомства. Кстати, на ITGM я в первый раз узнал про Semrush (тогда еще SEMrush). На одном из ITGM я и сам травил байку про технический долг.
Вообще раньше (ну лет 5-10 назад) можно было раз в неделю ходить на интересные митапы.

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

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

Может оно все живое и активно проходит, просто я уже не в теме? :)
#байки

"Жизнь становится лучше, когда ты постоянно предполагаешь, что можешь ошибаться.
Ты больше узнаешь, меньше обижаешься. И привлекаешь умных людей.
Ваша неправота ничего не говорит о вас, как о личности.
А вот невозможность ее признать - говорит." (с) чье-то из интырнетов #мысли_вслух

Manage Your Capacity, Not Your Time
"...важно не количество времени, которым вы можете жонглировать, распределять и управлять, а качество времени, которое вы можете потратить на свои задачи..."
"...независимо от того, где вы работаете и насколько высокую позицию вы занимаете, ваши возможности ограничены: каждый день вы работаете только определенное количество часов, и только определенное количество этих часов вы можете провести в состоянии продуктивности и потока..."
#management

7 признаков звиздеца во взаимодействии PM и разработки (отсюда)
Можно "поиграть" в бинго, но не хочется.
#процессы

На следующей неделе в отпуск.
Так что у меня "давайте после НГ" уже началось :)
#it_memes

Про компромиссы или 256 оттенков серого.
Самое большое заблуждение в IT (и не только), с которым часто приходится сталкиваться, это то, что все вокруг черно-белое.
А на самом деле везде и всегда есть контекст. Всегда есть развилка, место для маневра и компромиссов. Потому что везде вокруг люди.
Попытка привести все к 0, или 1 ни к чему хорошему не приводит. Особенно если не пытаться сделать контекст ясным для всех. Но это сложно и не все умеют, поэтому и возникает история “делаем так и не иначе”.
При этом компромиссы и принимаемые в них решения опасная штука: не фиксируя плюсы/минусы и “план Б”, мы слепо доверяемся якобы истине, всем понятной и разделяемой.

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

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

Добавляем очередной if-чик в функцию 100500 строк - это быстро, решение уже на уровне “паттерна”, место принятия решения локализовано. Ну вроде так. Или не так?
После какого количества if-чиков мы перестаем понимать то, что делает код? Как часто при этом перестает работать то, что до этого работало года 3 и никто проблем не видел? Когда новый if станет той каплей, когда прорвет плотину накопленного дерьма технического долга? И снова дилемма…

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

Стадии развития программиста:
- Ваш код гавно.
- Мой код гавно.
- Любой код гавно.
- Жизнь гавно.
- Выступаешь на конференции с темой: Как структурировать гавно, так чтобы оно не растекалось. (c) Danil Pismenny (@pismenny)
#мысли_вслух

Explorers are bad leaders
"Explorers are hard to follow. It’s better to let them wander alone, then hear their tales.

Explorers occasionally find a great place that would make a better home for many people. So that makes a job for a leader.

Leaders are easy to follow."
#management