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

Анонс: управленческий онлайн Summer Camp, 22–25 июня Лето — отличная возможность прокачать управленческие навыки, да еще и бесплатно. На следующей неделе я буду открывать директорский день на Summer Camp от Стратоплана: По формату мероприятие похоже на…

Скидка и промокод на курсы Яндекс.Практикум В бэклоге накопилось штук 5 постов, в том числе и материалы с конференций - и с Питерского TeamLead Conf, где был доклад и мастер-класс про платформенные команды и с Стратоплан SummerCamp, про оргдизайн но этот пост идет вне очереди - а все потому, что в нем промокод на курсы Яндекс Практикум, в том числе на те, где я автором побывал: * Технический директор // CTO : тут я не только автор, но и наставник, поэтому можем пообщаться лично * Middle Project Manager * Основы Project Management * и новый курс (старт 09.07) ИИ для продакта Промокод дает скидку в -15% , плюс с 01.07 цены повышаются, поэтому если давно хотели, но не решались, то самое время воспользоваться https://practicum.yandex.ru/promocode/?code=YAFRIENDEXPERT116196934988

Анонс: управленческий онлайн Summer Camp, 22–25 июня Лето — отличная возможность прокачать управленческие навыки, да еще и бесплатно. На следующей неделе я буду открывать директорский день на Summer Camp от Стратоплана: По формату мероприятие похоже на предыдущие конференции, но в этот раз фокус будет не только на умных презентациях, но и на отработке конкретных управленческих навыков. Тема моего воркшопа: "Оргдизайн в эпоху AI: как не ускорить хаос" И это прямое продолжение начатой вчера серии постов про Бизнес vs IT. Любой бизнес зарабатывает деньги через цепочку создания ценности: преобразует входящие ресурсы в продукт, пользу для клиента и любимое акционерами слово EBITDA. А IT — напомню, это информационные технологии, то есть в центре находится информация, а не только технологии, — помогает связать отдельные шаги этой цепочки в единый процесс. И одновременно увидеть, где находится узкое место, на каких стыках останавливается работа, какие зависимости мешают двигаться быстрее и насколько удачно проведены границы между командами. Особенно важным это становится сейчас, когда AI позволяет отдельному сотруднику или команде работать в несколько раз быстрее. Проблема в том, что компания от этого не обязательно ускоряется. Если разработка начала выдавать больше кода, но тестирование, согласования, приоритизация и принятие решений остались прежними, то AI не устраняет ограничения системы - просто становится больше незавершенной работы, хочешь измеряй ее в тасках или в проектах, суть дела не изменится. Именно поэтому оргдизайн становится must-have навыком директора. Директор отвечает не за локальную продуктивность отдельных людей, а за способность всей организации превращать их усилия в бизнес-результат. Ровно этим и займемся на воркшопе: * почему AI ускоряет людей, но не всегда ускоряет компанию * как смотреть на оргструктуру как на систему потоков, зависимостей и решений * как AI усиливает текущую конфигурацию организации — и хорошее, и плохое * как использовать AI для анализа, критики и моделирования оргдизайн-решенй. В результате участники уйдут с одной оргдизайн-гипотезой по своей команде или подразделению и с промптом, который можно применить уже на следующий день. 👉 ЗАРЕГИСТРИРОВАТЬСЯ Формат: онлайн Когда: 22–25 июня, по вечерам Участие: бесплатно — нужно подписаться на Telegram-каналы спикеров. Но там действительно умные и качественные каналы: сам всё читаю. Приходите. Будем разбираться, как ускорять не только людей, но и компанию целиком

Бизнес vs IT . Часть 1 Ох, вчера в комментариях всплыла очень мною любимая тема, которая триггерит меня уже много лет. Практически с первого дня работы CIO/CTO :-) Это деление на бизнес на ИТ: причем и как со стороны этого самого бизнеса, так и со стороны ИТ такое же деление слышу не реже, а может даже и чаще Мое глубокое убеждение, что на управленческих ролях такое разделение очень губительно и для самих айтишников и для компании в которой они работают. Поэтому попробую это раскрыть в нескольких частях и, по возможности, попробую не превратить в долгострой Итак, откуда вообще берется это деление? Одна из причин, кажется, историческая (как это правильно отметили в комментариях) - это наследие тех времен, когда ИТ было вспомогательной функцией автоматизации. Поэтому как-то с тем пор закрепилась в головах мантра: * Бизнес придумывает, что нужно; ИТ реализует * Бизнес отвечает за финальный результат; ИТ за систему То есть логика какая-то такая: когда был просто бизнес-процесс, потом приходили ИТ и на своем непонятном языке и компьютерами его автоматизировало Логика примерно такая: сначала был настоящий бизнес-процесс — продажи, закупки, склад, бухгалтерия, производство, логистика. А потом пришли ИТ, на своем непонятном языке и при помощи компьютеров, и этот процесс автоматизировали. Из такой картины мира почти автоматически рождается схема «заказчик — исполнитель» со всеми ее классическими минусами: * «что просили, то и получайте»; * «вы опять сделали не то, что нужно»; * «бизнес сам не знает, чего хочет»; * «ИТ опять всё затянуло и усложнило». Проблема в том, что сегодня для большинства компаний ИТ - это не просто вспомогательная функция автоматизаторов, а одна из ключевых функций, которая интегрирует всю компанию и связывает все процессы. Компьютер-то уже пару десятилетий на столе у каждого клерка стоит и надо думать, что наверное не просто так. Мысль это вообще не новая, встречалась еще в 2011 г "Why Software Is Eating the World", 2011) и ее часто перефразируют в духе "Every company is a software company — or will be acquired by one." И за прошедшие 15 лет с выхода этой статьи ситуация стала еще актуальнее: сегодня все больше компаний работают не просто "с помощью софта", а буквально внутри софта. Возьмите например пикеров на складах или в магазинах: уже софт управляет людьми, а не наоборот, как это было несколько лет назад. Особенно интересно посмотреть на небольшие продуктовые и ИТ компании. Казалось бы, если продукт компании это ИТ продукт (например SaaS), то ИТ это и есть бизнес! Но нет, очень часто и там проявляется это самое Бизнес vs IT или точнее в разрезе Разработка vs Продажи Так что если вы делите на бизнес и ИТ, попробуйте задать себе простой вопрос: бизнес - это кто конкретно? Продажи? Финансы? Operations? ГенДир? и если уж есть такое деление, означает ли это, что ИТ это не часть бизнеса вообще? В следующей части попробую разобрать, почему бизнесу на самом деле удобно держать ИТ в роли исполнителя — и почему это почти всегда плохо заканчивается.

Software 3.0: что теперь считать мощностью? Посмотрел видео Андрея Карпатого про Software 3.0 и поймал себя на мысли, что мы в очередной раз меняем представление о том, что такое «мощность» в ИТ. Когда-то мощность — это был CPU. Я тогда сам был разработчиком и отлично помню, как мы бились за каждый байт и такт. Средний разработчик знал, с какой скоростью луч обновляет картинку на ЭЛТ-мониторе, потому что хорошей практикой было обновлять экран сразу после прохода луча, чтобы не было мерцания. Славное время: демосцена, трекерная музыка и симулятор Марса в 5 КБ Потом, как писал Джоэл Спольски (автор VBA в Excel, Trello и Stack Overflow) в своем Strategy Letter VI , главным ограничением постепенно стала ширина канала — bandwidth, а latency с тех пор прописалась на Grafana-дашбордах. Уже не так важно, сколько килобайт занимает программа, если сеть позволяет - загрузим все и выполним в браузере. И хотя latency всё еще актуальная метрика, похоже, парадигма в очередной раз меняется. В Software 3.0 мощность — это уже не только CPU и не только bandwidth. Софт буквально начинает создаваться из промпта, поэтому на первый план выходит способность нейросети понять намерение, удержать контекст, вызвать нужные инструменты и безопасно выполнить действие. Мы пока еще не совсем в Software 3.0, но движемся в эту сторону. На днях обсуждали с коллегой: он одним промптом попросил Claude Code собрать базу потенциальных клиентов, подготовить индивидуальные письма и выстроить цепочку действий вплоть до отправки. Раньше это была бы возня на несколько дней: crawler + parser, анализатор, генератор текста, отправщик почты. Казалось бы - ну ок, меняется и меняется, что тут такого. Но в голову пришла мысль, что это полностью изменит подход к автоматизации и цифровизации в компаниях. Если раньше разработка софта была делом разработчиков, то теперь софт потенциально начнут делать все: кладовщик, бухгалтер, логист, закупщик, HR. Не в смысле, что они начнут писать классы или освоят промисы и слайсы, а в смысле, что смогут попросить AI-агента: «сделай мне отчет», «проверь эти заявки», «собери экран для проблемных поставок», «автоматизируй это правило». Фактически по масштабам автоматизации это новый Excel. Только если раньше Excel-макросы были локальным shadow IT и большинством CIO воспринимались, как неизбежное зло, то теперь уже сам CIO/CTO может стать тормозом в автоматизации собственной компании, если будет блокировать этот процес. И отсюда еще одна мысль: роль CIO/CTO будущего меняется — от центра разработки к центру координации безопасной автоматизации в компании своими силами. Потому что чем проще становится создавать софт, тем важнее становятся архитектура, права доступа, данные, аудит, sandbox, API, rollback и правила игры. Компиляторы, линтеры и IDE никуда не исчезнут, по крайней мере первое время. Но они только-только научились проверять код, а теперь нужно совсем другое - научиться проверять намерение, контекст и право на действие агента или сотрудника Поэтому SAP, 1С, ERP, WMS и другие корпоративные монстры, скорее всего, останутся на горизонте ближайших 5 лет, а может и больше. Но рядом с ними поселятся эти самые Software 3.0-агенты и будут делать локальные автоматизации поверх этих систем. То есть CTO будущего — это уже не только главный по разработчикам и инфраструктуре, а скорее роль, которая отвечает за то, как компания программирует саму себя Как вам такая мысль?

Технический долг проявляется не только в коде. По мере роста системы меняется сама природа изменений: становится больше зависимостей между командами, выше цена архитектурных решений и заметнее влияние инженерных практик на скорость разработки. В этом посте анонс докладов и мастер-классов из программы Saint TeamLead Conf 2026, которые по-разному помогают снижать стоимость и риски изменений — через TDD, выявление архитектурных рисков до production и выстраивание взаимодействия платформенных и продуктовых команд без лишних узких мест. 🔴Платформенная команда — это ускоритель или узкое место? Александр Апазиди (Независимый эксперт, ментор CTO (Apazidi IT)). Доклад и мастер-класс На докладе участники разберут типовые анти-паттерны платформенных команд и критерии, по которым можно оценить их эффективность. А на мастер-классе построят карту взаимодействия платформы с командами и определят точки роста. 🔴Никита Чурсин (Ozon Банк) Доклад «Что такое TDD — мифы и реальность». Вокруг практики разработки через тестирование (TDD) ходит множество мифов. Кто-то говорит, что это работает только в идеальном мире, где требования кристально понятны. Кто-то утверждает, что TDD — значит написать все тесты до кода, что практически невозможно. Кто-то же наоборот утверждает, что TDD гарантирует отсутствие багов и чистый дизайн. И это все неправда. Если все, что вы знаете о TDD, это что-то из описанного выше — приходите, будем вместе разбираться, где же собака зарыта. Воркшоп «Разработка без страха — через тестирование». Ситуация, когда мы боимся вносить изменения в свой код, нередка. Даже тесты зачастую не помогают справиться с этим ощущением, потому что мы им просто не доверяем. На воркшопе участники разберутся, что такое TDD, как писать тесты так, чтобы им можно было верить и как рефакторить без страха. 🔴Мастер-класс «Архитектурная ката». Владимир Невзоров (Servicepipe). Архитектурная ката выглядит как практико-ориентированный формат для тренировки системного мышления и проектирования в условиях ограниченного времени. Ценность мастер-класса — в фокусе на high-level design, выявлении рисков и обмене опытом между специалистами разных профилей в командной работе Приходите на эти доклады и мастер-классы на конференции, чтобы разобраться, как сохранять управляемость системы и предсказуемость изменений по мере роста сложности 🙌

Совет директоров от сооснователей Стратоплана - 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, и что с этим можно сделать без магического "давайте просто наймём ещё людей". И чтобы это был не просто пост-анонс, еще две просьбы: Если вы руководитель платформенной команды и хотите рассказать про свою боль, опыт или мнение по этой теме -- давайте созвонимся (напишите в личку или сразу запланируйте звонок). У меня уже есть несколько кейсов на которых будет построен доклад, но добавить новые будет всегда полезно А если вы руководитель платформенной команды, умеете фасилитировать группы, готовы приехать в Питер и хотите быть со мной со-ведущим воркшопа -- тоже пишите. Ожидаем до 100 человек, так что помощники точно будут нужны.

Было/стало : 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. Если кто вдруг есть в канальчике из Amazon или из компаний, где предпочитают 6 pager и подобные форматы - расскажите, как оно на самом деле?

Попробуй "extra thinking" Я ежедневно и помногу использую почти все доступные нейросети (ChatGPT, Claude, Gemini, в дополнение к ним еще и Perplexity для поиска) и поймал себя на неожиданной мысли: почти везде включаю thinking, а все чаще -- даже extra thinking.…

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

Нет, вы посмотрите на этого еретика, о чём он вообще? Признайте: ИИ с лёгкостью уделает вас в кодинге. Нет такой задачи, на которую у вас ушёл бы день, а ИИ не сделал бы её за пять минут. Всё кончено. Код будете писать не вы. Да-да, я знаю. Смиритесь. Но вот в чём штука - это даёт вам огромную силу, потому что теперь можно делать то, о чём раньше и мечтать не приходилось. Например, подумайте о покрытии тестами: вы же помните, какая это была морока. Надо писать все эти чёртовы тесты, и вы знаете, что тесты на самом деле не доказывают, что код работает. Запускаешь code coverage, ухмыляешься и говоришь: ну да, ладно, но это же не значит, что код работает. Это значит только, что он исполняется. Так вот, теперь это можно исправить, у вас появились ресурсы, чтобы это сделать. Говорите ИИ: покрой этот чёртов код тестами. А потом берёте mutation tester (да, это такой инструмент - и пусть ИИ его вам и напишет, уйдёт минут пять), дальше ИИ запускает этот инструмент, тот вносит изменения в исходный код и прогоняет все тесты. И если тесты не падают - он допишет тест, который поймает эту мутацию, и это значит, что у вас будет покрытие тестами. Ей-богу, у вас будет покрытие тестами. И знаете, что ещё можно? Можно анализировать качество кода. Можно написать инструмент, который смотрит на цикломатическую сложность. Кстати, есть отличный инструмент для этого. Ему лет двадцать. Называется CRAP - хорошее название, как расшифровывается - не знаю и знать не хочу. Это комбинация покрытия тестами и цикломатической сложности. И вы можете сказать ИИ: понизь метрику CRAP - ниже пяти, ниже четырёх, как хочешь. И это заставит его порезать все жирные функции на маленькие и покрыть их все тестами. Ей-богу - подумайте, какие у вас теперь рычаги, чтобы довести код до качества, какого вы никогда не видели. Знаю-знаю, я тот самый старый дед с Clean Code, но вот что я вам скажу: теперь вы можете сделать код чертовски чище, если заставите ИИ сделать это за вас. Да что этот дед может знать про разработку? Хотя погодите... Да это же Роберт Мартин - "Чистый код", "Чистая архитектура", "Идеальный программист", "Быстрая разработка программ"! За последний год от умеренного скептика он окончательно перешёл в стан апологетов использования ИИ в разработке, а теперь вот сидит у себя на веранде в халате по утрам и жжот глаголом :) Да что с него взять - дед наверное просто на старости лет выжил из ума, раз такое предлагает! Нуу, а что насчёт всех вот этих людей? За 52 года программирования оно никогда не приносило столько удовольствия ⬈ 90% моих навыков теперь стоят $0 …но остальные 10% стоят в 1000 раз больше Kent Beck (XP, TDD) Появление LLM меняет разработку настолько же радикально, как переход от ассемблера к языкам высокого уровня ⬈ Меняется само понятие того, что значит "программировать" ⬈ Martin Fowler (Refactoring, PoEAA) ИИ выведет на чистую воду тех, кто никогда не умел думать как инженер ⬈ Верификация становится узким местом. Кодогенерация сама по себе дешевая ⬈ Dave Farley (Continuous Delivery) Это третий золотой век разработки софта - благодаря ИИ ⬈ Меня это не пугает. Меня это радует. Меня это освобождает ⬈ Grady Booch (UML, OOAD) Писать код руками - это как проявлять фотоплёнку в тёмной комнате. Никто так больше не делает ⬈ Тебе больше не нужны шесть разработчиков плюс UX плюс продукт. Тебе нужен человек с проблемой и разработчик, который её решит ⬈ Gene Kim (Phoenix Project, DevOps Handbook) — Это ж всё сплошь архитектурные астронавты - что они могут знать про реальную разработку: как мы перекладываем JSON'ы, про наши CRUDогенераторы, и про то, насколько важно использовать табы вместо пробелов? Ну да, ну да :) А получается у них с ИИ именно потому, что для них разработка всегда была не про написание кода. Идеи этих дедов стали актуальны как никогда. Кстати, довольно интересно отслеживать эволюцию их взглядов, а с дядей Бобом ещё и спорить иногда случается :) #rant #дедпримитаблетки

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

20-23 апреля у Стратоплана пройдет конференция «Управление 2026» - 4 дня про то, как меняется управление у руководителей и директоров. Я буду выступать в директорской секции с докладом: "AI ускорил код. Почему компания все равно тормозит" Тема для меня любимая:…

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? Или что-то еще?

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