Т. е. оценки потенциальной прибыльности ЗАРАНЕЕ - НЕ ПРОИЗВОДИТСЯ.
При адекватном планировании этот этап идёт вторым пунктом, а не самым последним, когда претензии предъявлять уже не к кому
Карта != территория
Вы не получаете ОС от бизнеса о реализованных фичах? A/B тестирование, эксперименты лишняя трата времени?
Планирование - это прогноз. Ваши прогнозы всегда сбываются?
За время разработки может произойти многое: конкуренты выпустили продукт раньше вас и ваш релиз уже не так интересен; низкое качество реализации испортило все впечатление от фичи и она не принесла заявленной ценности; затянули с разработкой, а рынок уже другой и хайп прошел.
В продуктовой разработке без ОС никуда.
Чтобы докрутить конверсию в регистрацию на 1% порой столько надо экспериментов провести и копий сломать, одного прогноза тут не достаточно.
Кто лидирует технические вопросы в новой структуре и занимается архитектурой? Если команда состоит из мидлов например и так такового технического лидера внутри команды нет?
К сожалению, задачи с фиксированным сроком обычно появляются как снег на голову.
Команду разработки подключают уже в самы последний момент, когда все решения уже приняты и требования собраны, и проект уже утвержден. Команду ставят перед фактом, что есть срочная задачаа, которую нужно решить к такому-то числу.
Решение: подключать команду на этапе discovery для проработки проектов. Мы только начинаем это делать.
У меня, как у agile coach, есть доступ ко многим командам и ретроспективам, мы проводили исследования и интервью. Когда в компании работаешь 4 года, знания накапливаются в голове, остается их только оформить с помощью какого-либо инструмента.
Что может помочь собрать нежелательные явления:
Ретроспективы. От чего сильно бомбит команду или проблемы, которые не решаются на постоянной основе;
1t1 с сотрудниками из компании. Доверительные отношения в командах дает больше информации о проблемах;
Инетрвью/исследования. С другими Agile коучами проводили исследования на уровне всей компании мидл менеджмента.
Я советую прочитать Цель-2, тогда можно быстро погрузиться и узнать из бизнес-романа о данном и других инструментах.
P.S. Книги Голдратта одни из самых любимых и многие из них читаются на одном дыхании.
Согласен, есть и такие компании. Я надеюсь, что у нас все-таки не так, а те изменения, которые происходят в нашей компании, принесут пользу. Последние из них - ориентация и ответственность продуктовых команд за бизнес-показатели, теперь они напрямую влияют на бизнес и могут оценить свой вклад.
Ирина, почему для выявления зависимостей использовали Miro, а не Kaiten?
Приходилось же дублировать информация и синхронизировать ее потом?
Какой кейс не удалось реализовать в Кайтен для визуализация блокировок или чем было неудобно?
Карта != территория
Вы не получаете ОС от бизнеса о реализованных фичах? A/B тестирование, эксперименты лишняя трата времени?
Планирование - это прогноз. Ваши прогнозы всегда сбываются?
За время разработки может произойти многое: конкуренты выпустили продукт раньше вас и ваш релиз уже не так интересен; низкое качество реализации испортило все впечатление от фичи и она не принесла заявленной ценности; затянули с разработкой, а рынок уже другой и хайп прошел.
В продуктовой разработке без ОС никуда.
Чтобы докрутить конверсию в регистрацию на 1% порой столько надо экспериментов провести и копий сломать, одного прогноза тут не достаточно.
Спасибо за подробный план, возьму на заметку.
Кто лидирует технические вопросы в новой структуре и занимается архитектурой? Если команда состоит из мидлов например и так такового технического лидера внутри команды нет?
Как тебе известно, для управления решениями у нас внедряется метод OKR.
Я надеюсь, он как раз свяжет все уровни управления и сделает модель поставноки задач прозрачной.
Можно сказать, что основным продуктов является наш сайт и мобильное приложение. Поэтому можно считать, что у нас ИТ бизнес.
Спасибо за ссылочку, ознакомлюсь.
Agile и продуктовому подходу в ИТ уже 30 лет, сложно их назвать новомодными, учитывая, что первый ПК всего лишь на 10 лет старше :)
На мой взгляд, без изменений и адоптации компания раньше сдохнет.
@DikSoft А какой подход лучше использовать? И в чем его преимущества?
К сожалению, задачи с фиксированным сроком обычно появляются как снег на голову.
Команду разработки подключают уже в самы последний момент, когда все решения уже приняты и требования собраны, и проект уже утвержден. Команду ставят перед фактом, что есть срочная задачаа, которую нужно решить к такому-то числу.
Решение: подключать команду на этапе discovery для проработки проектов. Мы только начинаем это делать.
Узнал о инструменте после прочтения книги Элияху Голдратт. Цель-2. Дело не в везении.
Для построения Дерева текущей реальности я использовал материалы статьи: https://vc.ru/hr/81710-instrukciya-kak-stroit-derevo-tekushchey-realnosti-dlya-resheniya-biznes-problem
У меня, как у agile coach, есть доступ ко многим командам и ретроспективам, мы проводили исследования и интервью. Когда в компании работаешь 4 года, знания накапливаются в голове, остается их только оформить с помощью какого-либо инструмента.
Что может помочь собрать нежелательные явления:
Ретроспективы. От чего сильно бомбит команду или проблемы, которые не решаются на постоянной основе;
1t1 с сотрудниками из компании. Доверительные отношения в командах дает больше информации о проблемах;
Инетрвью/исследования. С другими Agile коучами проводили исследования на уровне всей компании мидл менеджмента.
Я советую прочитать Цель-2, тогда можно быстро погрузиться и узнать из бизнес-романа о данном и других инструментах.
P.S. Книги Голдратта одни из самых любимых и многие из них читаются на одном дыхании.
Согласен, есть и такие компании. Я надеюсь, что у нас все-таки не так, а те изменения, которые происходят в нашей компании, принесут пользу. Последние из них - ориентация и ответственность продуктовых команд за бизнес-показатели, теперь они напрямую влияют на бизнес и могут оценить свой вклад.