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

Анонс - бесплатный курс «Менеджмент 360» 1-4 сентября по вечерам

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

1 сентября -- тимлид. Переход из технической роли в управление людьми, базовый инструментарий, первые 90 дней и типовые факапы.
2 сентября -- руководитель отдела. Управление уже не одной командой, а несколькими командами и их руководителями, каскадирование целей, структура и оркестрация работы.
3 сентября -- CTO. Переход от инженерного управления к бизнес-партнерству, работа с бюджетом, советом директоров, аудитом систем и кризисами.
4 сентября -- COO. Стык стратегии и исполнения, экономика решений, цепочка ценности и работа всей операционной системы компании.

Я сам буду выступать 3 и 4 сентября в дни CTO и COO: расскажу про инструментарий COO и пообсуждаем про типовые проблемы и факапы в ролях CTO/COO с коллегами

Эфиры будут с 18:00 до 21:00 GMT+3, как типовые уроки в Стратоплане

Участие бесплатное, нужна регистрация в нескольких полезных телеграм каналах (я на них кстати и так уже подписан)
👉 https://stratoplan-school.com/360

Бизнес vs IT. Часть 2

В первой части писал, что деление на «бизнес» и IT -- во многом наследие времен, когда IT было вспомогательной функцией.

Но в 1990-х–2000-х эту границу не просто унаследовали — ее вполне сознательно строили: например менеджмент-гуру тех лет Tom Peters в книжке The Professional Service Firm 50 предлагал внутренним функциям вести себя как профессиональные сервисные компании.

То есть не "бухгалтерия", а "компания представляющая услуги учета". И не IT-отдел, а поставщик IT services.

Отсюда же модели вроде: Demand / Governance / Supply, где Demand формирует спрос, IT поставляет, Governance следит за стандартами и общими процессами

На бумаге всё выглядит очень разумно, но внутри большой корпорации есть одна проблема: это не настоящий рынок.

Demand обычно распоряжается не своими деньгами, а корпоративным бюджетом. Даже если бюджет формально сидит у руководителя функции, это всё равно деньги компании, а не деньги, которые он лично заработал и рискует потерять. А раз так, тогда включается режим "безлимитной карточки" : "давайте еще попробуем", "вот еще список доработок", "эффект сложно посчитать, но он точно будет"

Supply при этом тоже ведет себя рационально: есть запрос, есть бюджет — значит, надо делать.

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

Я сам успел пожить внутри почти эталонной реализации этой модели: в Volvo Trucks Russia я был CIO и отвечал за IT Demand, а IT Supply находился в отдельном глобальном подразделении Volvo IT.
И именно там меня впервые начало сильно раздражать само деление на «бизнес» и IT: я формально Volvo Trucks, а коллеги -- Volvo IT. Но деньги мы все получаем от продажи одних и тех же грузовиков. Зачем тогда вести себя так, будто мы две разные компании?

При этом сама сервисная модель может быть вполне успешной: например для Run она работает вполне нормально: техника, системы и инфраструктура уже существуют, обслуживать их всё равно надо. Основной вопрос -- можешь ли ты объяснить, почему сервис стоит именно столько.

А вот с Change всё сложнее: тут нужно обосновать сам факт необходимости изменений: зачем вообще сейчас тратить эти деньги и какой будущий эффект мы получим?

С этим традиционно сложнее -- и было 20 лет и сегодня, и в больших и средних компаниях (в маленьких все ок, так как дистанция до клиента, который платит зарплату минимальна)

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


А завтра будет пост о том, почему самому IT отделять себя от бизнеса зачастую еще удобнее.

Продолжаем делиться тем, что особенно высоко оценили участники Saint TeamLead Conf 2026 🌟

В первой части мы рассказали вам о докладах, теперь — о недокладных форматах, которые получили самые высокие оценки аудитории по содержанию и подаче.

1️⃣ Воркшоп «Платформенная команда — это ускоритель или узкое место?». Александр Апазиди (Независимый эксперт, ментор CTO Apazidi IT), Елена Большакова (Яндекс), Илья Прахт (Стратоплан, Thrive Technologies), Марина Орешина (Wildberries & Russ (RWB)), Никита Шевченко (DeltaClick (D Innovate Group)), Андрей Трапезин (BIOCAD), Антон Сарычев (Сибур Цифровой)

2️⃣ Архитектурная ката. Владимир Невзоров (Servicepipe)
3️⃣ Воркшоп «Настрой тело как инструмент перед важными встречами». Елена Балашова (Яндекс), Анастасия Фомина (Актриса театра и кино)
4️⃣ Мастер-класс «Черная риторика: распознать, понять, противостоять». Светлана Болсуновская (YADRO)

5️⃣ строчку разделили сразу два формата:
Открытая запись подкаста «Три тимлида заходят в бар». Политические игры в корпорациях и что стоит знать про это тимлиду. Виктор Корейша (Ozon), Анастасия Абрашитова (Yandex Infrastructure), Евгений Антонов (Yandex Infrastructure)

Круглый стол «Приведет ли внедрение AI-инструментов к сокращению ФОТ?». Евгений Дубовик (Синимекс), Иван Поддубный (Вебпрактик), Алик Курдюков (UnitedTraders), Даниил Подольский (YADRO)

Следующая TeamLead Conf 2026 пройдёт 3 и 4 декабря в Москве. Если хотите стать спикером — заявку на выступление ещё можно подать до 16 августа ✅

Выкладываю материалы семинара «Оргдизайн в эпоху ИИ»

Раньше анализ реального устройства организации был отдельным проектом: интервью, выгрузки из систем, process mining, работа аналитиков и консультантов. Это занимало недели, стоило дорого — и поэтому до такого анализа доходили немногие.

Сегодня первый цикл можно пройти за несколько часов.

На семинаре я показывал, как с помощью цепочки промптов и нескольких наборов данных:

— восстановить реальный поток работы, а не оргчарт;
— найти очереди, ожидания и скрытые точки принятия решений;
— отделить симптомы от возможных ограничений системы;
— дополнить анализ матрицей компетенций и картой прав решений;
— проверить несколько вариантов оргдизайна до начала реорганизации.

В итоге : за полтора часа прошли путь от базового Excel до гипотезы с ускорением до 30-50%, плюс провели симуляцию и базово оценили риски

Выкладываю:

🎥 видео семинара
📊 презентацию
📁 исходные данные и цепочку промптов

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

Скидка и промокод на курсы Яндекс.Практикум

В бэклоге накопилось штук 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 и подобные форматы - расскажите, как оно на самом деле?

Подумай долго и тщательно, продолжение

На одной встрече коллега заметил, что добавка "подумай долго и тщательно" отлично работает не только с ИИ, но и с людьми.

Попробовал пару раз -- действительно качество ответа заметно возрастает :-)

А чтоб думать "долго и качественно" с ИИ перешел таки (после долгих сомнений) на 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 — открыть и изучить.

Нет, вы посмотрите на этого еретика, о чём он вообще?

Признайте: ИИ с лёгкостью уделает вас в кодинге. Нет такой задачи, на которую у вас ушёл бы день, а ИИ не сделал бы её за пять минут.
Всё кончено. Код будете писать не вы. Да-да, я знаю. Смиритесь.

Но вот в чём штука - это даёт вам огромную силу, потому что теперь можно делать то, о чём раньше и мечтать не приходилось.

Например, подумайте о покрытии тестами: вы же помните, какая это была морока. Надо писать все эти чёртовы тесты, и вы знаете, что тесты на самом деле не доказывают, что код работает.
Запускаешь 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, это как ни странно не про технологии, и не про то как управлять айтишниками.

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