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

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

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

В IT чудес не бывает pinned «Не думал, что придется так скоро повторять прошлогоднюю историю (да и в принципе, что придется повторять "шаг на выход в никуда"), но решение принято. Я снова открыт к предложениям по возможному нанесению пользы в какой-нибудь интересной компании. Все как…»

Не думал, что придется так скоро повторять прошлогоднюю историю (да и в принципе, что придется повторять "шаг на выход в никуда"), но решение принято. Я снова открыт к предложениям по возможному нанесению пользы в какой-нибудь интересной компании. Все как в прошлый раз, технический менеджмент в продуктовой разработке (не заказной), РФ. Любые форматы работы, но с фокусом на гибрид, так понятней и интересней (Питер). Полная удаленка требует обсуждения деталей. Сейчас планирую перезарядиться, переформатировать мозг и четче сформулировать ожидания. Но уже готов пообщаться по рекомендациям тех, кто хорошо знает меня и мои возможности (но стеснялся меня хантить 😃). Дальше будем искать "обычными" способами, ждите новые #вопросы_с_собесов. Если у вас в компании есть что-то интересное - маякните мне пожалуйста (@maxbeard12). LinkedIn HH (эта ссылка откроется только у рекрутеров)

Скучали? Жизнь идет своей чередой, ключи все так же бьют по голове. Писать все так же не о чем, все мысли "съедаются" на подлете к "бумаге" 🙂 Зацепила статья, советы напомнили анекдот про филина-стратега. Но что-то в них есть. The Best Prioritization Is No Prioritization The better you are at moving fast the worse you can be at prioritization. Prioritizing well requires being very clever. Building fast is great because you don’t need to be clever at all. Prioritization is a trap. It wastes time, wastes effort, and delivers worse results than just executing faster. Instead of spending your time prioritizing: - Spend more time focusing on building faster (or literally just spend the time building) - Shift everyone into durable teams that don’t have to do cross-business prioritization at all, and manage your “prioritization” by the resourcing decisions of growing, downsizing, or splitting teams #management

Незаконченные консервативные #мысли_вслух Написание кода ишачком ускоряет процесс поставки в одном месте (которое, имхо, нечасто и было "узким" горлышком), но ярко подсвечивает проблемы других местах: продуктовом видении, планировании и взаимодействии. В итоге, есть риск того, что "расширив" пропускную способность в одном месте, мы просто положим систему переместив всю нагрузку туда, где производственная система может ее не выдержать. Самое сложное всегда было не написать код, а придумать что сделать/что продавать (чтобы там не говорили бизнес-люди, тыкая пальцем в разработку). Все эти "мы теперь быстрее проверяем гипотезы" умирают в месте, где заказчики не хотят быть частью гипотезы. А иногда и гипотез для проверки нет. Есть просто "заказчик попросил эту фичу" (что в целом тоже имеет право на жизнь в виде бизнеса) Кажется, что если "нужный" код еще не написан, то это не потому, что для этого нет рук и мозгов. Может просто этот код до сих пор никому и не нужен был по-настоящему? Или мы не умеем в приоритеты. Или нет понимания не то что последовательности шагов, но и направления движения? Думаю, что мы наблюдаем превращение software в настоящее soft, когда дешевле выкинуть и написать заново, чем разбираться в "Big ball of mud". PS это как одноразовая бытовая техника и автомобили... И да, так "веселее" для пользователя.

IT-басни в пятничных #it_memes Мораль: Где начальников полно, Там продукт, увы, говно. Там, где ответственности ноль, Результат — сплошная боль. Ну что, может еще созвончик?

Читаешь чью-то очередную статью. Начинаешь писать сюда черновик заметки по ней. Бегаешь по связанным хештегам. Понимаешь, что уже писал похожее и сам, и статьи были. Кажется, что уже нет тем, которые тут не помусолил. И задумываешься, а для чего и кому нужна очередная история? Одна из причин моей пропажи тут. Но реально прикольно залипать на старых заметках: часто прямо вспоминается кейс на работе или что-то другое, из-за чего заметка появилась. А иногда такой "О! Вот классно же написал, но вот недавно был кейс, так не ответил...". Короче, вот очередная статья про #metrics Engineering Metrics for Beginners Жаль, что большинство примеров метрик не для on-premise жизни. Буду потом залипать и вспоминать...

The un-hateable engineering managers The lie of Radical Candor and ruining an engineer's day I'm now willing to step into what might feel like Obnoxious Aggression to the other side, as long as I feel deep inside that I'm doing the right thing (which doesn’t mean always laying people off). I'm more ok with people being angry at me, not liking me, or even thinking I'm unfair. Hopefully it won't get to hate, but that might happen too. I still squirm inside a bit every time - which I think is a good sign. When I stop squirming, it’ll mean I stopped caring. Мне не хватало этой статьи... И да, у меня есть несколько кейсов для ответа на вопрос на собесе "Расскажите о случае, когда вы испортили кому-то день". Хороший вопрос, добавил в копилку вопросов для менеджерского собеса. #management

Почему все так закончилось? Да хз. С моей колокольни, которая и рядом не стояла там, где точно все видно было, видится как последовательная серия неправильно принятых решений (бизнес и технических) в разное время разными людьми: • неправильно определили целевую аудиторию продуктов • необычная кадровая политика на топ-уровне • "бессрочное" лицензирование с фокусом на поддержку, которую разработка конечно "завалила работой" (в этом месте я тот еще эксперт, но странно продать продукт, а потом почти бесплатно его дорабатывать несколько лет...) • резкий рост размеров департаментов разработки • проиграли борьбу с технической сложностью эксплуатации получившихся комбайнов, которые как SaaS под чуткими руками своих разрабов заработали бы, но не на внешке • неверные архитектурные решения ("прототипы" в проде) • на деске бороться с MS можно было только определив узкий набор функциональности, а не меряясь количеством фичей редакторов у них и у тебя (до сих пор вспоминаю и ржу над запросами по фичам анимации в презентациях). Думаю, был шанс в каком-то общем объединенном решении (почта+мессенджер+хранилище доков с редакторами), но объединенные системные требования становились несуразными. Ну а может просто печень у продавцов слабая... 🫠🍻 ЗЫ Ну и да, если кто-то не знал, обычные (без контроля со стороны регуляторов) компании до сих пор легко используют продукты MS у себя, деск уж точно.  #байки

Вчера вся лента пестрила "новостями" о "грядущих" сокращениях в МойОфис, все это разбавлялось рассуждениями "экспертов" о причинах провала. Ну во-первых, про эти сокращения была публичная инфа парой месяцев раньше, странно что все так возбудились только сейчас, когда многие сокращенные (жаль, что пока не все конечно) уже на новую работу вышли. Кстати, приятное удивление - те, кто озаботился и подсуетился, достаточно быстро получили возможность, выдохнув, приступить к выполнению новых задач на новом месте. Во-вторых, почти все упоминают только про злосчастные десктоп-редакторы, которые якобы "форки либры" и типа непонятно зачем нужны. Оставим тему с "форками" фантазерам, показывающим всем сведующим качество своей "экспертности". Но часто упоминающиеся 1000 человек сотрудников как будто только на деске и были... А что там у МойОфис еще было? Диванный эксперт-ITпарапсихолог тоже в деле. Что-то аж на 2 поста тележка разделила. Никакого инсайда (ну самую малость), все доступно на сайте или тырнетах, просто нужно почитать подробнее и подумать. У некоторых (редких) экспертов упоминалось про почтовое решение. На самом деле было 2 почтовых продукта . Фактически 2 внутренних конкурента, один - тяжело администрируемый "мегакосмолет" на "мульоны пользователей", второй - в целом неплохо работающий сервер. Но почему их 2? Поверьте не просто так 🙂 Про количество внутриразрабатываемых почтовых клиентов и их вариаций умолчу, но там было много. Вот вам раз проблема. Были еще отличные мобильные редакторы - имхо (и не только мое) один из лучших продуктов для редактирования доков на мобилах. Проблема 1: отличные, но бесплатные. И нафиг никому не нужно оно на мобиле за деньги. Как зарабатывать на них не придумалось, хотя одно время пытались сделать платные фичи. Проблема 2: одновременная разработка по Android и iOS. Не готов рассуждать без инсайдов про количество пользователей на той и другой платформе, но команда старалась минимизировать затраты унифицируя разработку с помощью Kotlin Multiplatform. Про корпоративный мессенжер Squadus из экспертов вообще никто не писал (не видел), а меж тем вполне работоспособная и удобная зверушка. Да на базе open source, но и команда небольшая. В целом из всего того чатообразного, с чем удалось столкнуться, вполне жизнеспособный продукт, но возможно с ограниченным рынком: маленьким компаниям не надо, у больших - большие ожидания (см.комменты ниже). Не удивлюсь, если дальше мы увидим его в списке продуктов какой-нибудь компании. Про мои любимые Документы Онлайн. Честно, я тут полгода пользуюсь похожим сервисом от Я. Так вот, ДО было сильно удобнее для работы. Но, есть "вероятные" проблемы со сложностью разворачивания, знаменитыми сценариями "коллаборации" совместного редактирования и максимальным количеством пользователей 😉 Что объединяет любые серверные on-premise продукты? Сложность со сценариями разворачивания и эксплуатации: все хотят sla 99.99(9), чтобы все разворачивалось в 1 клик, zero-downtime при обновлениях и вообще чтоб работало само. При этом не все готовы подтягивать качество своей инфры и внутренней экспертизы. В итоге ты или делаешь продукт для тех кто умеет в кубы, или тем кому просто нужна виртуалка, которая просто запускается и работает. Или оба варианта (долго-дорого), или только один, но всегда с определенными ограничениями по нефункциональным требованиям. Вообще (тут небольшой инсайд) - просто дохрена времени уходило не на разработку продуктовых фичей, а на нефункциональщину (развертывание, производительность, отказоустойчивость, геораспределенность и вот это все). При том, что каждый продукт по историческим причинам разрабатывался отдельно, всю эту нефункциональную обвязку каждая команда писала самостоятельно (да, это неэкономно...) продолжение

Всем привет Я думаю, что многие в курсе истории с МойОфис (НОТ) и того, что какую-то часть разработки там сокращают. Это тот момент, когда многих готов был бы взять без собесов и вот этого всего. Но во-первых все "не поместятся", а во-вторых каких-то специализаций у меня и вовсе нет. Обидно. Я понимаю про текущий рынок найма и то, что кандидатов на 1 место сейчас много (мягко говоря) и можно лениво ковырясь отбирать "лучших единорогов". Но если вдруг вам нужны люди "с гарантией от меня", маякните в личке. Есть сильные фронты, "ручные" тестировщики, девопсы (разных специализаций), PO, PjM. IT-парапсихолог уже не модно, попробуем IT-сватовство 😂 Чудес конечно не ожидаю, но если удастся кого-то свести и кому-то помочь, буду рад. ЗЫ ребята из НОТ, вы тоже можете маякнуть в личке, возможно я не про всех "добби" в курсе. Но, я строгий сват... без обид, ибо рекомендация для меня - это серьезно.

#5for5 1. Про 1:1 Признак хорошей встречи: после нее сотрудник чувствует, что его работа была замечена, его проблемы были восприняты всерьёз, и его профессиональный рост действительно имеет значение. 2. О ваших исходниках замолвите слово… Why Your Engineering Team Is Slow (It's the Codebase, Not the People) Я бы не сказал, что это основная причина тормозов, но бывает и такое. Про 5 признаков проблем с исходниками и что с ними делать 3. Почему делегирование не работает и что делать 4. Когда менеджеру нужно вмешаться 5. 6 навыков, необходимых для того, чтобы хорошо стратегировать #management #процессы #it_memes  "когда вышел на новую работу, видишь как устроены процессы и думаешь, что делать..."

Специализированный OWASP Top 10 for Agentic Applications 2026 Немного для тех, кто судорожно пытается хоть как-то придумать, как оценить все новые "AI фичи" на безопасность. #tech_read #security

Просто несколько зацепивших ссылок, без моего традиционного бубубу вокруг статьи. Почему-то вспомнились мои древние "5за5". • Про ошибки менеджеров • Хаос против бюрократии: выбирайте, что вам больше по душе. Или что на самом деле стоит за словами "нам нужно улучшить процессы" • Страдание — это не лидерство. Про пессимизм в менеджменте (о, даа). "Не вдохновляет, но..." (да, Семен?) • Страх разрушает вашу организацию • Ну и про проект "Аристотель" от гугла про эффективность команд (упоминается в предыдущей ссылке) Ну и картинка про "порядок и системность", заочно для #it_memes #management #5for5

Учитывайте, что все вот эти "вокруг да около" классно рассыпаются, когда ты их говоришь тому, кто их сам отлично применяет. Потому что он слышит именно "ты - ...удак Y", а не «Вы производите впечатление Y» или «Возможно, вы производите впечатление Y», или «Вы кажетесь Y». "Со мной сложнее спорить, если я скажу: «Вы производите впечатление человека Y», чем если я предположу, что каким-то образом обладаю особым пониманием того, кто вы есть на самом деле." Да с фига ли :) Тот, кому интересно спорить - только еще больше раззадориться. А вот для тебя будет неожиданностью, что все эти речевые эквилибристики не сработали. В общем, будьте готовы и имейте в себе силы и смелость говорить так, как есть. Естественно, без оскорблений, чудаки :) Мне кажется, всегда важнее аргументация. Вот ее и нужно готовить. А все обороты нужны лишь для того, чтобы забрало на шлеме раньше времени не упало. #management

Планирование (включая оценку) того, что нам нужно сделать в релизе, квартале, за год - это Сизифов труд? The Sisyphean Tragedy of Planning | Stop Trying To PUSH Rocks Up-Hill Like Sisyphus И вроде все верно, и про неточность прогнозов, оценки, изменяющийся контекст. И то что просто "вытягивать" (брать следующее по приоритету) и релизить по готовности удобнее, чем заранее планировать и коммититься в даты. И в целом забытый (ну или пропавший из инфолент) лозунг #NoEstimates про это же. Но бизнес не привык и не будет так работать. И большинство клиентов тоже. Им всем нужно понимать что будет сделано, а не "может быть сделано". Истина скорее где-то посредине, но все ближе к планам/целям и отмеченным датам. Иначе - это бесконечная история "а вот тут еще один мега-супер-пупер важный запрос прилетел, а вот еще..." А вообще в голове сложился тот коммент, что первым там нарисовался. #процессы

Я всегда говорил: везде есть свой уроборос... "Tech debt causes slowness. Slowness creates pressure. Pressure creates more tech debt. If your diagram has no loops, you probably haven’t looked hard enough. Chains are comforting because they have endpoints. Loops are uncomfortable because they don’t. That discomfort is the point!" Ask “what conditions made this likely?” rather than “what caused this?” This shifts the question into something systematic, rather than looking for a silver bullet. Every system has holes (incomplete tests, ambiguous runbooks, technical debt, etc). Individually, none of them are “the cause". The incident happens when enough of them line up at the same time. The Root Cause Fallacy In which framing it as a root cause means you've already lost #мысли_вслух #процессы

Практические знания (получаем контекст): - о тестируемом объекте (SUT) в целом - о том, что мы сделали нового - о внесенных изменениях и затронутой ими части функциональности - об основных (самых популярных/ожидаемых/итп) пользовательских сценариях - о пользовательских данных и том, как они участвуют во всех пунктах выше - кто и как тестировал внешние для нас компоненты, которые делают другие команды

Продолжаем. Что нам поможет с рисками? (почему-то вспомнился мем "а чего мы хотим?") Теория. ISO 25010 (Systems and software engineering|Systems and software Quality Requirements and Evaluation (SQuaRE)|System and software quality models и ее аналог ГОСТ Р ИСО/МЭК 25010-2015 (в виде pdf). Этот ISO описывает модель качества продукта через характеристики. • Functional Suitability (Функциональная пригодность): Полнота, корректность и уместность функций. • Performance Efficiency (Эффективность производительности): Временные характеристики, использование ресурсов, емкость (потенциальные возможности). • Compatibility (Совместимость): Совместное использование, интероперабельность. • Usability (Удобство использования): Понятность, обучаемость, управляемость, защита от ошибок пользователя, эстетика интерфейса. • Reliability (Надежность): Завершенность, доступность, отказоустойчивость, восстанавливаемость. • Security (Безопасность): Конфиденциальность, целостность, неподдельность, отслеживаемость, подлинность. • Maintainability (Поддерживаемость): Модульность, возможность повторного использования, анализируемость, модифицируемость, тестируемость. • Portability (Переносимость): Адаптируемость, возможность установки, замещаемость. Это то, что можно использовать, как реперные точки, относительно которых мы пытаемся обсуждать вопросы. “Просто” берем каждую из характеристик/подхарактеристик, уточняем наше текущее состояние и обсуждаем с бизнесом насколько его ожидания расходятся с нашей суровой реальностью. Что из этого критично, а чем можно пренебречь на данном этапе и как долго можно “пренебрегать”. Для новой функциональности делаем это на входе. Чем больше прозрачности - тем проще. Даже если бизнес, в силу разных обстоятельств, не может нам дать конкретики, то понимание того, где мы сейчас находимся, очень полезно нам самим. Банальный пример: вместо вопроса "а у нас будут заказчики с большими файлами?" (с ответом "конечно будут"), лучше задавать "у нас сейчас грузятся файлы до 10GB, этого достаточно будет в текущих условиях?". (Поверьте, только на собесах по системному дизайну такие вопросы задаются на входе и на такие вопросы всегда есть ответы) Практические знания (получаем контекст): - о тестируемом объекте (SUT) в целом - о том, что мы сделали нового - о внесенных изменениях и затронутой ими части функциональности - об основных (самых популярных/ожидаемых/итп) пользовательских сценариях - о пользовательских данных и том, как они участвуют во всех пунктах выше - кто и как тестировал внешние для нас компоненты, которые делают другие команды Дальше обсудим, как это все можно применить на практике. #quality