Как-то потерял Ивана Селиховкина в своей ленте, а он хорошие вещи пишет.
Когда-то занимался у него на курсе PMP, благодаря чему понял, что PrjM-ство не мое (кто-то бы знал, кто-то бы знал, чем придется заниматься спустя 10 лет…)
Рекомендую посмотреть его статью “Как измерять эффективность в ИТ-компании?” про три группы метрик:
• Метрики работы (TTM, CT, FE, Through Output, milestone deviation, etc)
• Метрики комфорта (NPS, текучка)
• Метрики продукта (MAU, DAU, retention, chun, LTV, ARPU)
#management

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

«Уместен пример история QA. Когда-то в каждой технической компании был отдел контроля качества, который тестировал код и “обеспечивал” (простите, это мои кавычки, я эту фразу даже в переводе написать не могу) качество.
От инженеров-программистов не требовалось писать тесты на своей код — это была работа отдела контроля качества. В конце концов мы поняли, что пишем программное обеспечение лучше, когда на самих инженеров возлагается ответственность за написание собственных тестов и тестирование собственного кода.

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

Мы не избавились от QA - отделы QA все еще существуют, особенно в некоторых отраслях, но они больше похожи на экспертов-консультантов. Они пишут наборы тестов и программное обеспечение для тестирования, но, что более важно, они являются ресурсом, позволяющим убедиться, что все пишут хорошие тесты и поставляют качественное программное обеспечение.
…
Специалисты здесь не для того, чтобы делать работу за вас, а для того, чтобы помочь вам сделать ее лучше...»

PS а саму статью обязательно почитайте, особенно те, кто верит в архитекторов, как отдельную роль.
#testing #it_философия

Традиционное, пятничное.
Всем сегодня без говнокода!
#it_memes

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

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

Короче, все кому заходит контент, но телега мешает его обсуждать, велком https://t.me/+eVSMX4QvqvxlNjcy

Я люблю воспоминания, благо чертоги памяти уже достаточно обширные. Хотя, как часто выясняется в разговорах с женой, на самом деле я плохо помню детали событий более чем 20-летней давности (+/-). И чем мне нравится мордокнига - это раздел “Воспоминания”.
На днях она напомнила про 10-летие видео И.Павличенко “10 причин почему лучше не строить распределенную команду” .
Посмотрел снова, всплакнул, посмеялся…
Помню еще в начале 2019 обсуждали на работе “А ведь плохо, когда часть команды работает из Праги, а другая из Питера. Получается как бы 2 команды, не де-е-ело. Нельзя так релоцировать.” (Хотя все же стоит различать полностью распределенную команду или кучкообразно-распределенную, есть нюансы, да).
Ну и потом пфф, 2020 год - “подержи мое пиво”. Тыдыщ, 2022 год - “и мой десяток бокальчиков”.
Да, на самом деле, проблемы из видео никуда не делись. Да, можно долго спорить про то, насколько команда сидящая в одной комнате продуктивнее распределенной и действительно ли это так. Но жизнь просто раз и поменяла правила игры. Подтянулось качество инструментов и да, как и прогнозировал Илья, мы стали их заложниками, а я дико скучаю по доскам в кабинетах. Поменялись ли сами люди и их отношение к работе? Нет 🙂
Если вернуться к видео и причинам по которым лучше "не делать распределенную команду":
1. Распределенная - это не команда. Хмм, нууу я скорее соглашусь.
2. Всё ресурсы - есть такое. Например, стал проще относится к факту расставания, связано с п1
3. Запутывание проекта - и такое есть.
4. Уходит самоорганизация - ну тут от людей зависит, если локально не было проблем у человека, то и с распределением не будет. Ну и да, не бывает самоорганизации у команды, есть организующие все люди внутри команды.
5, Продуктивность распределенной vs локальной команды - спорно, но-о-о, иногда такие мысли возникают.
6. Зависимость от инструментов и процессов - о даа. 100%. И инструменты, и процессы.
7. Разные таймзоны - в целом понятное ограничение
8. Тюнинг кросс-функциональности - не согласен. Оно или работает в хорошей команде, или не работает, от распределенности не зависит. Хотя фольклорно, в “курилке”, знания “всегда” лучше передаются, это почти факт 🙂
9. “Мы и они” - согласен
10. Где будет скрам-мастер? - ну это фигня, хотя при кучкообразной распределенности могут быть проблемы, да.

PS да, тут намешано все в кучу, “удаленка”, “распределенка”, “расчле...” (простите, питерское вырвалось).
Но воспоминания - это прикольно…
#байки #management

"Люди часто говорят говорят о «нестабильных (flaky)» тестах/проверках. Хочется аккуратно отметить, что это не проверка нестабильна, это наше понимание ситуации таково" (с) Michael Bolton
PS хорошая аналогия, но мне больше нравится определение "случайно успешные" для моргающих тестов

#мысли_вслух #testing #test_automation

Мы уже касались темы собесов.
У меня много любимых вопросов кандидатам, компаниям.
Если говорить о вопросах в мой адрес, то тоже есть любимые и не очень.
Самый нелюбимый вопрос мне на собеседованиях: "почему вы не подходите на эту должность/роль?".
Обычно, я настолько честен, прямолинеен, самокритичен и убедителен, что собеседующие после моего ответа даже не знают, что дальше спрашивать...
А какие вопросы не любите вы?

#байки #собеседования

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

Немного контекста:
«Обязанности менеджера распределены между тремя отдельными ролями: инженерами, лидами групп и коучами.

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

PS почитал, улыбнулся, где-то по чертогам памяти вспышкам пробежала аналогичная история из моего опыта...
НИХЕРА оно не масштабируется 😂
Там нюансов до одного места и самый важный из них - люди. Инженеров, которые будут готовы работать и умеют работать в такой парадигме очень мало. И как только компания решит расти, все мгновенно вернется к традиционной модели управления.
#management #байки #процессы

"Code freeze & release - ставки сделаны, ставок больше нет" (c) мое

Простите, сегодня без фотомемов.
Башка пустая после релиза...

#it_memes #байки

Самая известная структура компании (модель масштабирования) имени компании: Spotify model.
Многие до сих пор пытаются внедрить то, что рассказывал Книберг в 2014 не особо вдаваясь в детали, причины и подноготную этого устройства. А между тем в Spotify уже давно все не так, как все привыкли себе представлять. И сложности ровно такие же, как у нас всех: менеджмент, синхронизация команд, развитие людей.
И неважно как у вас называются команды, их менеджеры, как команды объединены, важно как в работе учитываются эти моменты:
•Поставка ценности – все улучшения системы следует проверять, задавая вопрос: помогает ли это улучшение/эксперимент нам обеспечить ценность?
•Обеспечение ценности продукта – требует проведения экспериментов и выяснения того, что работает для реальных конечных пользователей.
•Автономия важнее управления и контроля – без автономии невозможно обучение, совершенствование, инновации или способность адаптироваться к меняющимся обстоятельствам.
•Синхронизация — вместо того, чтобы указывать людям, что делать как с функциями продукта, так и с архитектурой продукта, сосредоточьтесь на том, чтобы команды согласовывали свои планы с общей целью продукта.
•Кросс-функциональные продуктово-ориентированные команды (фиче-тимы) — вместо функциональных команд (база данных, бизнес-логика, пользовательский интерфейс).
•Инженерная культура, ориентированная на обеспечение качества и простоты: создайте конвейер непрерывной поставки, который позволит командам создавать ценность независимо друг от друга. По сравнению с конвейером, который требует ожидания, пока команда DevOps выполнит развертывание. Во многих организациях DevOps — это команда, следующая за функциональной командой, которая развертывает приложение. Это известный антипаттерн.
•Психологическая безопасность – ключевым элементом дружелюбности к эксперименту является создание среды, в которой мы можем признать, что рискуем и извлекаем уроки из этого процесса. Причудливое название этого явления – «психологическая безопасность».
•Постоянное совершенствование как особенность системы: команды никогда не перестают совершенствоваться. Нам необходимо создать культуру, которая будет способствовать такому мышлению.
•Моральный дух – готовность и настойчивость членов команды работать ради общего блага.
•Улучшение потока работы через систему — инструменты включают ограничение незавершенной работы, перекрестную профессиональную переподготовку и устранение узких мест. Вы можете измерить успех этого как с помощью Cycle Time и Lead Time.
Что еще почитать:
Spotify doesn’t use “the Spotify model” and neither should you.

#процессы

Если вы хотите быстро улучшить результаты тестирования, замените «проверить X» на «ищите проблемы, связанные с X» М.Болтон
#мысли_вслух #testing

Период активного внедрения Agile/Scrum (для многих это до сих пор синонимы) в работу IT-команд совпал с моим становлением, как менеджера. И уже тогда у меня были вопросы “нафига нужен Scrum Master, если есть лид?” Ну то есть, чтобы что? Почему лид не может делать то, что ожидается от SM?
Версий было много, правильного ответа до сих пор нет (у меня нет, у теоретиков наверное есть). Есть только предположение, что далеко не каждый человек получивший менеджерские лычки и соответствующие полномочия сможет выстраивать в команде процессы, самоорганизацию и тп без подключения “дубинки” полномочий. А у SM какие полномочия? Только тру лидершип (чистое лидерство). И каждый вертится, как умеет...

И вот, не прошло и 20 лет, ты-дынц “Вашим следующим Scrum Master должен стать ваш менеджер”.

#management #процессы #байки

В этот раз тег #holywar сразу в заголовке: можем ли мерять продуктивность?
Один из моих любимых вопросов на собесе: в чем разница между производительностью и продуктивностью. Обычно обширное поле для рассуждений.
А эта короткая старая статья в свое время похоже заложила фундамент того, что я сейчас понимаю под эффективной работой и сеньорностью. Это понимаешь только спустя годы :)
There's No Such Thing As Software Productivity
Тезисы:
• Разработка ПО не является деятельностью, которая обязательно производит что-либо
• То что делают хорошие разработчики - они устраняют проблемы
• Ты не можешь измерить разницу продуктивности между хорошим и плохим разработчиком потому что там нет ничего, что можно измерить
• Если мы смогли решить проблему, вообще ничего не создавая, то все, что мы на самом деле производим - деньги на ветер

PS рубрика "листая дневничок": это я наткнулся на свою запись в блоге про эту статью.
PS2 А хорошо, до сих пор хорошо: "Добавить нечего. Надо просто вбить себе это directly в мозг! Лучше гвоздями." (с) Шульга

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

Тестовые окружения для слабаков. Пацаны тестируют в проде
#it_memes #testing #тесты_в_проде

Закон Парето (он же принцип 80/20):
80% результатов возникают из 20% причин, а 80% результатов возникают из 20% усилий.
Примеры из IT:
• 80% пользователей используют только 20% фичей
• 80% багов находятся в 20% кода
• 90% падений происходит из-за 10% ошибок
• 80% времени на фикс багов приходится на 20% от всех багов
• 80% изменений делается в 20% кода
• 80% кода пишется за 20% времени, оставшиеся 20% кода пишутся за оставшиеся 80% времени
Подробнее со ссылками на пояснения (не все уже открывается по ссылкам из статьи, но гуглится, при желании)

80% постов читают только 20% подписчиков 😃
#it_философия

"На каждом проекте, как ты его ни планируй, рано или поздно наступает фаза «Херачим!»" (c) чье-то из интернетов 2014
#мысли_вслух #it_философия

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

Немного рефлексии.
Что такое стратегия?
Посмотреть интернеты, доклады, книги - везде все вроде похоже, но понимание у всех все равно разное.

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

Обычно самые сложные вопросы решаемые на “стратегировании” - это “зачем нам туда”, “чтобы что” и классическое “как мы поймем, что дошли” (интересно, кто-то вообще доходит?).

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

В комментах хорошая картинка про хорошую/плохую стратегии.

Продолжение следует...
#it_философия #байки #стратегия

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

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

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

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

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

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

#байки