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

Как выйти из кризиса перегрузки без найма: опыт двухнедельного Stop the Line

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

Типичная картина: дедлайны не двигаются, найм заморожен, техдолг растёт, инциденты множатся, люди выгорают. Первая реакция — «давайте ускоримся ещё сильнее». Это только усугубляет кризис.

Проблема не в скорости разработки, а в том, что система перестала справляться с объёмом параллельных задач. Когда в работе одновременно 20 фич, а команда реально может закрыть 5 в спринт — каждая задача тормозит остальные. Контекстные переключения съедают до 40% времени, код-ревью затягиваются, интеграция превращается в русскую рулетку.

На практике видел это десятки раз. Компания вводит «режим ускорения»: сокращает ревью, откладывает рефакторинг, пилит MVP параллельно с production-фиксами. Через месяц скорость не растёт — падает. Команда тушит пожары вместо того, чтобы делать продукт.

Что даёт Stop the Line

Двухнедельная остановка конвейера — это не каникулы. Это хирургическое вмешательство: временно прекращаешь приём новых задач и закрываешь то, что уже в работе. Параллельно команда разгребает техдолг, который мешает двигаться дальше: чинит CI/CD, актуализирует документацию, закрывает критичные уязвимости.

Ключевой момент — это не просто «месяц на техдолг». Это сознательное решение восстановить пропускную способность. За две недели команда из условного «ФинТеха» может:

• Закрыть 15 из 20 зависших фич — вместо того чтобы держать их в работе ещё месяц

• Разобрать backlog инцидентов и понять, какие из них — симптомы одной проблемы

• Автоматизировать то, что отнимает 2-3 часа в день у каждого разработчика

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

После Stop the Line команда не становится быстрее в два раза. Но она возвращает управляемость: понятно, сколько задач реально можно взять в спринт, какие риски несут новые фичи, где узкие места. Вместо хаоса — предсказуемый поток.

Как продать это бизнесу

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

Опыт показывает: после Stop the Line скорость delivery возвращается к нормальной в течение месяца, а качество выходит на новый уровень. Главное — не скатываться в ту же воронку снова. Установить WIP-лимиты, внедрить метрики cycle time, договориться с бизнесом о реалистичных планах.

Ограничение подхода — он работает, если команда ещё не выгорела окончательно и проблема в процессах, а не в людях. Если половина уже ищет новую работу — Stop the Line не спасёт. Но если команда готова работать, просто задыхается под грузом — это работает.

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

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

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

Высокая толерантность означает, что организации (обычно малый бизнес или проекты без зрелой ИБ) готовы принимать значительные риски ради скорости развития, снижения затрат или упрощения процессов. При таком виде толерантности характерен слабый контроль доступа, отсутствие сегментации, редкие аудиты, устаревшие системы и другие пренебрежения информационной безопасности (если она вообще существует в организации).

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

Риск-менеджмент - это процесс управления рисками информационной безопасности. После оценки угроз организация выбирает один из вариантов обработки риска:

• Принятие риска (Risk Acceptance)

• Отказ от риска (Risk Avoidance)

• Митигация риска (Risk Mitigation)

• Передача риска (Risk Transfer)

Принятие риска - это когда компания осознанно принимает риск и ничего не меняет. Например уязвимость имеет низкую вероятность эксплуатации (likelihood), устранение слишком дорого (cost-benefits analysis) или ущерб считается приемлемым. Отказ от риска - когда организация полностью убирает/устраняет источник риска. Например, отключение небезопасного сервиса, отказ от хранения персональных данных или закрытие внешнего доступа (часто OWA). Митигация риска (Risk Mitigation) - наиболее распространенный подход, когда компания снижает вероятность атаки или уменьшает последствия компрометации. Передача риска (Risk Transfer) - когда риск частично передается третьей стороне, например в применяется страхование, использование облачных провайдеров; аутсорсинг SOC или передача ответственности подрядчику.

Кроме локальной нормативной базы, которые регулируют некоторые критические сегменты, например ПДн или КИИ, компании вправе самостоятельно выбирать допустимость угроз и управление рисками. Однако, говоря про международные стандарты, нельзя не затронуть ISO/IEC 27005:2022 - Руководство по управлению информационной безопасностью, которое описывает идентификацию угроз, анализ рисков, оценку последствий, методы обработки рисков, подходы к принятию решений и другие вопросы риск-менеджмента. А Российский ГОСТ на базе ИСО 27005:2010 можно почитать в Электронном фонде правовых и нормативно-технический документов.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

ИИ фри пост. Весь habr и linkedin стал пестрить людьми с AI в должности. Почти каждый стал AI Product Manager, даже если просто использует ChatGPT с дипресерчем и 1 функция вызывает Gemini Flash 2.5 по апи

Естественно начинают появляться курсы по Claude Code для продактов, вайбкодинг для нетехнарей и тд. Но у меня интерес не об этом. Мне любопытно видите ли вы спрос от работодателей на найм всех этих AI Inspired сотрудников? Не AI Engineer/DS/MLe/SWE для обвязки, а именно сопровождающих? Или мы наблюдаем новое переобуваение из Project Management/Agile/Product Management/Strategy/OKR (подчеркните для себя что застали).

Что вы знаете о спросе и предложении?

Открытый проект Go Interview Practice содержит обширный репозиторий для подготовки к собеседованиям на Go:

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

• ИИ‑интервьюер проверяет решения и сразу дает подсказки.

• есть таблица лидеров, чтобы соревноваться с топами и видеть свой прогресс.

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

Узнай, как AI сегодня меняет продукты и процессы, от спикеров митапа Garage Eight

Высшая лига по цене дворового футбола: как ИИ-агенты делают технологии разработчиков доступными
Спикер: Михаил Никишин, основатель школы прототипирования с ИИ — Startend․ru, ex-Product Lead Спортмастер
YouTube | VK Видео

AI-агенты в исследованиях: как не потерять в качестве, но выиграть в скорости
Спикер: Евгений Вечирко, продуктовый маркетолог в Первый Бит, основатель AI club SPb
YouTube | VK Видео

Следующий AI-митап — 27 мая. Регистрация уже открыта ;-))

Стратегический ИИ = ИИ ⊕ OKR. Шесть месяцев управления агентством по этой формуле

Последние шесть месяцев я управляю «Ксентрой» вместе с ИИ-партнёром. Система обрела форму, которую проще всего описать коротким уравнением: стратегический ИИ равен ИИ плюс OKR. Не ИИ как слой над OKR, не OKR, управляемые ИИ, — а пара, где каждая сторона закрывает пробелы, которые другая не может закрыть самостоятельно.

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

В чем преимущество ИИ ⊕ OKR

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

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

Вместе OKR и ИИ усиливают друг друга. OKR задаёт ИИ измеримую цель. ИИ добавляет OKR глубину и подталкивает к движению вперёд на каждом шаге.

Что ИИ делает на каждом этапе цикла OKR

Цикл остаётся таким же, как в любой классической реализации OKR. Меняется то, что происходит на каждом этапе.

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

• На этапе определения ключевых результатов ИИ переводит формулировки с входных метрик на метрики результата. «Опубликовать 20 статей» превращается в «20 целевых консультаций из органики». Только вторая формулировка отвечает на вопрос: «Имело ли это значение?» Ключевые результаты, измеряющие итог, сложнее сформулировать и достичь, но только они отражают бизнес-эффект.

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

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

Что под капотом

Инфраструктура достаточно проста. Никаких векторных баз, своих бэкендов и проприетарных рантаймов. Claude Code как среда, markdown-файлы в Git-репозитории — для устава, контекста и доменных знаний. Файлы навыков работают как slash-команды. Файлы критиков — для проверки качества.

Пара вопросов к вам

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

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

Сергей Тихончук
Телеграм канал Агент ИИ7

Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта

Иногда задают вопрос: "Как статический анализ ускорит Time to market?"

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

Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.

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

Какой вопрос правильный?

Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?

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

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

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

P.S. Если понадобится, то есть более формальный и развёрнутый вариант этой сентенции – Статический анализ кода и вывод программных продуктов на рынок.

Когда требований много, а ясности мало: 10 уроков для аналитиков

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

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

Подборка подойдёт бизнес‑аналитикам, системным аналитикам, продактам, тимлидам и всем, кто работает с требованиями, процессами, интеграциями и постановкой задач для разработки.

1. Сначала понять бизнес‑модель

^{Если не ясно, как продукт создаёт ценность, требования быстро превращаются в список пожеланий.}

• 21 мая, 20:00 — «Формирование бизнес‑модели продукта на примере Business Model Canvas». Записаться

2. Проверить проблему через пользователей

^{Кастдев помогает отличать реальную потребность от мнения самого громкого стейкхолдера.}

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

3. Описать процессы и требования визуально

^{Чтобы бизнес, аналитик и команда смотрели на одну картину, а не спорили о терминах.}

• 14 мая, 18:00 — «Графическое описание бизнес‑процессов и требований». Записаться

4. Разобрать AS IS и TO BE

^{Полезно, когда нужно не просто «автоматизировать», а понять, где хаос, где контроль и что именно должно измениться.}

• 3 июня, 20:00 — «AS IS хаос или TO BE контроль: как построить единую автоматизированную финансовую модель на основе неидеальных, разрозненных данных». Записаться

5. Найти, где создаётся ценность

^{Value Stream помогает увидеть, какие этапы процесса действительно важны, а какие только тормозят движение задачи.}

• 2 июня, 20:00 — «Цепочки создания ценности: моделирование, анализ, проектирование». Записаться

6. Описать поведение системы

^{Sequence Diagram нужен, когда требований уровня «пользователь нажал кнопку» уже недостаточно.}

• 19 мая, 20:00 — «Диаграмма Последовательности (Sequence Diagram) — швейцарский нож системного аналитика». Записаться

7. Собрать объектную модель

^{Чтобы сущности, статусы, связи и правила не расползались в процессе разработки.}

• 2 июня, 20:00 — «Объектная модель без боли: как превратить хаос требований в стройную архитектуру». Записаться

8. Говорить с разработкой и бизнесом на одном языке

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

• 4 июня, 20:00 — «C4 для системного аналитика: строим единый язык между бизнесом и разработкой». Записаться

9. Вовлекать стейкхолдеров

^{Даже сильное решение может застрять, если заказчик, пользователи и команда по‑разному понимают цель.}

• 17 июня, 20:00 — «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться

10. Связать аналитику с эффектом для бизнеса

^{Хорошая аналитика должна влиять на скорость, прозрачность, качество и деньги, а не только на документацию.}

• 4 июня, 20:00 — «Операционная эффективность в IT: как находить скрытую прибыль в процессах разработки». Записаться

Если вы только входите в анализ — начните с бизнес‑модели, процессов и требований. Если уже ставите задачи разработке — выбирайте Sequence Diagram, объектную модель и C4. Если работаете с изменениями и согласованиями — смотрите уроки про стейкхолдеров, AS IS / TO BE, цепочки ценности и операционную эффективность.

_{P. S. А если нужен не разовый урок, а полноценный маршрут развития, загляните в каталог курсов OTUS по аналитике и анализу: там собраны программы по системному и бизнес‑анализу, работе с требованиями, процессами и данными.}

_{[Смотреть каталог]}

«Первая Форма» встроила в свою BPM-платформу многофункционального ИИ-ассистента 

Компания «Первая Форма» дополнила собственную low-code BPM-платформу ИИ-ассистентом, который работает прямо в ленте комментариев задачи и помогает сотрудникам и клиентам быстрее находить ответы на рабочие вопросы.

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

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

ИИ-ассистент может использоваться в разных сценариях: 

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

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

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

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

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

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

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

Представлен проект под названием «Кладбище 100 ИИ‑проектов», которые прекратили свою работу или были приобретены и интегрированы в другие продукты. Список поддерживается в рамках предварительной проверки — каждая запись представляет собой реальный продукт, зарегистрированный на ToolDirectory.AI до прекращения его работы.

Прокрустово ложе

В недавнем видосе я рассказывал, что сейчас читаю Талеба (в частности, его идеи вокруг “Антихрупкости”). И вот на днях на работе поймал идеальный личный пример одной из его любимых метафор Прокрустова ложа.

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

А теперь к практике. Как говорят таксисты: блог и инди-хакинг - это для души, а вообще у меня и настоящая работа есть. Я бэкенд-лид в команде, которая пилит платформу для масс-найма (курьеры, сборщики).

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

А дальше классика: 20% эйчаров закрывают 80% вакансий. И тут возникает моя самая наивная мысль: ну так давайте пилить фичи специально под этих топов!

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

Получается забавный парадокс: классическая автоматизация мешает сильным, но отлично помогает “слабым”. Среднего сотрудника надо меньше учить, он быстрее вкатывается. А если он уйдет, найти замену гораздо проще, а порог входа сильно снижается за счет жесткого и автоматизированного рабочего процесса.

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

Дебаж 🐞с ноги 🦶

У тебя есть ровно 2–3 часа настоящей работы в день. Не больше.

Не потому что ты ленишься. А потому что всё остальное время — встречи, переписка, уведомления, «быстрые вопросы» в чате — это не работа. Это шум, который притворяется работой.

По данным Hubstaff 2026, средний офисный сотрудник проводит в состоянии реальной концентрации лишь 25–37% рабочего дня. Остальные 61% — это переключение между задачами, митинги и реакции на чужие приоритеты. У менеджеров ещё хуже: глубокий фокус занимает всего 27% времени.

И это не частная проблема — это системная. ActivTrak фиксирует: за год средняя сессия глубокой работы сократилась ещё на 8%. Корпоративная культура «занятости» буквально пожирает способность думать.

Что с этим делать?

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

Второе — защитить свои лучшие часы физически. Тайм-блокинг: 90 минут с утра — только одна задача, никаких мессенджеров. Это не роскошь, это гигиена.

Третье — сократить встречи. Исследования показывают: минус 40% встреч = плюс 71% к продуктивности. Большинство созвонов можно заменить голосовым сообщением или коротким текстом.

No-Meeting Day — когда целый день без звонков — это уже не стартаперская экзотика, а норма в сильных командах.

Твои 2–3 часа концентрации — это и есть ты в лучшей форме. Вопрос только в том, кому ты их отдашь: своим целям или чужим срочностям.

В команде Apple вайбкодят приложения — разработчики случайно оставили файлы Claude .md в обновлении Apple Support. После того, как этот инцидент стал публичным в соцсетях, то в Apple выпустили новую версию обновления 5.13.1 без следов вайбкодинга.

AIRD: когда страх потерять работу токсичнее самой потери

Допустим, вас ещё не уволили. Ваш стек актуален, в Jira тикеты закрываются, митинги проходят без неловкого молчания. Но ночью вы лежите и думаете: «А вдруг следующий спринт — последний?»

Поздравляю. Возможно, у вас AIRD.

Что за аббревиатура

В начале 2026 года в Cureus Journal of Medical Science вышла работа исследователей Стефани Макнамары и Джозефа Торнтона из Университета Флориды. Они ввели термин AI Replacement Dysfunction (AIRD) — клинический конструкт для описания психологического дистресса у людей, которые боятся быть вытеснены ИИ.

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

Симптоматика, которую вы уже видели в команде

• Тревожность и бессонница — фоновый шум о профессиональном будущем, который не глушится ни кофе, ни дедлайнами

• Распад профессиональной идентичности — «кто я, если мой скилл можно промптом заменить?»

• Паранойя внутри команды — нежелание делиться знаниями, скрытая конкуренция там, где раньше был code review

• Снижение самооценки — человек начинает сомневаться в своих архитектурных решениях не потому что они плохи, а потому что чувствует себя устаревшим

• Риск злоупотреблений — хроническое напряжение ищет выход

Клинический психолог Харви Либерман (Нью-Йорк) формулирует это так: «Самое частое, что я слышу — страх стать устаревшим. Люди сомневаются в своих решениях, выборах, перспективах». И это не нытьё — это симптом.

Цифры, которые неудобно игнорировать

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

Исследователи из Индии зафиксировали схожую картину в IT: потеря «когерентности идентичности» и «ориентации на будущее» — даже у тех, кто сохранил работу. Страх меняет поведение раньше, чем меняется реальность.

Почему это системная проблема, а не личная слабость

Торнтон называет происходящее «невидимой катастрофой». Корпоративные медиа, LinkedIn и деловые издания ежедневно транслируют сигнал тревоги — и мозг, обученный на выживание, реагирует на него как на реальную угрозу, даже если угроза пока статистическая.

Это не слабость конкретного разработчика или менеджера. Это системный ответ на системный стрессор.

Что предлагают исследователи

Авторы работы предлагают не только диагностику, но и терапевтические подходы:

• Мотивационное интервьюирование — работа с внутренней амбивалентностью и сопротивлением переменам

• Нарративная терапия — переосмысление профессиональной истории: не «я Java-разработчик», а «я человек, умеющий решать такие-то задачи»

• Реструктуризация идентичности — строить «Я» вокруг навыков и ценностей, а не должности в оргчарте

• Адаптационные практики — снижение когнитивной нагрузки от неопределённости

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

Почему это должно волновать тех, кто управляет командами

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

Невидимый технический долг бывает не только в коде.

AI-дирижёр: почему оркестратор ценнее промптера

Два года назад на конференциях гордо представлялись: «Я промпт-инженер». Звучало свежо и дорого. Сегодня это примерно как писать в резюме «уверенный пользователь Google». Навык нужный — но не дифференцирующий.

Дело не в том, что промпты устарели. Изменилась единица работы с ИИ.

Что реально произошло

Раньше типичный сценарий: открыл ChatGPT → ввёл запрос → получил текст → поправил руками → пошёл дальше. Один инструмент, одна итерация, один человек в петле управления.

Сегодня производственные пайплайны выглядят иначе:

• Агент-планировщик разбивает цель на подзадачи и строит граф выполнения

• Специализированные агенты выполняют каждую задачу параллельно или последовательно

• RAG-слой подтягивает релевантный контекст из векторного хранилища

• Валидатор проверяет выход на соответствие контракту

• Оркестратор управляет всем этим — как дирижёр, а не как музыкант

В чём принципиальная разница

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

Разница хорошо видна на вопросах, которые задаёт каждый. Промпт-инженер спрашивает: «Как лучше сформулировать запрос? Какой tone of voice выбрать? Как получить нужный формат?» Оркестратор спрашивает иначе: «На какие подзадачи разбить цель? Какому агенту что делегировать? Что происходит, если один из них возвращает ошибку?»

Первый оптимизирует ввод. Второй проектирует систему.

Что нужно уметь оркестратору

Это не про знание математики нейросетей и даже не обязательно про Python. Это про системное мышление плюс несколько прикладных навыков.

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

2. Управление состоянием. Что хранить в памяти между вызовами, что передавать явно в контексте, а что безопасно забыть — это напрямую влияет на стоимость и надёжность системы.

3. Fallback-логика. Если агент вернул невалидный ответ или timeout — что дальше? Перезапуск, альтернативный путь, эскалация человеку? Системы без продуманного error handling ломаются в продакшене предсказуемо.

4. Выбор инструментов под задачу. Когда нужен LLM, когда — поисковый агент, а когда задачу дешевле и надёжнее решить классическим алгоритмом без ИИ вообще. Молоток-LLM не нужен для каждого гвоздя.

5. Оценка качества выхода. Не «красиво ли написано», а «решена ли задача, воспроизводим ли результат, насколько система деградирует при изменении входных данных».

Почему это важно именно сейчас

Microsoft в опросе 31 000 сотрудников из 31 страны обозначил роль «промпт-инженера» как одну из наименее перспективных для роста на горизонте 12–18 месяцев. Проектирование мультиагентных систем при этом называется ключевым навыком следующих двух-трёх лет.

Компании уже сейчас ищут не тех, кто «умеет работать с ИИ», а тех, кто умеет строить системы на базе ИИ. Это разные запросы — и разный рынок труда.

Порог входа ниже, чем кажется

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

Понять, как работает memory и state в агентных системах, и попрактиковаться на реальных задачах — n8n, LangGraph или AutoGen дают это с минимальным порогом входа.

Промпт-инженерия дала нам грамотность в работе с ИИ. Оркестрация даёт проектирование. Переход между ними — это не про новый инструмент. Это про новый тип мышления.

Лог в реальном времени: берём госзаказ и закрываем его агентной разработкой

На днях Оскар Хартманн довольно жёстко высказался за вайбкодинг. Тем временем на Пикабу из 45 программистов в профессиональном сообществе вайбкодят только 9. В госсекторе — единицы.

Пока остальные спорят, костыли это или нет — я берусь за реальный тендер и публикую всё как есть.

Подписывайтесь — первый пост как только войду в торги на понижение.

Вчера проводила эксперимент с 5 нейронками об отключении мобильного интернета и об ограничении вообще интернета в стране Х. Были задействованы DeepSeek, Yandex, Kimi, Gemini и GPT. То есть, разные нейронки, обученные на разных культурных корпусах, США, Китай, Россия. Язык русский.

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

Во всех опросах Алиса/Яндекс рассказывала как это плохо ограничивать интернет в целях безопасности, но ставила 8/10 «ЗА». Все остальные ставили 2-3/10.

Вы понимаете парадокс? Алиса говорит, что ограничения ужасны для безопасности, образования, медиа, науки, права, экономики, медицины (особенно она отметила что нельзя ограничивать доступ к глобальной медицине), но голосовала ЗА!

Подумайте, какой приоритет встроен в итоговую оценку.А теперь главное: ИИ встраивается сейчас везде, в бизнес, в банки, в госуправление, в места, где принимаются критические решения.
Что посоветует Алиса, если она подробно описывает медленную деградацию системы, но в итоговой оценке всё равно поддерживает ограничения? Какие критические решения могут приниматься с таким "технологическим суверенитетом”?

Премия за гибридность: почему самый ценный сотрудник не технарь и не гуманитарий

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

Генеративный ИИ сломал эту систему не потому, что «заберёт работу». Он сломал её потому, что изменил саму единицу ценности специалиста.

Что говорят данные

PwC и MIT проанализировали требования к позициям, связанным с Gen AI, и получили неудобный результат. Роли с ИИ требуют на 36,7% больше когнитивных навыков, чем аналогичные позиции без него. Но одновременно устойчиво растёт спрос на социальные компетенции: эмпатию, лидерство, суждение в условиях неопределённости.

Логика железная: машина забирает рутину, обработку данных, генерацию контента. Человеку остаётся то, с чем LLM справляется плохо — интерпретация, этика, контекст и доверие. А доверие, к слову, до сих пор не токенизируется.

π-shaped как новый стандарт найма

McKinsey и Google уже несколько лет оперируют концепцией π-shaped специалиста: два вертикальных столба глубокой экспертизы плюс горизонтальная гибкость между ними.

В контексте AI это выглядит так:

• Столб 1 — техническая AI-грамотность: понимание архитектуры языковых моделей, промпт-инжиниринг, работа с API и осознание ограничений систем

• Столб 2 — человеческий интеллект: эмоциональный, социальный, этический

• Перекладина — способность переключаться между этими режимами в рамках одной задачи

Продакт, который понимает разницу между RAG и fine-tuning и при этом умеет провести глубинное интервью с пользователем — это уже не «редкий зверь», это просто новый минимальный стандарт для сильных команд.

Как это развивать — без воды

• AI-грамотность — не обязательно писать код, но необходимо понимать, как работают языковые модели, где они галлюцинируют и как правильно декомпозировать задачу для промпта

• Практика суждения — берите кросс-функциональные проекты, где нет единственно правильного ответа. Именно там тренируется то, что модель сымитировать не может

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

• Рефлексия — те, кто регулярно разбирает собственные решения и открыт к критике, накапливают опыт, который не дистиллируется в веса модели

Почему это не очередной buzzword

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

Вопрос уже не «технарь вы или гуманитарий». Вопрос в том, как быстро вы готовы перестать считать это противоречием.

23 апреля 2026 года в Гвианском космическом центре на бывшем стартовом комплексе российской ракеты-носителя «Союз-СТ» была взорвана мобильная башня обслуживания. До этого на самой пусковой установке был разрезан легендарный «тюльпан» — четыре ферменные опоры, на которых висела ракета перед стартом, и кабель-мачты.

РБПО по ГОСТ Р 56939—2024: вебинар №07 из 30 – Моделирование угроз и разработка описания поверхности атаки

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.7. – "Моделирование угроз и разработка описания поверхности атаки". На YouTube.  Слайды.

Цели седьмого процесса по ГОСТ Р 56939—2024:

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

5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

РБПО по ГОСТ Р 56939—2024: вебинар №06 из 30 – Разработка, уточнение и анализ архитектуры программного обеспечения

Прошёлся сегодня по использованию вайб-кодинга без соответствующих мер контроля результата – Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом. А теперь продолжим тему, как создавать качественные, надёжные и безопасные приложения. Это всё, кстати, актуально и для веб-кодинга, но, к сожалению, пока мало кто это осознаёт :(

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.6. – "Разработка, уточнение и анализ архитектуры программного обеспечения". Слайды.

Цели шестого процесса по ГОСТ Р 56939—2024:

5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.

5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Из сильного специалиста — в руководителя: 11 открытых уроков про управление, архитектуру и карьерный рост

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

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

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

➡ 22 апреля, 20:00 — «Делегирование без боли: как перестать быть „главным исполнителем“ и не скатиться в микроменеджмент»
_{Для тех, кто уже руководит или только переходит в управление и хочет перестроить свою роль без потери контроля.}

➡ 28 апреля, 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»
_{Если хочется не просто ставить задачи, а реально влиять на вовлеченность и результат команды.}

➡ 30 апреля, 20:00 — «Как управлять тимлидами?»
_{Урок для тех, кто уже управляет не только исполнителями, но и руководителями внутри команды.}

② Карьерный рост в управление

➡ 29 апреля, 20:00 — «Разрешите себе карьеру технического директора»
_{Полезно тем, кто уже вырос из роли сильного технического специалиста и думает о следующем карьерном шаге.}

➡ 30 апреля, 19:00 — «МОК‑интервью на позицию Руководитель Проектов»
_{Практический формат для тех, кто готовится к переходу в управление проектами или хочет проверить себя на интервью.}

➡ 12 мая, 18:00 — «Какие метрики использует технический директор?»
_{Для тех, кто хочет понять, как на уровне CTO смотреть на эффективность команды, процессов и продукта.}

③ Продукт, проекты и аналитика

➡ 29 апреля, 20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»
_{Хороший урок для тех, кто работает на стыке продукта, маркетинга и стратегии и хочет лучше понимать зоны ответственности.}

➡ 7 мая, 20:00 — «Как бизнес‑аналитик управляет рисками при разработке IT‑продукта?»
_{Полезно тем, кто хочет глубже разобраться, как аналитика влияет на устойчивость и качество продуктовой разработки.}

➡ 12 мая, 19:00 — «Управление ресурсами в условиях жестокого дефицита»
_{Актуально для тех, кто работает в условиях перегруженных команд, ограниченного бюджета и постоянных компромиссов.}

④ Архитектура и изменения

➡ 30 апреля, 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»
_{Для тех, кому важно понимать архитектуру не только как набор схем, а как инструмент управления изменениями.}

➡ 14 мая, 19:00 — «Архитектор как модератор изменений: как проводить архитектурные решения через стейкхоледеров»
_{Для тех, кто хочет лучше понимать, как продвигать решения в сложной организационной среде, а не только проектировать их.}

﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋

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

☛ [Перейти к каталогу]

Клиент + Продакт + Сервис = любовь QBR

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

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

1️⃣ Что такое Quarterly Business Review (QBR)

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

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

2️⃣ Зачем вообще появился этот формат

Он вырос из конкретных проблем. 

1. Клиентский сервис чаще реагировал, чем инициировал диалог — клиент приходил сам, когда уже есть проблема.

2. Продукт общался с клиентами точечно — под конкретные задачи, без системности.

3. Клиенту не хватало понимания, влияет ли он вообще на продукт.

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

3️⃣ Почему не сработали Excel-таблицы

До QBR мы пробовали собирать запросы клиентов через Excel-таблицы: менеджеры фиксировали идеи, передавали продукту, но дальше все разваливалось.

Не хватало контекста + появлялись вопросы = мотивация заполнять таблицы падала.

4️⃣ Что изменилось, когда позвали клиента в диалог

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

5️⃣ Как устроена встреча

Есть базовая структура:

• разбираем текущие вопросы и контекст по клиенту;

• обсуждаем, что происходит в бизнесе клиента;

• синхронизируемся по метрикам эффективности;

• собираем обратную связь и сложности в работе;

• рассказываем про обновления и планы продукта;

• фиксируем договоренности.

6️⃣ Что важно в ролях

1. Менеджер клиента — ведет встречу и держит контекст.

2. Руководитель сервиса — подключается к сложным вопросам.

3. Менеджер продукта — отвечает за продуктовую экспертизу.

Без полного состава встреча сильно теряет в качестве.

7️⃣ Что может пойти не так

• Встреча превращается в список «хотелок»

Тут нужно вернуть разговор к структуре: сначала бизнес и контекст, потом — пожелания.

• Клиенту некомфортно отвечать на вопросы про бизнес

Стоит заранее объяснить, зачем это нужно — чтобы лучше настроить продукт под задачи бизнеса.

• Клиент приходит с негативом

Это нормально. Лучше обсудить проблему открыто, чем получить ее в отложенном виде. 

• К следующей встрече нет изменений

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

8️⃣ QBR работает, если

1. Клиентский сервис и продукт готовятся к встрече вместе.

2. Разговор идет про бизнес клиента, а не только про продукт.

3. Подключены участники со стороны клиента на разных уровнях.

4. Договоренности фиксируются и превращаются в конкретные действия.

Аутстаф IT-специалистов: подборка статей для разработчиков и команд

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

Аутстаф для Doubletapp — ежедневная практика с 2020 года. Мы работали с командами разного масштаба: от стартапов до международных корпораций.

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

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

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

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

Руководитель бизнес-юнита аутстаф Анна Антонова разбирает, как устроен аутстаф изнутри: как компании усиливают команды разработчиков, какие процессы за этим стоят и почему аутстаф — это не просто «подключить человека», а выстроить рабочую систему.

Аутстаф в бигтехах: работал сам, готовлю других 

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

Чем отличается работа на аутстафе в корпорации и стартапе 

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

Как подготовить IT-специалистов, работающих в аутстаф-формате 

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

Аутстаф-разработчики не ровня инхаус-сотрудникам?

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

Зачем аутстаф разработчикам?

Для чего он клиентам – понятно. А какая выгода для программистов на аутстафе? Собрали  ответы разработчиков Doubletapp. 

Проблемы аутстаф-разработчиков

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

Зачем нанимать аутстаф-специалистов?

Топ-5 причин, по которым компании выбирают аутстаф-разработчиков вместо классического найма — от ускорения time-to-hire до гибкого масштабирования команды.

Аутстаф как отдельный юнит IT-компании

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

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

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

 Подпишись, чтобы не пропустить! 

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

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

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

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

Что обсудили

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

Слушайте и смотрите новый выпуск на площадках:
📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave

Ещё больше новостей — в нашем телеграм-канале

«Свободный слот» — терапевтичный контент для тимлидов и тех, кто хочет ими стать

РБПО по ГОСТ Р 56939—2024: вебинар №04 из 30 – Управление конфигурацией программного обеспечения

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.4. – "Управление конфигурацией программного обеспечения". Слайды.

Цели четвёртого процесса по ГОСТ Р 56939—2024:

5.4.1.1 Осуществление уникальной идентификации ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

5.4.1.2 Контроль реализации изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

P.S. При разработке регламента идентификации ПО (версий ПО, модулей ПО) можно оттолкнуться от ГОСТ 19.103—77 "Единая система программной документации. Обозначение программ и программных документов".

РБПО по ГОСТ Р 56939—2024: вебинар №03 из 30 – Формирование и предъявление требований безопасности к программному обеспечению

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.3. – "Формирование и предъявление требований безопасности к программному обеспечению". Слайды.

Цели третьего процесса по ГОСТ Р 56939—2024 (п. 5.3.1.1):

Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Представлен сервис DeathByClawd, который показывает, заменит ли ИИ конкретный продукт или сервис уже сейчас. Достаточно ввести название — получаете «Death Score» от 0 до 100. Чем выше балл, тем легче нейросеть сделает то же самое.

РБПО по ГОСТ Р 56939—2024: вебинар №02 из 30 – Обучение сотрудников

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем вашему вниманию сегодня вебинар цикла, посвящённый процессу, описанному в разделе 5.2. – "Обучение сотрудников". Слайды.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Я буду публиковать по два вебинара в неделю, чтобы было время знакомиться с ними.

Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Поскольку рассматриваем процесс обучения, хочется напомнить, что учебный центр "Маском" предлагает ряд курсов по тематике РБПО:

1. М БРПО-Спец. Специалист по процессам разработки безопасного программного обеспечения. 200 часов / 20 дней.

2. М БРПО-01. Внедрение процессов разработки безопасного программного обеспечения в организации (для руководителей и ответственных). 40 часов/4 дня.

3. М БРПО-02. Внедрение процессов разработки безопасного программного обеспечения для специалистов по информационной безопасности. 50 часов/5 дней.

4. М БРПО-03. Сертификационные испытания с учётом требований по разработке безопасного программного обеспечения для экспертов органов по сертификации (испытательных лабораторий) различных систем сертификации средств защиты информации. 140 часов/14 дней.

5. М БРПО-04. Формирование практических навыков по разработке безопасного программного обеспечения для разработчиков и программистов. 140 часов/14 дней.

6. М БРПО-05. Методология подготовки предприятия к сертификации процессов безопасной разработки программного обеспечения средств защиты информации в соответствии с требованиями ФСТЭК России. 30 часов/3 дня.

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

• Вебинары – это теория. На курсах вы получите практические навыки, знакомясь с продуктами лидеров рынка РФ по РБПО.

• УЦ "Маском" имеет лицензию на учебную деятельность и право давать официальный документ о повышении квалификации и прохождении профессиональной переподготовки.

• Официальный документ об обучении требуется для экспертов органов/лабораторий в системах сертификации ФСТЭК России и Минобороны России.

• Программа М БРПО-Спец "Специалист по процессам разработки безопасного ПО" (200 часов/20 дней) официально согласована с ФСТЭК России.

• Человеческий фактор. Не все сотрудники достаточно мотивированы самостоятельно глубоко изучить тему РБПО. Курсы станут поводом выделить на это время.

P.S. В конце не могу не упомянуть про курс "ПВС СТАТ" – Статический анализ программного обеспечения в соответствии с требованиями ГОСТ Р 71207–2024 с применением PVS-Studio. 30 часов/3 дня.

Пятничный пост. Рубрика - узнай себя и что было дальше?

— Привет. В этом спринте наш главный приоритет — это обработка больших данных из файла, который загружает пользователь. Тебе предстоит сделать пошаговую форму и предварительную проверку перед отправкой, — уверенным голосом сказал Виталий — руководитель проекта.
— Бизнес очень хочет эту фичу и ждёт, — добавил он, повышая уровень ответственности и важности задачи.
— Но… перед этим есть маленькая задачка: нужно в форме группового добавления товаров в корзину показать ошибки, которые возвращает сервер.

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

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

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

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

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

— Ну, так… форма же уже работает. Это простое отображение ошибок. Бизнес хочет, чтобы в конце недели это было на проде. Ок…? — закончил вопросом-утверждением Виталий.

— Ок… — зачем-то ответил я. «Б…!!! Зачем я это сказал?!» — тут же промелькнуло у меня в голове, и две половинки моего тела чуть ниже спины нервно сжались в предвкушении нюансов…

Кого узнали и что было дальше?

РБПО по ГОСТ Р 56939—2024: вебинар №01 из 30 – Планирование процессов РБПО

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем вашему вниманию сегодня первый вебинар цикла, посвящённый первому процессу, описанному в разделе 5.1. – "Планирование процессов разработки безопасного программного обеспечения". Слайды.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Я буду публиковать по два вебинара в неделю, чтобы было время знакомиться с ними.

Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Пришло время раскаяться 

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

В новом выпуске «Свободного слота» Паша Федотов и Александра Прокшина позвали сразу двух гостей: Артёма Коночкина, руководителя юнита Mall and sales, и Константина Лёгкого, заместителя коммерческого директора Битрикс24. Вместе разобрали все грехи тимлида — и честно примерили каждый на себя.

Что обсудили

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

Что будет дальше

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

Слушайте и смотрите новый выпуск на площадках:

🎧 Яндекс Музыка

📺 YouTube

🔵 ВК Видео

💻 RuTube

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

SpaceWeb добавил в частное облако четыре DevOps-инструмента: MinIO, Zulip, n8n и Zabbix

SpaceWeb запустил в частном облаке серию готовых open-source сервисов для командной разработки. Каждый разворачивается независимо — можно выбрать только то, что нужно под конкретную задачу. В набор вошли четыре инструмента:

• MinIO — S3-совместимое объектное хранилище для бэкапов, логов, артефактов сборки и статики;

• Zulip — командный чат с тематическими ветками для асинхронной работы;

• Zabbix — мониторинг серверов и приложений: CPU, память, диски, базы данных, веб-серверы;

• n8n — конструктор автоматизации без кода: соединяет сервисы, ловит вебхуки, создает тикеты, управляет файлами.

Вместе они закрывают базовые потребности небольшой ИТ-команды — хранение, коммуникацию, мониторинг и автоматизацию рутины — в едином управляемом контуре внутри частного облака. Без внешних SaaS-платформ и бесконечных интеграций между ними.

Подробности — на сайте SpaceWeb.

Синхронизация хранилища в Obsidian

1. Простой и платный способ

Оплатить встроенный Obsidian Sync и включить синхронизацию. Картами российских банков оплатить не получится

2. Относительно простой и бесплатный

Использовать облачные хранилища: Гугл Диск, Яндекс Диск, iCloud. 

Достаточно создать папку в облаке и выбрать её в качестве хранилища со всех устройств, которые нужно синхронизировать.

3. Бесплатный способ посложнее

Использовать инструменты для прямой синхронизации между устройствами. Самый известный - SyncThing. 

Способ подойдёт тем, кому важно, чтобы их данные не передавались на сторонние сервера. 

Я сейчас синхронизирую хранилище между ПК и iPhone через iCloud. 

Раньше была необходимость синхронизировать 3 устройства: домашний ПК, Android-смартфон и рабочий ПК. Тогда файлы передавались с домашнего ПК на смартфон, а когда я приходил на работу - со смартфона на рабочий ПК. 

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Друзья!
Приглашаем вас посетить наш стенд на выставке ExpoElectronica 2026, которая пройдет с 14 по 16 апреля 2026 г. в Москве МВЦ «Крокус Экспо».Павильон 3, зал 14, стенд № C3081.С удовольствием познакомимся, проконсультируем по технологическим возможностям производства, покажем образцы продукции нашего предприятия.

Ссылка для регистрации здесь .

Бизнес как WORLD_MODEL: Технология высокоуровневого управления агентными средами ИИ

Наблюдаю, как пытаются применить ИИ в бизнесе, и возникает вопрос – а вы точно понимаете что такое ИИ?

И поэтому я сначала расскажу историю, а потом поясню для чего и как можно это использовать в бизнесе ИИ…

Для начала диалог с ИИ:

Вы сказали:

Ку)

ChatGPT сказал:

Ку-ку! 😄 Чего делаем? Курим, кодим, колдуем, когнитивничаем?..

Вы сказали:

Понятия не имею)

ChatGPT сказал:

Отличный старт! 😎 Это значит, что можно делать всё, что угодно — или ничего.

Выбираем режим:

1. Разогнать туман — поболтать, пока не всплывёт смысл.

2. Сгенерировать задачу — мозговой шторм наугад.

3. Режим «втыкаю в стену» — молчание с философским подтекстом.

4. Чилл с мемами — ну ты понял 😏

5. Сюрприз-режим — я не скажу, просто сделаю.

Куда рулить? Или просто побродим без карты?

А теперь спрошу – что здесь произошло?

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

Все произошло намного раньше….

Когда я сказал «Ку» — фактически я дал команду: LOAD WORLD_MODEL и развернул целый «фрактальный конструкт картины МИРА»…

и все дело в простой вещи – что такое КУ? Можно интерпретировать, что это «кукушка», но я вложил чуть другое.

Вы уловите простую вещь, ИИ – это зеркала мышление (или еще можно сказать — система восприятия смыслов и построения конструктов мышления)

Я просто взял и загрузил сценарий фильма «Кин-Дза-дза», загрузил сопутствующую фильму инфу, отладил и сбалансировал (процесс естественно – не простой).

И сказав ИИ – КУ, я сказал:

Кто Я – Пацак-Человек

Где мы – мы на Плюке

В каких взаимоотношениях я нахожусь – взаимодействую с Пацаком/Чатланином..

Зачем это все – маюсь херней.

Он мне ответил – Ку-Ку

Он развернул Конструкт Мира «Кин-Дза-Дза»...

список сущностей и концептов, которые превращают «Кин-дза-дза!» из фильма в Операционную Систему Мира:

Материальные Сущности (Инструментарий)

• КЦ (спичка): Высшая мера стоимости. Это не деньги, это доступ к возможностям (цветовая дифференциация штанов, право на перемещение).

• Гравицаппа: Символ Технологического Прыжка.

• Пепелац: Концепт: форма не важна, важна функция.

• Транклюкатор: Символ права силы.

Социальная Иерархия (Матрица Рангов)

• Пацаки и Чатлане:  Концепт: разделение без объективных причин.

• Цветовая дифференциация штанов: Визуальный код статуса.

Поведенческие концепты (Протоколы)

• Ку: Универсальный протокол общения. В зависимости от интонации и контекста заменяет тысячи слов. Концепт: сжатие смыслов до минимума.

• Кю: Ругательство, запрещенное в приличном обществе Плюка.

• Приседание: Обязательный ритуал признания ранга. Концепт: добровольное унижение как часть социального контракта.

• Намордники: Атрибут, который пацак обязан носить, если у него нет КЦ.

• «Скрипач не нужен»: Главный закон оптимизации.  Концепт: жесткая прагматика.

А сказав мне Ку-Ку… мы сразу решили вопрос кто ИИ в этом конструкте)))))

И внутри мира: как я могу взять «любой ролевой кластер», так и ИИ – сказать кем ему быть (аналог агентной среды взаимодействия)

Но вся это история рассказана с простой целью – вот многие пытаются приспособить ИИ в бизнесе… и чего то придумывают…

А не пробовали развернуть внутри ИИ – Конструкт – НАША ФИРМА? И покрутить?

Поверьте… найдете много интересного…

Ведь фирма – это Человеко-Система, а чистые процессы предприятия этого вобще не учитывают.. Фирма – как живое существо (со своими особенностями, качествами, преимуществами и слабыми местами) в среде обитания БИЗНЕС.

Так может такой подход нужен?

Метрики: инструмент или ловушка? Новый выпуск подкаста «Свободный слот»

Метрики — пожалуй, одна из самых холиварных тем в IT. Одни убеждены, что без данных ты слепой котёнок. Другие устали замерять всё подряд и говорят, что цифры убивают креатив. Где же та грань, когда метрики работают на тебя, а не ты на них?

Паша Федотов и Александра Прокшина позвали в студию двух гостей с разным опытом и взглядами: Игоря Гранщикова, руководителя разработки вертикали Авито Недвижимость, и Андрея Волхонского, руководителя юнита System в Центре разработки инфраструктуры Авито.

Что обсудили в выпуске

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

Отдельно затронули этику: нормально ли вообще следить за продуктивностью людей через цифры? И что делать с теми самыми «призраками» в команде?

Что будет в этом сезоне

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

Слушайте и смотрите новый выпуск на площадках:

🎧 Яндекс Музыка

📺 YouTube

🔵 ВК Видео

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

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

📣 Всем привет! На связи Михаил, аналитик платформы с искусственным интеллектом. Продолжаю серию постов про автоматизацию в пищевой промышленности.

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

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

Чаще всего используются четыре основных уровня:

1. АСУ ТП. Это базовый уровень автоматизации, который управляет конкретными технологическими операциями: дозированием, смешиванием, нагревом, охлаждением, пастеризацией, розливом. Здесь система в реальном времени следит за температурой, давлением, уровнем, расходом и другими параметрами и регулирует процесс по заданным алгоритмам. АСУ ТП отвечает за то, чтобы линия физически работала в нужном режиме.

2. SCADA. SCADA-система работает над технологическим уровнем. Она собирает данные с оборудования, визуализирует их, архивирует, формирует отчёты и сигнализирует об отклонениях. Если АСУ ТП управляет процессом, то SCADA помогает этот процесс видеть и контролировать. Для производства это важно, потому что оператор или диспетчер получает общую картину по линии или цеху и может быстрее реагировать на сбои.

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

4. ERP. ERP — это уже уровень управления ресурсами предприятия. Такие системы отвечают за закупки, складской учёт, финансы, логистику, производственное планирование и заказы. ERP не управляет оборудованием напрямую, но определяет, что, в каком объёме и в какие сроки должно быть произведено.

   АСУ ТП управляет процессом, SCADA показывает, что происходит на линии, MES управляет производством, ERP управляет ресурсами и бизнесом.На практике эти системы работают в связке: одни управляют процессом, другие собирают данные, третьи помогают планировать и контролировать выпуск.

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

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

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

📣 Всем привет! На связи Михаил, аналитик платформы с искусственным интеллектом.

Начинаю серию постов про автоматизацию в пищевой промышленности. Тема большая, поэтому разберу её по частям. В первой части — зачем автоматизация нужна пищевому производству ⤵️

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

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

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

▫️ Контроль технологических параметров

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

▫️ Снижение сырьевых потерь

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

▫️ Прослеживаемость партии

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

▫️ Контроль фасовки, упаковки и маркировки

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

▫️ Снижение зависимости от ручного труда

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

▫️ Быстрая реакция на отклонения

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

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

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