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

Анонс: управленческий онлайн 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 и подобные форматы - расскажите, как оно на самом деле?

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

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