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

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

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

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

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

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

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

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

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

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

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

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

Хорошая стратегия помещается на лист А4

Давно не было про стратегию.

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

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

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

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

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

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

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

Стратегия отвечает на вопрос: за счет чего именно мы собираемся выиграть? И вот тут начинается самое сложное.

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

И главное, нужно сделать несколько принципиальных выборов.

1. На каком рынке мы вообще хотим работать и почему?
2. Какого клиента хотим привлекать, а от какого готовы отказаться?
3. На чём собираемся строить своё преимущество?
4. Что компания принципиально не будет делать, даже если на этом можно заработать?
5. Куда мы направим ограниченные деньги, время и людей?


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

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

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

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

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

После AI Growth Days

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

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

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

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

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

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

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

Год назад я уже пытался с помощью нейронок перенести свой личный сайт с Webflow на статический стек HTML/CSS/JS, чтобы не зависеть от платформы.

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

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

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

То, во что я тогда уперся и что так и не смог нормально решить за 10 часов, сейчас получилось сделать практически одним промптом. Далее я попросил внести еще несколько улучшений. В итоге сайт стал на 62% легче и вдвое быстрее, при этом полностью сохранив внешний вид, поведение и SEO.

Вот что получилось в итоге: https://www.naumenko.tech

О вайб-кодинге и вреде автоматизации

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

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

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

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

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

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

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

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

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

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

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

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

Channel photo updated

Регламенты не внедряются сами

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

Почему?

Потому что старый способ по-прежнему проще и привычнее. «По-старому» почти всегда побеждает «по-новому», если за новым подходом не стоит ничего, кроме ещё одного документа в корпоративной Wiki.

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

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

Что для этого можно сделать?

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

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

Обязательно установите дедлайн на ознакомление. Например: «до пятницы, 18:00».

Если до этого момента комментариев нет, считаем, что замечаний к документу у сотрудника тоже нет. После этого аргумент «я не согласен» уже не работает.

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

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

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

Тогда у вас появится реальный пример. Остальным гораздо проще «продать» то, что уже работает у коллег, чем то, что просто написано в Wiki. Особенно если новый регламент показал измеримый результат.

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

Клиенты платят не за то, что ты думаешь

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

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

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

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

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

Вот такая история у меня для вас сегодня.

С 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-услуг». Такой вывод становится основой для новых гипотез.

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

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

От диплома — к продукту: как студентки защитили ИТ-решения перед рынком

На прошлой неделе мы собрали представителей рынка и HR-директоров ИТ-компаний и дали слово четырём выпускницам Высшей школы бизнеса НИУ ВШЭ. Выпускницы питчили свои работы и получали обратную связь от тех, кто каждый день решает в своей работе аналогичные проблемы.

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

Все четыре работы делались вместе с командами .redev, а научными руководителями выступили Сергей Костин, Татьяна Пименова и Иван Спиридонов.

Две работы были посвящены продажам и логистике

✅Екатерина — ИИ и автоматизация в процессе продаж ИТ-компании. Решение уже работает в .redev: конверсия по воронке выросла на каждом этапе. Стек — AmoCRM, PostgreSQL, Yandex DataLens, прогнозирование на Prophet.

✅Яна — интеллектуальная маршрутизация доставки последней мили. На неё приходится больше половины логистических затрат. Алгоритм SA+VNS довёл долю доставленных заказов до 88,1% и выровнял нагрузку между курьерами. IRR проекта — 28,7%.

Еще две улучшают процессы в HR-направлении

✅Олеся — ассистент для оценки компетенций и планов развития. Подготовка к перформанс-ревью сжимается с 4 часов до 65 минут (–73%). Принцип — «человек в контуре»: ИИ помогает, а не заменяет руководителя.

✅Мария — ИИ-скрининг кандидатов. Более 1000 откликов на вакансию и 4–6 часов ручного разбора на 100 резюме — знакомая боль каждого рекрутера. Платформа экономит более 30 часов в неделю, данные обрабатываются локально.

Подробнее читайте на РБК ⏪

А после Сергей Костин и Александр Науменко вместе с залом валидировали ключевые гипотезы HRM-продукта: реальна ли боль, готов ли рынок к ИИ-помощнику, за какие метрики HR-директора готовы платить и что становится настоящим блокером внедрения.

Спасибо студентам за доверие, а участникам за интересные и острые вопросы!

Дорожная карта и планирование в гибких методологиях

Если внимательно посмотреть на гибкие методологии разработки, то можно заметить, что в их основе лежит та же логика, что и в цикле PDCA (Plan → Do → Check → Act), о котором я писал ранее. Эта логика в целом применима к любой работе с неопределённостью, а не только к разработке программного обеспечения.

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

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

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

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

Учу продажам, но коммуникацией не владею

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

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

Пишу ему сам. В ответ получаю что-то невнятное: вроде нет, такой доклад не подходит. Ну я, естественно, начинаю спрашивать: подскажите, пожалуйста, чем он не подходит, что не так? Что ещё можно? Я могу другие темы предложить. Каковы критерии отбора докладов?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Втфа! Я случайно снес пост со статьёй из-за спамеров! Но он всё равно отображался как-то криво из-за этих блокировок, поэтому дублирую. https://vc.ru/office/2869878-kak-effektivno-provodit-vstrechi-i-planerki-bez-poter-vremeni