Апазиди АйТи: про IT, разработку и менеджмент

Совет директоров от сооснователей Стратоплана - 22.05 13:00 (бесплатно)Есть такой типовой и неприятный управленческий парадокс: плохие решения почти никогда не выглядят плохими в момент принятия.Обычно всё наоборот -- есть опытная команда (и даже внешние консультанты - сам таким был), есть презентация на 40 - 100 слайдов, есть уверенность, что "мы всё посчитали". А потом через год выясняется, что решение было неоптимальное, спустя пару сотен потраченных миллионов выясняется, что "ну было же очевидно, что это неудачный путь"И самое неприятное, что это происходит не только с неопытными руководителями. Опытные C-level тоже откатываются в типовые паттерны: начинают защищать уже принятое решение, путают уверенность с правотой, недооценивают системные ограничения или продолжают "дожимать" стратегию, которая уже давно перестала работать.Такие ситуации несколько разбирались в формате закрытого "Совета Директоров" на курсах Стратоплана, а в этот раз его сооснователи -- Слава Панкратов и Саша Орлов -- собирают бесплатный онлайн кейс-клуб для обсуждение таких ситуаций и общих паттернов. Это будет интересно руководителей разного уровня, но в большей степени для для основателей компаний и CxO (и для тех, кто планирует таковыми стать)То есть это можно использовать не просто как интересный эфир, а как инструмент проверки собственных решений:* тех, которые уже приняли;* тех, которые принимаете сейчас;* и тех, которые ещё предстоит принять.На выходе обещают карту 7 паттернов, в которые откатываются даже опытные руководители при принятии решений под давлением.Плюс будут обсуждать, почему MBA, аналитика, фреймворки и прошлый опыт в текущей реальности могут не помогать, а иногда даже мешать. Что, на мой взгляд, само по себе тема для отдельного холивара :-)Свой кейс тоже можно отправить на разбор после регистрации.Дата: 22 мая, 13:00 GMT+3Формат: онлайн, 1.5 часаУчастие бесплатное, без обязательных подписок и скрытых оплат.Регистрация здесь

Сегодняшний пост не совсем по теме канала, но у меня складывается интереснейший тур почти по всем основным городам в России - так что если есть желание лично встретиться (ближайшие 1-4 недели), то напишите в личку, уточнимся по датам и слотамhttps://t.me/apazidi_go/3967

Платформенная команда -- ускоритель или узкое место?В июне буду в Питере на конференции Saint TeamLead Conf и буду вещать аж два раза (оба раза в секции TechLead Conf)Первый раз -- с докладом «Платформенная команда -- это ускоритель или узкое место?»Второй -- с воркшопом на эту же тему, где будем уже не просто рассуждать про красивые схемы оргдизайна, а приземлять теорию на реальность участников: кто у кого что просит, где застревают задачи, почему "сервис для команд" внезапно превращается в обязательный согласующий орган, и как с этим жить.Идея доклада: платформенные команды обычно создаются, чтобы ускорять разработку и снижать нагрузку на продуктовые команды. Но иногда получается наоборот: через платформу начинает проходить всё -- CI/CD, инфраструктура, доступы, окружения, шаблоны, согласования, консультации, "посмотрите, пожалуйста, почему не работает", "у нас важный проект сделайте нам уникальное окружение" -- и вместо ускорителя появляется новое узкое место.В докладе хочу разобрать, почему так происходит:* как размытые границы ответственности превращают платформу в команду "принеси-подай-почини-за-всех"* что такое Team API и как его применить на практике* какие метрики стоит смотреть, чтобы понять: платформа действительно ускоряет команды или просто героически разгребает входящий поток* и как проектировать платформенную команду, так чтобы она стала полноценным сервисомА на воркшопе будем пробовать разбирать реальные кейсы участников: где у них сейчас платформа, где продуктовые команды, где очередь, где bottleneck, и что с этим можно сделать без магического "давайте просто наймём ещё людей".И чтобы это был не просто пост-анонс, еще две просьбы:Если вы руководитель платформенной команды и хотите рассказать про свою боль, опыт или мнение по этой теме -- давайте созвонимся (напишите в личку или сразу запланируйте звонок). У меня уже есть несколько кейсов на которых будет построен доклад, но добавить новые будет всегда полезноА если вы руководитель платформенной к

Было/стало : 6 pager memo или почему ИИ может стать твоим начальникомЕсть такой 6 pager memo документ/подход из Amazon: суть в том, что вместо красивой презентации решения принимаются по основе документа, достаточно строгой структуры и сильно ограниченного в размереЭто приводило к тому, что процесс написания 6 pager memo был очень когнитивно тяжелой задачей и заставлял автора обдумать ситуацию с разных точек зрения ДО того, как выносить его на чтение/обсуждение (да, и еще интересная практика - встречи на которые собираются топы, что бы прочитать документ : ведь просто найти время в календаре для чтения нет, поэтому лучший способ убедиться, что все на одном уровне понимания - это дать прочитать документ в начале встречи в тишине или даже собрать отдельную встречу под это)В известном интервью Безоса есть мысль о том, что в результате эти 6 pager memo становятся такими кристально понятными и заряженными смысл, будто "ангелы поют с небес"Теперь вернемся в 2026 г и повсеместного использования AI, который одинаково хорошо сгенерирует хоть 6 pager, хоть 600 pager (c одинаковым (околонулевым) смыслом). Я решил погуглить (или как теперь называется глагол для поиска в perplexity?) и нашел вот такую статью - Writing Crystalized Thinking At Amazon. Is AI Muddying It?Оказалось, по словам авторов, что ситуация драматически ухудшается и некогда data driven Amazon с поющими ангелами превращается в корпоративный нейрослоп, где повсеместно вместо использования собственного ума заставляют использовать ИИ и поощряют большие документы (ведь менеджер может теперь не читать, а сделать выжимку с помощью ИИ).И это как мне кажется как раз то, что обсуждали в комментариях к прошлому посту: если использовать ИИ, как усилитель - то становишься умнее. А если как заменитель своего ума, то буквально ИИ становится твоим начальником, ведь теперь именно он (оно?) определяет - что и как ты думаешь и как выглядишь перед коллегами. Короче еще чуть-чуть и матрица наконец станет реальностью :-)p.s. Если

Попробуй "extra thinking" Я ежедневно и помногу использую почти все доступные нейросети (ChatGPT, Claude, Gemini, в дополнение к ним еще и Perplexity для поиска) и поймал себя на неожиданной мысли: почти везде включаю thinking, а все чаще -- даже extra thinking.…Подумай долго и тщательно, продолжениеНа одной встрече коллега заметил, что добавка "подумай долго и тщательно" отлично работает не только с ИИ, но и с людьми.Попробовал пару раз -- действительно качество ответа заметно возрастает :-)А чтоб думать "долго и качественно" с ИИ перешел таки (после долгих сомнений) на ChatGPT Pro , теперь общение с ИИ больше напоминает компиляцию программы : дал промпт, ушел пить кофе, через 10 минут получаю результат.Не скажу, что все ответы с Pro стали лучше - для большинства тем он сильно избыточен и слишком медленный. Но если нужно реально думать долго и искать неочевидные выводы, сравнить варианты, найти риски - pro'шка отрабатывает получше.

Не усложняй: книга про то, как не утонуть в проектном управленииОдно из прикольных открытий во время работы в IBM было в том, что дата завершения проекта должна быть известна сильно заранее. Желательно — обведена в календаре ярким маркером.Казалось бы, очевидно, но уже в первом моём не-IBM проекте я услышал прекрасное: «мы планируем запуститься где-то в 4-м квартале». Надо ли говорить, что следующий слайд объяснял, почему не удалось запуститься "где-то в 3-м квартале", ну а через год было полное бинго: слайды про неудачи запуска уже во всех четырёх кварталах.Тот проект мы в итоге с большими сложностями закрыли, а его замену сделали с нуля за 9 месяцев, из которых 5 заняло согласование плана и бюджета.Из этого я вынес важный урок : чем длиннее проект, тем больше шансов не успеть вовремя, а значит "дробилка" проектов - один из главных элементов успеха.Большой проект нужно дробить на этапы. Этапы — на месяцы. Месяцы — на недели. Недели — на дни. В ИТ мы называем это спринтами, а обычные люди (например на стройке) — календарным планированием.И уже много лет спустя, когда мы в СИБУРе искали основу для метода управления проектами, я с большой радостью увидел эту же "дробилку", только гораздо более продуманную, во фреймворке p3.express. И сразу в него влюбился — о чём уже писал (или вот хабр) и даже выступал вот тут или тут .Так вот, это всё длинное интро к тому, что вышла книга Димы и Леры Ильенковых про p3.express — "Не усложняй! Управление проектами по методу P3.express" (ссылка на литрес в заголовке)Название отлично отражает суть : есть куда более полные методики, закрывающие множество аспектов и сотни шаблонов документов (хех, типовой шаблон на разработку в IBM был 66 страниц!), но конкретного ответа на типовые вопросы "А что мне делать завтра?" они зачастую не дают.Кстати, в этом и еще одна сильная сторона P3.express: в нем есть вся управленческая мудрость поколений о том, КАК управлять проектом. Но он не подменяет руководителя — все ключевые решения о том, ЧТО нуж

Постоянно обсуждаем это на встречах и курсах: Работа CTO, это как ни странно не про технологии, и не про то как управлять айтишниками. А скорее про то, как достигать бизнес-цели с помощью технологий. Вот собственно и классики (и заодно кумиры молодости, типа Кента Бека и Ричарда Мартина) подтянулись.

Нет, вы посмотрите на этого еретика, о чём он вообще?Признайте: ИИ с лёгкостью уделает вас в кодинге. Нет такой задачи, на которую у вас ушёл бы день, а ИИ не сделал бы её за пять минут.Всё кончено. Код будете писать не вы. Да-да, я знаю. Смиритесь.Но вот в чём штука - это даёт вам огромную силу, потому что теперь можно делать то, о чём раньше и мечтать не приходилось.Например, подумайте о покрытии тестами: вы же помните, какая это была морока. Надо писать все эти чёртовы тесты, и вы знаете, что тесты на самом деле не доказывают, что код работает.Запускаешь code coverage, ухмыляешься и говоришь: ну да, ладно, но это же не значит, что код работает. Это значит только, что он исполняется.Так вот, теперь это можно исправить, у вас появились ресурсы, чтобы это сделать. Говорите ИИ: покрой этот чёртов код тестами. А потом берёте mutation tester (да, это такой инструмент - и пусть ИИ его вам и напишет, уйдёт минут пять), дальше ИИ запускает этот инструмент, тот вносит изменения в исходный код и прогоняет все тесты. И если тесты не падают - он допишет тест, который поймает эту мутацию, и это значит, что у вас будет покрытие тестами. Ей-богу, у вас будет покрытие тестами.И знаете, что ещё можно? Можно анализировать качество кода. Можно написать инструмент, который смотрит на цикломатическую сложность.Кстати, есть отличный инструмент для этого. Ему лет двадцать. Называется CRAP - хорошее название, как расшифровывается - не знаю и знать не хочу. Это комбинация покрытия тестами и цикломатической сложности.И вы можете сказать ИИ: понизь метрику CRAP - ниже пяти, ниже четырёх, как хочешь. И это заставит его порезать все жирные функции на маленькие и покрыть их все тестами. Ей-богу - подумайте, какие у вас теперь рычаги, чтобы довести код до качества, какого вы никогда не видели.Знаю-знаю, я тот самый старый дед с Clean Code, но вот что я вам скажу: теперь вы можете сделать код чертовски чище, если заставите ИИ сделать это за вас.Да что этот дед может знать про разработку?Хотя пог

20-23 апреля у Стратоплана пройдет конференция «Управление 2026» - 4 дня про то, как меняется управление у руководителей и директоров. Я буду выступать в директорской секции с докладом: "AI ускорил код. Почему компания все равно тормозит" Тема для меня любимая:…Презентация выступления доступна по ссылке , спасибо тем кто присоединился и слушал!(ссылка на видео)Во время презентации было несколько интересных вопросов в чате, на которые не успел ответить - отличный повод сделать еще одну серию постов. Надо только про три кейса закончить, которые начал ранее - во вторник с группой их отлично обсудили на уроке "Системный people management" )

20-23 апреля у Стратоплана пройдет конференция «Управление 2026» - 4 дня про то, как меняется управление у руководителей и директоров.Я буду выступать в директорской секции с докладом: "AI ускорил код. Почему компания все равно тормозит"Тема для меня любимая: поток ценности, оргдизайн, эффективность, Голдратт, value added vs non-value added time — и вообще про то, почему локальные ускорения еще не означают, что быстрее стал весь бизнес.Поговорим о том:* что такое организационная вязкость* где AI реально ускоряет, а где только маскирует проблему* какие задержки чаще всего тормозят компанию* что с этим может сделать директорРегистрация бесплатная, занять места можно по ссылке вот тут https://stratoplan-school.com/management/

Кейс 3. Коллега, который играет по своим правиламПродолжаем серию про оргдизайн и взаимодействие в командах, предыдущие серии -- "сложный начальник" и "незаменимый сотрудник". Сегодня кейс посередине -- про коллегу на одном уровне. Цель всей серии -- показать, что несмотря на то, что проблемы кажутся разными, у всех у них одна и та же причина, об этом будет скоро завершающий пост.Итак, представьте, что вы работаете в большой компании-бигтехе, в тандеме Product Owner + Tech Lead, на должности Tech Lead (или PO -- не суть важно).Вы в компании всего полгода, ваш коллега-напарник сильно дольше, уже 4 года. У вас общий руководитель CTO, размер команды, скажем, 15 человек.Распределение полномочий классическое: PO отвечает за продуктовую часть и список задач, Tech Lead -- за их техническую часть и реализацию задач в срок.Вроде на старте кажется, что всё ок, но очень быстро выясняется, что коллега играет по своим правилам:* решения обсуждаются устно;* задачи не фиксируются в бэклоге;* приоритеты меняются на ходу.Вы поднимаете этот вопрос на личном обсуждении, а в ответ: "Мне так удобно, мы так всегда работали, еще с организации команды, когда нас всего было трое. Если вам нужно фиксировать что-то в бэклоге -- фиксируйте, я не против".Такой ход работы очень быстро приводит к тому, что ожидания не совпадают с реальностью. Команда занята переработками, переделками, появились задержки в сроках.При этом коллега, когда дела идут хорошо, уверяет, что это успех продукта, а когда плохо -- "техническая команда не так поняла требования". Вы решили обсудить с CTO, но у него позиция осторожная: «Попробуйте договориться внутри тандема. Если станет критично, то вернемся к разговору».Что делать в этой ситуации? Давить силой на формализацию? Подстраиваться? Эскалировать CTO и заставить его принять чью-то сторону? Отгородить команду от PO? Или что-то еще?

Кейс. Незаменимый сотрудникПродолжу серию кейсов про оргдизайн и взаимодействие в командах. Пока без ответов -- просто ситуация и вопрос в зал, тем более, что комментарии настолько хороши, что хоть сейчас можно в книжку управленческой мудрости добавлять.Итак, знакомый всем сценарий -- незаменимый сотрудник. Как правило, работает давно, знает все детали и обладает какими-то критическими знаниями, например:* как исправить критический инцидент (вспоминаем книжку «Проект Феникс»);* как разобраться в древнем легаси и ничего не порушить;* как работают забытые интеграции и прочие знания «прошлых поколений»;* почему тут «все не так просто» и как подступиться к сложной проблеме.Не менее знакомый сценарий -- делиться знаниями не хочет. И, может быть, даже не отказывает в советах, но новичков не обучает, документацию не обновляет, что и как работает, не рассказывает -- «я же разработчик, а не лектор или шут».Команда от него зависит, пока он на месте, все работает. Но как только он уходит в отпуск или не доступен -- часть процессов встает.Что делать в этой ситуации? Оставить как есть? Заставить силой? Уволить?

09.04 Круглый стол : Delivery 2.0 как изменение процесса, а не набор ИИ-инструментовЗавтра с друзьями и коллегами из Umbrella IT и не только будем обсуждать как ИИ меняет процесс разработки. Тема заявлена интересная - не столько про то, как запустить Cursor или Claude Code, сколько про сам процесс и систему управления.Уверен, что будет интересно - если есть возможность и желание присоединится и послушать + позадавать вопросы, то регистрируйтесь вот тутhttps://umbrella-it-event.timepad.ru/event/3879949/#register

Кейс. Сложный начальникМне нужно как-то наладить регулярность постов, поэтому сделаю-ка я еще одну серию, на этот раз про любую тему -- про оргдизайн, власть и взаимодействия в командах и поэтому дальше планирую несколько кейсов на эту тему, под которыми надеюсь подвести общий итог.Итак, кейс: представьте себя руководителем сравнительно большой (40-50 человек) команды в большой компании. Над вами есть прямой начальник, который отвечает уже за 150+ человек, включая вашу команду. Он пришел недавно, и вы с ним регулярно не согласны:* Он микроменеджерит, лезет в работу конкретных разработчиков и раздает странные задачи напрямую.* Формулирует поручения в стиле «сделай нужное чудо», а на приемке говорит: «Что вы натворили, ОЧЕВИДНО же, что нужно было делать совсем другое».* Ставит срочные встречи за 10 минут до начала или звонит: «Зайди срочно», а тема оказывается не срочной и часто вообще не важной.* Меняет процессы на ходу: то Kanban, то Scrum, то сходил на конференцию и теперь «с понедельника срочно внедряем лайфхаки оттуда».* Ключевых людей вокруг себя он уже поменял: HR и двоих ваших бывших коллег-руководителей заменил на лояльных ему новичков (некоторых привел с прошлой работы)Команда устает, люди выгорают. Два ваших тимлида уже принесли заявления на увольнение -- «с ним я работать не могу». Комментарий начальника: «Не нравится работать, пусть уходят». Но риски потери знаний, развала команды и просадки результата остаются почему-то в вашей зоне ответственности.Вы решили донести риски до совсем биг-босса (начальника начальника), с которым у вас хорошие отношения. Он согласился, что ваши доводы серьезные, и пообещал разобраться. Они встретились с вашим руководителем, но тот как-то убедил его в своей правоте, и вы получили емейл от биг-босса: «Делай все так, как тебе сказано».Бонусом ваш начальник теперь зол еще и лично на вас: вы эскалировали и заставили его оправдываться наверху.Вопрос: что в этой ситуации делать?

Попробуй "extra thinking"Я ежедневно и помногу использую почти все доступные нейросети (ChatGPT, Claude, Gemini, в дополнение к ним еще и Perplexity для поиска) и поймал себя на неожиданной мысли: почти везде включаю thinking, а все чаще -- даже extra thinking. И вдобавок к этому стал прямо писать в промпте: "подумай долго и тщательно"Мой типовой кейс использования -- это промпты типа:* проверь варианты* опиши риски* оспорь мою гипотезу* где я неправ* задай недостающие вопросыА для таких задач быстрый (instant) ответ часто оказывается худшим — модель поддакивает, пересказывает промпт другими словами, хвалит или выдает первое правдоподобное объяснение вместо нормального разбора.Из этого совет: если вам кажется, что модель тупит, переключите на режим thinking плюс опционально добавляйте "подумай долго и тщательно" в промпт Очевидно, что это не универсальный совет, иногда instant, может, и будет лучше (хотя навскидку приходит только проверка орфографии и простых фактов), но если хочется из нейросети получить полноценного мыслительного партнера -- "extra thinking" прям отлично помогает.