Пришло на ум | Науменко Александр

Слабая команда или управление?

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

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

Если бы. Если бы. Если бы.

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

Стоит посмотреть и на руководителя. Как он ставит задачи? Как дает обратную связь? Развивает ли людей? Насколько быстро принимает кадровые решения? Умеет ли вообще собирать сильную команду или у него из раза в раз появляются «не те» сотрудники?

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

Потому что задача руководителя не просто получать результат, а делать команду сильнее!

Сравните несколько команд внутри компании. Где люди растут, а где остаются на одном уровне? Где выполняются планы? Где сотрудники осваивают новые навыки и становятся самостоятельнее? Где сильные остаются в компании, а где регулярно уходят?

А потом посмотрите, что в этих командах остается неизменным. Это руководитель!

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

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

Коротко: динамика развития команды важный показателей качества менеджмента.

Как превратить сопротивление в инициативу

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

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

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

При этом задача руководителя не в том, чтобы научить команду автоматически говорить «да». Это другая крайность. Задача в том, чтобы заменить автоматическое «нет» на вопрос «Что нужно сделать, чтобы это сработало?». Но сначала стоит понять, откуда вообще берется сопротивление.

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

Поэтому я бы начинал с простого вопроса «Что вас здесь беспокоит?»

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

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

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

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

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

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

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

В хорошем сценарии люди уже сами приходят и говорят «Здесь можно сделать лучше. Давайте попробуем вот так».

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

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

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

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

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

Как собрать финмодель за четыре часа

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

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

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

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

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

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

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

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

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

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

После AI Growth Days

В воскресенье ночью наконец добрался домой и начал переваривать всё, что произошло за эти несколько дней на крутейшей конференции AI Growth Days.

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

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

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

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

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

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

С 27 по 29 августа мой приятель Ваня Ярославцев из Alto проводит конференцию AI Growth Days (ex-AGDays).

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

В программе три дня пользы и общения:

🔴 27 августа: pre-party конференции — знакомимся и настраиваемся на продуктивную пятницу.

🔴28 августа: официальная программа — более 20 спикеров и два зала. «Бизнес» — про рост продаж и эффективности для заказчиков, «Профи» — про развитие производства и разработки для IT-компаний и агентств. Вечером — after-party с уральским размахом.

🔴29 августа и в выходные: экскурсия по стрит-арту Екатеринбурга и digital-баня.

AI Growth Days — самое значимое событие про искусственный интеллект на Урале в этом году, и совсем скоро здесь соберётся 200+ участников.

Следить за анонсами: @agdays
Купить билеты и посмотреть программу: agday.ru

Как ИИ разбирает мои встречи и хранит важное

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

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

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

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

После того как агент обработает транскрипт, мне в Telegram приходит саммари. К нему прикладываются исходный транскрипт и список задач и договорённостей в формате Markdown. Такой формат удобно читать самому и при необходимости снова отдать LLM. Материалы я могу сразу переслать человеку, с которым у нас была встреча.

Агент все сохраняет в Obsidian. Каждая встреча превращается в отдельную заметку с набором метаданных. Заметки раскладываются по папкам «год → месяц», поэтому в истории встреч легко ориентироваться.

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

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

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

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

Маркетинговый план без ROI

Недавно разбирал маркетинговый план одной компании. Ребята делают B2B-продукт, оборот около 120 млн. в год. Маркетолог принёс документ: контент-план, SEO, конференции, email-рассылки, вебинары несколько раз в квартал. Красиво оформлено, всё расписано по месяцам.

Я сразу спросил: «Сколько это должно принести в деньга? Какой ROI?» Пауза. «Ну, мы планируем вырасти по трафику на 30%, увеличить количество заявок вдвое». Хорошо. А сколько из этих заявок конвертируется в контракты? Ещё пауза. Какой средний чек? Молчание.

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

У меня был клиент — небольшая компания. Они исправно вели блог, публиковали две статьи в неделю и делали это два года. Трафик на блог был приличный. Когда мы начали разбираться, выяснилось, что за два года ровно два клиента пришли из блога. Суммарно — на 600 тысяч рублей. А только на написание статей ушло около 1,5 млн: зарплата контент-менеджера плюс редактор на аутсорсе.

Канал работал в минус, но никто этого не считал, потому что трафик рос и «значит, всё правильно».

Чтобы маркетинговый план стал финансовым инструментом, нужно протянуть метрику от каждой активности до денег. Выглядит это так: берёте канал — например, конференцию. Стоимость участия — 150 тысяч рублей, плюс три дня работы сейлза и маркетолога. Итого вложили условно 200 тысяч.

Исторически с похожих конференций приходило 5–7 тёплых контактов, из которых закрывалось 1–2 сделки. Средний чек — 800 тысяч рублей, маржа — 40%. Значит, ожидаемая отдача — где-то 320–640 тысяч рублей маржи. Экономика сходится — едем. Если конференция новая и истории нет, ставите минимальный прогноз, делаете один раз, смотрите результат, а потом решаете.

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

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

Переформатировать план несложно. Нужно добавить три колонки к каждой активности: сколько стоит, сколько ожидаем получить контрактов, сколько это должно принести маржи.

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

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

Как проверять гипотезы

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

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

В этот раз мы поступили иначе. Важно признать, не все гипотезы подтверждаются. И чем быстрее и дешевле мы их проверяем, тем быстрее находим правильное направление для развития бизнеса. Но гипотезы нужно уметь формулировать. Когда запускаешь эксперимент, важно обозначить: мы проверяем гипотезу X, критерий успеха — Y, бюджет и срок — Z.

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

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

И да, иногда проверка гипотез может стоить дорого. Но иногда ещё дороже стоит её непроверка.

Больше двух лет в роли ментора

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

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

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

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

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

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

Одно дело сказать: «Вам нужно делегировать», «Вам нужны KPI» или «Вам нужна стратегия». Совсем другое — понимать, как всё это внедрить в конкретной компании с конкретной командой, ограничениями и сопротивлением изменениям.

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

Фундамент непрерывного улучшения

Давайте поговорим про цикл PDCA (Plan → Do → Check → Act), который предложил Эдвардс Деминг.

Сегодня этот подход считается классикой управления и лежит в основе Agile, Lean и большинства современных методологий непрерывного улучшения. После Второй мировой войны именно идеи Деминга помогли японской промышленности, включая Toyota, совершить экономический рывок, о котором до сих пор пишут в учебниках по менеджменту.

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

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

Всё действительно довольно просто. Но именно эта простота и делает подход настолько эффективным.

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

Первый опыт кодинга на вайбе production-ready системы

Делюсь с вами успехами моего вайб-кодинга и применения кодовых агентов — Claude Code в моём случае.

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

Я попросил сделать рефакторинг, и он говорит: «Крутую мы систему написали — очень мощную, production-ready, но можно было сделать гораздо проще».

Короче, он расписал, как сделать проще. В итоге вместо того, чтобы изначально сделать быстрый инструмент для автоматизации моей работы — один Python-скрипт, который срабатывает по триггеру, — мы подняли n8n, настроили кучу workflow, развернули Postgres и собрали базу на Obsidian с синронизацией.

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