Что приносит нам и бизнесу наибольший вред?
Тезис:
То, о чем мы не знаем, вредит нам больше всего.
Реальные проблемы, блокеры и потенциальные зоны роста чаще всего лежат за пределами нашей компетентности.
Часто вижу, как лидеры и их команды снова и снова пытаются решать одни и те же проблемы, исходя из своего текущего уровня знаний и опыта, хотя в предыдущие итерации это должного эффекта не дало.
Я связываю это с эффектом "полной чаши". В полную чашу уже не налить воды. "Переполненная чаша" закрывает способность смотреть и видеть шире. Глубина познаний и опыта в определённой теме, особенно подкреплённая признанием окружающих, создает иллюзию экспертности во всем. А это когнитивное искажение.
Результат: команды и даже целые департаменты, дивизионы, организации "буксуют" и стоят на месте, проблема не решается. Ведь бывают целые команды этих самых экспертов, порождающих "горе от ума".
Что делать?
1️⃣ Если вы обнаружили себя в такой ситуации, первое, что делаем, - это признаемся себе: "Я профан в этом вопросе". Прямо вот так - взять и сказать себе это. Вслух. Искренне.
2️⃣ Первый шаг открывает доступ к "состоянию ученика" и пробуждает в нас готовность слышать и внимать.
3️⃣ Не бояться привлекать помощь: идти и найти людей, которые справились с аналогичной проблемой, узнавать, как достигали текущего уровня, интересоваться, что делали, выяснять и записывать себе фишки. Выяснять, каких результатов удалось достичь.
4️⃣ Таких походов из пункта 3 должно быть много - не один, не два и не три. Идеально, если не менее десяти. Ага!
5️⃣ Если пойдёте делать п. 3 и 4 без шага 1, все пойдёт по известной линии - вы не услышите со своей экспертностью, что вам говорят, пропустите важное и впустую потратите время.
6️⃣ Пункт 4 создаст вам насмотренность и вытащит из области "я не знаю, чего я не знаю" в область "я знаю, что я не знаю". А там у вас появляется возможность принимать решения, управлять и действовать. Появляется возможность вырабатывать гипотезы и идти их проверять.
Чем выше и сложнее уровень проблем, тем сложнее вам будет выполнять п. 4. Сами понимаете, воронка выживших в этой эволюционной гонке сужается. Тогда ищем экспертов, решавших подобные задачи, и разговариваем с ними, слушаем и воспринимаем их фишки и аргументы, сопоставляем и анализируем. Стараемся разобраться!
Сходить в одну-две "великие" компании и формально попросить, чтобы рассказали, как они делали/делают - не вариант. На конференциях тоже все рассказывают красивые истории. Желательно проводить кропотливый "допрос", копать глубоко и спрашивать о результатах!
Несмотря на свою тривиальность, способ супер действенный. И важно не забывать, п.п. 1 и 2 имеют решающую роль. Попрётесь со своей экспертизой искать решения - так и будете тусить вместе с ней на месте. Хотя, учитывая нынешние темпы и скорости, этого самого "на месте" уже не бывает. Стоять - значит деградировать или, что хуже, "копать себе могилу".
Открытого всем разума и изящных решений. 🙌
#мышлениепредпринимателя #ростбизнеса #изменения
Тезис:
То, о чем мы не знаем, вредит нам больше всего.
Реальные проблемы, блокеры и потенциальные зоны роста чаще всего лежат за пределами нашей компетентности.
Часто вижу, как лидеры и их команды снова и снова пытаются решать одни и те же проблемы, исходя из своего текущего уровня знаний и опыта, хотя в предыдущие итерации это должного эффекта не дало.
Я связываю это с эффектом "полной чаши". В полную чашу уже не налить воды. "Переполненная чаша" закрывает способность смотреть и видеть шире. Глубина познаний и опыта в определённой теме, особенно подкреплённая признанием окружающих, создает иллюзию экспертности во всем. А это когнитивное искажение.
Результат: команды и даже целые департаменты, дивизионы, организации "буксуют" и стоят на месте, проблема не решается. Ведь бывают целые команды этих самых экспертов, порождающих "горе от ума".
Что делать?
Чем выше и сложнее уровень проблем, тем сложнее вам будет выполнять п. 4. Сами понимаете, воронка выживших в этой эволюционной гонке сужается. Тогда ищем экспертов, решавших подобные задачи, и разговариваем с ними, слушаем и воспринимаем их фишки и аргументы, сопоставляем и анализируем. Стараемся разобраться!
Сходить в одну-две "великие" компании и формально попросить, чтобы рассказали, как они делали/делают - не вариант. На конференциях тоже все рассказывают красивые истории. Желательно проводить кропотливый "допрос", копать глубоко и спрашивать о результатах!
Несмотря на свою тривиальность, способ супер действенный. И важно не забывать, п.п. 1 и 2 имеют решающую роль. Попрётесь со своей экспертизой искать решения - так и будете тусить вместе с ней на месте. Хотя, учитывая нынешние темпы и скорости, этого самого "на месте" уже не бывает. Стоять - значит деградировать или, что хуже, "копать себе могилу".
Открытого всем разума и изящных решений. 🙌
#мышлениепредпринимателя #ростбизнеса #изменения
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍4❤1
Мысль дня!
©Томас Хаксли
Замените слово "наука" на слово "бизнес" или "продукт" и соприкоснитесь с прекрасным. 😁
Главная трагедия науки в том, что прекрасные гипотезы часто разрушаются неприглядными фактами.
©Томас Хаксли
Замените слово "наука" на слово "бизнес" или "продукт" и соприкоснитесь с прекрасным. 😁
😁6
Почему ваша команда постоянно занята, а ключевые бизнес-метрики стоят на месте?
Наверняка знакомая ситуация для многих руководителей в IT:
* Разработчики пишут код, таски в Jira закрываются сотнями.
* Отчеты показывают высокую "утилизацию" команды.
* На дейли-митингах все докладывают, что усердно работают.
Но когда вы открываете дашборд с главными показателями бизнеса (выручка, активация пользователей, удержание), вы не видите ожидаемого роста. Кажется, что команда бежит на месте. В чем причина?
Чаще всего корень проблемы — в разрыве между Discovery и Delivery.
Проблема возникает, когда процесс Delivery полностью оторван от Discovery.
Как это выглядит на практике:
* Бизнес или продакт-менеджер приносит "готовое" ТЗ.
* Команда разработки, не задавая вопросов о ценности, берет его в работу.
* Через несколько недель или месяцев фича выкатывается в прод.
* Она не приносит результата. Метрики не растут.
* Все разводят руками. Разработчики говорят: "Мы сделали все по ТЗ". Бизнес говорит: "Разработчики медленные и дорогие".
В итоге команда превращается в "фичефабрику", которая эффективно поставляет то, что никому не нужно. Энергия тратится, деньги сжигаются, бизнес не растет.
Что делать? Начать задавать правильные вопросы:
Для CTO и тимлидов:
Как мы можем помочь продактам быстрее и дешевле проверять гипотезы? Можем ли мы вместо большой фичи сделать простой MVP или A/B-тест? Как будем замерять ценность?
Для CPO и продактов:
Как мы доказываем ценность идеи перед тем, как отдать ее в дорогую разработку? Используем ли мы карты гипотез, JTBD, прототипы?
Для CEO и основателей:
Понимает ли вся команда, на какие бизнес-цели она работает? Связаны ли их OKR или KPI с реальным ростом компании, а не просто с количеством закрытых задач?
Построение моста между Discovery и Delivery — это ключ к тому, чтобы ваша команда не просто была занята, а приносила измеримый бизнес-результат.
Всем продуктивных поставок и полезных поставок, ведущих к росту бизнеса!🙌
#оргдизайн #продуктовыйменеджмент #agile #delivery #discovery #управлениекомандой
Наверняка знакомая ситуация для многих руководителей в IT:
* Разработчики пишут код, таски в Jira закрываются сотнями.
* Отчеты показывают высокую "утилизацию" команды.
* На дейли-митингах все докладывают, что усердно работают.
Но когда вы открываете дашборд с главными показателями бизнеса (выручка, активация пользователей, удержание), вы не видите ожидаемого роста. Кажется, что команда бежит на месте. В чем причина?
Чаще всего корень проблемы — в разрыве между Discovery и Delivery.
Delivery (Поставка) — это то, что команды разработки обычно делают хорошо. Это процесс создания и выпуска продукта. Они отвечают на вопрос: "Как нам сделать это правильно?" (быстро, качественно, без багов). Рекомендуемые метрики: Cycle time, Lead time, предсказуемость потока, пропускная способность (Throughput), WIP (Work In Progress), Blockers / Blocked Time (Блокеры и время блокировки).
Discovery (Исследование) — это процесс поиска ответа на вопрос: "А что правильно делать?". Какие проблемы пользователей мы решаем? Какая фича даст максимальный эффект для бизнеса? Какую гипотезу нужно проверить в первую очередь?
Проблема возникает, когда процесс Delivery полностью оторван от Discovery.
Как это выглядит на практике:
* Бизнес или продакт-менеджер приносит "готовое" ТЗ.
* Команда разработки, не задавая вопросов о ценности, берет его в работу.
* Через несколько недель или месяцев фича выкатывается в прод.
* Она не приносит результата. Метрики не растут.
* Все разводят руками. Разработчики говорят: "Мы сделали все по ТЗ". Бизнес говорит: "Разработчики медленные и дорогие".
В итоге команда превращается в "фичефабрику", которая эффективно поставляет то, что никому не нужно. Энергия тратится, деньги сжигаются, бизнес не растет.
Что делать? Начать задавать правильные вопросы:
Для CTO и тимлидов:
Как мы можем помочь продактам быстрее и дешевле проверять гипотезы? Можем ли мы вместо большой фичи сделать простой MVP или A/B-тест? Как будем замерять ценность?
Для CPO и продактов:
Как мы доказываем ценность идеи перед тем, как отдать ее в дорогую разработку? Используем ли мы карты гипотез, JTBD, прототипы?
Для CEO и основателей:
Понимает ли вся команда, на какие бизнес-цели она работает? Связаны ли их OKR или KPI с реальным ростом компании, а не просто с количеством закрытых задач?
Построение моста между Discovery и Delivery — это ключ к тому, чтобы ваша команда не просто была занята, а приносила измеримый бизнес-результат.
Всем продуктивных поставок и полезных поставок, ведущих к росту бизнеса!🙌
#оргдизайн #продуктовыйменеджмент #agile #delivery #discovery #управлениекомандой
👍10🔥5👌3⚡1
Как перестать спорить о сроках и начать поставлять ценность? Внедряем Систему Проверки Гипотез.
В прошлом посте мы говорили о разрыве между Discovery и Delivery. Команда разработки может быть супер-эффективной, но если она делает "не то", бизнес-результата не будет.
Классический симптом этой проблемы - бесконечные споры о сроках.
Продакт:
Разработчик:
Этот спор бессмысленен, потому что обе стороны говорят о разном. Продакт говорит о ценности, которую нужно получить, а разработчик - о стоимости реализации конкретного решения.
Как разорвать этот порочный круг? Перестать обсуждать "фичи" и начать обсуждать "гипотезы".
Система Проверки Гипотез - это простой, но мощный инструмент, который помогает всей команде (бизнесу, продактам, разработке) договориться на берегу, что мы делаем, зачем и как поймем, что это сработало.
Это ваш мост между Discovery и Delivery.
Ниже привожу один из возможных шаблонов формулирования гипотез:
1. Мы верим, что... (Гипотеза)
2. Чтобы проверить это, мы... (Эксперимент)
3. Мы поймем, что правы, если... (Метрики)
4. Это будет стоить нам... (Стоимость проверки)
Как я говорил выше, это лишь один из возможных шаблонов формулирования гипотезы. Не важно в каком порядке вы расставите тезисы. Главное, чтобы в формулировке гипотезы были отражены: сам эксперимент, что надо сделать, чтобы поменять поведение пользователя, метрики - как будем понимать, что гипотеза подтвердилась, стоимость/сложность проверки.
Что это дает вашей команде:
✅ Фокус на ценности: Вместо "сделать фичу" целью становится "проверить гипотезу и вырастить метрику".
✅ Снижение рисков: Вы не тратите месяцы на разработку того, что может не сработать. Стоимость ошибки минимальна.
✅ Общий язык: CTO, CPO и CEO начинают говорить на языке экспериментов и данных, а не мнений и авторитета.
✅ Скорость: Проверить 3-4 гипотезы через дешевые эксперименты можно за то же время, что пилить одну большую фичу "вслепую".
Перестаньте требовать от разработки "соблюдать сроки". Вместо этого спросите: "Как нам максимально быстро и дешево проверить вот эту гипотезу?".
Разница в результате вас удивит.
P.S. Важно сказать, что подобный подход с Системой Проверки Гипотез работает не только в софтверной разработке. При некоторой адаптации он может отлично показать себя и в других областях. Например, у меня был опыт внедрения подобного подхода в маркетинге.
Побольше вам подтвержденных гипотез и удачных экспериментов! 🙌
#продуктовыйменеджмент #agile #growthhacking #jtbd
В прошлом посте мы говорили о разрыве между Discovery и Delivery. Команда разработки может быть супер-эффективной, но если она делает "не то", бизнес-результата не будет.
Классический симптом этой проблемы - бесконечные споры о сроках.
Продакт:
"Мне нужна эта фича к концу квартала!"
Разработчик:
"Это займет полгода, тут сложная архитектура".
Этот спор бессмысленен, потому что обе стороны говорят о разном. Продакт говорит о ценности, которую нужно получить, а разработчик - о стоимости реализации конкретного решения.
Как разорвать этот порочный круг? Перестать обсуждать "фичи" и начать обсуждать "гипотезы".
Система Проверки Гипотез - это простой, но мощный инструмент, который помогает всей команде (бизнесу, продактам, разработке) договориться на берегу, что мы делаем, зачем и как поймем, что это сработало.
Это ваш мост между Discovery и Delivery.
Ниже привожу один из возможных шаблонов формулирования гипотез:
1. Мы верим, что... (Гипотеза)
Формулируем изменение в поведении пользователя, которое принесет ценность.
Пример: Мы верим, что добавление раздела "С этим товаром покупают" на страницу корзины увеличит средний чек.
2. Чтобы проверить это, мы... (Эксперимент)
Описываем минимальное действие, которое нужно совершить для проверки гипотезы. Это еще не полноценная фича!
Пример: ...мы реализуем блок с 3 статичными рекомендациями для 10% пользователей.
3. Мы поймем, что правы, если... (Метрики)
Определяем конкретные, измеримые показатели успеха. Никаких "пользователям понравится".
Пример: ...конверсия в добавление дополнительного товара из этого блока составит >5%, и средний чек в тестовой группе вырастет на 3%.
4. Это будет стоить нам... (Стоимость проверки)
Оценка трудозатрат от команды разработки на реализацию именно этого минимального эксперимента.Примечание:
Пример: ...~15 человеко-часов работы (фронтенд + бэкенд).
Как я говорил выше, это лишь один из возможных шаблонов формулирования гипотезы. Не важно в каком порядке вы расставите тезисы. Главное, чтобы в формулировке гипотезы были отражены: сам эксперимент, что надо сделать, чтобы поменять поведение пользователя, метрики - как будем понимать, что гипотеза подтвердилась, стоимость/сложность проверки.
Что это дает вашей команде:
✅ Фокус на ценности: Вместо "сделать фичу" целью становится "проверить гипотезу и вырастить метрику".
✅ Снижение рисков: Вы не тратите месяцы на разработку того, что может не сработать. Стоимость ошибки минимальна.
✅ Общий язык: CTO, CPO и CEO начинают говорить на языке экспериментов и данных, а не мнений и авторитета.
✅ Скорость: Проверить 3-4 гипотезы через дешевые эксперименты можно за то же время, что пилить одну большую фичу "вслепую".
Перестаньте требовать от разработки "соблюдать сроки". Вместо этого спросите: "Как нам максимально быстро и дешево проверить вот эту гипотезу?".
Разница в результате вас удивит.
P.S. Важно сказать, что подобный подход с Системой Проверки Гипотез работает не только в софтверной разработке. При некоторой адаптации он может отлично показать себя и в других областях. Например, у меня был опыт внедрения подобного подхода в маркетинге.
Побольше вам подтвержденных гипотез и удачных экспериментов! 🙌
#продуктовыйменеджмент #agile #growthhacking #jtbd
👍5🔥5
Про Систему Проверки Гипотез...
В предыдущем посте я сфокусировался на формулировании гипотез и на картинке привел пример - как подобная система может строиться и выглядеть.
В реальных продуктах с этим подходом нам удавалось делать кратный рост. В одном ИТ продукте, например, мы за 14 месяцев добежали до выручки 100+ млн в год. Точка А была +/- 10 млн в год.
Дайте огоньков, расскажу подробнее, как этой системой управлять. 😁😉
В предыдущем посте я сфокусировался на формулировании гипотез и на картинке привел пример - как подобная система может строиться и выглядеть.
В реальных продуктах с этим подходом нам удавалось делать кратный рост. В одном ИТ продукте, например, мы за 14 месяцев добежали до выручки 100+ млн в год. Точка А была +/- 10 млн в год.
Дайте огоньков, расскажу подробнее, как этой системой управлять. 😁😉
Telegram
Механика Эволюции Бизнеса
Как перестать спорить о сроках и начать поставлять ценность? Внедряем Систему Проверки Гипотез.
В прошлом посте мы говорили о разрыве между Discovery и Delivery. Команда разработки может быть супер-эффективной, но если она делает "не то", бизнес-результата…
В прошлом посте мы говорили о разрыве между Discovery и Delivery. Команда разработки может быть супер-эффективной, но если она делает "не то", бизнес-результата…
🔥12
У вас больше 10 гипотез в работе? Пора перестать управлять ими в голове и построить систему.
Итак, вы начали мыслить гипотезами. Это уже огромный шаг к созданию продуктов, которые нужны рынку. Но тут возникает новая проблема:
* Одна гипотеза проверяется в A/B-тесте.
* Вторая ждет дизайнера.
* Третью обсуждали на прошлой неделе, но забыли записать.
* Четвертая оказалась успешной, но никто не помнит точных цифр.
В итоге вместо системной работы - хаос. Ценные инсайты теряются, а команда не понимает, что сейчас в приоритете.
Ниже поделюсь моим способом решения - Канбан-доска для трекинга гипотез.
Это не просто набор колонок, а визуализация всего вашего процесса генерации и проверки ценности — от смутной идеи до подтвержденного бизнес-результата. Давайте разберем на примере (см. изображение в предыдущем посте), как работает этот конвейер.
____
Шаг за шагом по доске гипотез:
1. Идеи (Бэклог)
Это ваш "входящий" поток. Сюда попадает абсолютно всё: инсайты после общения с клиентом, идеи с командного брейншторма, предложения от техподдержки. На этом этапе нет критики и отбора. Задача - зафиксировать мысль.
На доске: "Если организуем e-mail рассылку..."
2. Гипотезы (Формулировка)
Здесь идея превращается в структурированную гипотезу. Мы берем сырую мысль из бэклога и "упаковываем" ее по четкому шаблону (как в прошлом посте): определяем эксперимент, метрики успеха и ожидаемую стоимость проверки.
На доске: "Если заменим офер..., то увеличим конверсию на 2%". Идея получила конкретику и измеримость.
3. Приоритизация
Самый важный этап для бизнеса. Здесь команда (CPO, CTO, маркетинг) решает, какую гипотезу взять в работу следующей. Используйте любую удобную модель (ICE, RICE, или просто оценку "влияние/усилия"), чтобы выбрать эксперимент, который даст максимум знаний при минимуме затрат.
На доске: гипотезы получают теги: "Доход", "Привлечение", "Удержание", что помогает в принятии решений.
4. Проверка (В работе)
Колонка для гипотез, над которыми прямо сейчас работает команда. Разрабатывается MVP, настраивается A/B-тест, запускается рекламная кампания. Важно ограничивать количество задач в этой колонке (WIP-лимит), чтобы не распылять фокус и быстрее получать результат.
5. Сбор метрик
Эксперимент завершен. Теперь мы собираем данные. На этом этапе гипотеза "остывает", пока мы не наберем статистически значимый объем информации для принятия решения.
6. Подтверждена / Не подтверждена
Финал.
Мы анализируем данные и делаем однозначный вывод.
Подтверждена: Отлично! Мы принимаем решение о масштабировании (раскатываем фичу на всех, вкладываем бюджет в канал).
Не подтверждена: Тоже отлично! Мы только что сэкономили месяцы разработки и сотни тысяч рублей, не став делать ненужную вещь. Мы получили ценный инсайт о наших пользователях.
____
Такая доска делает процесс проверки гипотез прозрачным, управляемым и, самое главное, предсказуемым. Вы в любой момент времени знаете, сколько у вас идей, что проверяется и что из этого работает.
Это и есть настоящий, системный Growth Hacking.
Всем системы и порядка в процессах! 🙌
P.S. Накидайте реакций если интересно, что я имел в виду здесь в п.3. 😉
В отдельном посте я подробнее расскажу о системе тегирования гипотез и зачем это нужно.
#kanban #agile #продуктовыйменеджмент #growthhacking #оргдизайн
Итак, вы начали мыслить гипотезами. Это уже огромный шаг к созданию продуктов, которые нужны рынку. Но тут возникает новая проблема:
* Одна гипотеза проверяется в A/B-тесте.
* Вторая ждет дизайнера.
* Третью обсуждали на прошлой неделе, но забыли записать.
* Четвертая оказалась успешной, но никто не помнит точных цифр.
В итоге вместо системной работы - хаос. Ценные инсайты теряются, а команда не понимает, что сейчас в приоритете.
Ниже поделюсь моим способом решения - Канбан-доска для трекинга гипотез.
Это не просто набор колонок, а визуализация всего вашего процесса генерации и проверки ценности — от смутной идеи до подтвержденного бизнес-результата. Давайте разберем на примере (см. изображение в предыдущем посте), как работает этот конвейер.
____
Шаг за шагом по доске гипотез:
1. Идеи (Бэклог)
Это ваш "входящий" поток. Сюда попадает абсолютно всё: инсайты после общения с клиентом, идеи с командного брейншторма, предложения от техподдержки. На этом этапе нет критики и отбора. Задача - зафиксировать мысль.
На доске: "Если организуем e-mail рассылку..."
2. Гипотезы (Формулировка)
Здесь идея превращается в структурированную гипотезу. Мы берем сырую мысль из бэклога и "упаковываем" ее по четкому шаблону (как в прошлом посте): определяем эксперимент, метрики успеха и ожидаемую стоимость проверки.
На доске: "Если заменим офер..., то увеличим конверсию на 2%". Идея получила конкретику и измеримость.
3. Приоритизация
Самый важный этап для бизнеса. Здесь команда (CPO, CTO, маркетинг) решает, какую гипотезу взять в работу следующей. Используйте любую удобную модель (ICE, RICE, или просто оценку "влияние/усилия"), чтобы выбрать эксперимент, который даст максимум знаний при минимуме затрат.
На доске: гипотезы получают теги: "Доход", "Привлечение", "Удержание", что помогает в принятии решений.
4. Проверка (В работе)
Колонка для гипотез, над которыми прямо сейчас работает команда. Разрабатывается MVP, настраивается A/B-тест, запускается рекламная кампания. Важно ограничивать количество задач в этой колонке (WIP-лимит), чтобы не распылять фокус и быстрее получать результат.
5. Сбор метрик
Эксперимент завершен. Теперь мы собираем данные. На этом этапе гипотеза "остывает", пока мы не наберем статистически значимый объем информации для принятия решения.
6. Подтверждена / Не подтверждена
Финал.
Мы анализируем данные и делаем однозначный вывод.
Подтверждена: Отлично! Мы принимаем решение о масштабировании (раскатываем фичу на всех, вкладываем бюджет в канал).
Не подтверждена: Тоже отлично! Мы только что сэкономили месяцы разработки и сотни тысяч рублей, не став делать ненужную вещь. Мы получили ценный инсайт о наших пользователях.
____
Такая доска делает процесс проверки гипотез прозрачным, управляемым и, самое главное, предсказуемым. Вы в любой момент времени знаете, сколько у вас идей, что проверяется и что из этого работает.
Это и есть настоящий, системный Growth Hacking.
Всем системы и порядка в процессах! 🙌
P.S. Накидайте реакций если интересно, что я имел в виду здесь в п.3. 😉
На доске: гипотезы получают теги: "Доход", "Привлечение", "Удержание", что помогает в принятии решений.
В отдельном посте я подробнее расскажу о системе тегирования гипотез и зачем это нужно.
#kanban #agile #продуктовыйменеджмент #growthhacking #оргдизайн
Telegram
Механика Эволюции Бизнеса
Как перестать спорить о сроках и начать поставлять ценность? Внедряем Систему Проверки Гипотез.
В прошлом посте мы говорили о разрыве между Discovery и Delivery. Команда разработки может быть супер-эффективной, но если она делает "не то", бизнес-результата…
В прошлом посте мы говорили о разрыве между Discovery и Delivery. Команда разработки может быть супер-эффективной, но если она делает "не то", бизнес-результата…
🔥6👍2
Как понять, какую гипотезу выбрать? Привяжите ее к вашей воронке роста.
В прошлый раз мы говорили о Канбан-доске для трекинга гипотез. Вы могли заметить, что у карточек были теги: "Привлечение", "Удержание", "Доход" и пр. Это не просто метки для удобства. Это — ваш стратегический компас.
Каждый такой тег привязывает гипотезу с конкретным этапом "пиратской" воронки AAARRR (или AARRR, если убрать Awareness). Это фреймворк, который декомпозирует рост вашего бизнеса на ключевые этапы.
Чтобы ваши эксперименты не были хаотичными, первый шаг — найти самое узкое место в вашей воронке. Где вы теряете больше всего клиентов или денег? Именно туда и нужно направить фокус вашей команды.
Давайте разберем, что означает каждый тег на доске и какие гипотезы за ним стоят.
____
(A)wareness / Информирование
Вопрос: Как потенциальные клиенты вообще узнают о нашем существовании?
Пример гипотезы: "Мы верим, что публикация экспертной статьи на VC.ru приведет к нам 1000 целевых посетителей на сайт".
Цель: Расширить охват, повысить узнаваемость бренда.
(A)cquisition / Привлечение
Вопрос: Как нам превратить посетителя сайта или подписчика в лида (например, в того, кто оставил заявку)?
Пример гипотезы: "Мы верим, что замена формата лендинга с формата 1 на формат 2 увеличит конверсию в заявку на 2%".
Цель: Увеличить количество регистраций, заявок, установок.
(A)ctivation / Активация
Вопрос: Как сделать так, чтобы новый пользователь получил первую ценность от продукта и понял, "что здесь к чему"?
Пример гипотезы: "Мы верим, что внедрение интерактивного онбординга вместо серии писем увеличит долю пользователей, создавших свой первый проект, на 15%".
Цель: Повысить вовлеченность на старте, довести до "Aha-момента".
(R)etention / Удержание
Вопрос: Как сделать так, чтобы пользователи возвращались в наш продукт снова и снова?
Пример гипотезы: "Мы верим, что еженедельная email-рассылка с итогами недели в их аккаунте заставит 20% пользователей вернуться в продукт".
Цель: Снизить отток (Churn Rate), повысить пожизненную ценность клиента (LTV).
(R)evenue / Доход
Вопрос: Как нам увеличить заработок с одного пользователя?
Пример гипотезы: "Мы верим, что предложение дополнительной услуги по прокачке продаж в комплекте с основным продуктом увеличит средний чек на 20%".
Цель: Увеличить средний чек (ARPU/ARPC), повысить конверсию в платящего.
(R)eferral / Виральность
Вопрос: Как сделать так, чтобы наши текущие пользователи приводили нам новых?
Пример гипотезы: "Мы верим, что бонус "приведи друга и получи месяц бесплатно" увеличит виральный коэффициент до 1.1".
Цель: Снизить стоимость привлечения клиента (CAC), запустить сарафанное радио.
Как это использовать на практике:
Оцифруйте вашу воронку. Найдите этап, где теряется больше всего пользователей. Это ваше ограничение. Сфокусируйте 80% гипотез на решении проблемы именно на этом этапе.
Если необходимо, то приоритизируйте также гипотезы внутри каждого этапа воронки (тега на доске).
Следует отметить, что именно ваша воронка может и зачастую должна быть кастомизирована. Я взял типовую для удобства разбора механики и отражения смыслов.
Так вы перестаете "стрелять из пушки по воробьям" и начинаете целенаправленно расширять самое узкое место в вашем бизнесе.
Это и есть работа на стыке продуктового менеджмента, маркетинга и системного подхода.
Всем фокусировки на самом важном - на том, что может дать наибольший эффект! 😉🙌
#продуктовыйменеджмент #growthhacking
В прошлый раз мы говорили о Канбан-доске для трекинга гипотез. Вы могли заметить, что у карточек были теги: "Привлечение", "Удержание", "Доход" и пр. Это не просто метки для удобства. Это — ваш стратегический компас.
Каждый такой тег привязывает гипотезу с конкретным этапом "пиратской" воронки AAARRR (или AARRR, если убрать Awareness). Это фреймворк, который декомпозирует рост вашего бизнеса на ключевые этапы.
Чтобы ваши эксперименты не были хаотичными, первый шаг — найти самое узкое место в вашей воронке. Где вы теряете больше всего клиентов или денег? Именно туда и нужно направить фокус вашей команды.
Давайте разберем, что означает каждый тег на доске и какие гипотезы за ним стоят.
____
(A)wareness / Информирование
Вопрос: Как потенциальные клиенты вообще узнают о нашем существовании?
Пример гипотезы: "Мы верим, что публикация экспертной статьи на VC.ru приведет к нам 1000 целевых посетителей на сайт".
Цель: Расширить охват, повысить узнаваемость бренда.
(A)cquisition / Привлечение
Вопрос: Как нам превратить посетителя сайта или подписчика в лида (например, в того, кто оставил заявку)?
Пример гипотезы: "Мы верим, что замена формата лендинга с формата 1 на формат 2 увеличит конверсию в заявку на 2%".
Цель: Увеличить количество регистраций, заявок, установок.
(A)ctivation / Активация
Вопрос: Как сделать так, чтобы новый пользователь получил первую ценность от продукта и понял, "что здесь к чему"?
Пример гипотезы: "Мы верим, что внедрение интерактивного онбординга вместо серии писем увеличит долю пользователей, создавших свой первый проект, на 15%".
Цель: Повысить вовлеченность на старте, довести до "Aha-момента".
(R)etention / Удержание
Вопрос: Как сделать так, чтобы пользователи возвращались в наш продукт снова и снова?
Пример гипотезы: "Мы верим, что еженедельная email-рассылка с итогами недели в их аккаунте заставит 20% пользователей вернуться в продукт".
Цель: Снизить отток (Churn Rate), повысить пожизненную ценность клиента (LTV).
(R)evenue / Доход
Вопрос: Как нам увеличить заработок с одного пользователя?
Пример гипотезы: "Мы верим, что предложение дополнительной услуги по прокачке продаж в комплекте с основным продуктом увеличит средний чек на 20%".
Цель: Увеличить средний чек (ARPU/ARPC), повысить конверсию в платящего.
(R)eferral / Виральность
Вопрос: Как сделать так, чтобы наши текущие пользователи приводили нам новых?
Пример гипотезы: "Мы верим, что бонус "приведи друга и получи месяц бесплатно" увеличит виральный коэффициент до 1.1".
Цель: Снизить стоимость привлечения клиента (CAC), запустить сарафанное радио.
Как это использовать на практике:
Если необходимо, то приоритизируйте также гипотезы внутри каждого этапа воронки (тега на доске).
Следует отметить, что именно ваша воронка может и зачастую должна быть кастомизирована. Я взял типовую для удобства разбора механики и отражения смыслов.
Так вы перестаете "стрелять из пушки по воробьям" и начинаете целенаправленно расширять самое узкое место в вашем бизнесе.
Это и есть работа на стыке продуктового менеджмента, маркетинга и системного подхода.
Всем фокусировки на самом важном - на том, что может дать наибольший эффект! 😉🙌
#продуктовыйменеджмент #growthhacking
👍5🤩2⚡1🔥1
В поисках «говорящего Буратино» для вашего бизнеса
Привет! 👋
Сегодня пишу о наболевшем. Меня тут недавно захлестнули размышления. Хочу поделиться с вами и узнать ваше мнение.
В основе размышлений - тезис, который я пока сформулировал так:
"Капитан Очевидность!" - скажете вы. И будете правы. Но попробую копнуть глубже.
______
Запрос на «КАК?»
Я постоянно слышу от клиентов:
👉 "КАК нам заработать больше денег?»
👉 "КАК нам вырасти в X раз?"
👉 "КАК масштабировать продукт?"
Это абсолютно нормальные вопросы. Но единицы задают другой, гораздо более важный вопрос: "А какие УСЛОВИЯ для этого должны быть соблюдены?» (Вопрос "ЗАЧЕМ?" пока оставим за скобками, допустим, с ним всё ясно).
Гонка «быстрее-скорее» заставляет нас искать «волшебные таблетки» и простые рецепты. Мы сосредотачиваемся на технике прямого воздействия...
Бежит домой, берёт рубанок, полено, повторяет движения. Что-то даже получается... Вот только Буратино не разговаривает. А со временем ещё и трескается.
______
Секрет Папы Карло
А всё потому, что у Папы Карло никто не спросил про УСЛОВИЯ, при которых работает его «инструкция». А там, оказывается, целый мир:
🌲 Правильная влажность древесины.
🔪 Острота и удобство инструментов.
⚒️Предварительная обработка заготовок.
🤝 Долгая практика с мастером.
🔥 Сильное намерение (та самая «болючая проблема»).
✨ И ещё какая-то «хренова магия», которую столяр впитал за годы практики.
Папа Карло знает об этих условиях. Поэтому его Буратино и говорит, и не разваливается.
______
Мудрые и остальные
Я замечал, что опытные и мудрые учителя раскладывают любое «КАК» на две части:
1️⃣ Прямое воздействие (сама техника).
2️⃣ Условия, при которых эта техника (рецепт, приём) сработает.
Но то опытные и мудрые. А остальные:
а) Знают только первую часть и не думают о второй.
b) Стали догадываться о второй части, но пока не могут её сформулировать.
c) Осознали, но не знают, как «продать» эту идею, потому что в ответ часто слышат: «Сложнааа, не душни, давай по делу!»
______
Похоже, что в комплексных системах (а бизнес - это комплексная система) прямых методов недостаточно. Крайне важно задавать себе вопрос: «При КАКИХ УСЛОВИЯХ эта инструкция/фреймворк/методика сработает у НАС?»
Тогда, может быть, мы начнем задумываться о проблемах, которые решаем изменениями, о поддержке топов и/или основателя, которая так важна при изменениях и пр.
Тогда, возможно, мы лучше поймем, когда и как наши команды с большей вероятностью добьются нужного результата.
И безумных, бесполезных «трансформаций» и внедрений очередного «модного фреймворка» станет чуть меньше.
...Но это не точно. 😉
А что вы думаете по этому поводу?
#система #стратегия #agile #трансформация #бизнес
Привет! 👋
Сегодня пишу о наболевшем. Меня тут недавно захлестнули размышления. Хочу поделиться с вами и узнать ваше мнение.
В основе размышлений - тезис, который я пока сформулировал так:
Вероятность стабильного повторения результата повышается при выполнении и соблюдении требуемых условий. Прямого воздействия на объект комплексных изменений недостаточно. ©
"Капитан Очевидность!" - скажете вы. И будете правы. Но попробую копнуть глубже.
______
Запрос на «КАК?»
Я постоянно слышу от клиентов:
👉 "КАК нам заработать больше денег?»
👉 "КАК нам вырасти в X раз?"
👉 "КАК масштабировать продукт?"
Это абсолютно нормальные вопросы. Но единицы задают другой, гораздо более важный вопрос: "А какие УСЛОВИЯ для этого должны быть соблюдены?» (Вопрос "ЗАЧЕМ?" пока оставим за скобками, допустим, с ним всё ясно).
Гонка «быстрее-скорее» заставляет нас искать «волшебные таблетки» и простые рецепты. Мы сосредотачиваемся на технике прямого воздействия...
- О, какой крутой Буратино у тебя получается! Покажи, КАК? - Ага, понял...
Бежит домой, берёт рубанок, полено, повторяет движения. Что-то даже получается... Вот только Буратино не разговаривает. А со временем ещё и трескается.
______
Секрет Папы Карло
А всё потому, что у Папы Карло никто не спросил про УСЛОВИЯ, при которых работает его «инструкция». А там, оказывается, целый мир:
🌲 Правильная влажность древесины.
🔪 Острота и удобство инструментов.
⚒️Предварительная обработка заготовок.
🤝 Долгая практика с мастером.
🔥 Сильное намерение (та самая «болючая проблема»).
✨ И ещё какая-то «хренова магия», которую столяр впитал за годы практики.
Папа Карло знает об этих условиях. Поэтому его Буратино и говорит, и не разваливается.
______
Мудрые и остальные
Я замечал, что опытные и мудрые учителя раскладывают любое «КАК» на две части:
Но то опытные и мудрые. А остальные:
а) Знают только первую часть и не думают о второй.
b) Стали догадываться о второй части, но пока не могут её сформулировать.
c) Осознали, но не знают, как «продать» эту идею, потому что в ответ часто слышат: «Сложнааа, не душни, давай по делу!»
______
Похоже, что в комплексных системах (а бизнес - это комплексная система) прямых методов недостаточно. Крайне важно задавать себе вопрос: «При КАКИХ УСЛОВИЯХ эта инструкция/фреймворк/методика сработает у НАС?»
Тогда, может быть, мы начнем задумываться о проблемах, которые решаем изменениями, о поддержке топов и/или основателя, которая так важна при изменениях и пр.
Тогда, возможно, мы лучше поймем, когда и как наши команды с большей вероятностью добьются нужного результата.
И безумных, бесполезных «трансформаций» и внедрений очередного «модного фреймворка» станет чуть меньше.
...Но это не точно. 😉
А что вы думаете по этому поводу?
#система #стратегия #agile #трансформация #бизнес
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍2🔥1
🙌
Поэкспериментировал с методическим контентом, поделился мыслями.
Пока не однозначно понял, что вам заходит. 🤔
Поделитесь в комментах, какой контент интереснее, полезнее?
Теперь, пожалуй, поэкспериментирую с кейсами.
Сегодня поделюсь первой частью кейса: Как мы ускорили поставку кода на 40%, перестав "ускорять" разработчиков.
Всего частей будет 4.
Т.к. там была целая многоходовка. :)
Поэкспериментировал с методическим контентом, поделился мыслями.
Пока не однозначно понял, что вам заходит. 🤔
Поделитесь в комментах, какой контент интереснее, полезнее?
Теперь, пожалуй, поэкспериментирую с кейсами.
Сегодня поделюсь первой частью кейса: Как мы ускорили поставку кода на 40%, перестав "ускорять" разработчиков.
Всего частей будет 4.
Т.к. там была целая многоходовка. :)
👍4🔥3
Кейс: Как мы ускорили поставку кода на 40%, перестав "ускорять" разработчиков.
Часть 1/4: Поиск ограничения.
Ко мне обратился CTO технологической компании с классической проблемой:
Знакомая история, правда?
Далее я расскажу в четырех частях, как мы решали задачу сокращения времени поставки.
Вместо того, чтобы искать виноватых, мы с CTO решили найти системное ограничение (то самое "бутылочное горлышко"), которое тормозило весь процесс.
Шаг 1: Визуализация и анализ потока:
Разложили весь процесс поставки ценности на этапы и замерили Cycle Time для каждого из них:
- Аналитика и проектирование: ~3 дня
- Разработка: ~5 дней
- Ревью кода (Code Review): ~8 дней!
- Тестирование: ~4 дня
- Релиз: ~1 день
Ограничение найдено. Задачи проводили в ожидании и прохождении ревью кода почти в два раза больше времени, чем в самой разработке. В целом, команда справлялась не плохо, но их результат просто "простаивал" в очереди.
Шаг 2: Первые быстрые решения:
Мы сфокусировались на решении проблемы именно с ревью. И начали с самого очевидного — размера задач, которые поступали на проверку. Команда часто отправляла на ревью огромные Merge Requests (MR).
———
справка для тех, кто не из ИТ:
Что такое MR?
Merge Request (или Pull Request) — это запрос от разработчика на добавление его нового кода в основной проект. Это стандартный этап проверки качества в современной разработке.
———
Проблема в том, что проверить огромный MR на 2000 строк кода — это ад для ревьюера. Такую задачу постоянно откладывают, она требует огромной концентрации.
Поэтому нашим первым и главным решением стало правило: "Ограничить размер MR". Мы договорились отправлять код на проверку маленькими, логически завершенными порциями.
Помимо этого, мы внедрили еще пару правил:
Приоритет №1 для тимлидов: Ревью кода стало их главной задачей.
Ввели SLA: Договорились, что любой MR должен получить первую реакцию в течение 4-х рабочих часов.
Результаты первого этапа.
Уже эти простые организационные изменения дали невероятный эффект:
1️⃣ Среднее время на этапе ревью кода сократилось с 8 до 4 дней.
2️⃣ Общий Time-to-Market уменьшился на 20%.
3️⃣ Уровень стресса в команде снизился, так как исчезли "зависшие" на несколько дней задачи.
Но мы понимали, что это только начало. Ведь сказать команде "делайте задачи меньше" — легко. А вот КАК научить их это делать системно?
Об этом — в следующей части кейса.
Расскажу, как мы учили команду правильно декомпозировать задачи и почему это изменило всё.
Накидайте огня 🔥, если ждете продолжения!
Ну и всем скорости (там где надо)! 😁🙌
#кейс #теорияограничений #agile #kanban #timetomarket #cto #оргдизайн #devops
Часть 1/4: Поиск ограничения.
Ко мне обратился CTO технологической компании с классической проблемой:
"Мы медленно выкатываем фичи. Бизнес недоволен, команда демотивирована. Я требую от них работать быстрее, но Time-to-Market только растет".
Знакомая история, правда?
Далее я расскажу в четырех частях, как мы решали задачу сокращения времени поставки.
Вместо того, чтобы искать виноватых, мы с CTO решили найти системное ограничение (то самое "бутылочное горлышко"), которое тормозило весь процесс.
Шаг 1: Визуализация и анализ потока:
Разложили весь процесс поставки ценности на этапы и замерили Cycle Time для каждого из них:
- Аналитика и проектирование: ~3 дня
- Разработка: ~5 дней
- Ревью кода (Code Review): ~8 дней!
- Тестирование: ~4 дня
- Релиз: ~1 день
Ограничение найдено. Задачи проводили в ожидании и прохождении ревью кода почти в два раза больше времени, чем в самой разработке. В целом, команда справлялась не плохо, но их результат просто "простаивал" в очереди.
Шаг 2: Первые быстрые решения:
Мы сфокусировались на решении проблемы именно с ревью. И начали с самого очевидного — размера задач, которые поступали на проверку. Команда часто отправляла на ревью огромные Merge Requests (MR).
———
справка для тех, кто не из ИТ:
Что такое MR?
Merge Request (или Pull Request) — это запрос от разработчика на добавление его нового кода в основной проект. Это стандартный этап проверки качества в современной разработке.
———
Проблема в том, что проверить огромный MR на 2000 строк кода — это ад для ревьюера. Такую задачу постоянно откладывают, она требует огромной концентрации.
Поэтому нашим первым и главным решением стало правило: "Ограничить размер MR". Мы договорились отправлять код на проверку маленькими, логически завершенными порциями.
Помимо этого, мы внедрили еще пару правил:
Приоритет №1 для тимлидов: Ревью кода стало их главной задачей.
Ввели SLA: Договорились, что любой MR должен получить первую реакцию в течение 4-х рабочих часов.
Результаты первого этапа.
Уже эти простые организационные изменения дали невероятный эффект:
Но мы понимали, что это только начало. Ведь сказать команде "делайте задачи меньше" — легко. А вот КАК научить их это делать системно?
Об этом — в следующей части кейса.
Расскажу, как мы учили команду правильно декомпозировать задачи и почему это изменило всё.
Накидайте огня 🔥, если ждете продолжения!
Ну и всем скорости (там где надо)! 😁🙌
#кейс #теорияограничений #agile #kanban #timetomarket #cto #оргдизайн #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍2
Природа и следствия противоречий
Готовлюсь к курсу - читаю бесконечно обожаемого мной Голдратта - "Выбор".
Делюсь выжимкой мысли.
1️⃣ Нежелательные явления и проблемы часто в своей основе имеют конфликты.
2️⃣ Конфликты часто являются следствием отсутствия приемлемого для сторон компромисса.
3️⃣ Приемлемый компромисс и консенсус сторон зачастую невозможен потому, что в основе лежат противоречия, которых мы хотим.
(10 шапок из одной шкуры; легкий, экономичный, суперпрочный, супербыстрый и дешевый джет; 10 проектов на 2 человека; умные, ответственные, самостоятельные сотрудники, которые должны делать то, что я говорю; консультант, который научит всех, кого я нанял, быть умными и годными и т.п.)
4️⃣ Если необходимо устранить проблему или нежелательное явление, необходимо смотреть в ключевые предпосылки и в природу, лежащего в основе этих явлений, противоречия!
По-моему - Гениально!
Желая починить проблему, ищите противоречия и устраняйте/нейтрализуйте их, друзья! 🙌
—————
P.S. Завтра продолжение кейса: "Как мы ускорили поставку кода. Часть 2/4: Искусство декомпозиции." 😉
#TOC #теорияограничений #Голдратт
Готовлюсь к курсу - читаю бесконечно обожаемого мной Голдратта - "Выбор".
Делюсь выжимкой мысли.
1️⃣ Нежелательные явления и проблемы часто в своей основе имеют конфликты.
2️⃣ Конфликты часто являются следствием отсутствия приемлемого для сторон компромисса.
3️⃣ Приемлемый компромисс и консенсус сторон зачастую невозможен потому, что в основе лежат противоречия, которых мы хотим.
(10 шапок из одной шкуры; легкий, экономичный, суперпрочный, супербыстрый и дешевый джет; 10 проектов на 2 человека; умные, ответственные, самостоятельные сотрудники, которые должны делать то, что я говорю; консультант, который научит всех, кого я нанял, быть умными и годными и т.п.)
4️⃣ Если необходимо устранить проблему или нежелательное явление, необходимо смотреть в ключевые предпосылки и в природу, лежащего в основе этих явлений, противоречия!
По-моему - Гениально!
Желая починить проблему, ищите противоречия и устраняйте/нейтрализуйте их, друзья! 🙌
—————
P.S. Завтра продолжение кейса: "Как мы ускорили поставку кода. Часть 2/4: Искусство декомпозиции." 😉
#TOC #теорияограничений #Голдратт
🔥6❤1
Кейс: Как мы ускорили поставку кода.
Часть 2/4: Искусство декомпозиции.
В прошлой части 1 мы нашли "бутылочное горлышко" — этап ревью кода. Чтобы его расширить, команде нужно было научиться системно работать с маленькими задачами.
Просто сказать "режьте задачи мельче" — не работает. В ответ вы услышите: "Это невозможно, фича слишком сложная и связанная!".
Проблема не в сложности фичи, а в подходе к ее разделению. Мы перестали говорить о "слоях" и ввели два простых, но мощных принципа.
Принцип 1: "Принцип Бургера" (или Вертикальный срез)
Команды часто режут задачи "горизонтально", по технологическим слоям. Это как если бы повар отдавал вам бургер на тарелку перед вами по частям: сначала испек все булочки, потом пожарил все котлеты, потом нарезал весь салат. Клиент ждет, но не получает полноценного блюда, пока все компоненты не будут готовы и собраны.
Мы перешли на "Принцип Бургера" (или "вертикальный срез"). Суть в том, чтобы каждый раз давать пользователю возможность "откусить" маленький, но полноценный кусочек продукта, в котором есть все слои: и фронтенд, и бэкенд, и база данных.
Пример: фича "Профиль пользователя"
Плохо (горизонтально):
1) Сделать всю базу.
2) Сделать все API.
3) Сверстать весь профиль.
Хорошо ("Принцип Бургера"):
Укус 1: Реализовать простое отображение имени и аватара. <-- Уже готовый мини-бургер, можно пробовать!
Укус 2: Добавить возможность редактирования имени.
Укус 3: Добавить возможность загрузки нового аватара.
Каждый такой "укус" — это маленькая, понятная задача, которую можно сделать, отревьюить и выкатить за 1-2 дня.
Принцип 2: Техника "Шаги младенца" (Baby Steps)
Для особенно сложных и "неделимых" задач мы использовали простой вопрос:
"Представь, что у тебя есть всего 2 часа. Какой самый маленький, но осмысленный шаг ты можешь сделать в сторону реализации этой фичи, чтобы его можно было проверить?"
Этот вопрос волшебным образом меняет оптику. Вместо мыслей о конечной архитектуре разработчик начинает думать о первом шаге.
Результаты внедрения этих техник:
✅ Команда научилась видеть большие фичи как набор маленьких, независимых "бургеров".
✅ Размер Merge Requests сократился в среднем в 3-4 раза.
✅ "Пробка" на этапе ревью кода практически исчезла.
Но оставалась еще одна проблема: как убедиться, что эти маленькие, быстрые "укусы" не ломают то, что уже работает? Для этого нам пришлось освоить еще одну практику — разработку через тестирование (TDD).
Об этом — в третьей части кейса.😉
Дайте знать в комментариях, понравился ли вам "Принцип Бургера"? 👇
"Кормите" людей быстро, пусть и не большими частями полноценного блюда!😉😁
#кейс #декомпозиция #agile #scrum #verticalslicing #оргдизайн #управлениекомандами #devops
Часть 2/4: Искусство декомпозиции.
В прошлой части 1 мы нашли "бутылочное горлышко" — этап ревью кода. Чтобы его расширить, команде нужно было научиться системно работать с маленькими задачами.
Просто сказать "режьте задачи мельче" — не работает. В ответ вы услышите: "Это невозможно, фича слишком сложная и связанная!".
Проблема не в сложности фичи, а в подходе к ее разделению. Мы перестали говорить о "слоях" и ввели два простых, но мощных принципа.
Принцип 1: "Принцип Бургера" (или Вертикальный срез)
Команды часто режут задачи "горизонтально", по технологическим слоям. Это как если бы повар отдавал вам бургер на тарелку перед вами по частям: сначала испек все булочки, потом пожарил все котлеты, потом нарезал весь салат. Клиент ждет, но не получает полноценного блюда, пока все компоненты не будут готовы и собраны.
Мы перешли на "Принцип Бургера" (или "вертикальный срез"). Суть в том, чтобы каждый раз давать пользователю возможность "откусить" маленький, но полноценный кусочек продукта, в котором есть все слои: и фронтенд, и бэкенд, и база данных.
Пример: фича "Профиль пользователя"
Плохо (горизонтально):
1) Сделать всю базу.
2) Сделать все API.
3) Сверстать весь профиль.
Хорошо ("Принцип Бургера"):
Укус 1: Реализовать простое отображение имени и аватара. <-- Уже готовый мини-бургер, можно пробовать!
Укус 2: Добавить возможность редактирования имени.
Укус 3: Добавить возможность загрузки нового аватара.
Каждый такой "укус" — это маленькая, понятная задача, которую можно сделать, отревьюить и выкатить за 1-2 дня.
Принцип 2: Техника "Шаги младенца" (Baby Steps)
Для особенно сложных и "неделимых" задач мы использовали простой вопрос:
"Представь, что у тебя есть всего 2 часа. Какой самый маленький, но осмысленный шаг ты можешь сделать в сторону реализации этой фичи, чтобы его можно было проверить?"
Этот вопрос волшебным образом меняет оптику. Вместо мыслей о конечной архитектуре разработчик начинает думать о первом шаге.
Результаты внедрения этих техник:
Но оставалась еще одна проблема: как убедиться, что эти маленькие, быстрые "укусы" не ломают то, что уже работает? Для этого нам пришлось освоить еще одну практику — разработку через тестирование (TDD).
Об этом — в третьей части кейса.😉
Дайте знать в комментариях, понравился ли вам "Принцип Бургера"? 👇
"Кормите" людей быстро, пусть и не большими частями полноценного блюда!😉😁
#кейс #декомпозиция #agile #scrum #verticalslicing #оргдизайн #управлениекомандами #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Механика Эволюции Бизнеса
Кейс: Как мы ускорили поставку кода на 40%, перестав "ускорять" разработчиков.
Часть 1/4: Поиск ограничения.
Ко мне обратился CTO технологической компании с классической проблемой:
"Мы медленно выкатываем фичи. Бизнес недоволен, команда демотивирована.…
Часть 1/4: Поиск ограничения.
Ко мне обратился CTO технологической компании с классической проблемой:
"Мы медленно выкатываем фичи. Бизнес недоволен, команда демотивирована.…
👍9❤2🔥2
Кейс: Как мы ускорили поставку кода.
Часть 3/4: TDD — наш ремень безопасности.
Итак, в первой части мы нашли "бутылочное горлышко", а во второй части научились декомпозировать задачи по "Принципу Бургера". Команда начала поставлять ценность маленькими, быстрыми порциями.
Но тут возник новый, предсказуемый страх, особенно у CTO и тимлидов:
Это абсолютно справедливое опасение. Скорость без качества — это просто быстрый путь к падению прода. Чтобы двигаться быстро и безопасно, нам был нужен "ремень безопасности". И им стала практика TDD (Test-Driven Development) — разработка через тестирование.
—————
Что такое TDD простыми словами?
Это переворот мышления. Вместо классического подхода "сначала пишем код, потом его тестируем", мы делаем наоборот:
1️⃣ Сначала пишем тест, который ПРОВАЛИВАЕТСЯ (Красный этап). Мы описываем в виде кода, как должна работать функция, которой еще не существует. Запускаем тест — он, естественно, падает, потому что кода нет.
2️⃣ Потом пишем САМЫЙ ПРОСТОЙ код, чтобы тест ПРОШЕЛ (Зеленый этап). Наша задача — сделать так, чтобы тест как можно быстрее стал "зеленым". Никаких мыслей об идеальной архитектуре на этом шаге.
3️⃣ И только потом улучшаем код (Рефакторинг). Теперь, когда у нас есть "зеленый" тест, который страхует нас от ошибок, мы можем смело улучшать код, делать его красивым, быстрым и правильным, постоянно запуская тесты и убеждаясь, что мы ничего не сломали.
—————
Этот цикл "Красный — Зеленый — Рефакторинг" стал для команды новой мантрой.
Почему это сработало?
Изначально команда сопротивлялась (как и абсолютное большинство):
Но уже через пару-тройку недель большинство увидело магию этого подхода:
🔥Железобетонная уверенность: Каждый маленький "бургер" кода, который создавала команда, был с самого рождения покрыт тестами. Ребята гораздо меньше стали бояться вносить изменения в старый код, потому что тестовый "щит" мгновенно сообщал, если что-то пошло не так.
🔥Ревью кода стало проще: Проверять код, к которому прилагаются понятные тесты, в разы легче. Тесты служат живой документацией, объясняющей, что именно должен делать код.
🔥Количество багов в проде сократилось на ~70%: Мы перестали находить глупые ошибки на этапе ручного тестирования или, что еще хуже, от пользователей. Автотесты отлавливали их за секунды.
🔥Ускорение, а не замедление: Да, в моменте написание кода с тестами занимает чуть больше времени. Но это с лихвой окупается экономией на ручном тестировании, поиске багов и исправлении поломок в будущем.
Мы научили команду писать качественный код и не бояться скорости.
Но оставался последний шаг: как убрать человеческий фактор и сделать эту проверку качества полностью автоматической и неотвратимой?🤔
Об этом — в финальной, четвертой части кейса, где мы с командой построим автоматический "конвейер доверия".
Как вам идея TDD?
Кажется сложной или, наоборот, логичной?
Поделитесь в комментариях! 👇
Всем системных и, по возможности, автоматизированных решений. 😁🙌
P.S. Очень буду ждать ваших реакций! 😻
#кейс #tdd #testdrivendevelopment #agile #devops #scrum #оргдизайн #управлениекомандами
Часть 3/4: TDD — наш ремень безопасности.
Итак, в первой части мы нашли "бутылочное горлышко", а во второй части научились декомпозировать задачи по "Принципу Бургера". Команда начала поставлять ценность маленькими, быстрыми порциями.
Но тут возник новый, предсказуемый страх, особенно у CTO и тимлидов:
"Если мы вскоре будем выкатывать изменения "по 10 раз в день", как нам быть уверенными, что мы ничего не сломали? Мы же потонем в регрессионном тестировании!"
Это абсолютно справедливое опасение. Скорость без качества — это просто быстрый путь к падению прода. Чтобы двигаться быстро и безопасно, нам был нужен "ремень безопасности". И им стала практика TDD (Test-Driven Development) — разработка через тестирование.
—————
Что такое TDD простыми словами?
Это переворот мышления. Вместо классического подхода "сначала пишем код, потом его тестируем", мы делаем наоборот:
—————
Этот цикл "Красный — Зеленый — Рефакторинг" стал для команды новой мантрой.
Почему это сработало?
Изначально команда сопротивлялась (как и абсолютное большинство):
"Это же дольше! Нам придется писать в два раза больше кода!".
Но уже через пару-тройку недель большинство увидело магию этого подхода:
🔥Железобетонная уверенность: Каждый маленький "бургер" кода, который создавала команда, был с самого рождения покрыт тестами. Ребята гораздо меньше стали бояться вносить изменения в старый код, потому что тестовый "щит" мгновенно сообщал, если что-то пошло не так.
🔥Ревью кода стало проще: Проверять код, к которому прилагаются понятные тесты, в разы легче. Тесты служат живой документацией, объясняющей, что именно должен делать код.
🔥Количество багов в проде сократилось на ~70%: Мы перестали находить глупые ошибки на этапе ручного тестирования или, что еще хуже, от пользователей. Автотесты отлавливали их за секунды.
🔥Ускорение, а не замедление: Да, в моменте написание кода с тестами занимает чуть больше времени. Но это с лихвой окупается экономией на ручном тестировании, поиске багов и исправлении поломок в будущем.
Мы научили команду писать качественный код и не бояться скорости.
Но оставался последний шаг: как убрать человеческий фактор и сделать эту проверку качества полностью автоматической и неотвратимой?🤔
Об этом — в финальной, четвертой части кейса, где мы с командой построим автоматический "конвейер доверия".
Как вам идея TDD?
Кажется сложной или, наоборот, логичной?
Поделитесь в комментариях! 👇
Всем системных и, по возможности, автоматизированных решений. 😁🙌
P.S. Очень буду ждать ваших реакций! 😻
#кейс #tdd #testdrivendevelopment #agile #devops #scrum #оргдизайн #управлениекомандами
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Механика Эволюции Бизнеса
Кейс: Как мы ускорили поставку кода на 40%, перестав "ускорять" разработчиков.
Часть 1/4: Поиск ограничения.
Ко мне обратился CTO технологической компании с классической проблемой:
"Мы медленно выкатываем фичи. Бизнес недоволен, команда демотивирована.…
Часть 1/4: Поиск ограничения.
Ко мне обратился CTO технологической компании с классической проблемой:
"Мы медленно выкатываем фичи. Бизнес недоволен, команда демотивирована.…
👍3🔥2❤1🤔1
Кейс: Как мы ускорили поставку кода.
Часть 4/4: Автоматизация доверия.
В предыдущих частях мы нашли ограничение, научились декомпозиции и внедрили TDD. Команда начала писать надежный, покрытый тестами код.
Но оставалась одна лазейка — человеческий фактор.
🤔 А что, если разработчик торопился и забыл запустить тесты перед отправкой кода?
🤔 А что, если он запустил только свои тесты, а не все, и случайно сломал код коллеги?
Чтобы построить по-настояшему предсказуемую систему, нужно было исключить эти "а что, если". Нам нужен был беспристрастный контролер, который будет проверять КАЖДОЕ изменение. И мы его построили с помощью CI/CD пайплайна.
Как заработал наш "страж качества":
Разработчик заканчивает свой "бургер" кода и отправляет его в систему (создает MR).
В ту же секунду автоматически запускается пайплайн:
Этап 1: Сборка. Система пытается собрать проект. Если код написан с ошибками и проект не собирается — стоп, MR блокируется.
Этап 2: Прогон ВСЕХ автотестов. Запускается полный набор тестов: и старые, и новые, написанные для этой фичи. Это самый важный этап.
Этап 3: Анализ качества кода (Linting). Автоматическая проверка на соответствие стандартам кодирования, принятым в команде.
Вердикт от робота:
Если хоть один шаг провалился — пайплайн "краснеет" и блокирует MR. Система физически не даст влить в проект код, который ломает сборку или тесты. Разработчик получает уведомление:
Если все шаги "зеленые" — MR получает заветную галочку. Это сигнал для тимлида:
Финальные итоги нашего марафона:
1. Нашли ограничение (ревью кода).
2. Научились декомпозиции ("Принцип Бургера").🍔
3. Внедрили TDD, как методологию качества.
4. Автоматизировали проверку через CI/CD пайплайн.
Итоговый результат:
Time-to-Market сократился на 40%, количество багов в проде упало на 70%, а предсказуемость релизов выросла до 95%.
Мы не просто "ускорили" команду. Мы построили систему, в которой быстро и качественно — это не компромисс, а стандартный режим работы.
Всем зеленых пайплайнов и предсказуемых релизов! ✅🙌
Как вам кейс?😊
#кейс #cicd #devops #automation #agile #tdd #оргдизайн #управлениекомандами
Часть 4/4: Автоматизация доверия.
В предыдущих частях мы нашли ограничение, научились декомпозиции и внедрили TDD. Команда начала писать надежный, покрытый тестами код.
Но оставалась одна лазейка — человеческий фактор.
🤔 А что, если разработчик торопился и забыл запустить тесты перед отправкой кода?
🤔 А что, если он запустил только свои тесты, а не все, и случайно сломал код коллеги?
Чтобы построить по-настояшему предсказуемую систему, нужно было исключить эти "а что, если". Нам нужен был беспристрастный контролер, который будет проверять КАЖДОЕ изменение. И мы его построили с помощью CI/CD пайплайна.
CI/CD — что это и зачем?Мы настроили этот конвейер так, чтобы он автоматически запускался на каждый Merge Request (MR) — то есть на каждую попытку добавить новый код в проект.
CI/CD (Continuous Integration / Continuous Delivery) — это полностью автоматизированный конвейер, который берет код разработчика и проводит его через все этапы проверки и доставки до пользователя.
Как заработал наш "страж качества":
Разработчик заканчивает свой "бургер" кода и отправляет его в систему (создает MR).
В ту же секунду автоматически запускается пайплайн:
Этап 1: Сборка. Система пытается собрать проект. Если код написан с ошибками и проект не собирается — стоп, MR блокируется.
Этап 2: Прогон ВСЕХ автотестов. Запускается полный набор тестов: и старые, и новые, написанные для этой фичи. Это самый важный этап.
Этап 3: Анализ качества кода (Linting). Автоматическая проверка на соответствие стандартам кодирования, принятым в команде.
Вердикт от робота:
Если хоть один шаг провалился — пайплайн "краснеет" и блокирует MR. Система физически не даст влить в проект код, который ломает сборку или тесты. Разработчик получает уведомление:
"Иди и исправляй".
Если все шаги "зеленые" — MR получает заветную галочку. Это сигнал для тимлида:
"Код технически исправен, можно смотреть бизнес-логику".
Финальные итоги нашего марафона:
1. Нашли ограничение (ревью кода).
2. Научились декомпозиции ("Принцип Бургера").🍔
3. Внедрили TDD, как методологию качества.
4. Автоматизировали проверку через CI/CD пайплайн.
Итоговый результат:
Time-to-Market сократился на 40%, количество багов в проде упало на 70%, а предсказуемость релизов выросла до 95%.
Мы не просто "ускорили" команду. Мы построили систему, в которой быстро и качественно — это не компромисс, а стандартный режим работы.
Всем зеленых пайплайнов и предсказуемых релизов! ✅🙌
Как вам кейс?😊
#кейс #cicd #devops #automation #agile #tdd #оргдизайн #управлениекомандами
🔥5❤3👍1
Привет, друзья 🙌
Пришло время поделиться новостями.
Сбылась мечта. 🥳 Я очень давно хотел попасть на обучение по Теории Ограничений. Искал достойных тренеров, которые мне откликались бы. И вот свершилось...
В минувшие сб и вс прошёл первую ступень по сновам мыслительных процессов TOC (Теории Ограничений) Голдратта у замечательной Александры Брызгаловой @Bryzgalova_biz
А это канал Саши: https://news.1rj.ru/str/AABryzgalova
Это было весьма не просто. Высокая когнитивная нагрузка. Много размышлений и переосмыслений. Много инсайтов и подрыва парадигм мышления.
Именно этого, честно говоря, я и ждал от TOC. 😁
Невероятная глубина и сила подхода.
Уверен, что именно эти знания сделают мою практику ещё сильнее а моё участие в поиске решений для моих клиентов кратно полезнее. Думаю, по мере осмысления и освоения на практике, буду по-немногу делиться здесь с вами мыслями, инсайтами практикой.
Однозначно, в TOC я всерьез и надолго.
Всем изящных и действенных решений в бизнесе.
#теорияограничений
Пришло время поделиться новостями.
Сбылась мечта. 🥳 Я очень давно хотел попасть на обучение по Теории Ограничений. Искал достойных тренеров, которые мне откликались бы. И вот свершилось...
В минувшие сб и вс прошёл первую ступень по сновам мыслительных процессов TOC (Теории Ограничений) Голдратта у замечательной Александры Брызгаловой @Bryzgalova_biz
А это канал Саши: https://news.1rj.ru/str/AABryzgalova
Это было весьма не просто. Высокая когнитивная нагрузка. Много размышлений и переосмыслений. Много инсайтов и подрыва парадигм мышления.
Именно этого, честно говоря, я и ждал от TOC. 😁
Невероятная глубина и сила подхода.
Уверен, что именно эти знания сделают мою практику ещё сильнее а моё участие в поиске решений для моих клиентов кратно полезнее. Думаю, по мере осмысления и освоения на практике, буду по-немногу делиться здесь с вами мыслями, инсайтами практикой.
Однозначно, в TOC я всерьез и надолго.
Всем изящных и действенных решений в бизнесе.
#теорияограничений
🔥9👏5❤4
Please open Telegram to view this post
VIEW IN TELEGRAM
Задачи, которые нужно выполнить (JTBD), вместо выдуманных «персонажей». Как понять, за что вам действительно платят? 🧐
Привет, друзья!
Не знаю как вы, а я все ещё натыкаюсь на "персоны" и "портреты" в разработке продуктов:
Персонажи не покупают продукты. Люди «нанимают» их для выполнения своей «работы».
Проблема в том, что чаще всего персоны - это всего лишь демографический портрет. Они не объясняют причинно-следственную связь, почему человек выбирает тот или иной продукт. Они не отвечают на главный вопрос:
Какую РАБОТУ (задачу) пытается выполнить клиент?»
Именно здесь на сцену выходит мощнейший фреймворк Jobs To Be Done (JTBD)
Люди покупают продукты не ради продуктов. Они «нанимают» их для выполнения определённой «работы» (Job) в их жизни. Эта «работа» может быть функциональной, эмоциональной или социальной.
__
Рассмотрим идею на примере Сервиса для автоматического отслеживания ошибок в коде.
❌ "Очевидная" работа (взгляд, сфокусированный на фичах):
"Нам нужен инструмент, который ловит исключения (exceptions) в Python и JavaScript и присылает уведомления".
✅ Настоящая работа, которую нужно выполнить (взгляд, сфокусированный на клиенте):
Разработчик или тимлид "нанимает" Сервис не просто для отлова ошибок. Он хочет "быстро узнавать о критических сбоях в продакшене раньше, чем о них напишут разгневанные пользователи, чтобы сохранить репутацию продукта и спокойно спать по ночам".
Как сервис решает "настоящую" работу:
1️⃣ Проактивность: Он узнает о проблеме первым, а не из тикета поддержки.
2️⃣ Спокойствие: Уверенность в том, что ни один критический сбой не останется незамеченным.
3️⃣ Эффективность: Он получает всю необходимую информацию (контекст пользователя) для быстрого исправления, а не пытается воспроизвести ошибку "вслепую".
Результат: Клиент покупает не "отчеты об ошибках", а уверенность, спокойствие и сэкономленное время. Это и есть "работа", на которую он нанял продукт.
__
И как JTBD поможет вашему бизнесу?
1. Создавать продукты, которые действительно нужны:
Вместо того чтобы гадать, что хотят пользователи, вы понимаете их глубинные потребности и мотивации.
2. Отстроиться от конкурентов:
Вы конкурируете не с похожими продуктами, а с любым решением, которое клиент "нанимает" для выполнения той же "работы".
3. Отыскать инновации и возможно даже "голубой океан":
JTBD открывает новые возможности для инноваций, показывая, где текущие решения не справляются с "работой" клиента.
4. Эффективный маркетинг:
Вы говорите с клиентом на языке его "работ" и проблем, а не на языке функций вашего продукта.
Как применять JTBD на практике?
👉 Исследовать:
Проводить глубинные интервью, чтобы понять, какие "работы" пытаются выполнить ваши клиенты. Спрашивать "почему?" и "для чего?"
👉 Формулировать "работы":
Используйте такой шаблон и смотрите на задачу глазами клиента:
Где клиенты "страдают"? Где текущие решения не справляются? Это ваша точка роста.
👉 Проектировать решения: Создавать продукты, которые лучше выполняют "работу" клиента, а не просто добавляют новые функции.
P.S. Давайте прекратим создавать продукты для "Марии, 32 года". Давайте создавать продукты для "Марии, которая хочет быстро и безопасно добраться до работы, чтобы не опоздать на важную встречу и чувствовать себя уверенно".
Всем ясного понимания пользователей и огненных продуктов! 🙌
#JTBD #JobsToBeDone #ПродуктовыйМенеджмент #Discovery #GrowthHacking #БизнесТрекинг #Инновации
Привет, друзья!
Не знаю как вы, а я все ещё натыкаюсь на "персоны" и "портреты" в разработке продуктов:
"Наша персона — это Мария, 32 года, любит йогу и кофе..."Звучит красиво, но по моему опыту, это часто приводит к созданию продуктов, которые становятся посредственными, либо никто не покупает. Почему?
Персонажи не покупают продукты. Люди «нанимают» их для выполнения своей «работы».
Проблема в том, что чаще всего персоны - это всего лишь демографический портрет. Они не объясняют причинно-следственную связь, почему человек выбирает тот или иной продукт. Они не отвечают на главный вопрос:
Какую РАБОТУ (задачу) пытается выполнить клиент?»
Именно здесь на сцену выходит мощнейший фреймворк Jobs To Be Done (JTBD)
Люди покупают продукты не ради продуктов. Они «нанимают» их для выполнения определённой «работы» (Job) в их жизни. Эта «работа» может быть функциональной, эмоциональной или социальной.
__
Рассмотрим идею на примере Сервиса для автоматического отслеживания ошибок в коде.
❌ "Очевидная" работа (взгляд, сфокусированный на фичах):
"Нам нужен инструмент, который ловит исключения (exceptions) в Python и JavaScript и присылает уведомления".
✅ Настоящая работа, которую нужно выполнить (взгляд, сфокусированный на клиенте):
Разработчик или тимлид "нанимает" Сервис не просто для отлова ошибок. Он хочет "быстро узнавать о критических сбоях в продакшене раньше, чем о них напишут разгневанные пользователи, чтобы сохранить репутацию продукта и спокойно спать по ночам".
Как сервис решает "настоящую" работу:
Результат: Клиент покупает не "отчеты об ошибках", а уверенность, спокойствие и сэкономленное время. Это и есть "работа", на которую он нанял продукт.
__
И как JTBD поможет вашему бизнесу?
1. Создавать продукты, которые действительно нужны:
Вместо того чтобы гадать, что хотят пользователи, вы понимаете их глубинные потребности и мотивации.
2. Отстроиться от конкурентов:
Вы конкурируете не с похожими продуктами, а с любым решением, которое клиент "нанимает" для выполнения той же "работы".
3. Отыскать инновации и возможно даже "голубой океан":
JTBD открывает новые возможности для инноваций, показывая, где текущие решения не справляются с "работой" клиента.
4. Эффективный маркетинг:
Вы говорите с клиентом на языке его "работ" и проблем, а не на языке функций вашего продукта.
Как применять JTBD на практике?
👉 Исследовать:
Проводить глубинные интервью, чтобы понять, какие "работы" пытаются выполнить ваши клиенты. Спрашивать "почему?" и "для чего?"
👉 Формулировать "работы":
Используйте такой шаблон и смотрите на задачу глазами клиента:
"Когда [ситуация], я хочу [мотивация], чтобы [желаемый результат]".👉 Искать неудовлетворенные "работы":
Где клиенты "страдают"? Где текущие решения не справляются? Это ваша точка роста.
👉 Проектировать решения: Создавать продукты, которые лучше выполняют "работу" клиента, а не просто добавляют новые функции.
P.S. Давайте прекратим создавать продукты для "Марии, 32 года". Давайте создавать продукты для "Марии, которая хочет быстро и безопасно добраться до работы, чтобы не опоздать на важную встречу и чувствовать себя уверенно".
Всем ясного понимания пользователей и огненных продуктов! 🙌
#JTBD #JobsToBeDone #ПродуктовыйМенеджмент #Discovery #GrowthHacking #БизнесТрекинг #Инновации
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤1💯1
Механика Эволюции Бизнеса
Ну что ж, друзья. Пришло время вскрываться. 😁
Давайте разберем рейтинг который получился и приоткроем завесу, возможно, для кого-то будет что-то неожиданное. 😉
1-е место. Больше всех голосов набрало "Виноделие".
Пожалуй, вы угадали, и среди моих клиентов еще ни разу не было виноделов! 😁 Хотя, хорошие вина я очень уважаю 🍷, кое-что в них понимаю, и при возможности с удовольствием посещаю винодельни и знакомлюсь с ними.
На 2-м месте оказался "Общепит".
И вы снова угадали, среди моих клиентов пока не было никого из этой ниши, при всем моем уважении и любви к хорошим ресторанам. 😁
На 3-м месте оказались "Коллекторские агентства".
А вот здесь промашка вышла. 🤷♂️🥳 На самом деле среди моих клиентов есть ребята из коллекторского агентства. И знаете, они отличные предприниматели с подвижной логикой и проявленным действием (как и положено предпринимателям). Самое офигенное - это их миссия!
У ребят миссия - помогать людям экологично избавляться от плохих долгов. И это совсем непривычно нашему уху и глазу.
- Что? Коллекторы? Экологично? Помогать?
Ага! Ребята находят и выкупают долги физлиц у банков с большими дисконтами и предлагают должникам загасить долг на выгодных для должника условиях без судебных разбирательств. Все в плюсе! 🤷♂️
Итого:
Автодиллеры, Финтех и банки, ИТ, Производство сложной электроники, коллекторы - были проекты развития!
Из неуказанных здесь еще была работа с HR Tech, Data+AI, Краткосрочная аренда жилой недвижимости.
GameDev, Bet Business, Медтех, производство товаров народного потребления, Инфобез (как отдельный выделенный бизнес) - пока не было.
Как-то так.
Удивило ли вас что-то?😁
В каки нишах компетенции бизнес-трекера и орг консультанта думаете не применимы?😉
#бизнестрекинг #оргразвитие #развитиебизнеса
Давайте разберем рейтинг который получился и приоткроем завесу, возможно, для кого-то будет что-то неожиданное. 😉
1-е место. Больше всех голосов набрало "Виноделие".
Пожалуй, вы угадали, и среди моих клиентов еще ни разу не было виноделов! 😁 Хотя, хорошие вина я очень уважаю 🍷, кое-что в них понимаю, и при возможности с удовольствием посещаю винодельни и знакомлюсь с ними.
На 2-м месте оказался "Общепит".
И вы снова угадали, среди моих клиентов пока не было никого из этой ниши, при всем моем уважении и любви к хорошим ресторанам. 😁
На 3-м месте оказались "Коллекторские агентства".
А вот здесь промашка вышла. 🤷♂️
У ребят миссия - помогать людям экологично избавляться от плохих долгов. И это совсем непривычно нашему уху и глазу.
- Что? Коллекторы? Экологично? Помогать?
Ага! Ребята находят и выкупают долги физлиц у банков с большими дисконтами и предлагают должникам загасить долг на выгодных для должника условиях без судебных разбирательств. Все в плюсе! 🤷♂️
Итого:
Автодиллеры, Финтех и банки, ИТ, Производство сложной электроники, коллекторы - были проекты развития!
Из неуказанных здесь еще была работа с HR Tech, Data+AI, Краткосрочная аренда жилой недвижимости.
GameDev, Bet Business, Медтех, производство товаров народного потребления, Инфобез (как отдельный выделенный бизнес) - пока не было.
Как-то так.
Удивило ли вас что-то?😁
В каки нишах компетенции бизнес-трекера и орг консультанта думаете не применимы?😉
#бизнестрекинг #оргразвитие #развитиебизнеса
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Наблюдаю одно фундаментальное явление. Мало кто владеет навыком "раздевать" проблему до сути.
По моему мнению, это важнейший навык. Ибо то, как корабль назовём, так и поплывем. Как проблему определим, то и будем решать.
Если определим, что нам не хватает людей, начнём делать моё любимое - "заливное из людей". Станет ли от этого лучше и легче — вообще не факт!
Но проблема не может висеть в вакууме, она всегда относительна. А именно — она всегда должна трактоваться в разрезе цели рассматриваемой системы (бизнес, продукт, подразделение, личная карьера и пр.).
Если цель занять долю рынка Х% и мы обозначаем, что у нас нехватка людей (как же часто это звучит мне в уши 😁) , то хорошо бы ответить себе на вопросы:
1. И что именно блокирует эта самая нехватка людей?
2. Какую именно проблему относительно цели это вызывает?
3. Что не получается?
Эта самая "хватка" людей — это просто ваше подложенное решение под невыявленную проблему. Бывает, что реальную проблему не обязательно прибавление людей полечит.
И вот когда реальная проблема ясна, то и решения будут в разы эффективнее.
В следующем посте расскажу признаки - как отличить и понять, что вы нашли реальную проблему. А это не так тривиально, как кажется. 😉 Говорю так, потому что наблюдал за десятками команд.
Работать с выявлением проблемы умеют не многие. 🤷♂️
#TOC #управлениеизменениями #agile
По моему мнению, это важнейший навык. Ибо то, как корабль назовём, так и поплывем. Как проблему определим, то и будем решать.
Если определим, что нам не хватает людей, начнём делать моё любимое - "заливное из людей". Станет ли от этого лучше и легче — вообще не факт!
Но проблема не может висеть в вакууме, она всегда относительна. А именно — она всегда должна трактоваться в разрезе цели рассматриваемой системы (бизнес, продукт, подразделение, личная карьера и пр.).
Если цель занять долю рынка Х% и мы обозначаем, что у нас нехватка людей (как же часто это звучит мне в уши 😁) , то хорошо бы ответить себе на вопросы:
1. И что именно блокирует эта самая нехватка людей?
2. Какую именно проблему относительно цели это вызывает?
3. Что не получается?
Эта самая "хватка" людей — это просто ваше подложенное решение под невыявленную проблему. Бывает, что реальную проблему не обязательно прибавление людей полечит.
И вот когда реальная проблема ясна, то и решения будут в разы эффективнее.
В следующем посте расскажу признаки - как отличить и понять, что вы нашли реальную проблему. А это не так тривиально, как кажется. 😉 Говорю так, потому что наблюдал за десятками команд.
Работать с выявлением проблемы умеют не многие. 🤷♂️
#TOC #управлениеизменениями #agile
👍6🔥5❤2💯1
Как отличить проблему от её тени?
Правила формулирования проблем или Нежелательных Явлений (НЖЯ) на базе Теории Ограничений Голдратта.
Знакомо?
📍 «У нас плохая коммуникация»,
📍 «Сотрудники немотивированы»,
📍 «Процессы неэффективны».
Эти фразы — мусор. Они не помогают решать проблемы, а только порождают новую бесполезную работу. И мы нередко попадаем в ловушку подобного мышления.
Почему? Потому что это не проблемы. Это ярлыки.
Настоящую проблему можно пощупать. Её можно измерить. Её могут одинаково признать и о ней могут одинаково договориться два (или более) спорящих.
Как же формулировать проблемы по-настоящему? Я использую принципы из Теории Ограничений Голдратта.
Вот основные правила формулирования Нежелательных Явлений (НЖЯ):
1️⃣ НЖЯ — это наблюдаемый факт, а не диагноз
❌«Плохая командная работа» (это оценка)
✅«Отдел маркетинга передаёт отделу продаж лиды без контактов в 30% случаев» (это факт)
2️⃣ НЖЯ — это конкретное негативное последствие, состояние, а не процесс.
❌«Клиенты часто меняют требования» (это может быть и хорошо)
✅«Из-за изменений требований в середине спринта мы переделываем 20% работы» (вот это уже больно)
3️⃣ НЖЯ — это проблема, а не скрытое решение
❌«Нам не хватает CRM-системы» (это уже решение!)
✅«47% клиентов получают коммерческие предложения с опозданием более чем на 2 дня»
4️⃣ НЖЯ — это системная проблема, а не обвинение
❌«Менеджер Иванов некомпетентен» (обвинение)
✅«По проектам менеджера Иванов в 3 раза чаще поступают претензии по качеству» (системный факт)
Почему это работает?
Когда вы формулируете НЖЯ как наблюдаемые факты, вы:
• бьёте в корень, а не по веткам;
• убираете эмоции и субъективизм;
• Создаёте ясность для всей команды;
• Находите настоящие, а не мнимые причины проблем.
Всем ясного формулирования проблем и эффективного их устранения! 🙌
#теория_ограничений #голдратт #управление #проблемы #бизнес #анализ
Правила формулирования проблем или Нежелательных Явлений (НЖЯ) на базе Теории Ограничений Голдратта.
Знакомо?
Эти фразы — мусор. Они не помогают решать проблемы, а только порождают новую бесполезную работу. И мы нередко попадаем в ловушку подобного мышления.
Почему? Потому что это не проблемы. Это ярлыки.
Настоящую проблему можно пощупать. Её можно измерить. Её могут одинаково признать и о ней могут одинаково договориться два (или более) спорящих.
Как же формулировать проблемы по-настоящему? Я использую принципы из Теории Ограничений Голдратта.
Вот основные правила формулирования Нежелательных Явлений (НЖЯ):
1️⃣ НЖЯ — это наблюдаемый факт, а не диагноз
❌«Плохая командная работа» (это оценка)
✅«Отдел маркетинга передаёт отделу продаж лиды без контактов в 30% случаев» (это факт)
2️⃣ НЖЯ — это конкретное негативное последствие, состояние, а не процесс.
❌«Клиенты часто меняют требования» (это может быть и хорошо)
✅«Из-за изменений требований в середине спринта мы переделываем 20% работы» (вот это уже больно)
3️⃣ НЖЯ — это проблема, а не скрытое решение
❌«Нам не хватает CRM-системы» (это уже решение!)
✅«47% клиентов получают коммерческие предложения с опозданием более чем на 2 дня»
4️⃣ НЖЯ — это системная проблема, а не обвинение
❌«Менеджер Иванов некомпетентен» (обвинение)
✅«По проектам менеджера Иванов в 3 раза чаще поступают претензии по качеству» (системный факт)
Почему это работает?
Когда вы формулируете НЖЯ как наблюдаемые факты, вы:
• бьёте в корень, а не по веткам;
• убираете эмоции и субъективизм;
• Создаёте ясность для всей команды;
• Находите настоящие, а не мнимые причины проблем.
Всем ясного формулирования проблем и эффективного их устранения! 🙌
#теория_ограничений #голдратт #управление #проблемы #бизнес #анализ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤2👍2💯1