Проекты с легаси — это всегда испытание для любого менеджера. В Альфа-Банке наш PM столкнулась с задачей, которая уже три года «тянулась» на 85% и угрожала застрять навсегда. Аудит вернул прогресс на 79%, но запустил настоящую перезагрузку управления.
В итоге проект реально ожил: команды чётко знают, что от них требуется и в какие сроки, руководитель держит в руках инструмент влияния на результат, а любой менеджер видит актуальный статус продукта — и почему тот «засветился» на дашборде.
Главное — проект сдвинулся с мёртвой точки, процент выполнения восстановили и прогноз — 95% к концу года.
Мы провели эксперимент и убедились — классическое обучение можно не заменять, а ускорять
Зачем
Обычно оператор идёт по стандартному пути: неделя обучения, неделя адаптации, потом первые смены под контролем. Медленно. Мы проверили: можно ли сделать так, чтобы новичок уже в первую смену закрывал диалоги — и не наугад, а качественно.
Что сделали
Построили систему дообучения операторов на базе ChatGPT plugins.
Каждый плагин — типовой кейс: от «где мой заказ» до «верните деньги, но я без чека».
Оператор учится на примерах прямо в GPT, разбирает реальные кейсы, видит ответы и объяснения.
60–70 плагинов под самые типовые ситуации
Результат
Кол-во закрытых диалогов у новичков в первую смену выросло в 3 раза
Качество ответов не просело
Обучение стало дополнением к классике — не конкурирует, а усиливает
4 куратора на группу из 30 человек
7 аккаутов на ChatGPT по 30$
Что не заработало
Без базовой теории GPT не спасёт: нужен фундамент
Не все операторы готовы «учиться у машины»
Некоторые кейсы требуют тонкости, где GPT пока слабее человека
Проблема с оплатами в ChatGPT из-за отсутсвия доступа к Enterprise плану у GPT (они не дают и 60$+ за человека), а на team плане — плохая управляемость доступами
Бизнес-эффект
Быстрее вводим операторов в строй с увеличением в 3 раза закрываемых диалогов в первой смене
Стандартизируем ответы и сценарии
GPT-тренинг не заменяет академию — он её ускоряет
Операторы выходят в смену не «на авось», а уже с руками, натренированными на кейсах
Дальше — масштабирование и тонкая настройка под каналы и сегменты
Видеоинструкции для продактов: куда идти работать, как освоить вайб-кодинг и что делать, чтобы грамотно управлять процессами Обо всем этом — в записях докладов с нашего Product Meetup.
«Product manager. Предпринимательство vs Enterprise vs Стартап. Кому, куда и зачем?» Спикер: Александр Иосса, руководитель цифрового продукта в Альфа-Банке YouTube | VK Видео
«Вайб-кодинг для продакт-менеджеров: от идеи до прототипа за один день» Спикер: Сергей Чекмарёв, AI Product Manager в tх.legаl YouTube | VK Видео
«Жизненный цикл процесса: как создавать, внедрять и завершать процессы» Спикер: Александр Бондаренко, СРО в Garage Eight YouTube | VK Видео
Пивот стартапа (от англ. “pivot” - “вращение”) — это не отказ от идеи. Это смена траектории, которая позволяет продукту найти своё настоящее место на рынке.
По опыту работы стартап-студии скажу, что чаще всего о пивоте мы говорим на раннем этапе ещё до запуска, когда есть первые данные исследований и тестов. Это происходит тогда, когда видно, что пользователи не равнодушны, но в текущем виде проект как-то не складывается.
Что указывает на необходимость пивота?
Неправильно подобрана ЦА. Люди, на которых рассчитывали, не видят ценности, зато смежная группа проявляет больше интереса.
Неверно подобран функционал. Ожидания пользователей не закрыты, зато есть запрос на другое решение.
Боль не острая. Проблема существует, но ради её решения мало кто готов менять привычки или платить.
Рынок или контекст изменился. Появились новые технологии, конкуренты или внешние факторы: исходная модель перестала быть актуальной.
Пивот - это совершенно нормально, не стоит расстраиваться, если эксперт или инвестор советует вам сделать его. К примеру, известные сервисы - Slack, YouTube - стали такими именно после пивота. Поворот идеи - это про честность с самим собой. А ещё это возможность сохранить сильные стороны проекта - команду, наработки и экспертизу, направив их в более выигрышную сторону.
Работать в одной команде много лет или менять их несколько раз в год
Обсудили с девчонками-тестировщицами Контура. 💅 Капа Потапова шесть лет в одной команде, Катя Заусова — из бюро тестировщиков, меняет проекты и контекст задач каждые несколько месяцев.
Постоянная смена команд вызывает чувство одиночества и отсутствия долгосрочных связей с коллегами
Меняет команды: Я в команде бюро год и это был мой самый главный страх, что когда перейду туда, то лишусь коллег, с которыми можно пообщаться, попить чай, потусить в свободное время. Но этот год показал обратное: бюро тестировщиков — это тоже команда, у нас есть свои традиции, общение и мероприятия. Это всё позволяет чувствовать себя частью чего-то большого и важного. Но я ещё и сама по себе человек активный, мне важно знакомиться и общаться.
Не меняет команды: Вот! Это самое главное. Мне — наоборот, чтобы сблизиться с коллегой, нужно больше времени — иногда и года не хватает. Я в своей команде уже больше шести лет, и многие коллеги стали роднульками. Но чтобы к этому ощущению прийти, нам нужно было сделать кучу совместных проектов.
Когда работаешь в одной команде, можно решать более интересные задачи, чем когда всё время меняешь её
Не меняет команды: Когда ты работаешь очень долго в одном проекте и одной команде, ты уже знаешь все нюансы и какие там есть проблемы. Не просто «копаешь от рассвета до заката», а понимаешь суть — почему надо сделать так, а не иначе, с чем можно столкнуться в процессе. Для меня интересные проекты — это те, в которых есть неочевидное, когда надо поковыряться, договориться с кем-то.
Меняет команды: В бюро тестирования интересно то, что первое время ты делаешь те задачи, которые никогда ещё не делал. Здесь процессы нужно поднимать с нуля, например, настроить автоматизацию или ревью аналитики. В одном из моих прошлых проектов нужно было выстроить стратегию тестирования, а там были одни разработчики и в итоге всё превратилось в стратегию автоматизации: разбирались, что мы покрываем автотестами, когда это делаем и в каком количестве.
Работа в одной команде даёт больше чувства значимости в успехе продукта
Меняет команды: Конечно, потому что ты регулярно вносишь свою лепту. Но тут ещё важно, чтобы команда рассказывала о своих результатах и успехах, вакуума быть не должно, когда человек думает «У меня есть одна зона ответственности, а на другие даже не смотрю». Чтобы чувствовать свою значимость, тебе нужно хотя бы видеть продуктовые метрики фич.
Не меняет команды: Я бы ещё добавила, что далеко не всем важно ощущать себя частью успеха команды. Бывают люди, которым важно только понимание того, сколько они зарабатывают и возможен ли рост: остальное не очень волнует. Наверное, когда ты приходишь в команду, которая только стартует, и если у тебя есть возможность заложить какой-то фундамент, то в дальнейшем ты будешь чувствовать себя причастным к этому процессу.
Работа в одной команде может привести к выгоранию из-за однообразия
Не меняет команды: Любая работа может, если неправильно распределять ресурсы и не соблюдать баланс, работать по выходным и круглосуточно. Это не зависит от того, в команде ты или в бюро. К потере интереса скорее приведёт монотонность и рутина. С другой стороны, постоянный хаос тоже может быстро надоесть.
Я спасаюсь тем, что у меня много непроектных активностей, например, мероприятия и обучение.
Работа в разных командах позволяет предложить свежий взгляд на задачи, что ценно для продукта
Меняет команды: Главное не применять этот свежий взгляд резко и ультимативно, обрубая всё, что было до этого. Потому что всё новое — это стресс, и каким бы не был продукт, поначалу обновления будут тяжело и долго внедряться.
Не меняет команды: Когда работаешь в бюро, то видишь разные команды с разными подходами. Это прикольно с точки зрения того, что ты так наращиваешь свой опыт и насмотренность, и поэтому у тебя для всех всегда будет пул решений на любой вкус.
От диагностики к действию: три обязательных шага перед разработкой стратегии компании
После завершения диагностики бизнеса, когда метрики собраны и бизнес-модель проработана, многие руководители допускают ключевую ошибку — сразу переходят к разработке глобальной стратегии. На основе опыта управления компаниями в кризисных ситуациях я вывел три обязательных этапа, которые необходимо пройти до стратегического планирования.
Первым делом мы проводим стресс-тест денежного потока по трем сценариям:
Снижение выручки на 20% в течение квартала
Потеря ключевого клиента (15+% от выручки)
Одновременное возникновение операционных кризисов
Инструменты:
Модель денежного потока в Excel/Google Sheets с чувствительностью параметров
Дашборд основных финансовых показателей
Регулярный (еженедельный) контроль свободного денежного потока
Результат: понимание реального горизонта планирования. Если компания имеет менее 3 месяцев финансовой подушки, стратегия роста бессмысленна — сначала нужно обеспечить выживание.
2. Аудит операционной команды: диагностика человеческого капитала
Метрики показывают «что происходит», но только люди могут объяснить «почему». В первые недели после диагностики я провожу серию структурированных интервью с ключевыми руководителями.
Методология:
45-минутные сессии один на один
Единый список вопросов для всех участников
Фиксация не только ответов, но и невербальных реакций
Ключевые вопросы:
«Какие три решения за последний год вы считаете ошибочными и почему?»
«Если бы вы получили полномочия CEO на 24 часа, что бы вы изменили в первую очередь?»
«Какие неочевидные возможности мы упускаем на рынке?»
Анализ результатов: выявление скрытых конфликтов, определение реальных (а не декларируемых) центров влияния, оценка потенциала текущей команды.
3. Быстрые победы: создание импульса для изменений
Долгосрочная стратегия требует месяцев для реализации, но команда и инвесторы ждут сигналов изменений уже сейчас. Мы идентифицируем точки приложения усилий по критериям:
Эффект достигается за 1-3 месяца
Затраты ресурсов минимальны
Результат заметен для большинства сотрудников
Примеры из практики:
Кейс 1: Оптимизация отчетности Проблема: ежедневный 15-страничный операционный отчет готовился 3 часа в день Решение: сократили до 1 страницы ключевых метрик Результат: экономия 60 человеко-часов в неделю
Кейс 2: Устранение потерь лидов Проблема: 23% заявок с сайта не доходили до CRM Решение: настроили интеграцию и автоматизацию мессенджера с AmoCRM за 2 недели Результат: +15% к конверсии в продажу
Почему эта последовательность критически важна
Представьте себе строительство: сначала закладывают фундамент, затем возводят стены, и только потом думают о дизайне интерьеров. В бизнесе та же логика:
Финансовая безопасность — фундамент, без которого любая стратегия рухнет при первом же кризисе
Аудит команды — несущие стены, от прочности которых зависит реализация любых планов
Быстрые победы — отделочные работы, которые демонстрируют прогресс и поддерживают мотивацию
Пропуск любого из этих этапов приводит к классической ошибке: созданию «стратегии на бумаге», которая не работает в реальности из-за финансовых ограничений, сопротивления команды или потери доверия стейкхолдеров.
В комментариях предлагаю обсудить: какие подготовительные этапы перед стратегическим планированием используете вы? С какими вызовами сталкивались при их реализации?
Представлен репозиторий Free Certifications с бесплатными сертификациями по IT-технологиям от Google, Oracle Microsoft и других компаний. Все сертификаты строго разделены по категориям: фронтенд, бэкенд, SQL, Data Science, информбезопасность, аналитика и ещё множество тем.
Обычно в начале карьеры дизайнеров дико бесит, когда клиент советуется с женой/коллегами/котом.
Тем временем, основной показатель роста — не бояться неидеального процесса и уверенно нырять в хаос с головой. Мнения коллег клиента? Отлично, бесплатная фокус-группа! Десятки итераций? Прекрасно, мы в творческом потоке! Это и есть та самая «магия опыта».
Вы называетесь синьор и вас до сих пор бомбит от правок? У меня для вас плохие новости
Разработка в 2025 году — это уже не только про умение писать код. Важно уметь работать в связке с ИИ, быстро адаптироваться к новым инструментам и смотреть на задачи шире, чем строки кода. Автоматизация ускоряет процессы, языковые модели становятся полноценным помощником, а кибербезопасность требует внимания как никогда раньше.
Мы собрали опыт наших разработчиков: какие технологии и подходы важны уже сегодня, какие навыки стоит развивать и где искать новые знания.
Что формирует будущее разработчиков
1. ИИ и языковые модели. Инструменты вроде Cursor/Windsurf и LLM помогают быстрее и качественнее выполнять то, что вы уже умеете, или разобраться в новой теме. LLM берут на себя «черновую» работу: исправляют опечатки, улучшают оформление кода, помогают с декомпозицией задач и первичным код‑ревью. Это снижает нагрузку и освобождает время под архитектурные решения.
2. Кибербезопасность. С ростом объема данных и активным использованием ИИ‑решений увеличивается и число атак. В 2025 году безопасность уже не «дополнительная опция», а критически важный аспект разработки. В приоритете: оперативное устранение уязвимостей, поддержка зависимых библиотек в актуальном состоянии, а также проектирование безопасных систем.
Главные скиллы
— Промпт‑инжиниринг и итеративный подход. Чем лучше вы понимаете и формулируете задачу для LLM, тем лучше результат. Разбивайте сложные задачи на небольшие, пошагово уточняйте вводные, добавляйте контекст, референсы и критерии качества. — Умение адаптироваться к изменениям. Мир меняется быстро: нужна гибкость и готовность учиться новым инструментам и подходам. — Осознанное применение ИИ. ИИ ускоряет рутину, но не заменяет понимания. Код или решения без осознания внутренних механизмов сложнее поддерживать; сырые и неадаптированные ответы часто дороже, чем написать с нуля. — Критическое и системное мышление. Хороший разработчик видит систему целиком, задает вопросы, сравнивает варианты и думает на несколько шагов вперед: архитектура, влияние изменений, риски и стоимость владения.
Как развиваться разработчику
1. Книги, курсы и пет‑проекты. Рабочая связка: цель → план → небольшой прототип → разбор ошибок. LLM помогают собрать персональный план обучения: перечисляете, что знаете и что хотите изучить, — получаете черновой roadmap и список практик.
2. Конференции и митапы. Это возможность обменяться опытом и задать вопросы. Сильно прокачивает подготовка собственного доклада: структурируете знания, получаете обратную связь, улучшаете подходы.
3. Полезные тг‑каналы. Удобно следить за анонсами моделей, обновлениями LLM и промпт‑подходами в профильных каналах. Выберите несколько источников и регулярно сверяйте советы с документацией и собственным кодом.
Ассоциация “Проектный Альянс” выпустила книгу “Управление проектами для заинтересованных сторон (стейкхолдеров)" (В.Воропаев, Я.Гельруд, О.Клименко), посвященную стейкхолдерам проекта и тому, как собирать управление сложными проектами вокруг интересов всех ключевых игроков, а не только команды PM.
Я прочитал новинку, и вот тезисно про книгу, ее плюсы и особенности.
Плюсы:
Нацеленность на сложные крупнобюджетные проекты, вне зависимости от сферы (не столько привычные ИТ-проекты, но и “стройки века” и производственно-добывающие проекты). Сейчас комплексных материалов в этой сфере сильно не хватает, имхо, если знаете - напишите в комментах.
Здоровая хардкорность. Да, тут не заскучаешь над авторскими эмоциями и отступлениями. Книга на 70% состоит из математического аппарата, формул, которых "гуманитариям не понять" (с), но которые прекрасно впишутся в excel и ИСУП и помогут проекту. Авторы именно считают, а не оценивают эффективность проектного управления.
Комплексность. Не одна мат.модель, а набор, от детерминированных до вероятностных, с разбором их ограничений для сложных проектов. В итоге получается обобщенная сетевая модель.
Несколько точек зрения, соответствующих разным стейкхолдерам: инвестора, заказчика, поставщика, регулирующих органов, коммерческой службы и, конечно, команды проекта. Каждому — свои цели, функции, компетенции и метрики. И еще отдельная карта связей.
Пример схемы из книги
Из этого складывается основа (скорее ТЗ) для интегрированной информационной системы управления проектами, которая должна собрать вместе всё: архитектуру, логику взаимодействия сторон, планы финансов/поставок/налогов, функции по всем стадиям жизненного цикла.
Есть практическая оптика для разных ролей: таблицы с ожиданиями, целями, ограничениями и инструментами по каждой стороне призваны помочь быстро собрать «карту интересов» под конкретный портфель/программу. Причем тут без формул...
И есть особенности.
Монографический стиль. Среди авторов - доктор технических наук, и книга ни разу не лайтовый гайд, к которым многие из нас привыкли, а солидная академическая работа с формальными постановками и алгоритмами. Листается в целом быстро, но ожидает от читателя готовности к моделям и матанализу.
Математический аппарат - это и достоинство, и порог входа. Но, с другой стороны, есть понятные гуманитариям выводы, и если они ок, то дальше можно погружаться и в расчеты с шарящими коллегами.
Логика “сверху вниз”, от универсальной модели проектного управления к конкретным календарям, ресурсам и т.д. Если привыкли «от Jira к стратегии», то придётся развернуть взгляд.
Резюме. Рекомендую книгу, в первую очередь, PMO, руководителям портфелей/программ, менеджерам крупнобюджетных проектов, интеграторам и консультантам, кто “варится” в многосубъектных проектах с конфликтующими интересами.
Представьте: вы смоделировали процесс, нажали кнопку, и он работает. Сам назначает задачи, сам контролирует сроки, сам правит данными. Это не фантастика, а реальность с исполняемыми процессами на Camunda. 23 сентября мы покажем, как это сделать на бесплатном вебинаре «Уровни моделирования бизнес-процессов. Исполняемый BPMN».
Что будет в эфире:
✔️ Живой разбор работы в Camunda: от установки до запуска.
✔️ Покажем, как программировать логику шлюзов и создавать пользовательские формы.
✔️ Ответим на вопрос: какую модель пойдет исполнять движок, а какую — нет.
🗓 Дата: 23 сентября
⏰ Время: 17:00–18:00 (Мск)
👨🎓 Спикер: Алексей Тарасов — аналитик с 10-летним опытом.
ТОП-5 КНИГ, которые изменили мое видение управления
Всем привет! Меня часто спрашивают, что почитать для развития CEO-мышления. Делись своей подборкой книг, которые дали мне больше всего инсайтов.
«The Hard Thing About Hard Things» Бена Горовица Самая честная книга о кризисах, принятии сложных решений и выживании бизнеса. Никакой теории — только личный опыт вывода компаний из пропасти. Ключевой инсайт: «Иногда нет правильных решений. Есть только твое решение и готовность его реализовать».
«Good Strategy / Bad Strategy» Ричарда Румельта Лучший антидот от пустых словосочетаний вроде «стать лучшим на рынке». Учит отличать реальную стратегию от ее имитации. Ключевой инсайт: «Сердце хорошей стратегии — диагностика главного вызова и концентрация ресурсов на его решении».
«High Output Management» Энди Гроува Библей операционного управления от легендарного CEO Intel. Как создавать системы, которые работают без твоего постоянного вмешательства. Ключевой инсайт: «Выход менеджера = выход его команды × его влияние на смежные команды».
«The Innovator’s Dilemma» Клейтона Кристенсена Почему стоит читать: Объясняет, почему успешные компании умирают, игнорируя «подрывные» инновации. Must-read для тех, кто думает о долгосрочном росте. Ключевой инсайт: «Рынки меняются быстрее, чем любые компании. Выживают те, кто учится меняться вместе с ними».
«The First 90 Days» Майкла Уоткинса Лучшее руководство для мягкого входа в новую роль CEO. Десятки практических фреймворков для диагностики и планирования. Ключевой инсайт: «Ваша цель — не доказать свою правоту, а понять реальное положение дел и адаптироваться к нему».
Бонус для своих: Также рекомендую обратить внимание на:
«Thinking, Fast and Slow» Канемана (принятие решений)
«Measure What Matters» Доерра (про OKR)
«Leaders Eat Last» Сина (лидерство)
Что из этого читали? Какие книги добавите в список? Жду ваши рекомендации в комментариях! 📚
Представим ситуацию. Большой аутсорс, 5 распределённых команд, у каждой обычно в работе по 1–3 проекта. Наступает момент, когда текущий проект сдан, а новый проект ещё не утверждён: документы в стадии подписания, а ТЗ ещё не сформировано. Команда разработчиков ждёт отмашки, возникает свободное время между проектами. Что делать? Бюджет утекает на разработчиков, которые ничем не заняты. Какой выход из ситуации, когда кончились задачи?
Я очень часто сталкиваюсь с этим кейсом, и по моему опыту есть решение. Если дать разработчику волю, он скорее свалит в кофейню, чем будет просиживать штаны, пока нет проекта или задач. Пустая трата ресурсов для вас обоих. Но из свободного времени можно извлечь выгоду как для команды, так и для самого разработчика - последний выиграет даже больше. Речь идёт об обучении. И я говорю не о курсах или конференциях. Лучшее обучение - это практика. В одной из команд мы сделали следующее. Каждому разработчику дали задание: описать свой пет-проект, который он хочет реализовать, и список технологий, которые он при этом прокачает.
Возник следующий вопрос от разработчика: «А что мне делать, если я не хочу никакой пет-проект и у меня нет идеи?» В таком случае его тимлид должен придумать за него, предложить варианты, и вместе они должны решить. Далее каждому разработчику выделяется отдельный репозиторий в рамках вашей инфраструктуры. Всё должно выглядеть так, будто это настоящий боевой проект - это очень важно.
Каждый рабочий день разработчики должны пилить свой пет-проект под флагом вашей компании и рассказывать о своём прогрессе и планах на дейлике. Тимлид в свою очередь должен контролировать их, проводить ревью и по возможности помогать и консультировать. Наша задача - дать возможность разработчику наконец-то реализовать свои идеи не после тяжёлого рабочего дня, а прямо тут, за деньги (его же ЗП). Полная свобода действий в плане развития и прокачки навыков.
Что мы в итоге имеем и в чём выгода?
Вместо просиживания штанов разработчик качает навыки, причём те, которые он сам выбрал, на проекте, который он сам захотел. Тем временем мы не вкладываем дополнительный бюджет на курсы и прочее обучение. Сотрудник прокачивается более органически. Компания по-прежнему платит оклад, но команда продолжает быть в тонусе, потому что мы даём им творческий карт-бланш. Мотивация от этого выше, чем скучать в ожидании нового проекта.
По своей сути мы лишь устраиваем небольшой хакатон для своих сотрудников, не привлекая дополнительные ресурсы в команду. Таким образом, любой длительный простой между задачами превращается в прокачку вашей команды. Стратегия и рамки могут меняться в зависимости от реалий компании и команды, но в основе должна оставаться идея: не тратить простой впустую, а превращать его в ценность - для разработчика, команды и компании.
Почему агентский бизнес без табличек — это рулетка
Агентская модель кажется простой: взял клиентов, нанял исполнителей, разницу между ставками забрал себе. Но на практике это постоянные качели. Стоит кому-то из сотрудников заболеть, как приходится закрывать проект своими руками. А если клиент задержал оплату, то можно попасть в кассовый разрыв.
Именно поэтому я с первого дня решил, что нужно вести учёт финансов. Мы настроили отчёт о движении денежных средств (ДДС), потом добавили платёжный календарь и P&L. Выглядит это в виде красивых дашбордов.
Теперь мне стало спокойнее, почувствовал больше контроля. Если календарь показывает минус в конце месяца — у нас есть время усилить продажи, дозакрыть клиентов или сократить косты. Мы обсуждаем это на партнёрских встречах каждую неделю, поэтому не ждём конца месяца, когда уже нельзя будет ничего исправить.
Фактор случайности никуда не делся: сделки иногда срываются, или неожиданно прилетают новые контракты. Но теперь агентство — это не рулетка, а система, где я понимаю, сколько мы зарабатываем и что мы можем сделать, чтобы прийти к желаемым цифрам.
Привет! Меня зовут Антон Гесин. Обычно меня представляют как основателя Kids MBA — сети бизнес-школ для детей. Но на самом деле, это лишь часть того, чем я живу. Мне всегда было интересно создавать, развивать и учить — будь то бизнес, люди или даже старые скрипки.
Привет! Меня зовут Антон Гесин.
Последние 17 лет я в предпринимательстве. Начинал с IT — создал и потом продал две веб-студии. Потом был опыт в ритейле, работа с поставками из Китая, а затем — запуск Kids MBA. Сегодня проект работает в 12 городах и учит больше тысячи детей. Для меня это не просто бизнес — это способ менять будущее через образование.
Наконец то я почувствовал зов блога и вот мой первый пост. Буду писать про будни CEO.
Первый шаг любого CEO это диагностика проекта. Это про глубочайшую диагностику. Мне нужно быстро понять: где тело болит, где скрыты точки роста, а где нас в ближайшем квартале может ждать неприятный сюрприз.
Я не верю в сотни метрик. Я верю в несколько ключевых, которые как рентген показывают здоровье бизнеса. Вот моя «великолепная пятерка» для старта диагностики.
Cash Runway (Запас хода)
Это не просто деньги на счетах. Это ответ на главный вопрос: «Сколько месяцев мы можем прожить, если доход упадет до нуля?». Расчет прост: (Денежные средства) / (Ежемесячные операционные расходы). Меньше 6 месяцев — красный, тревожный цвет. Меньше 3 — пора бить в набат. Без понимания этого числа все стратегии — просто замки из песка.
Customer Lifetime Value (LTV) / Customer Acquisition Cost (CAC)
Это священный грааль для любого бизнеса. LTV — сколько денег один клиент приносит за все время сотрудничества. CAC — сколько мы тратим, чтобы его привлечь. ➗ Соотношение LTV:CAC = 3:1 — классика, признак здорового бизнеса. ➖ Меньше 3:1? Мы слишком много тратим на привлечение или мало зарабатываем с клиента. ➕ Больше 5:1? Возможно, мы недоинвестируем в маркетинг и упускаем рост.
Gross Margin (Валовая маржа)
Показывает, насколько прибыльны наши основные операции, без учета общих расходов. Низкая валовая маржа — это симптом: либо цены слишком низкие, либо себестоимость (производство, логистика, команда) вышла из-под контроля. Если здесь дыра, никакой рост продаж не спасет.
Revenue Growth Rate (Темп роста выручки)
Всё просто: растём мы или нет? Но я смотрю не на абсолютные цифры, а на тренды:
📈 Замедляется рост? Значит, рынок насыщается или наша стратегия исчерпала себя. 📉 Отрицательный рост? Требуются срочные и, возможно, болезненные решения.
Net Promoter Score (NPS) — Индекс лояльности
NPS показывает готовность клиентов рекомендовать ваш продукт или услугу. Это не просто цифра, а барометр клиентской лояльности и удовлетворенности.
Высокий NPS означает не только лояльных клиентов, но и:
➞ Снижение стоимости привлечения (CAC) ➞ Увеличение lifetime value (LTV) ➞ Естественный рост через сарафанное радио
Низкий NPS? Это прямое указание на проблемы в:
Качестве продукта или услуги
Клиентском обслуживании
Соответствии ожиданий и реальности
Но метрики — это лишь цифры. За ними должна стоять логика.
Поэтому я всегда сажусь за Lean Canvas. Я рисую его заново, даже если он уже есть. Почему? Потому что он заставляет меня сложить разрозненные метрики в единую картину бизнес-модели.
Низкий LTV/CAC? Смотрю на блок «Value Proposition» и «Channels». Может, мы не доносим ценность или привлекаем не тех клиентов?
Плохая валовая маржа? Это прямое отражение блоков «Cost Structure» и «Revenue Streams».
Высокая текучка? Часто коренится в нерешенных «Customer Problems» или токсичном процессе («Key Metrics» как раз таки!).
Вывод: Метрики — это симптомы. Lean Canvas — это карта, которая помогает понять, в каком органе болезнь и как эти органы связаны между собой.
Только так можно поставить точный диагноз и назначить правильное лечение, а не просто бороться с температурой.
Вжарим рок в этой дыре!
А на что в первую очередь смотрите вы? В комментариях жду вашу «топ-5».
В этот раз в гости пришёл Александр Лукьянченко, технический руководитель кластера Architecture. Саша работает в Авито почти 10 лет: компания менялась на его глазах, а сам он прошел путь от разработчика до менеджера высшего звена. В интервью вместе с Сашей и ведущим Виктором Раевым, руководителем разработки юнита Services Base, поговорим вот о чём:
как выглядит путь от разработчика до менеджера высшего звена длиной в 10 лет;
какие изменения произошли в Авито с 2016 года;
как зарождалась PaaS — платформа, которая теперь облегчает жизнь инженерам;
что такое AvitoPlato и какие планы по развитию продукта на будущее.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Я люблю читать и писать про всякие разные крутые менеджерские находки, креативные решения и к чему они приводят. На глаза попался интересный кейс парня, который в 19 лет стартовал свою компанию, а потом стал чуть ли не самым молодым миллиардером. Кейс известный и в нем видны совершенно простые, но оч крутые бизнес решения. Но по порядку.
Это вообще не «очередной IT стартап, который опять стрельнул не пойми откуда и, возможно, туда же и пропадет». Хотя было бы вполне логично и в духе времени.
История связана с куда более материальными вещами и от этого еще более интересная. Парень по имени Бен Франсис вел обычную себе жизнь среднестатистического молодого человека: учеба, подработка курьером аж за 8 баксов в час и спорт по ночам. Парень мечтал быть футболистом, но что-то пошло не так и он решил переквалифицироваться в боди билдинг. Причем в качалку он ходил как одержимый.
Как увлеченный спортсмен, он быстро сообразил, что на рынке существует прям таки дыра по предложению одежды именно для ребят, которые активно качают бицепс и не пропускают день ног. Все, что было от известных брендов - стандартная одежда, в которой выглядишь как браток из 90-х. То есть он нашел спрос на уже вполне сформировавшиеся рынке, что не просто.
В итоге, понимая, что хочет он сам и ему подобные, наш герой со своим друзьями купил швейную машинку, трафаретный принтер и начал создавать одежду, как он это видел под брендом GymShark.
Что меня зацепило в разрезе именно менеджмента и бизнеса. Бен, используя лежащие на поверхности инструменты, которые не стоили практически ничего, смог почти забесплатно создать безумную осведомленность и интерес своего комьюнити о бренде.
Как любой увлеченный спортсмен он был подписан на YouTube фитнес блоггеров, у которых смотрел технику, питание, ну и вообще вдохновлялся. В то время инфлуэнсеры еще не на столько избаловались, чтобы брать безумные деньги за рекламу, при этом Бен сообразил, что подписота-то растет, причем там сидит сплошная целевая аудитория.
Поэтому он сделал очевидный, но очень умный ход конем: начал рассылать свою продукцию своим же кумирам с личными письмами, где рассказывал про то, как тот или иной блоггер его вдохновил/помог и предложением посмотреть, что они там нашили. Ну то есть одно размещение ему стоило баксов 30 (продукт плюс отправка) при гигантской теплой аудитории.
Так как спорт комьюнити очень вменяемое и дружное, инфлуэнсеры с удовольствием рассказали о полученном продукте и своем опыте. А то, что писал им персонализированные сообщения - добавили желания рассказать про его проект.
Но самый фурор был, когда GymShark принял участие в выставке BodyPower в 2013 году. Сам предприниматель до конца не верил, что из этого что-то получится. Но сразу после открытия их стенд взяли штурмом атлеты, блоггеры, представители залов. Не удивительно: все об этом слышали от чуваков, на которых ты не просто подписан, а кому доверяешь. Ну и дальше понеслась… были победы и поражения, но по итогу на сегодняшней день компания GymShark оценивается в 1.3 млрд. Долл и конкурирует с такими гигантами, как Nike и адик….
Меня это история привлекла тем, что вместо того, чтобы пытаться использовать общеизвестные, дорогостоящие или сложные способы продвижения, которые являются барьером для малого бизнеса, Бен посмотрел чуть шире и взял то, что уже есть в доступе, но чем мало кто пользуется.
Часто предприниматели вместо того, чтобы юзать простые и понятные инструменты оптимизаций, улучшений и т.д за бешеные деньги покупают советы и решения, которые, как и они, использует весь рынок. А как можно выиграть у кого-то, если бежишь с ними с одной скоростью?
Имеет смысл сначала подумать: есть ли простой метод решения моей задачи перед тем, как бросаться во все тяжкие и тратить нажитое непосильным трудом не пойми на что.
Когда я работал исполнительным директором в Smartykids, в нашем отделе продаж было 12 менеджеров. Мы пытались по-разному мотивировать продавцов и фокусировать их на результате.
У нас в офисе был установлен колокол. Когда приходила оплата, ответственный за оплату менеджер шёл и бил в колокол.
Также мы купили магнитную доску и расположили на ней 12 машинок. У каждого менеджера был месячный план в 1 млн рублей. Каждый день на планёрке менеджеры двигали эти машинки. Так все видели, кто сколько продал в этом месяце.
Вначале это работало хорошо. Продавцы включились, стали бодрее выполнять планы. Но постепенно рос дух соперничества, и спустя 3 месяца отстающие продавцы стали выгорать. С большинством из них мы в итоге попрощались.
Это пример простенькой визуализации, которая фокусировала сотрудников на результат. Для таких экспериментов вам даже не нужны навороченные дашборды. Можно начать с простых инструментов, которые под рукой.
Привет, я Юра, Project-менеджер с 10-летним стажем. Рассказываю о личном опыте в IT. тг: @projectmindset_pm
«О чем на самом деле думает проджект-менеджер во время митинга: перевод с корпоративного на русский»
На рабочих митингах мы все разговариваем на корпоративном языке, так уж заведено. Разработчики, которые умеют не только писать код, но и разговаривать на корпоративном языке, со временем становятся тимлидами и техническими директорами. Но что такое этот корпоративный язык? Покажу вам глазами проджект-менеджера.
Про оценку сроков
Каждому проджекту знакомо. Митинг с заказчиком и командой, вдруг, не согласовав оценку с менеджером, разработчик говорит: «Ну, это задача дня на четыре... Если ничего не помешает». Тут же слышится от заказчика: «Фиксируем, через 4 рабочих дня будет готово». Вспышка, шторм, помешательство. У проджекта в голове: «Ага, “Если ничего не помешает”, так вам ничего и не помешает, конечно. Сейчас начнется: мало ресурсов на сервере, срочный баг от другого клиента, а тестирование? В этой оценке указана только время разработки! Минимум неделя нужна. А обещать буду за 7 рабочих дней». Проджект тут же говорит вслух на корпоративном: «Предлагаю заложить на задачу 7 рабочих дней с учетом возможных рисков и интеграции в основной процесс. Нужно обстоятельно убедиться, что функционал готов к релизу». Заказчик недоверчиво фиксирует 7 рабочих дней на задачу — фух, пронесло 😓
Про «немного поменять ТЗ»
Это из фонда золотых цитат заказчиков: «Мы тут подумали и хотим немного улучшить концепцию. Фактически, всё остается по-старому, просто логика немного меняется». С этого начинается внутренний диалог проджекта: «„Улучшить концепцию“... Это значит пришить к штанам капюшон и выкинуть 3 недели работы. „Логика немного меняется“ — это сделаем из грузовика экскаватор, новый движок, новая база данных и отказ от всего, что уже сделано». Проджект говорит вслух: «Понимаю ваше стремление к улучшению! Давайте проведем отдельную встречу вместе с аналитиком, где вы подробно расскажете о новой концепции. Мы проведем анализ, посчитаем новые сроки и бюджет и обсудим решение». (редко кто меняет изначальную логику, увидев новые сроки и бюджет 😉)
Работа PM — это искусство баланса между желаемым, возможным и реализуемым. Главное — сохранять спокойствие и дальновидность.
