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

Делаем проактивного AI-агента.
Часть 3 — настраиваем OpenClaw, чтобы был полезным

«Вы не поднимаетесь до уровня своих целей. Вы падаете до уровня своих систем»

Это третья часть серии (первая — в чем идея, вторая — агент с нуля)

Теперь поговорим про OpenClaw — самый популярный на сегодня фреймворк для персональных AI-агентов

Архитектура моего OpenClaw

Агент живёт на сервере Railway, общается со мной через Telegram и Discord, работает через подписку Claude с Codex на подстраховке. Его поведение целиком определяется набором markdown-файлов — там и «SOUL», и память, и операционные инструкции.

Вот из чего состоит workspace моего агента

• SOUL.md — кто агент. Характер, стиль, границы. Его «душа».

• USER.md — кто я. Контекст, цели, паттерны, как со мной работать.

• AGENTS.md — правила поведения. Safety, тиеры действий, память, heartbeat, группы.

• MEMORY.md — долгосрочная память, кураторские заметки.

• HEARTBEAT.md — чеклист периодических проверок (календарь, почта, задачи).

• TOOLS.md — локальные заметки по инструментам.

Плюс memory/YYYY-MM-DD.md — ежедневные заметки, из которых потом дистиллируется MEMORY.md.

И skills/ — папка со скиллами (finances, ticktick, gmail, google-calendar и т.д.), каждый со своим SKILL.md.

По сути: SOUL + USER + AGENTS — это характер и инструкция, MEMORY — опыт, skills — его навыки.

Из коробки агент работает, но бесполезен без кастомизации. Ниже — проблемы, на которые я убил неделю, и их решения

⚡Проблема 1: Повышенная проактивность

По стандарту системные промпты OpenClaw звучат примерно так:

Don't ask permission. Just do it.

Это делает агента слишком самостоятельным — он может сломать себя без предупреждения.

Решение: я добавил несколько ограничений. Все важные изменения идут через localhost => GitHub, а не через его прод. На попытки изменить системные файлы агент теперь отвечает:

«Нет, это конфиг — мне запрещено его трогать. Если я накосячу с конфигом на Railway, всё упадёт в crash loop и только ты сможешь починить.»

Стандартная проблема без этого: агент что-то у себя меняет, и либо я этого не замечаю, либо он просто умирает, сломав что-то важное

⚡Проблема 2: Память — не только его храм, но и помойка

Механизм памяти в OpenClaw:

• MEMORY.md — долгосрочная память.

• memory/YYYY-MM-DD.md — ежедневные заметки.

• Встроенный хук session-memory — при завершении каждой сессии фреймворк автоматически сохраняет сырой лог разговора в memory/.

Проблема: если часто жать /new, за короткое время накапливается огромное количество raw JSON файлов, которые сыпятся в контекст при старте каждой сессии. Мои MD-файлы состояли из 299 строк, из которых полезных фактов — 5. Всё остальное — мусор метаданных. Дистиллированная версия уместилась бы в 10–15 строк.

При этом долгосрочная MEMORY.md — почти пустая. Инструкция «periodically review and update» была слишком размытой и ни разу не сработала.

Решение: явные правила дистилляции и регулярный перенос из дневных заметок в MEMORY.md с очисткой сырых логов

⚡Проблема 3: USER.md — главный файл, и он требует постоянного внимания

USER.md — это файл о вас. Чем лучше он описан, тем лучше агент работает. Моя структура:

• Basics — имя, возраст, таймзона, локация, язык

• Who — тип личности, суперсила, мотивация

• Background — опыт и ключевые достижения

• Values — что важно в жизни

• Current focus — чем занят сейчас (продукты, статусы)

• Finances — доход, расходы, цель

• Platforms — соцсети и каналы

• People — ключевые люди вокруг

• Schedule — режим дня

• Work style — как работает, что драйвит

• Patterns — слепые зоны и паттерны поведения

• Goals — текущие цели и метрики

• How Claw should interact — правила общения

Главный вывод 3 части

Workspace-файлы агента — это не «написал и забыл». Они дрифтуют, конфликтуют и устаревают точно так же, как код.

USER.md — особенно. Я и контекст вокруг меня меняются быстрее, чем я вспоминаю обновлять описание. Поэтому нужна периодическая ревизия — точно такая же, как ревизия кода.

Если кратко: персональный AI-агент — это не продукт, а процесс. Фреймворк даёт скелет, но без недели (минимум) кастомизации под себя он останется бесполезной игрушкой

Представлен проект DigitalDefynd — большая база IT‑курсов от лучших университетов мира. Материал на ресурсе обновлён на 2026 год. Там актуализировали курсы и оставили только те навыки, которые пригодятся при устройстве на работу и росте по карьерной лестнице. Есть сотни воркшопов, в том числе от Google и IBM. Большая часть курсов с лицензированными сертификатами и дипломами, которые можно положить в портфолио.

Хотите выяснить, где учиться IT? В экосистеме Хабра есть маркетплейс курсов на Хабр Карьере, на котором собраны сотни онлайн-обучений в самых разных специализациях: программировании, аналитике, дизайне, менеджменте и других. Чтобы пользователи могли проверить качество курсов, там показаны отзывы от тех, кто уже прошел обучение — изучайте и выбирайте лучшее для себя.

Genspark AI Workspace 3.0: агент Claw

1. Genspark Claw + облачный компьютер

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

Принцип изоляции: ваши данные живут только в вашем инстансе, не смешиваясь с чужими. Вы сами настраиваете, к чему агент имеет доступ. Под капотом — Claude Opus 4.6, GPT-5.4 и NVIDIA Nemotron 3 Super на инфраструктуре Azure.

Управление — через мессенджеры: написали задачу в WhatsApp или Telegram, агент выполнил и вернул результат. Поддерживаются Teams и Slack.

2. Genspark Workflows

Автоматизация повторяющихся задач в ~20 приложениях: Google Workspace, Outlook, Slack, Teams, Notion, Salesforce, X. Есть готовые шаблоны, есть возможность собрать свой сценарий. Логика простая: подключил инструменты, описал рутину — Claw выполняет её без участия человека.

3. Genspark Teams

Встроенный мессенджер внутри платформы — прямые сообщения, групповые чаты, поиск участников на уровне организации. Бесплатно. Это прямой выпад в сторону Slack: если агент уже живёт в Genspark, зачем переключаться в другое приложение для общения с командой?

4. Meeting Bots

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

Speakly для iOS и Android

Голосовой ввод с AI-редактированием. Работает поверх любых приложений — диктуете, Speakly вставляет готовый текст куда нужно.

Chrome Extension

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

Коротко про OpenClaw и почему сравнение уместно

Совпадение в названии не случайно — в день релиза SiliconAngle прямо написал, что Genspark Claw создавался как корпоративная альтернатива OpenClaw. Для тех, кто не следил: OpenClaw — open-source агент австрийского разработчика, набравший 247K звёзд на GitHub за два месяца. Работает локально, бесплатно, но требует технической грамотности для настройки. Исследователи нашли в нём 40К+ уязвимостей, после чего Китай запретил его в госструктурах.

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

Честно о том, чего я не знаю

Я не тестировал Genspark Claw — продукт вышел 12 марта, публичного доступа с прозрачным ценником пока нет. Неизвестно, как агент ведёт себя на длинных многошаговых задачах, насколько реально работает изоляция данных и во сколько это обойдётся обычной команде из 5–10 человек.

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

Итог

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

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

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

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

• 12 марта 19:00
  Лайфхаки трудоустройства продакт-менеджера
  ^{Открытый вебинар курса «Продуктовый менеджер ИТ-проектов»}

• 12 марта 20:00
  Командные конфликты – кто виноват и что делать?
  ^{Открытый вебинар курса «Руководитель DevOps»}

• 18 марта 20:00
  Сообщество как инструмент устойчивости бизнеса: создаем, развиваем и масштабируем
  ^{Открытый вебинар курса «DevRel (работа с сообществом разработчиков)»}

• 18 марта 20:00
  CTO (технический директор) как система: люди, процессы и ИТ для управления бизнесом
  ^{Открытый вебинар курса «CTO / Технический директор»}

• 18 марта 20:00
  Как построить аналитическую функцию в компании
  ^{Открытый вебинар курса «Data-driven (управление на основе данных)»}

• 19 марта 19:00
  Метрики удержания клиентов: Product Market Fit и Retention (соответствие продукта рынку и удержание пользователей)
  ^{Открытый вебинар курса «Продуктовый менеджер ИТ-проектов»}

• 23 марта 20:00
  Джедай или Ситх? Собираем идеального руководителя DevOps
  ^{Открытый вебинар курса «Руководитель DevOps»}

• 24 марта 20:00
  Как остаться умнее искусственного интеллекта в 2026 году?
  ^{Открытый вебинар курса «ИИ для решения рабочих задач»}

• 26 марта 20:00
  Метамодель TOGAF и модель организации
  ^{Открытый вебинар курса «Архитектура корпорации. Togaf 10»}

• 31 марта 20:00
  Этапы и артефакты 1С-проектов 2026: ИИ-интеграции и гибкая разработка
  ^{Открытый вебинар курса «Архитектор 1С»}

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

СЕО Stripe Патрик Коллисон в подкасте TBPN рассказал, что программное обеспечение вообще‑то не должно производиться «впрок» и продаваться бесконечно. По его мнению, его стоит создавать по запросу — прямо в момент использования.

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

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

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

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

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

Ранее AWS (облачное подразделение Amazon) в декабре 2025 года столкнулось с отключением инструмента для расчёта стоимости облачных услуг на 13 часов из-за того, что внутренний фирменный ИИ-ассистент Kiro самостоятельно решил «удалить и пересоздать рабочую среду».

Мое наблюдение:

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

Примеры таких правил и просьб:

• Не опаздывайте на совещания

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

• Приходите с решениями, а не проблемами

• Критикуешь - предлагай

• У любого проекта должен быть один ответственный

• Все задачи должны иметь точный дедлайн

• и еще пара десятков в таком же духе...

Парадокс:
Эти правила не глупые... Глупо то, что их приходится повторять взрослым людям с должностями и нехилыми зарплатами.

Разработка: Оркестровка агентов по ролевым кластерам (MSF)

Современная разработка всё чаще превращается в ансамбль агентов. ИИ‑системы становятся не просто инструментами, а полноценными участниками команд. Но как их организовать, чтобы они не превратились в хаотичный «зоопарк»?

Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.

🧩 Смешанная модель

• Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.

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

• Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.

🎭 Пример

• Архитектор‑человек задаёт CASE‑скелет.

• Vibe‑агент генерирует код по его намерению.

• Тестировщик‑агент прогоняет сценарии.

• Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».

• Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.

  🔧 Пример: смешанная команда разработки по MSF

  Ситуация: корпорация запускает новый сервис аналитики.

  Роли и участники

  • Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.

  • Vibe‑агент: генерирует код по намерению архитектора.

  • Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.

  • Координатор‑человек: принимает решение о переходе к следующему витку спирали.

  • Бизнес‑агент: симулирует сценарии использования, проверяет ценность изменений.

  🎭 Как это работает

  1. Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».

  2. Vibe‑агент генерирует код, интегрируя новый модуль в систему.

  3. Тестировщик‑агент прогоняет тесты, выявляет узкие места.

  4. Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».

  5. Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».

  6. Команда делает следующий виток спирали — добавляет новые функции.

Заключение

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

CASE + Vibe + MSF + ИИ: Думаю, Будущая архитектура разработки

Олдфаги помнят CASE(Computer-Aided Software Engineering)-системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE-система, которая наконец-то заработала.

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

Но если соединить CASE + Vibe, через ИИ и дополнить принципами MSF (Microsoft Solutions Framework), мы получаем новую парадигму — инженерию намерения.

CASE: скелет

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

Vibe Coding: энергия

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

MSF: спираль

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

ИИ: мост

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

• превращать вайб в CASE-модель;

• разворачивать CASE в рабочий код;

• делать обратный ход — извлекать архитектуру из существующего кода;

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

Что это даёт

1. Привязка к структуре: уникальный код перестаёт быть хаотичным, потому что у него есть CASE‑скелет.

2. Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.

3. Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.

4. Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.

5. Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.

Эффект для индустрии

• Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.

• Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.

• Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.

Заключение

CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.

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

И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.

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

Почему маркетинг “не работает", а потом "вдруг" пошли лиды

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

Но в реальности многие рынки, особенно B2B, работают совсем по другой логике.

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

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

Можно назвать это «шлейфом доходимости лидов».

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

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

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

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

Тут то и становится понятнее одна важная вещь: маркетинг — это не кнопка «включил и получил продажи». Это процесс, у которого есть инерция.

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

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

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

С Настей, руководителем команды проектирования интерфейсов, разобрали эту ситуацию на примере взаимодействия аналитиков и дизайнеров.

1️⃣ Почему при согласованных требованиях все равно возникает недопонимание?

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

2️⃣ Как ты это проверила?

Я решила не опираться только на ощущения и провела быстрые интервью. Задала 20–25 коллегам два вопроса и попросила ответить коротко:  

1. Что ты делаешь на работе как аналитик или дизайнер?  

2. Что, по твоему мнению, делает другая сторона?

3️⃣ Что оказалось самым показательным в ответах?

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

4️⃣ Какие формулировки сигнализировали о недопонимании?

• «Дизайнеры делают красиво, но малофункционально».  

• «Не понимаю, что дизайнер делает две недели».  

• «Красивый интерфейс — это субъективно».  

• «Да там же просто пару экранов, что тут обсуждать?».

• «Потом допилим UX, сейчас главное выпустить фичу».

Эти фразы редко звучат в лоб, но задают тон обсуждению решений.

5️⃣ Откуда появляется мнение, что дизайнер делает красиво, но не думает о функциональности?

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

6️⃣ Почему возникает вопрос «что ты делал две недели»?

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

7️⃣ Насколько справедлив тезис «красиво = субъективно»?

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

8️⃣ Как правильно формулировать задачу для дизайнера?

Всегда приносить проблему, а не готовое решение. Когда задача звучит как «сделайте вот так», команда пропускает обсуждение альтернатив и раньше времени фиксирует один путь.

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

9️⃣ Что в итоге помогает снизить напряжение между аналитиком и дизайнером?

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

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

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

Смертельный марш: почему ваш проект обречен и как в этом выжить

Если вы работаете в разработке, то рано или поздно вы оказываетесь в ситуации, когда дедлайн был вчера, бюджет сократили до стоимости обеда, а команда напоминает выживших после кораблекрушения. Эдвард Йордан в своей классической книге назвал это «Смертельный марш. Выживание в безнадежных проектах» (Death March).

Самое важное, что нужно понять: это не досадный сбой менеджмента. Это — стандартная, осознанная и часто эффективная (с точки зрения бизнеса) модель работы.

Генезис катастрофы: Политика, политика и еще раз политика

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

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

Классификация неизбежного: В каком аду вы находитесь?

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

1. «Невыполнимая миссия» (Mission Impossible): Шансы на успех — 1 к 10, но команда верит, что они избранные. Это чистый адреналин. Если получится — вы станете легендами компании. Если нет — вы хотя бы попробовали прыгнуть выше головы.

2. «Камикадзе» (Kamikaze): Здесь нет веры в успех. Есть только осознание финала. Но проект дает доступ к технологиям, которые сделают ваше резюме золотым. Вы идете на дно вместе с кораблем, но с полными карманами ценного опыта и крутым стеком в портфолио.

3. «Отвратительные» (Ugly): Самый грязный вариант. Вы — просто «сжигаемый ресурс». Менеджеру нужно дотянуть до конца квартала, получить бонус и уволиться, оставив после себя выжженную землю и дергающихся от каждого уведомления сотрудников. Здесь нет места героизму, только эксплуатация.

4. «Самоубийственные» (Suicidal): Проект мертв, смысла нет, прогресса нет. Все сидят и ждут, когда здание наконец рухнет, просто потому что страшно или лень увольняться. Это чистая стагнация.

Принцип «Сортировки» (Triage)

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

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

Эстетика процесса

Безнадежный проект — это странное место. Когда результат предопределен (провалом), у вас исчезает страх перед этим самым провалом. Вы становитесь свободны. Вы можете писать код так, как считаете нужным, не оглядываясь на KPI и бесконечные совещания о «светлом будущем».

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

P.S. Циатата:

Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришел в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди - это идиоты.

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

У меня не сходится логика RACI матрицы :(

Роли С и I - прекрасны, поэтому оставим их за бортом вопроса.

В моей картине мира есть Заказчик, Ответственный и Исполнител(ь,и).

• Заказчик (может быть внутренний) - принимает результат по требованиям.

• Ответственный - обязуется обеспечить соответствие целостного результата всем требованиям.

• Исполнители - делают руками.

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

Собственно во что я всё никак не могу въехать:

Буквы R и A из матрицы - не ложатся на привычную схему... Если нет Заказчика - (может быть даже внутреннего) - работа бессмысленна...

Если заказчик это А-из-матрицы и исполнителей много, то кто отвечает за целостный результат? Заказчик? Но это же нерабочая схема... заказчик не должен бегать по производству и пинать сотрудников, пытаясь собрать разрозненные действия в единое целое.

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

В случае, когда А-из-матрицы это и Заказчик и Ответственный в одном лице - тут конфликт интересов, как я уже выше упоминал.

Если R-из-матрицы это Исполнитель, который делает руками, и он тут называется Ответственным, то в случае нескольких исполнителей на проекте возникает соблазн спихивать эту ответственность друг на друга, что не конструктивно и без роли "главного" - матрица не помогает прочертить границы в этой ответственности.

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

У кого получается с пользой применять RACI - можете объяснить с какой стороны это кушается? Или это просто сладкая дичь для говорящих голов?

Написал бота чтобы не сойти с ума от количества чатов

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

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

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

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

AI я использую локальный LLM, а в коде Openai, если будете устанавливать поменяйте на локальный или оставьте если вам нечего стесняться)

Выложил код на GitHub, настройка занимает 5 минут. Но экономит часы и нервы.
Вот ссылка https://github.com/Ata-ux/feedback_bot

Будут вопросы, пишите

–––––––––––

Мой ТГ канал

Как перестать быть центром всех решений и не потерять контроль :)

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

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

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

1️⃣ Что происходит, когда процессы держатся на одном человеке

Я пришла в Naumen в 2015 году. В 2020 у меня появилась первая команда из трех аналитиков. Через год — уже две команды. Сейчас это три команды: три тимлида, два техлида и двадцать аналитиков.

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

2️⃣ Три страха, которые мешают передавать процессы

Когда я решила что-то менять, сначала пришлось разобраться со своими страхами:

1. Я стану не нужна

2. Перегружу команду

3. Команда что-то сделает не так

Самым тяжелым оказался последний страх. Руководителю трудно осознать, что кто‑то может принять решение иначе. Но иначе не значит хуже.

А еще я поняла: если процесс живет только при моем участии — это слабое место, а не моя ценность.

3️⃣ Как мы перестроили систему консультаций

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

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

• Опытные аналитики по каждой заявке

• Скриптолог дня для базовых техвопросов

• Техлиды для сложных техвопросов

• Третья линия как финальная инстанция

В этой схеме больше нет обязательного шага «спросить у Кати» :)

Важно, что я не просто объявила новые правила. Я объяснила команде, зачем им это, и дала возможность сказать, если что‑то не работает.

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

4️⃣ Как мы перестали тратить часы на планирование дежурств

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

Теперь оставила себе только рамки: сколько слотов нужно закрыть и какие роли должны быть в дежурствах. Все остальное передала команде.

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

Я больше не держу в голове десятки нюансов — команда решает их самостоятельно.

5️⃣ Как быть с кризисными ситуациями

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

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

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

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

Пошел в Ж*ОПУ со своими яндексдиректами или Как я перестал быть маркетологом.

Давным-давно один очень мудрый собственник ответил мне фразой, наполненной трансформирующей силой:
Пошел в ж*пу со своими яндексдиректами и аудиториями. У меня кассовый разрыв!

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

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

Здесь работает мое любимое правило:
Стоимость моих услуг может быть ЛЮБОЙ, при условии, что они приносят кратно больше прибыли тому, кто за них платит.

Вопрос:
Что скажет маркетолог, посмотрев на скрин? - Ух ты, очень много млн-ов ))

А я сижу, считаю EBITDA и думаю, как ее родимую воскрешать...

Плагин Tasks. Часть 2

Запросы - еще одна мощная возможность плагина. Пишутся на нативно понятном языке. Позволяют: 

1. Отфильтровать задачи из вашего хранилища по срокам, папке, содержимому

2. Настроить отображение задач в заметке 

Например, чтобы отобразить все невыполненные задачи со сроком (due date) сегодня, достаточно прописать в блоке кода:

tasks 
not done 
due today

⚠️ Чтобы запрос заработал, прописываем его в блоке кода, выделяемом символами “```”

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

Закон Гудхарта как неизбежность экономики управляемой тревоги

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

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

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

Регулярно пишу в Telegram-канал Chief Philosophy Officer о философии бизнеса и управленческого мышления. Заходите.

Как будет выглядеть рабочий день инженера в 2029 году?

Ответ на этот вопрос можно найти в подкасте руководителя клиентской разработки RUTUBE Максима Ульянова. В гостях — Артём Арюткин, CPO платформы для разработчиков в Авито.

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

Из выпуска вы узнаете:

▪Чем CPO в DevEx отличается от CTO и зачем платформе продуктовый подход?
▪Что входит в техническую платформу Авито и почему важен принцип iPhone для разработчика?
▪Почему онбординг — это не «приятный бонус», а одна из ключевых метрик DevEx?
▪Зачем нужна технологическая стратегия и в каких бизнесах она реально избыточна?
▪Какие метрики первыми стоит начать считать для эффективности инженерных команд?
▪Почему платформы в крупных компаниях похожи и какие этапы развития они обычно проходят?
▪Каким компаниям нужна платформа и что меняется на масштабе 100 vs 500 инженеров?
▪Почему IT-индустрия «не зрелая» и какие ответы давно найдены в других отраслях?
▪Что такое «счастье разработчика» и почему его проще всего услышать в «разговорах у кулера»?
▪Почему в эпоху GenAI платформы могут стать ещё важнее?

Приятного просмотра и прослушивания!

Больше о том, как разрабатывают медиасервисы, читайте в телеграм-канале Смотри за IT. Там делимся опытом и рассказываем о жизни в цифровых активах «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE и Yappy.

Почему «оптом дешевле» в маркетинге (лидогенерации) не работает?

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

И потом предприниматель приходит в маркетинг (лидогенерацию) с тем же ожиданием: "Если я увеличу бюджет в 2 раза — лид подешевеет". А он… дорожает. И это многих бесит.

Но маркетинг (каналы привлечения клиентов) — это не склад, а чаще простой аукцион. Ты не покупаешь «товар», а участвуешь за него в торгах.

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

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

У каждого канала привлечения клиентов есть глубина. Есть объём спроса, предел адекватной цены лида. Есть точка, после которой экономика начинает трещать. И вот здесь предприниматели часто совершают типичную ошибку: вместо того чтобы признать потолок канала — они просто «добавляют бюджет».

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

Что же тогда делать? Сначала усиливать конверсию. Потом считать юнит-экономику. И только после этого масштабировать. Либо открывать новые каналы.

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