2 интересных примера взаимодействия CPO и CTO.

Как много из людей C-level готовы к открытому обсуждению проблем, вместо истории "они там ничего не шарят, щас мы тут сами все сделаем..."?

Я встречал оба кейса в реальной жизни, но "правильный" кейс был очень редким.

Но после разговора с "открытыми забралами" часто возникает вопрос и "что дальше?" Что на самом деле происходит между этими 2мя состояниями на картинке?
Высказали друг другу претензии и разошлись? Никакой синхронизации не произойдет.
Иногда бывает история, когда задачу на выработку решения отдают вниз, со стороны читается "мы не смогли договориться, давайте сами". Или, такое тоже бывает, на самом деле отдают не полномочия на решение. А "билет на встречи", где кто-то что-то обсуждает, но без апрува свыше ничего нельзя зафиксировать. Этакие "встречи делегатов-посредников".

В общем, обозначить свою позицию явно и без излишнего политеса - важно. Но еще важнее, уметь дальше договориться, возможно даже наступив на свои амбиции.

#management

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

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

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

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

#management

Забавно, в очередной раз, нарисовал себе концепт в голове.
И снова, какая неожиданность - ничего умного и нового не придумал 😃

Можно считать это насмотренностью или это и есть опыт?

Measuring Manager Effectiveness -- Can You Even Quantify It?
• Technical Ability
• Project Management
• People Management

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

PS Может просто уже читал эту статью и потом согласие с ней трансформировалось и авторизовалось в собственное мнение.

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

Похожая история была с законом Конвея и его Inverse Conway Maneuver, но там точно "сначала идея, потом статья и термин"

#management

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

А потом вот нашлась и причина "популярности".

Я, чего уж там, не любитель читать про ИИ (и так уже из каждого утюга, даже в моих IT-менеджмент подписках).
Но тут канал интересный по духу, бодрый движ.
Хотя мне не хватает пометки "пост сгенерирован и отправлен ИИ". А то опасение, что синтетика, без души 😃

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

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

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

Если предположить, что
1) закон Паркинсона работает (а эмпирика показывает, что так и есть)
2) у задачи нет сроков выполнения*

-> получается, что задача никогда не будет сделана, а значит, никому ненужная.

*Если сроки выполнения задачи перенесли 3 раза** - она тоже бессрочная.
** число получено эмпирическим путем

А что если это не задача, а релиз? 🤔
"Вот это поворот..." - скажите вы.
Но бывает же такое, когда релиз двигают по дате, и обычно всегда аргументированно. И иногда аргумент "нам дата некритична".
Если релиз перенесли несколько раз, то что нужно делать? И нужно ли?

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

Просто хотел напомнить.

#мысли_вслух #it_философия

The 20 Software Engineering Laws
Why software projects fail, systems rot, and teams slow down.

Я часто тут вспоминаю про закономерности Паркинсона и Конвея. А таких эффектов больше 🙂.

Какой из них вам нравится больше всего или с каким чаще всего сталкиваетесь?

Кстати, в списке нет одного из моих любимых: принципа Парето (он же принцип 80/20).

PS от "Every program attempts to expand until it can read mail" (Zawinski's Law) знатно орнул, смахнув украдкой слезу. Как обычно, все уже описано и придумано за нас. А "цифровые рабочие пространства", "универсальные коммуникационные платформы" и прочие юнифаеды, лишь подтверждение спиральной динамики.

#it_философия

Вспомнил, что я когда-то тоже делал список эффекто-законо-принципов, но больше в сторону психологии.
Оказалось ему уже почти 10 лет 😲
Задача не стояла в объяснении каждого термина, а просто в том, чтобы все было собрано в одном месте. Ниже самые интересные 🙃

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

Эффект Даннинга — Крюгера
Определение в вики слишком затянутое. Я его понимаю так: глупые не понимают, что они глупые, потому что они глупые. Но при этом уверены, что они круты. А умные "знают, что ничего не знают" и думают, что все остальные о них того же мнения.

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

Закон Паркинсона (на самом деле их три, но чаще вспоминают первый и мы именно его недавно вспоминали. А между тем 3й вариант такой прикольный 😜)
1. "Работа заполняет время, отпущенное на неё"
2. "Расходы растут с доходами"
3. "Рост приводит к усложнённости, а усложнённость — это конец пути"

Эффект Рингельмана (или эффект социальной лени)
"Индивидуальный вклад участника группы уменьшается по мере того, как размер группы растет"

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

Теория разбитых окон
В качестве примера, "если в здании разбито одно стекло, и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна".
В IT эта теория хорошо ложится на понятие технического долга.

Теория мотивации Герцберга
Двухфакторная теория мотивации, которая опирается на то, что удовлетворённость от работы зависит от её внутренних и содержательных характеристик, а неудовлетворённость зависит от внешних характеристик работы и её контекста. Эти характеристики делятся на две группы: гигиенические факторы, недостаток в которых приводит к неудовлетворенности, и мотивирующие факторы приводящие к удовлетворению работой.
Обстановка на работе и условия труда + мотивирующие факторы = состояние удовлетворённости
Обстановка на работе и условия труда – мотивирующие факторы = нулевой эффект
ЗЫ кстати, зарплата не входит в число мотивирующих факторов. Классическая гигиена.

Модель Такмана (командная динамика)
Стадии развития команды: Формирование, Шторм, Нормализация, Работа, иногда добавлют Закрытие. Любые изменения в количественном составе (приход-уход), скорее всего переведет команду на начальную или просто более раннюю стадию.

#it_философия

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

Ключевое в этом всем - "казаться". Кому-то кажется, а кому-то совсем не кажется.
И да, тараканы на цвет и размер везде разные. Поэтому и люди теперь "у нас", потому что "тараканы" на прошлом месте задолбали.

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

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

"Раньше мы ревьювили каждую строчку кода перед деплоем в прод".

былины в пятничных #it_memes

"If you’re not embarrassed by the first version of your product, you’ve launched too late" Reid Hoffman

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

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

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

#мысли_вслух #процессы #quality

Идеи важнее реализации (оставлю себе тут перевод, опыт блога показывает, что тырнет неожиданно не вечен)

Не привязывайтесь к тому, что вы создали.
Привязывайтесь к тому, чего вы пытаетесь достичь.

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

Невозвратные затраты неизбежны. Жесткость — это выбор.

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

Сильные команды относятся к идеям легко, а к целям — твердо.

Эта гибкость — не нерешительность. Это уважение к тому факту, что понимание улучшается в процессе работы.

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

PS с Днем знаний всех. Ученье — свет, а неученье — тьма. Всем знаний ⚡️