Управление проектами *

Чёрный лебедь в дата-центре и реестры рисков

Недавно я писал о пожаре в американском дата-центре Lake Mariner. Там всё оказалось весьма топорно: проблемы с пожарной безопасностью и размазанная ответственность.И кончилось безобидно вроде.

А сегодня пожар произошел в дата-центре Яндекса в Сасово. Причина совсем другая — атака беспилотников. Площадка остановлена, проблемы возникли у сторонних сервисов (ну вы наверняка ощутили).

Перед нами почти классический "чёрный лебедь". Ещё несколько лет назад вероятность поражения ЦОД беспилотником вряд ли всерьёз рассматривалась в большинстве проектов. Однако важно различать причину форсмажора и её последствия. Потому что предсказать конкретную угрозу сложно, а вот сценарий полной потери ДЦ — вполне стандартная задача. 

Вот вы сегодня работаете руководителем проекта или аналитиком. Проектируете систему, согласовываете требования, организуете разработку, внедряете. А завтра дата-центр, на котором всё работает, — фьюить! И результаты нескольких месяцев работы недоступны. Разумеется, вы не можете предотвратить пожар или вражескую атаку. Но можете ещё на этапе проектирования задать несколько вопросов - как минимум себе.

Что произойдет, если завтра исчезнет вся площадка? 

Сколько времени бизнес готов прожить без системы? 

Сколько данных допустимо потерять? 

Есть ли резервный сценарий? 

Кто и как будет восстанавливать работу? 

И ответы (если их получите...) превратить в конкретные нефункциональные требования: восстановление за четыре часа (RTO), потеря не более 15 минут данных (RPO), сохранение документов при недоступности внешнего сервиса. Цифры условные)

За всё это приходится платить. И решение, сколько потратить на защиту от маловероятной катастрофы, — оно уже не техническое, а как раз управленческое. И один из "проектных" уроков этой ситуации в том, что вероятность риска — ни разу не константа. Мир меняется, иногда быстрее, чем наши реестры рисков и проектные допущения. Я, кстати, когда учился на курсах РП в Яндексе, как раз на уроке про управление рисками услышал от лекторов, что никакие реальные реестры они не продумывают, а просто копируют таблички. Но это было давно)

Ну и подборочка, где почитать подробнее — про такие вот риски и их проработку:

• Как составить план аварийного восстановления — вполне доступное объяснение RTO, RPO, анализа влияния на бизнес и планирования восстановления. С примерами.

• Проектирование отказоустойчивости ИТ-систем — о том, как учитывать отказы компонентов и внешних зависимостей при проектировании.

• ГОСТ Р ИСО 31000-2019 — общая методология управления рисками: выявление, оценка, обработка и пересмотр.

• ГОСТ Р ИСО 22301-2021 — управление непрерывностью деятельности организации, подготовка к сбоям и восстановлению.

• ГОСТ Р ИСО/МЭК 25010-2015 — модель качества программных систем, в том числе надёжность, отказоустойчивость и восстанавливаемость.

Скрытая цена ИИ-решения: что учесть при расчёте окупаемости

Часто слышу вопрос: как посчитать окупаемость ИИ-решения на базе LLM?

Давайте разбираться.

Готовый расчёт окупаемости поставщик не покажет: кроме его цены, все числа в нём ваши. Как подойти к построению модели расчёта и что в ней учесть?

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

1. Запишите недопустимое. Заранее определите для процесса, какие последствия ошибки компания не примет ни за какую экономию. Список утверждает владелец процесса. От инструмента он не зависит: он одинаков для любого ИИ и для человека.

2. Найдите место проверки и замерьте её цену. Где такую ошибку можно поймать до того, как её последствия станут необратимыми? Проверка должна быть независимой от ИИ и опираться на внешние факты, а не на его выводы. Сколько стоит такая проверка на один случай, замерьте на выборке: в ваших системах этого числа, скорее всего, нет. Часто проверка съедает ровно то время, которое обещал поставщик.

3. Если поймать ошибку нечем, меняйте распределение операций между исполнителями — человеком, ИИ и программным кодом. Цель — чтобы критичный факт приходил к ИИ уже подтверждённым. Если и это невозможно, откажитесь от ИИ.

4. Заложите затраты на сохранение навыков у проверяющих. Человек, который каждый день видит подсказки ИИ, со временем проверяет хуже. Навык приходится поддерживать намеренно, и это время людей. Без этого качество проверки со временем деградируют.

5. Считайте затраты и эффект целиком. Затраты — это не только цена поставщика. Это ещё время людей на проверку и исправления, потери от пропущенных ошибок, интеграция и обучение, а также цена сохранить возможность вернуться к работе без ИИ. Эффект — не только экономия на текущей работе, но и новые результаты, до которых раньше не дотягивались.

Окупается решение, которое приносит больше, чем стоит проверка работы ИИ.

Полные реальные доходности с 1870 г. ..- недвижимость, а не акции

В одном из исследований NBER были определены полные реальные доходности с 1870 по 2015 год по основным классам активов для 16 стран с развитой экономикой (гос. облигации и краткосрочные векселя, акции и недвижимость).

Интересный вывод, который противоречит многим другим исследованиям, в очень долгосрочной перспективе именно жилье, а не акции, обеспечивает лучшую доходность. Оба типа активов приносили в среднем около 7% в год за 145 лет, при более высокой волатильности доходности акций (доходность от аренды недвижимости составляла около 50% общей долгосрочной доходности жилья).​

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

Когда «надо управлять» уже недостаточно: 4 задачи, которые требуют системы

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

И здесь опыта и интуиции уже мало. Нужна система: понимать, где искать точку влияния, на какие данные опираться, что автоматизировать и как оценивать результат.

Собрали бесплатные открытые уроки для тех, кто управляет продуктами, процессами, командами и технологическими направлениями.

1. Запускать продукты и оценивать их результат

• 8 октября, 20:00. «Как запустить ИИ‑продукт: от бизнес‑гипотезы до первых измеримых результатов». Записаться

• 12 октября, 20:00. «Сколько стоит один ответ вашего AI‑агента — и почему он думал 40 секунд?». Записаться

• 21 октября, 20:00. «Как посчитать ценность ИИ: метрики и ROI, которые нужны менеджеру». Записаться

2. Выстраивать процессы и автоматизировать работу

• 12 октября, 20:00. «Промпты без случайного результата: как проектировать устойчивые сценарии работы с LLM». Записаться

• 14 октября, 20:00. «ИИ‑агент как супероружие системного аналитика: составляем ТЗ за 10 минут». Записаться

• 19 октября, 20:00. «Как наладить процессы без вложений: никаких бюджетов, систем и выделенных команд». Записаться

3. Принимать решения на основе данных, целей и рисков

• 13 октября, 20:00. «Технологии и принципы построения DQaaS (Data Quality as a Service) в современных системах управления данными». Записаться

• 14 октября, 20:00. «Математика на службе у CISO: как принимать решения на основе данных». Записаться

• 15 октября, 20:00. «Цели и метрики как одно целое». Записаться

• 15 октября, 20:00. «ИИ в управлении рисками: предиктивная аналитика для тестировщика». Записаться

4. Управлять ролью, командой и взаимодействием

• 19 октября, 19:00. «CIO в эпоху ИИ». Записаться

• 19 октября, 20:00. «Как понять, что вы уже выполняете роль COO — даже если должность называется иначе». Записаться

• 20 октября, 19:00. «Стабильность команды и взаимозаменяемость людей». Записаться

• 21 октября, 20:00. «Анатомия сопротивления: превращаем токсичных стейкхолдеров в союзников проекта». Записаться

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

📖 Что почитать по теме управления

Если хочется разобрать управленческие ситуации подробнее — читайте наши недавние статьи про команды, архитектуру и влияние ИИ на работу специалистов:

• «Когда сотрудник тормозит команду: как говорить с ним прямо, но без давления» 
  _{о сложных разговорах, обратной связи и том, как разбирать проблемы в работе без лишнего давления.}

• «10 типовых ошибок при внедрении управления корпоративной архитектурой (Enterprise Architecture) и как их исправить» 
  _{о системных ошибках при внедрении Enterprise Architecture и способах их избежать.}

• «Кто платит за ИИ‑продуктивность: почему выгорают middle‑инженеры»
  _{о скрытой нагрузке, которую AI‑инструменты могут создавать внутри команды, и о том, что важно учитывать руководителю.}

Анонсировано приложение, которое помогает убрать под ковёр ненужный хлам на рабочем столе. Разработчик пообещал доделать проект и выпустить решение для всех желающих.

«Восход» стал «Логарифмикой»: мы открыли доступ к рабочей среде поверх ОС

В предыдущей статье я рассказывал, почему мы взялись переосмысливать рабочий стол и собирать материалы вокруг проектов, а не приложений. Теперь продукт можно скачать: 5 октября мы запустили открытую бета-версию.

За время подготовки к запуску сменилось название. «Восход» было рабочим названием. Теперь наш продукт называется так же, как и компания — «Логарифмика».

Коротко напомню идею. Документы, веб-сервисы и переписка одного проекта обычно находятся в разных местах. В Логарифмике для каждого проекта создаётся отдельный контекст: вы собираете нужные материалы на холсте, располагаете их как удобно и возвращаетесь к сохранённому рабочему пространству после переключения на другие дела.

Приложение работает поверх существующей ОС. Сейчас доступны версии для Windows 10/11 и macOS Sonoma и новее. Linux-версия — в планах на 2027 год.

Это первая публичная версия: ещё доступны не все заявленные возможности, и нам предстоит многое доработать. До начала 2027 года Логарифмика будет бесплатной.

Главный вопрос из предыдущей статьи остаётся: оправдывает ли дополнительный слой интерфейса время на его освоение? Теперь это можно проверить на собственной работе.

Если решите попробовать, я советую начинать с какого-то небольшого нового проекта или дела, которое хочется обособить от остального. 

Соберите его материалы, поработайте, переключитесь на другое дело, а затем вернитесь. Стало ли проще продолжить? Что пришлось искать заново? Где сама Логарифмика мешала?

Скачать: logarithmica.ru

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

Буду рад конкретным сценариям и замечаниям в комментариях — особенно тому, что оказалось неудобным или непонятным.

А мы, со своей стороны, будем рассказывать о том, что нового мы добавили или исправили. 

Стиль управления

Я работал в стартапах с разным стилем управления и создания продуктов.

С обязательными отчётами и без них.
С таск-трекерами и без них.
С обязательным офисом и полной удалёнкой.
С длинным планированием и решениями по ходу.

Часто процессы складываются под представление руководителя о том, как должна выглядеть нормальная работа. Кто-то считает естественным офис, отчеты и постоянные синхронизации. Кто-то принципиально выбирает удалёнку, свободный график и асинхронное общение. Микросервисы могут казаться правильным решением даже на этапе MVP, а монолит — единственным способом двигаться быстро. Эти убеждения подпитаны прошлыми проектами, удачными кейсами и историями успеха тех, за кем они наблюдали. Каждый искренне считает свой формат нормой и может привести десятки причин, почему именно его подход правильный. Поэтому изменить эти представления почти невозможно.

Но ни один стиль управления и создания продукта не определяет, выживет проект или нет.

🥺 Тем, кто хотел быть оркестратором ИИ-агентов, посвящается!

Мы же тут начали находить себе место в прекрасном будущем? Дескать, хорошо, ИИ будет выполнять работу, а мы, конечно, руководить, ставить задачи, распределять, проверять результаты. Кто-то же должен спрашивать у агентов: "Коллеги (с), а почему это до сих пор не готово?"

И вот некий Итан Моллик пишет, что это ошибочное предположение.
https://www.oneusefulthing.org/p/the-dot-and-the-swarm
Последний год он тоже предполагал, что мы будем управлять командами AI-агентов примерно так же, как управляем людьми. Назначим аналитика, исполнителя, проверяющего, над ними поставим менеджера, определим правила, кто кому передает результат и в каких случаях несёт вопрос наверх. В общем, всё знакомое. Можно даже должностные инструкции почти не переписывать.

Однако Моллика впечатлил эксперимент OpenAI, в котором тысячи агентов работали над математической задачей,обменивались миллионами сообщений, подхватывали идеи друг друга, развивали перспективные направления. Люди задали направление и немного поправляли ход работы.

Попробуйте представить такое с людьми. Уже на этапе "тысячи участников" вижу, что всё глохнет на совещании по согласованию состава рабочей группы. А агенты, похоже, как-то разобрались.
Вот и возникает занятный вопрос: сколько управленческой работы существует потому, что сама задача сложная, а сколько — потому, что её выполняем мы?

Нам, людям, важно, кто получит признание. Мы не всегда охотно делимся информацией. Бывает, защищаем свой “участок”, даже когда это мешает общему делу. Да и просто не можем одновременно следить за работой тысячи коллег. А у агентов всё это может быть устроено иначе. И тогда наша привычная организация (с отделами, начальниками и согласованиями) им особо не пригодится.

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

Но для тех, кто занимается проектами и автоматизацией, вопрос уже вполне практический: “А не собираем ли мы сложный процесс там, где скоро будет достаточно поручить задачу целиком?” Сначала шаг А, потом Б, затем согласование, потом проверка. Мы долго выясняли порядок действий, аккуратно и с муками его описали в куче инструкций, автоматизировали. А через какое-то время агенту можно будет просто сказать, какой результат нужен, и дать доступ к необходимым данным.
Вы скажете: "Ну уж управлять-то всё равно придётся человеку". Вполне возможно. Только придется заново разбираться, в чём именно состоит эта работа.

Сейчас все говорят о внедрении ИИ. Внедрение инструментов ИИ становится мемом - "Зачем надо? Мы не знаем. Когда надо? Сейчас."

Редко, когда можно услышать четко сформулированные причины и ГЛАВНОЕ - целевое состояние после реализации инструментов ИИ.

Среди коллег и клиентов, я не так часто слышу, но все же слышу такую фразу, что-то подобное - «Наш отдел/блок/компания тратит слишком много времени на рутину, нужно внедрять ИИ», либо «ИИ модно/это будущее, если мы не реализуем, то реализуют другие, а мы опоздаем, потеряем, упустим…»

Если вы сталкивались с таким, а вы с таким сталкивались... то какие ОСНОВНЫЕ вопросы вы зададите, чтобы ПОНЯТЬ нужно ли, а если нужно, то можно ли, а если можно – то, что и как будет реализовано?

Задавайте вопросы, они помогают людям думать.

Я для себя сформулировал и стараюсь задавать следующие. Пользуйтесь:

1. Какие именно процессы вы считаете рутинными? Чтобы понять, где проблема.

2. Сколько времени сотрудники тратят на эти процессы? Чтобы оценить масштаб.

3. Какие данные и системы используются в этих процессах и какие будут? Чтобы понять, есть ли база для автоматизации и какие будут созданы новые зависимости и риски.

4. Являются ли указанные вами процессы точными, надежными, обеспечивают ли процессы качество данных? Чтобы понять возможность, применимость и последствия реализации ИИ инструментов.

5. Как внедрение инструментов ИИ повлияет на компанию, вовлеченных и ускоренных сотрудников, в долгосрочной перспективе? Чтобы понять, что произойдет с опытом и знаниями, обучением, развитием и сохранением преемственности знаний и опыта сотрудниками и компанией после внедрения инструментов ИИ.

6. Кто будет владельцем процесса и результата после внедрения? Чтобы понять кто будет нести ответственность за работу, и кто будет отвечать за результат.

7. Готовы ли люди, которых затронет изменение, работать по-новому? Чтобы понять, приживется ли решение.

ИИ является инструментом. Но инструмент без цели превращается в хайп и мемы. В хайп, в какой-то мере, способный нести риски для бизнеса. Как в части базовой информационной безопасности, так и долгосрочных перспектив ведения бизнеса.

Задавайте правильные вопросы до того, как начнёте. Какой бы вы вопрос задали, в дополнение к моим?

Можно ли получить от агента надёжный результат, не спроектировав для него работу? Судя по тому, как мы с агентами работаем, многие на это рассчитывают.

Мы научились писать агентам промпты и учимся принимать у них результат. А проектировать для них работу так и не начали. Поэтому ошибки повторяются от эксперимента к эксперименту и не исчезают ни с новой моделью, ни с более длинной инструкцией. Ниже — почему так происходит и три принципа, которые можно взять на вооружение, когда проектируете работу для агента.

Когда появились компьютеры, работу для них не стали описывать так же, как для служащих. Машина не понимает замысла, поэтому появились алгоритмы: работу пришлось описывать так, как её способен исполнить новый исполнитель.

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

Агент — третий тип исполнителя. Он интерпретирует ситуацию, как человек, но без норм, опыта и последствий, которые человек приносит с собой.

Поэтому ни один из подходов проектирования не подходит для агента. Подробнее почему — в статье «Почему AI-агент не цифровой сотрудник».

Посмотрите, как в статьях об агентах разбирают их ошибки. Агент выдал неприемлемый результат, и дальше обсуждается, как такую ошибку поймать и кто за неё отвечает. Вопрос, можно ли было устроить работу так, чтобы этой ошибки не было, почти не возникает.

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

• Проектируйте от работы, а не от агента. Сначала определите, какую ошибку вы не готовы принять и после какого действия её уже не исправить. Только потом решайте, что поручить агенту.

• Решите, что агенту не нужно интерпретировать. Всё, что можно установить независимо, передайте ему уже подтверждённым. Интерпретацию оставьте там, где ради неё агент и нужен.

• Определите, как примете результат, до запуска и отдельно от агента. Когда критерии приёмки известны заранее, работа для агента проектируется точнее, а результат принимать проще.

Почему, на ваш взгляд, работу для агентов почти не проектируют: не знают как, не видят смысла или ждут, что следующая модель справится сама?

Каждый руководитель сталкивался с этим: команда генерирует десятки идей, но до релиза доходят единицы, а прибыль продукта не растёт. Причина — разорванное мышление. Решение — на метауровне.

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

Содержание
✔️ Креативная разминка.
✔️ Презентация метанавыков и школ.
✔️ Кейс. ИИ-решение персонализации рассылок показало интересные результаты при запуске, но потом отпугнуло пользователей. Как быть?
✔️ Разберём эту ситуацию через три линзы — три школы метанавыков:
— Креативное мышление поможет переформулировать задачу.
— Системное мышление создаст структуру.
— Продуктовое мышление разложит идею на компоненты по ценности и риску.
✔️ Подведём итоги, ответим на вопросы.

📆 Когда: 5 октября в 17:00 (Мск)
👨‍🎓 ️Спикер: Гафитулин Тимур, эксперт по техникам мышления

✍️ Записаться

Как я использую ИИ в работе и что ему пока не доверяю.

Чем больше я работаю с ИИ, тем меньше воспринимаю его просто как «инструмент для написания текстов и анализа информации».

Для меня он уже скорее дополнительный участник рабочего процесса. Но участник, которому я очень чётко определяю границы.

Что я уже регулярно отдаю ИИ?

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

Например:

— собрать и структурировать информацию;

— сделать первичный анализ;

— подготовить summary встречи;

— разобрать backlog и предложить варианты приоритетов;

— найти несоответствия или потенциальные проблемы;

— подготовить вопросы к встрече или требованиям;

— сформулировать несколько вариантов решения;

— сделать черновик документа или плана.

Особенно ценю не столько сам готовый результат, сколько возможность быстро пройти первый слой работы и дальше уже заниматься тем, где действительно нужен мой опыт.

Что он пока не может заменить?

ИИ может посмотреть на backlog и предложить логичный порядок задач. Но он может не знать, что у нас есть договорённость с бизнесом, важный клиент или обязательный релиз, который полностью меняет картину.

Он может увидеть, что команда стала медленнее, и предложить пять возможных причин.Но он не проживает эту ситуацию вместе с командой и не знает всех нюансов, которые иногда невозможно выразить в цифрах.

И я точно не отдаю ему на откуп ответственность за финальное решение.

Поэтому я могу использовать его анализ, спорить с ним, просить предложить альтернативы.

А что я принципиально не готова отдавать ИИ?

Всё, где цена ошибки - человек, деньги, безопасность или серьёзные последствия для бизнеса.

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

Тезис «AI нельзя доверять» слишком однобоко звучит. 

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

Там, где результат легко проверить и ошибка обратима, можно давать системе больше свободы. Там, где решение влияет на деньги, безопасность, людей, клиентов или обязательства компании, нужен осознанный человеческий контроль.

17 бесплатных вебинаров для аналитиков: ИИ, требования, бизнес-процессы и микросервисы

Привет, Хабр. Хороший анализ начинается не с документа и не с диаграммы. Сначала нужно понять, какую задачу решает бизнес, затем — разобраться с требованиями, договориться со стейкхолдерами, описать процессы и превратить всё это в понятное техническое решение.

Чем сложнее становятся продукты и системы, тем важнее для аналитика видеть картину целиком: от бизнес-целей и клиентского опыта до требований, бизнес-логики, данных и архитектуры. А ещё — уметь работать с изменениями и использовать ИИ там, где он действительно помогает ускорить рутинную работу.

В этом посте собрали 17 открытых вебинаров для тех, кто хочет развивать навыки системного и бизнес-анализа.

Системный анализ и требования

• 28 сентября в 20:00. «Валидация требований с ИИ в техническом проекте».

• 29 сентября в 20:00. «Зелёные тесты, неверный продукт: как системному аналитику принимать работу ИИ-агента».

• 14 октября в 20:00. «ИИ-агент как супероружие Системного Аналитика: составляем ТЗ за 10 минут».

• 22 октября в 20:00. «Управление изменениями требований».

Бизнес-анализ и управление процессами

• 5 октября в 20:00. «Как связать стратегические цели компании с KPI команд».

• 6 октября в 20:00. «Как найти точки роста и улучшить бизнес-процесс: от диагностики до новой модели».

• 15 октября в 20:00. «Цели и метрики как одно целое».

• 19 октября в 20:00. «Как наладить процессы без вложений: никаких бюджетов, систем и выделенных команд».

Стейкхолдеры, клиент и продукт

• 5 октября в 20:00. «Как AI помогает продакту быстрее проверять гипотезы».

• 8 октября в 20:00. «Как запустить ИИ-продукт: от бизнес-гипотезы до первых измеримых результатов».

• 21 октября в 20:00. «Анатомия сопротивления: превращаем токсичных стейкхолдеров в союзников проекта».

• 22 октября в 20:00. «Любовь с первого касания: как CJM помогает строить отношения с клиентом».

Архитектура, бизнес-логика и интеграции

• 6 октября в 20:00. «Практические подходы к переходу от монолита на микросервисы».

• 20 октября в 20:00. «Tool Calling и MCP: интеграция ИИ-агентов с корпоративными системами».

• 21 октября в 20:00. «Основы проектирования бизнес-логики в микросервисной архитектуре».

Данные и аналитика

• 30 сентября в 20:00. «Качество данных: риски и ответственность».

• 20 октября в 20:00. «Метрики качества данных и стратегия внедрения».

Полный список открытых вебинаров смотрите в календаре мероприятий.

Представлен открытый проект Claude Code Skills & Plugins — Agent Skills for Every Coding Tool - 338 готовых скиллов для ИИ, чтобы заменить команду специалистов, включая:

• Совет директоров — CEO, CTO, CFO, CMO, юрист, CISO и еще несколько видов руководителей.

• Разработчики — архитектура, фронтенд, бэкенд, DevOps, тестирование, RAG, MCP‑серверы.

• Продакты — продакт‑менеджер, UX‑ресерч, дизайн, роадмапы.

• Маркетологи — контент, SEO, реклама, оптимизация под выдачу нейронок.

• Продажи — ценообразование, сделки, партнерства, участие в тендерах.

• Финансисты — бюджет, прогнозы, DCF‑модели, анализ рынка.

• Проджекты — SCRUM‑мастер, Jira, Confluence.

• Комплаенс — GDPR, ISO 27001, SOC 2, аудит.

• Исследователи — обзор литературы, гранты, патенты, маркетинговый ресерч.

• Личный ассистент — разбор почты, недельные ревью, дипворк, созвоны с подсчётом их стоимости.

Хочу придраться к слову «план»

План. Plan. Планирование. Planning.

Часто встречаю эти слова в бизнес‑литературе, особенно в переводной.
А дальше слышу это слово у менеджеров.

Я не уверен, у меня нет управленческого опыта в англоязычной зоне.
Но у меня есть Ютуб.

И так как я умею слушать, я слышу...

Слышу, что наш человек вкладывает в слово «план» коннотации почти векового опыта советских пятилеток.

План у нас — это «чтоб на века», «чтоб стояло крепче, чем советская власть!», это наш дед строил дачу, приговаривая обоснование своего фундаментализма.

Слово план у нас тяжёлое, мы хотим «сесть и запланировать», жёстко, каскадно, достоверно, глубоко, системно, последовательно и с предварительным глубоким анализом.

Все черновые наброски на салфетке — для нас это не план, а подтирочная бумага.

Диаграмма Ганта в три экрана вышиной и шесть экранов шириной — вот это план! Явно видно, люди поработали, молодцы!

И это в современных ИТ‑компаниях с достаточно молодым менеджментом.

Тем временем в англоязычной зоне я слышу «Show me something, plan, notes, anything.»

Покрутить эту фразу на языке. Почувствуйте иное отношение.

‑-

И то же самое со словом «планирование».

У нас планирование — это нечто фундаментальное, требующее внятной подготовки, точных прогнозов и выделенного времени.
У нас само планирование — это проект.

А там это planning.

Я это слышу как «постоянное планирование».
Как процесс, а не проект.

Это у нас до сих пор считается, что стратегия — это план, что надо собраться, поднатужиться, сделать серьёзные морды и раз в году на сратегической (я не опечатался) наврать друг другу, как мы будем взаимодействовать ближайшие три года, чтоб всем доказать, что мы ещё ого‑го!

А на Западе стратегия и не была планом, даже у Ансоффа, отца‑основателя стратменеджмента. Даже у него это процесс с корректировками.

Но отечественный менеджер не может просто так отпустить опыт советских пятилеток.

‑-

Встаёт вопрос, почему мы оглядываемся на Запад?
Наша производительность ниже.
Мы решили жить в их мире с их правилами, растём на их опыте и их бизнес‑литературе.
Хорошо бы в своём нарративе понимать, что и онтология у нас разная.

В середине 19-го века акции железнодорожных компаний играли ту же роль, что и акции технологических компаний сегодня.

Статистика из книги "Двигатели, двигающие рынки: британский железнодорожный бум", описывающая поведение акций и процентных ставок 1820-1840-е годы, подтверждает опасения игроков рынка. В случае роста инфляционных ожиданий и начала роста процентных ставок, на рынках акций технологических лидеров может начаться сильная коррекция.

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

Прекрасная история про внедрение AI в Oracle. Причем формально — про технологии, а по существу про управление.

Кратко: Oracle, которая вкладывает десятки миллиардов долларов в инфраструктуру для чужого AI, еще год назад толком не понимала, как с пользой применить его у себя. Продавать будущее клиентам — это одно, а наладить собственную работу — отдельная задача.

Но чу! Весной массово внедрили ChatGPT Enterprise и Codex. С корпоративными правилами, безопасностью, все как положено. За три месяца доля пользователей достигла 80%. И разработчики действительно начали быстрее писать код. По словам CIO, в отдельных случаях то, на что раньше у команды уходило два‑три квартала, теперь получается сделать примерно за неделю.

Казалось бы, вот оно, счастье…Но тут выяснилось, что написанный код надо еще протестировать, проверить, развернуть и выпустить. И все эти процессы почему‑то не ускорились вслед за программистами. Поэтому до клиента продукт существенно быстрее пока не доезжает. Раньше перед тестированием лежала небольшие кучки кода, а теперь лежат огромные, — но зато «вы только гляньте, как быстро ее насыпали!» И вот теперь Oracle переделывает и остальные процессы под новую скорость.

Потом пришел счет за AI. Оказалось, что 80% сотрудников, активно использующих модели, — это одновременно и расходы. Причем дорогую модель вполне можно увлеченно гонять на работе за счет работодателя, и неважно, что с задачей справилась бы и дешевая. И теперь сотрудникам показывают, чем именно они пользуются и сколько это стоит. После этапа «давайте уже пользуйтесь» наступил этап «а чем это вы там так пользуетесь, аккуратно там».

И вишенка — поиск уязвимостей. Oracle получила ранний доступ к модели Anthropic Mythos Preview. За две недели та нашла больше потенциальных проблем безопасности, чем компания находила за весь предыдущий год. Тут бы и радоваться, но… примерно 60–70% находок оказались ложными срабатываниями. А разбирать их поручили людям. Теперь инженер должен проверить, действительно ли тут проблема или просто ерунда. Пришлось создавать отдельный процесс проверки «находок», чтобы разработчиков не завалило этой «помощью».

В общем, история замечательная. Код производим быстрее, подозрительные места находим быстрее, деньги расходуем тоже вполне бодро. А чтобы клиент получил результат быстрее, приходится разбираться со всем устройством работы. И в итоге ускорения пока особо и нет…

Источники: Business Insider, есть пересказ тут https://thenextweb.com/news/oracle‑internal‑ai‑rollout‑town‑hall

Модель уровня opus 5 бесплатно. swe-2 в devin, но есть нюансыНа выходных многие ломанулись тестировать SWE-2: до 10 октября он бесплатен в Devin Desktop и CLI. Модель интересная: дообученная от Kimi K3, аккуратно правит код, хорошо держит фронт и умеет много агентской рутины. Плюс сразу подхватывает AGENTS.md, skills, MCP и привычные CLI-интеграции. Целей нет, зато есть /loop

Нюанс №1
У части пользователей незаметно включается Adaptive, а по умолчанию рядом маячит Fusion. В итоге ты думаешь, что работаешь на бесплатном SWE-2, а квота уезжает на роутер или lead-модель.В Fusion SWE-2 может быть только допом, а Fable/Astra/Sol платной основой. Дневная квота много у кого горит
Нюанс №2
Бесплатно не значит безлимитно по скорости. По ощущениям, после 5–6 параллельных сессий TPS режется примерно со 100 до 70, в пик может падать до 30. Плюс периодически прилетают 429, и API притормаживает
Чтобы не платить за соседей:

devin --model swe-2-high
/model swe-2-high
/session-stats

В конфиге закрепить (например) %APPDATA%\devin\config.json,

{
  "agent": {
    "model": "swe-2-high"
  }
}

Ну а /fusion, /model adaptive и /handoff не трогать. В статистике должна быть одна модель SWE-2, без Lead/Sidekick, и quota не должна уменьшаться.

P.S. Низкий порог входа по почте и слабая привязка к устройству сделали промо очень удобным для мультиаккаунтинга. Те 1 аккаунт за 20$ на почту + vps + cliproxyapi =>десятки индусов абузят через сабагентов. А еще конечно это по сути бесплатная мощная модель для любых ваших ИИ продуктов

P.P.S. 100% включат недельные квоты для free tier, но попробуй успеть пока не разобрали

Про нестандартные решения и продуктовых инженеров

Мы тут обсуждаем в наших командах, как строить разработку в новых условиях и возможностях. Так чтобы это и не вайбкодинг, но и не эджайл по-советски. Понятно, что сквозная агентная инженерия, спеки, харнесс, подписки, все дела... Но пока продакт и инженер-билдер это не один человек, проблемы в коммуникации и сквозных бизнес-процессах неизбежны. Это просто как преамбула.

***

Думаю, вы понимаете, что в одиночку единорога уже можно конечно пробовать, но пока это скорее ошибка выжившего, как и в целом с успехом. Как правильно -- все знают. В теории.

Так вот, мы по-прежнему командами работаем. Небольшими командами. Может быть расскажу как-нибудь об этом подробнее.

Но сегодня о другом.

Обновили и утвердили очередную методологию процесса разработки. В моменте все счастливы. Но вы думаете она нас сделает успешными? Ну нет конечно.

Успешными людей и компании делают нестандартные решения.

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

Либо вы дурак или новичок, что в данном случае практически равноценно, и просто еще не знаете, что так нельзя.

Либо вы профи с огромным прикладным опытом и уже слишком хорошо знаете, почему именно так нельзя, когда это действительно нельзя, а когда вполне можно.

Все, кто посередине, обычно лучше всех знают, как правильно. 

Давайте признаемся, что мы все плюс-минус посередине. Поэтому рассчитывать на спасительное незнание правил или гениальность огромного опыта нам не приходится. Придется включать голову и сознательно учиться делать иначе.

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

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

Решил об этом не в командных чатах, а с трибуны, как Владимир Ильич. Может кому тоже полезно будет. 

Неотправленный пост моим командам:

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

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

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

Поэтому я пока по-прежнему буду полагаться больше на инженеров с сильным продуктовым мышлением. Никакая методология не должна превращать их в исполнителей спецификаций или электриков, соединяющих провода изолентой.

Надо давать им возможность самостоятельно восстанавливать смысл, замечать противоречия, задавать вопросы, принимать инженерные решения с учетом продуктовой цели и вытягивать продукт даже через неизбежно неполный, противоречивый и замусоренный контекст. Он все равно не будет полным. Он у людей-то всегда не полон!

Можно убиться за чистоту контекста, но так и не сделать продукт или так и не вывести его на рынок. Таких большинство, если что. А делают все по уму.

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

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

Другими словами, включает голову, по полной.

Неисповедимы пути ©
Как проектирование ЧПУ станков довело
до церковнославянского справочника.
И неясно, куда занесет ещё.

Я инженер. Работаю с достаточно сложными проектами в нефтянке
в роли СТО да проектного менеджера с упором на технические вопросы.
Всякое там ТОиР, стройка, проектирование, производство, КиП и тому подобное

Как частный личный проект с год назад с товарищами
задумали и начали делать 3–4 осевые ЧПУ станки небольших форматов.
Итогом добрались до церковнославянского сайта‑справочника и нейросеток.
Грабли банальные, если оглядываться назад и, видимо,
для многих «в теме» очевидные. Но мы по ним
оттоптались знатно. Думаю — будет еще много

Логика странная, но есть.
1. Для отработки конструкционных решений — нужно делать тесты.
Для наших ЧПУ — что‑то с большим количеством мелких элементов,
достаточно объемное и сложное. При этом недорогое и, чтоб не в мусор,
если получается что‑то приятное. Ибо обидно выкидывать.
Случайно наткнулись на православные иконы из дерева.
Подходит. Пробуем. Для отработки нюансов с ЧПУ оказалось шикарно.

2. Проект нежданно расширился в сторону производства икон. Ибо интересно.
Наловили кучу факапов и тонкостей с материалами, фрезами, химией.
Будучи агностиками по сути, реально получаем удовольствие. Факт.
Выяснилось, что тут свой большой объемный и непростой мир. Забавно.
Кардинально пересмотрели некоторые инженерные решения по станкам. Cool

3. Проект расширился в сторону 3D моделирования.
Выяснили, что 3D моделей хороших мало. При том количестве разного,
что «в интернетах есть» — реально качественного и достойного очень немного.
Есть свои тесные сообщества со своими правилами и ценами,
репутацией, рейтингами и «чужим входа нет».
Нейросетки не катят, как оказалось. Увы. «Все ручками».
Поэтому жесткая и очень ресурсная наработка опыта
работы с моделированием трехмерного разного.

4. Проект расширился снова, теперь в програминг для станков. Оказалось,
что есть глобальная разница в G‑code для станка по разному сделанного.
Одна и та‑же модель на одном железе дает кратно разные результаты.
Итогом курсы, обучение, тесты, бессонные ночи и в 2 раза меньше
машинного времени при сильно лучшем результате на той‑же «базе»
Ибо 28 часов работы станка на одно изделие, и 15 таки
существенная разница по всем понятиям.

5. И снова проект расширился. Теперь в сторону информационную.
При всей «банальности» иконы как объекта, нашлась уйма нюансов.
Оказалось, что все сильно непросто в части надписей, шрифтов,
расположений элементов и тому подобных «мелочей». И даже
в епархиях часто спорят и не знают, как «правильно» и «нужно».
Итогом — сайт‑справочник, с надписями, словарем, шрифтами,
написанием и кучей новых (для нас) знаний о старославянском.

6. И снова расширение. Потому что моделей уже сотни,
вариантов куча, программы разные, фото‑видео копятся.
Нужно это все каким‑то образом хранить, холить и лееять.
Да и показывать надо порой выбранные вещи, что уже сложно
в части оперативного поиска да выборки. Банальные каталоги
где‑то на облаке не рабочее решение. Увы.
И снова в помощь codex да grok, и снова
очередной проект, теперь хранилища.

Зачем пишу?
Поделиться очередной иллюстрацией того,
как жизнь порой разворачивается в странные
и забавные проекты, задачи, решения, контакты.
Как относительно простой проект вдруг превращается
превращается, превращается в шорты © в какую‑то экосистему,
и укапывание в неизвестные досель области знаний.

Цифровая трансформация

Может это уже не такой модный термин, но я вижу в нем огромный потенциал. Да только, чтобы этот потенциал реализовать - важно понимать полезность. Самую суть выгоды от применения цифры.

Актуальный свод знаний по бизнес процессам (CBOK 4) дает три разных определения термина:

1. The Enterprise Project: “Цифровая трансформация — это интеграция цифровых технологий со всеми составляющими бизнеса, коренным образом меняющая то, как бизнес организован и как он создает ценность для потребителей.”

Это прям идеальный пример основания для волшебного мышления, мол “а давайте всё покрасим в коричневый и тогда у нас всё получится!” Что… почему… как это будет работать и за счет чего принесет пользу - вообще не понятно - просто красивый лозунг. Более того тут и зло закопано в виде не универсальности, т.к. не для абсолютно любой ситуации это применимо так, чтобы обязательно стало лучше.

2.… второе определение от George Westerman - даже приводить не буду… там одна сплошная эмоция без каких-либо оснований

3. Salesforce: “Цифровая трансформация — это процесс использования цифровых технологий для создания новых или изменения существующих бизнес-процессов, культуры, клиентского опыта в ответ на меняющиеся требования бизнеса и рынка.”

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

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

Давайте представим себе большую организацию, где часть сотрудников разговаривает на китайском, часть на арабском, а остальные - на итальянском. При этом у одних есть только почта, у других только проводной телефон, а у третьих - курьеры и телеграф.

Если всю эту сложность мы свяжем через интернет и будем автоматически переводить на английский - эффективность работы очевидно и радикально возрастет!

Эффект от цифровой трансформации похож на приведенный пример, где переход на цифру снижает издержки на взаимодействие, где все объекты обретают цифровые двойники, которые связаны по скоростным цифровым каналам с применением реализованных в цифре алгоритмов.

Получается, что цифровая трансформация - это переход на единый протокол взаимодействия всех элементов рабочей системы… как разнокалиберные шестеренки смазать правильным маслом.

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

И для всего этого вовсе не обязательно менять всю бизнес модель.

Заметка на полях. Про людей, ИИ и проблемы.

По отзывам на «Человека и Рой» у меня сложилось ощущение, что мы одновременно сильно переоцениваем три вещи: способность людей думать, способность ИИ думать и сложность задач, которые людям и ИИ предстоит решать.

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

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

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

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

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

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

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

Когда нет фундамента в основе, когда цели размыты и научный подход вышел покурить, получаются вот такие красивые модели:

Что мешает сюда включить еще два пункта “Красный” и “Кислый”? А двух крокодилов, которые один зеленый, а другой на север?

Или любое из других красивых слов, типа “Цели”, “Мотивация”, “Системы”, “Согласованность”…

Мой любимые вопросы:

1. а это десять из скольких возможных?

2. а почему именно десять?

Переводя разговор в практическое русло - приведенная схема, как и тысячи подобных - пытаются сделать черных лебедей в черном ящике белыми, ручными и предсказуемыми. Но когда нет понимания о составе скотного двора внутри объема остается только наугад выхватывать красивые слова и красиво их оформлять в виде красивой инфографики.

Применение подобных моделей вообще не гарантирует, что значимые риски будут рассмотрены и предусмотрены, а значит - это пустая трата времени.

Как собрать ИИ-агента под свои рабочие задачи — тренинг от Практикума

Подойдёт руководителям, предпринимателям и всем, кто работает с информацией. Не нужны навыки программирования или опыт в IT.

В программе — теория и много практики:

• Разберётесь в ИИ-агентах. Узнаете, чем они отличаются от чат-ботов и как работают автономные цепочки действий.

• Поработаете с промптами. Научитесь формулировать эффективные запросы и управлять поведением ИИ с помощью инструкций, контекста и примеров.

• Создадите базу знаний. Соберёте ИИ-помощника, который знает внутренние документы компании и отвечает на вопросы по ним.

• Соберёте собственного ИИ-агента. Настроите его под свою профессиональную задачу, подключите документы или базу знаний и протестируете работу.

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

Тренинг проведёт Евгений Паточенко — академический руководитель магистерской программы «Аналитика больших данных» НИУ ВШЭ. Более 15 лет внедряет бизнес-приложения в крупнейших российских и международных компаниях, специализируется на применении ИИ в бизнесе.

Тренинг пройдёт онлайн и займёт около 5 часов с двумя перерывами по 20 минут. Во время обучения можно задавать вопросы эксперту в чате. Платные подписки на ИИ-инструменты не нужны — для практики можно использовать бесплатные.

→ Записаться на тренинг

Аналитик между бизнесом и разработкой: что нужно знать сегодня

Задача поставлена, но никто не может точно объяснить, что именно нужно сделать. Бизнес ждёт результат, разработчики задают десятки уточняющих вопросов, а изменения продолжают появляться по ходу проекта.

Работа аналитика — превратить этот хаос в понятную систему: выявить потребности, зафиксировать требования, найти слабые места и помочь команде прийти к правильному решению.

Подобрали бесплатные уроки, которые помогут усилить практические навыки системного и бизнес‑анализа.

Системный анализ и работа с требованиями

• 8 сентября, 20:00. «Системный аналитик и его ценность глазами компании». Записаться

• 23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться

• 22 октября, 20:00. «Управление изменениями требований». Записаться

Бизнес-анализ и процессы

• 15 сентября, 20:00. «Как аналитик 1С ведет задачу от интервью до приемки: сквозной кейс интеграции с мобильным рабочим местом». Записаться

• 6 октября, 20:00. «Как найти точки роста и улучшить бизнес-процесс: от диагностики до новой модели». Записаться

• 15 октября, 20:00. «Цели и метрики как одно целое». Записаться

Моделирование и коммуникация

• 17 сентября, 20:00. «Событийные подпроцессы в BPMN 2.0: как моделировать процессы, реагирующие на события». Записаться

• 21 октября, 20:00. «Анатомия сопротивления: превращаем токсичных стейкхолдеров в союзников проекта». Записаться

ИИ в работе аналитика

• 28 сентября, 20:00. «Инструменты ИИ в работе бизнес-аналитика». Записаться

• 29 сентября, 20:00. «Зелёные тесты, неверный продукт: как системному аналитику принимать работу ИИ-агента». Записаться

• 14 октября, 20:00. «ИИ-агент как супероружие Системного Аналитика: составляем ТЗ за 10 минут». Записаться

Выбирайте темы, которые помогут закрыть ваши текущие рабочие задачи, и развивайте экспертизу системного или бизнес‑аналитика.

А если хотите посмотреть все открытые уроки месяца по другим направлениям — собрали их в сентябрьском дайджесте.

Секреты победителей премии “Intercomm” или как упаковать ваш проект в заявку так, чтобы жюри влюбилось в него с первого взгляда…

Осталось не так много времени для подачи материалов на участие в премии “Интеркомм” Напомню, что номинация “Лучший блог на Хабре” подходит тем компаниям, у кого

• 1. Есть активный блог на Хабре.

• 2. У блога есть цель, стратегия, концепция, результаты, планы на будущее.

• 3. В развитии блога принимают участие сами сотрудники компании. 

  Как заполнить заявку, что отразить в презентации, обязательно ли нужны ли видеоролики? С этими и другими вопросами можете смело приходить к нам. Это не дает гарантии победы, но облегчает ваш путь. Естественно, призовые места получат не все, и это вполне объяснимо. Зато, принимая участие в премии, вы не просто рассказываете миру о своем блоге, вы набираетесь опыта, развиваете свою насмотренность, покачиваете крутые навыки, которые в следующий раз могут сыграть решающую роль. Многие участники премий прошлых лет говорят, что это как минимум помогает привлечь внимание к проекту внутри компании, а также получить поддержку руководства и даже дополнительный бюджет! А мы готовы делиться с вами подробными рекомендациями по заполнению заявки, так что стучитесь.

Итак, советы и лайфхаки от победителей прошлого года

1. В заявке нужна четкая логика и строгая структура. Основа заявки - это суть проекта. Потом результаты и самые важные его фишки, отличительные черты. Описания рабочих процессов можно убрать или максимально сократить.

2. В дополнительных материалах, особенно в роликах, желательно показать людей, которые принимают участие в проекте, и людей, для которых он делается ( по возможности). Это всегда цепляет.

3. Описание проектов лучше делать в строгом соответствии с критериями, по которым будет оцениваться проект. В номинации “Лучший блог на Хабре” - свои особые критерии, и форма заявки отличается от общей стандартной формы. Поэтому обратите внимание на то, какой именно шаблон вы скачали и заполняете. Если вы пропустили и не расписали хоть один критерий, у заявки будет меньше шансов дойти до финала. Если вы понимаете, что какой-то критерий у вас не дотягивает до идеала, его все равно не надо пропускать, опишите его коротко. А тот критерий, который у вас преобладает, распишите подробнее.

4. Если материалы недостаточно хорошо оформлены и структурированы  - это может стать причиной для снижения оценки. Также очень важна грамотность. Пусть ее нет среди критериев, но грамотность во всех материалах - это то, что на что смотрит жюри в первую очередь.

5. Проекты - участники премии чаще всего работают на бизнес-результаты и на выполнение целей компании, и это очень хорошо. Но не забывайте показать и человеческую сторону проекта: как он работает на людей, как он меняет их жизнь, как помогает им раскрываться, развиваться, объединяться.

6. Добавляйте в заявку все материалы, которые у вас есть по данному проекту -  ссылки, фото, презентации, отзывы, результаты опросов, ролики… т.е. абсолютно любые материалы, которые помогут получить жюри максимально полное представление о проекте.

7. Интересные артефакты, фишки, какие-то атрибуты, даже небольшие, но любопытные нюансы такие, например, как кофейные стаканчики в офисе компании с QR-кодом, ведущим на сайт проекта - тоже классная часть истории! Не упускайте такие вещи и обязательно прописывайте и показывайте их.

8. Любое внутреннее и внешнее промо вашего проекта - тоже интересно и важно для результата и увеличения охвата.

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

10. Организаторы не советуют слишком увлекаться ИИ и делать материалы с помощью цифрового ассистента. Это видно, это не цепляет и самое грустное, что проект теряет свою душу, свой характер, свою индивидуальность. 

Как не поделиться свежей историей про ответственность на проектах!.. Причем формально-то совсем не про них, зато ее можно использовать как аргумент «а вот даже у лидеров рынка еще хуже нашего»...

https://arstechnica.com/features/2026/09/the-ai-data-center-boom-is-causing-new-accountability-problems/

Кратко: в Штатах строят Lake Mariner — дата-центр за 3,2 лярда долларов. Интересанты соответствующие: Google и Anthropic.

И там бахнул пожар. Слава богу, без катастроф: никто не погиб, пожар потушили. Но зато выяснилось, насколько объект "готов" к пожару.

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

А дальше - вот оно, прекрасное устройство проекта. Одна контора владеет и управляет дата-центром, землю арендует у другой структуры, связанной с тем же собственником, Гугл финансирует, Anthropic покупает. Плюс подрядчики, местные власти, энергетики, пожарные и наверняка еще много кто остался за рамками статьи.

То есть там наверняка была нарисована целая библиотека матриц ответственности, оргструктур, протоколов, оценок рисков и прочей прекрасной проектной документации. Каждый прекрасно отвечал за что-нибудь свое. А потом случился пожар, которому пофиг на это...

Но вот про противопожарную безопасность никто не думал. Часть гидрантов была не подключена, документации по системам тушения не было и т.д. А тут бах - и пожар. И концов нет. И нет планов действий. И некому их выполнять. Все молодцы, всё сделали в зоне своей ответственности и пошли смотреть на пожар как зрители (Ну ладно, кто-то хотя бы вызвал пожарных).

Финал тоже неплох. После пожара TeraWulf (это типа управляйка) сообщила, что происшествие разобрали и приняли дополнительные меры, в том числе по гидрантам и взаимодействию с пожарными. Но через два месяца начальник пожслужбы сказал журналисту, что, "насколько ему известно", проблемные гидранты всё еще сухие.

А вы говорите, "риски"...

Проектов больше, чем людей: как управлять портфелем в условиях дефицита ресурсов?

Рост числа проектов не всегда сопровождается ростом команды. Когда ресурсов не хватает, приходится вручную расставлять приоритеты и перераспределять людей, а контроль сроков, бюджета и обязательств становится всё сложнее.

Как сохранить управляемость портфеля, когда проектов становится больше, а ресурсов – нет? На вебинаре 17 сентября в 12:00 покажем, как с помощью решения Digital.Q.PM «Управление проектами» выстроить сквозной процесс – от постановки бизнес-цели и создания проекта до его выполнения и завершения.

Покажем на практике, как Digital Q.PM помогает снизить ручную нагрузку на менеджеров, эффективнее использовать ограниченные ресурсы и управлять большим количеством проектов без потери прозрачности и контроля.

Также разберем, как на каждом этапе процесса связаны данные, задачи и различные системы платформы, чтобы управление проектами оставалось прозрачным и контролируемым.

• Создание проекта на основе поставленной бизнес-цели

• Управление ресурсами в условиях их дефицита

• Планирование и контроль бюджета

• Контроль выполнения проектных обязательств

• Взаимодействие различных систем платформы в едином процессе управления проектом

Кому будет интересно:

• Руководителям РМО

• Руководителям проектов и программ

• Специалистам по управлению ресурсами и портфелем проектов

• ИТ-директорам

• Руководителям цифровой трансформации

Зарегистрироваться на вебинар можно по ссылке

Вебинар для компаний из Москвы: как сэкономить до 300 000 ₽ на патентной заявке

Технологические компании Москвы могут бесплатно получить услуги по патентованию своих продуктов и технологий, благодаря поддержке от Московского инновационного кластера.

✅ Уже более 100 компаний и ИП из Москвы патентуют свои решения за счет Фонда.

Онлайн Патент — официальный партнер программы. Наши патентные поверенные проведут для вас патентный поиск, подготовят заявку и проконтролируют весь процесс экспертизы вплоть до решения Роспатента.

Приглашаем вас на встречу, на которой специалисты Онлайн Патента расскажут:

• как работает патентная монополия на продукт и что она дает бизнесу?

• какие решения можно запатентовать и как заблокировать нарушителей?

• как воспользоваться программой Московского инновационного кластера?

Когда: 9 сентября в 10:00 по московскому времени. 

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

Современный рынок ИТ похож на состояние, когда люди научились делать молоток, а гвозди еще не изобрели.

Кругом бегает толпа прогрессивных инноваторов и пытается бить молотком по всему, до чего дотянется.

Очень серьезные чечки бегают с большими молотками. Стартаперы — с креативным нечто «похожим на».

Есть ощущение — что нужная вещь! Кто‑то хвастается удачными попаданиями.

Умники уже даже занимаются улучшением молотка — то ручку длиннее сделают, то в новый цвет покрасят.

Вот только… гвоздей пока нет…

Такое ощущение :)

С 26 августа по 2 сентября на Бирже заказов Инфостарта появились новые задачи для разработчиков, консультантов и аналитиков 1С. Основные темы недели - маркировка, электронные перевозочные документы, интеграции и доработка конфигураций.

Среди новых заказов:

• Этикетка Wildberries для УТ 10.3

• Перепродажа маркируемой продукции между организациями

• Внедрение процессов в 1С:Документооборот 3.0

• Исправление загрузки госконтрактов из ЕИС

• Консультация по агрегации марок в УНФ

• Загрузка реквизитов из Excel и обмен с InSales

• Загрузка финансовой модели в 1С

• Поддержка Bluetooth-сканера в мобильной платформе

• Выгрузка товаров во Фронтол 6

• Разработка документа «Рекламация»

• Настройка «Контур.Логистики» для 1С:КА

• Загрузка цен ЖНВЛП с сайта ГРЛС

• Отображение цены в подборе 1С:Розницы 2.0.

• Подключение УНФ к «Честному знаку»

• Интеграция УТ 11 с расширением ESD от СБИС Настройка обмена между УТ 11.5 и 1С:Бухгалтерией.

• Настройка телефонии в Альфа-Авто 6

Биржа заказов Инфостарта позволяет напрямую связаться с заказчиком и обсудить условия работы. Комиссия с исполнителя не взимается.

Подборка материалов: что почитать аналитику

Собрали подборку из пяти материалов о разных задачах аналитика: от работы с требованиями и взаимодействия с командой до поиска решений и использования ИИ.

➡️ ИИ для бизнес-аналитика

Какие задачи аналитика можно частично передать ИИ, какие инструменты использовать в работе и о каких ограничениях важно помнить.

➡️ Как подружить работу дизайнера и аналитика

Как формулировать задачи, договариваться об ожиданиях и обсуждать решения, когда аналитик и дизайнер смотрят на одну задачу с разных сторон.

➡️ Мягкие навыки аналитика

Какие навыки помогают аналитику видеть задачу шире, выявлять требования, проводить встречи, обмениваться информацией и организовывать свою работу.

➡️ Как продуктовый аналитик помогает разработке двигаться быстрее 

Как подготовить задачу так, чтобы сократить количество уточнений и переделок, расставить приоритеты и иногда найти решение без дополнительной разработки.

➡️ Рецепты самопомощи аналитика

Как замечать типичные проблемы в работе с требованиями и задачами и какие приемы помогают не допускать ошибок или вовремя их исправлять.

Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️

Инструменты. Про «почему».

«Почему» — один из самых интересных вопросов.

«Что», «где», «когда» и «как» — дополнения. Они позволяют очень подробно выяснить все обстоятельства произошедшего, кроме причины.

Еще есть «кто». Вот это уже отличный вопрос.

Кто ошибся? Кто не проверил? Кто нарушил инструкцию?

Оператор?

Прекрасно. Провести обучение, получить подпись, закрыть корректирующее действие.

До следующего оператора.

А есть «почему».

Почему оператор ошибся? Почему проверка не сработала? Почему инструкция позволяет ошибиться? Почему процесс вообще зависит от того, ошибется сегодня конкретный человек или нет?

С этим вопросом надо быть осторожнее. Пара лишних «почему» — и вместо оператора можно обнаружить процесс. Еще пара — и людей, которые этот процесс придумали и годами им управляют.

Toyota в свое время сделала сформулировала и внедрила 5 Why.

Один из самых известных инструментов качества в мире построен на ошеломительной идее:

если хочешь узнать, почему что‑то произошло, спроси «почему». И не прекращай после первого ответа.

Все.

Реально все.

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

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

И ведь это действительно работает.

Но самая издевательская часть всей истории в другом: недооценивать профессионалов не стоит.

Почему дефект попал клиенту? Оператор его пропустил.

Почему пропустил? Не выполнил требуемую проверку.

Почему не выполнил? Отклонился от рабочей инструкции.

Почему отклонился? Недостаточно хорошо знал требования.

Почему недостаточно хорошо знал? Недостаточное обучение.

Root cause: недостаточное обучение.

Прекрасно. Провести обучение, получить подпись, закрыть корректирующее действие.

До следующего оператора.

Toyota дала нам инструмент, чтобы за ошибкой оператора искать реальную причину.

Мы за деньги научились с его помощью «искать» ошибку оператора еще тщательнее.

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

Зато теперь — по методологии, с использованием инструментов Lean.

«Почему» действительно прекрасный вопрос.

Главное — вовремя остановиться и случайно не выйти на самих себя.

Почему коммерческие инициативы застревали между функциями

У каждой функции был собственный план. Команды были заняты, задачи двигались. И всё же коммерческие инициативы застревали между ними.

Назвать дату запуска заранее было почти невозможно. Приоритет менялся уже в работе, незавершённые задачи копились, а настоящую причину задержки находили тогда, когда исправлять было поздно.

В такой ситуации легко добавить Scrum: новые роли, встречи, доску. Мы начали с менее эффектных вопросов. Кто имеет право поставить задачу в общий поток? Где определяется приоритет, если интересы функций расходятся? Сколько работы система вообще способна нести одновременно? Кто принимает компромиссное решение?

Ответы изменили конструкцию работы. Появился общий кросс-функциональный контур приоритизации, двухнедельные Scrumban-циклы и ясные критерии входа и завершения. Мы ограничили незавершённую работу и стали регулярно разбирать узкие места — по тому, где действительно останавливался поток.

Время вывода инициатив сократилось примерно вдвое. Затем отдельная работа с узкими местами дала ещё около 20% ускорения. Предсказуемость выхода достигла 99%, объём незавершённой работы снизился на 40%.

Цифры здесь важны. Но сильнее всего этот кейс изменил мой взгляд на Agile. Доска хорошо показывает проблему, ритм помогает её обсуждать. Ни то ни другое не заставляет функции договориться об общем приоритете и принять ответственность за результат целиком.

С тех пор, когда каждая команда выполняет свой план, а клиент всё ещё ждёт, я смотрю не на дисциплину отдельных команд. Я ищу место, где между ними перестало приниматься решение.

Если узнаёте такую ситуацию, напишите «поток». Отправлю короткую диагностику из 10 вопросов: она помогает увидеть, где система теряет скорость, маржу и ответственность.

Обучающие игры Хабра. Приглашаем вас на бесплатный Демо-день 2 сентября!

Всем привет! Я тут с хорошей новостью для компаний, которые ведут корпоративный блог на Хабре или только собираются начать его вести.

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

Что же это за игры? 

Самыми популярными и востребованными уже стали две игры - «Попробуй Хабр» и «Готовим статью на Хабр». Первая - для тех компаний, которые хотят узнать, как построить диалог с аудиторией через экспертный контент и какие подходы лучше выбрать для того, чтобы эффективно решать свои бизнес-задачи с помощью блога на Хабре (эту игру мы традиционно проводим на всех Тест-драйвах, поэтому в отдельной презентации она не особо нуждается). А вторая часто используется в процессе обучения корпоративных авторов (как начинающих, так и опытных) и помогает участникам разобраться в позитивных и негативных паттернах при подготовке статей на Хабр. 

2 сентября мы проведем эфир, основной темой которого как раз и будут наши игры. Там мы также расскажем про новую разработку под названием «Остров Хабра», участники которой учатся оттачивать навыки убедительной коммуникации. Ну и, конечно, представим две свежие новинки - это игры “Собери свою первую статью на Хабр” и “Путь автора”. Они помогают компаниям снять сразу две боли - “У нас нет опытных авторов, которые знают, как писать на Хабр” и “У нас вообще нет авторов и мы не знаем, где их взять”. 

Уверена, что эти боли испытывают не только редакторы, но и те люди, которые отвечают за развитие корпоративных блогов на Хабре и контент-маркетинг в целом. Если вы хотите подробнее узнать об этих играх и протестировать их, регистрируйтесь на наш Демо-дэй, который пройдет онлайн 2 сентября. Участие бесплтатное!

! Сразу скажу, что это будут не полноформатные игры (обычно они занимают 1,5-2 часа), а только короткая демоверсия каждой игры, чтобы участники созвона могли быстро понять смысл и механику.  

На встрече мы дополнительно расскажем последние новости и тренды Хабра. Мероприятие бесплатное, но количество мест ограничено. Спешите зарегистрироваться!

12 открытых уроков для руководителей: команда, проекты, стратегия и ИИ

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

Хочется распределить ответственность, раньше замечать проблемы, принимать решения на основе данных и использовать ИИ там, где он действительно экономит время — чтобы команда работала предсказуемее, а у руководителя оставался ресурс на развитие и стратегические задачи.

Собрали ближайшие открытые уроки OTUS для тимлидов, руководителей проектов, менеджеров и тех, кто готовится к следующему уровню ответственности.

Управление командой

• 9 сентября, 20:00. «Как тимлиду распределять ответственность и не становиться узким местом команды». Записаться

• 16 сентября, 20:00. «Диагностика команды: как выявить проблемы до того, как они повлияют на результат». Записаться

• 16 сентября, 20:00. «Сложные разговоры в команде: как давать обратную связь без эскалации». Записаться

Стратегия и развитие руководителя

• 8 сентября, 20:00. «От технического лидера к CTO: как начать принимать решения на уровне бизнеса». Записаться

• 22 сентября, 20:00. «Метрики CTO: показатели, которые действительно нужно контролировать». Записаться

Управление проектами и процессами

• 1 сентября, 20:00. «Практическое применение нейросетей для моделирования процессов». Записаться

• 14 сентября, 19:00. «Анти‑паттерны управления: Почему „помощь“ заказчиков убивает проекты и как вернуть контроль». Записаться

• 17 сентября, 20:00. «Событийные подпроцессы в BPMN 2.0: как моделировать процессы, реагирующие на события». Записаться

• 23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться

ИИ для руководителя

• 3 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться

• 21 сентября, 20:00. «Один рабочий день с ИИ: от писем и таблиц до готовой презентации для руководителя». Записаться

• 24 сентября, 20:00. «PM + ИИ: собираем статус‑отчёт, реестр рисков и прогноз сроков за 40 минут». Записаться

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

ЧТО ПОЧИТАТЬ

Если хотите глубже разобраться в управлении командами, процессами и собственной управленческой траекторией, собрали ещё несколько материалов из блога:

• «Кто платит за ИИ‑продуктивность: почему выгорают middle‑инженеры» — о скрытой нагрузке в командах при внедрении ИИ и о том, что руководителю важно учитывать в метриках и распределении ответственности.

• «10 типовых ошибок при внедрении управления корпоративной архитектурой (Enterprise Architecture) и как их исправить» — о системных ошибках в управлении архитектурой и способах их избежать.

• «Когда сотрудник тормозит команду: как говорить с ним прямо, но без давления» — о сложных разговорах, обратной связи и работе с проблемами внутри команды.

• «Путь до CTO: как пройти его самому и помочь пройти другому» — о переходе от технической экспертизы к роли руководителя и развитии управленческих компетенций.

Больше открытых уроков и практических занятий собрали в дайджесте.

Весной я стал крепко задумываться о дальнейшем развитии своего "Блокнота продакта". Сам по себе он интересен (и не только мне!), но выглядит застрявшим на уровне 2021 года.

В 2026-м же... одно то, что YCombinator анонсировал прямой запрос на "Cursor для продактов" - уже даже не звоночек) А на последнем рабочем месте у меня постоянно был запущен терминал с Клодом, ещё одна агентская система в браузере и периодически поднимались чаты для отдельных вопросов.

Продукт без вариантов надо двигать в сторону AI, вопрос в деталях. Сейчас это совершенно классический SaaS - онлайн-приложение с веб-клиентом. И я вижу несколько путей развития:

1. Оставить концепцию SaaS, но добавить MCP-сервер, чтобы можно было достучаться до данных в сервисе из уже привычного инструмента.

2. Переделать в локальное приложение, со встроенным интерфейсом взаимодействия с LLM и хранилищем обвязки, к которому можно будет подключать внешние сервисы для непосредственно инференса. Такой вариант ближе всего к понятию "Cursor для продактов".

3. Двигаться постепенно, начав с синхронизации с локальным хранилищем в markdown, что даст возможность работать с ним параллельно любым другим инструментом.
   
   Это удобно реализовывать, но не выглядит как MVP, потому что заметная часть практического использования будет где-то за контуром продукта.

Вот что бы предложили (или чем бы заинтересовались) вы?

На Бирже заказов Инфостарта опубликованы новые проекты для разработчиков и консультантов 1С. В подборке за 20–26 августа - интеграции, перенос данных, доработка отчетов, складские решения и работа со старыми конфигурациями.

Новые проекты

• СофтФон в АльфаАвто 6 – комплексная настройка телефонии и возможная донастройка Asterisk 

• Доработать или добавить отчет «Карточка расчетов» в 1С:Гаражи 

• Задачи по ТСД и «Складу 15» 

• Разработка обмена УПП–ERP в шине DatareonPlatform 

• Обработка для переноса данных между базами 1С 7.7 

• Настроить одновременную печать на два принтера в УНФ 3.0 

• Внешняя обработка для группового изменения фасовки в УТ 10.3 

• Переход с УНФ 1.6 на УНФ 3.0 для Казахстана

В списке есть как небольшие доработки, так и интеграционные проекты. Условия и стоимость части заказов обсуждаются напрямую с заказчиками.

Посмотреть другие задачи на Бирже заказов Инфостарта

Как Юнитрек за 2 недели подготовила ИИ-платформу к федеральному запуску и масштабировала ее до 100 000 участников

🏭 Что за компания
Юнитрек — российский разработчик платформы для бизнес-симуляций и деловых игр на основе реальных кейсов и практик предпринимателей. На платформе пользователи проходят игровые сценарии, принимают управленческие решения, разбирают кейсы и используют ИИ-инструменты для обучения и развития предпринимательских навыков.

⚡ Задача
Команда готовила федеральный запуск платформы в рамках проекта «ИЗЗЗИ Бизнес Рост». Нужно было за короткий срок подготовить инфраструктуру, способную масштабироваться до 100 000 участников и выдерживать до 5 000 одновременных подключений.

Пилотная версия не была рассчитана на такой сценарий: при федеральном запуске объем нагрузки должен был вырасти примерно в 50 раз. При этом важно было обеспечить стабильную работу приложения и быструю доставку контента пользователям из разных регионов.

☁️ Что сделали
Чтобы не тратить время на самостоятельное развертывание и поддержку инфраструктуры, команда Юнитрек воспользовалась управляемыми сервисами Cloud.ru Evolution. Ими удалось закрыть весь стек — от пользовательской части и хранения данных до ИИ-компонентов. Пилотную инфраструктуру команда развернула за два дня, а после успешного тестирования масштабировала решение до федерального уровня менее чем за две недели — без ручного администрирования: при росте нагрузки ресурсы наращивались автоматически.

🦾 Что получили в итоге
Удалось не только запустить платформу, но и увеличить объем нагрузки примерно в 50 раз по сравнению с пилотом. Сейчас у платформы более 10 000 регулярно активных пользователей. При этом инфраструктура способна выдерживать рост до 100 000 участников. Команда не тратила ресурсы на капитальные вложения в инфраструктуру и ИИ-стек, а полностью сосредоточилась на развитии игровых механик и пользовательского опыта. В планах масштабировать емкость платформы до 200 000 пользователей и использовать платформу для новых образовательных программ, включая обучение школьников и студентов основам предпринимательства.

Все детали кейса  — на сайте.

Присоединяйтесь к встрече для ИТ-руководителей — поговорим про изменения, стратегию, выгорание и управление в эпоху ИИ 🤖

Встреча для ИТ-лидеров пройдет 28 августа в Москве с онлайн-трансляцией. В программе доклады и дискуссии о внедрении ИИ-агентов, управлении изменениями, стратегических ставках в эпоху ИИ и биологии выгорания.

Вас ждут доклады:

• «Разрыв: между амбицией и исполнением». По данным Gartner, ИИ-агентов реально внедрили около 17% компаний, при этом более 60% планируют сделать это в ближайшие два года. Разберём, почему ожидания расходятся с реальностью и как этот разрыв влияет на ИТ-команды.

Спикер — Дмитрий Лаптев, директор по технологической стратегии MWS.

• «Эволюция Agile в эпоху агентов: как ИИ сделать союзником команды, а не угрозой?». Обсудим, почему простая замена людей агентами не даёт качества и как перестроить работу, чтобы ИИ расшивал узкие места.

Спикеры — Евгений Калабин, руководитель группы обучения и продвижения практик Agile MWS, и Ольга Склярова, лидер Agile ИТ-кластера «Продажи и обслуживание» MWS.

• «Вредные советы по управлению изменениями: как перестроить процессы и выжить». Разбор реальных кейсов с юмором: что происходит, если пропустить ключевые шаги ADKAR, почему команда сопротивляется изменениям и как превратить разовые «вау»-инициативы в устойчивые процессы.

Спикер — Ольга Шутова, тимлид команды разработки Т-Банка.

• «Биология выгорания: как стресс из двигателя прогресса превратился в когнитивное искажение». Поговорим о том, как стресс влияет на продуктивность и творческое мышление, и как управлять своим состоянием.

Спикер — Сергей Харитонов, молекулярный биолог, сотрудник МГУ, научный сотрудник Института биологии старения и медицины здорового долголетия.

• «Управлять тем, чего ещё нет: как запускать новое и делать стратегические ставки в эпоху AI». Как выбирать идеи, которые заслуживают инвестиций, и проверять гипотезы в условиях неопределённости.

Спикер — Анастасия Азоркина, главный менеджер продукт

• «Работа не work, работа — волк: серые практики устройства в ИТ». Какие скрытые риски несут сторонние помощники и «серые» практики при найме в ИТ и как компаниям защитить себя.

Спикер — Андрей Репин, лидер QA ИТ-кластера «Развитие инфраструктуры» MWS.

📅 Когда: 28 августа в 17:30

📍 Где: Москва, метро Технопарк + онлайн-трансляция

👉 Регистрируйтесь, чтобы обсудить актуальные вызовы с коллегами. Ждем вас!