Если на матрице не размещать альтернативные решения, то она не будет их учитывать, конечно :)
По поводу необходимости технического бэкграунда у менеджеров уже сотни копий сломано, в том числе на Хабре. По своему опыту могу сказать, что мне лично навыки программирования помогают только в проектной части, а для продуктовой части менеджмента программерские навыки или фиолетовы, или оказывают негативный эффект.
Если рассматривать только одну сторону управления, то, конечно, понимание важности хорошей кодовой базы (~минимизированный техдолг) и опыт оценки сроков по собственному опыту программирования сильно помогает в организации процесса разработки.
Однако как показывает мировой опыт — одной только правильно выстроенной и успешно завершённой разработки недостаточно для успеха на рынке и статья как раз о том, чтобы оглядываться в первую очередь на бизнес-показатели продукта, а не на своё представление о нём и счастье пользователей
Приведённый вами пример как раз к оценке сроков и относится. Матрица обычно используется не для принятия технических решений, а для выбора, какую из идей брать в работу / не брать в работу.
Для простоты — ваш пример Идея1:
Реализация X — N дней, A отдачи
Реализация Y — M дней, B отдачи
При этом в бэклоге есть и другие идеи:
Идея2 — O дней, C отдачи
Идея3 — P дней, D отдачи.
И в данном случае, если для Идеи1 варианты реализации оценены некорректно (прогнозируемая отдача не учитывала риски техдолга или «подготовительных работ», которые относятся к проекту по реализации Идеи1), то и матрица отобразит это некорректно.
Вообще матрица — это инструмент визуализации оценок и сравнения их между собой, однако если оценки сделаны некорректно, то матрица это не как не «подсветит». Вопрос «торгов» за выбор того или иного решения для оценки как раз и решается формулой с уровнем доверия. Если менеджер оценивает вероятность преимуществ рефакторинга как низкую, а разработчик как высокую, уровень доверия это решит.
Есть разные способы определения уровня доверия и в следующей статье данного автора один из способов описан (планирую сделать перевод позже). Основное преимущество этого способа в том, что он отталкивается от реальных данных, а не споров технической и бизнес-команд
Когнитивные искажения — не изобретение автора.
Психолог Д. Канеман получил Нобелевскую премию за исследования в этой сфере, в них он опроверг все имевшиеся на тот момент предположения о рациональности людей, описываемые экономической моделью.
Нобелевку он получил в 2002, представленный вами документ датируется 1997 годом, поэтому игнорирует иррациональность человека и пытается описывать риски как матмодель.
У Канемана есть книга «Thinking, fast and slow», которая как раз излагает суть исследований и на примерах раскрывает ущербность теории о том, что люди рациональны
Если использовать матрицу для приоритизации продуктового бэклога (приоритизация проектов), а не проектного (приоритизация задач), то внутри проекта задачи из «денежной ямы», требующиеся для реализации задач из «больших ставок» относятся к одному проекту и оцениваются совокупно.
Не очень понятно, что вы имеете ввиду под «могут сместить» — приведите пример.
В рамках именно приоритизации с помощью матрицы инкрементальные задачи должны «заполнять пустоты», а не быть самодостаточным проектом. Для решения проблемы смещения по графику как раз и предлагается более трезво оценивать сроки
При оценке сроков подразумевается оценка реализации в целом, при этом низкое качество кода не навязывается матрицей, если разработчик оценил сроки с плохой реализацией, то матрица в этом точно не виновата :)
По примеру — именно для таких кейсов автор и предлагает вводить понятие уровня доверия, чтобы не гадать, что и сколько в каких перспективах принесёт — проблемы, упущенную выгоду или переработку т.к. космолётным решением никто не пользуется
В данной статье разобран наиболее популярный (по субъективному мнению автора) метод приоритизации бэклога, предложены способы улучшения этого метода.
Как альтернативу можно использовать и другой метод, конечно, однако в вашем предложенном методе проблемы, описанные выше, сохраняются — при оценке риска, эффекта и затрат проявляются те же когнитивные искажения, что так же влияет на всю оценку
Оригинальная матрица предполагает использование именно квадрантов (более подробно, например, тут: habr.com/company/hygger/blog/359208)
Последняя формула выведена автором именно с учётом критики оригинальной матрицы.
Предложенная картинка выглядит интересно :)
Раскройте, пожалуйста, как на вашем графике учитывается уровень доверия? Плюс у вас не учтён вариант с «отрицательной ценностью», когда в результате релиза фичи компания деньги не зарабатывает, а теряет.
Плюс не очень понятно по самому графику — по Y ценность, по X трудозатраты? Выглядит так, как будто у вас это именно вектора, но я не уверена, что понимаю правильно
Согласна с вами, очень часто ситуация обстоит именно так, однако на данный момент довольно популярны подходы по исследованию потребностей — как качественные (CustDev, Design Thinking), так и количественные (Lean Startup) методы, которые в комбинации показывают хорошие результаты
Хочу обратить ваше внимание, что это не авторская статья, а перевод :)
Банк Идей глобально — просто список идей (например, в Excel), а бэклог зачастую размещают в таск-трекерах / диаграммах Ганта / специализированном инструментарии для роадмапов. Я думаю, автор имел ввиду именно эту разницу — идеи ещё не обязательно будут взяты в работу в том виде, в каком записаны и предполагают лёгкую запись, расширение и т.п.
Расскажите, как вы работаете с бэклогом тикетов из техподдержки.
Если баг воспроизводится и тестировщик ставит задачу, но сам баг редкий / некритичный / по другой причине не приоритетный, то как определяется, когда (если) задача берётся в работу?
Кто «грумит» этот бэклог? Продуктовый менеджер? На основе каких данных?
Или просто фиксированный объём человекочасов в каждом релизе фиксируется для исправления багов из бэклога саппорта?
Как правило, самая сложная в решении проблема — не рассортировать таски, а выделить ресурсы (особенно если не всё соответствует стратегическим планам компании) — интересно почитать, как вы решаете именно эту проблему
Не знаю, насколько продуктивно на проблемных / решенческих интервью прорабатывать сразу несколько разных фичей — человек-то нежелезный, банально устанет :)
Что касается пересечения фичей:
В большинстве компаний всё равно так или иначе работа ведётся над несколькими задачами одновременно (даже канбан-метод это позволяет), полностью вся команда одну идею не пилит просто потому, что специализацию никто не отменял.
Проблемы фокусирования вроде не должно быть — программисты пишут код по шаг-проекту для идеи №1, исследователи и продакт работают над сбором фидбека по шаг-проекту идеи №2 и т.д.
Есть ощущение, что во многих компаниях одновременно в работе и так большое количество проектов (что распыляет, конечно), поэтому если это будут более «обстуканные об рынок» проекты, то глобально ничего не поменяется.
Про«каноничный скрам» ничего не могу сказать, если мне не изменяет память, скрамгайд не регламентирует распределение задач внутри DevTeam и распределение задач внутри проектов (или шаг-проектов в случае GIST), поэтому противоречия вроде бы нет.
Как решить проблему набора в спринт Инкрементов (задач) из разных проектов (шаг-проектов) — команда сама решит на планировании и возникшие по ходу сложности разберёт на ретро.
Спасибо за статью!
1. Кто входит в продуктовую команду кроме продуктовых менеджеров? Исследователи (какие?), маркетинг?
2. Как решаете проблемы, связанные с заморозкой задач (изменились приоритеты, продуктовая команда изменила после исследований / действий регулятора / etc.)? Due date в этом случае на время заморозки как-то обнуляется?
3. Почему не формируете кросс-функциональные инженерные команды вокруг продуктовых команд? Как я поняла из текста, у вас сейчас матричная структура и проблемы планирования возникают именно из-за этого размазывания продуктовых задач по функциональным отделам.
4. Когда применялась схема работы №3, как были приняты решения о распределении квот между командами? Вычислялась ли какая-то бизнес-составляющая (доходность, перспективность, важность для пользователя и т.п.) продукта, что влияло на приоритеты в выделении инженеров?
Да, как способ коммуникации с «менее гибкими» коллегами, роадмапы однозначно нужны — просто потому что более консервативным сотрудникам / отделам / компаниям сложно отказаться от стратегического мышления вида «план-задача».
Конкретно GIST хорошо ложится на OKR (что упомянуто как раз с примерами), а OKR сам по себе подразумевает бОльшую гибкость, переход от мышления вида «план-задача» в сторону «цель-задача», при этом ещё и задачу исполнитель сам себе ставит.
Начинать переход можно хотя бы с формулирования стратегии на год в виде целей, а не задач, пусть даже на первых порах задачи тоже будут спускаться сверху директивно. Это может быть больно, будет становиться заметно, насколько «верх» способен грамотно поставить директивную задачу, которая будет достигать заданной цели, что вызовет вопросы к компетентности. Возможно, в компании начнутся более глобальные изменения, которые повлекут изменение подходов…
В общем, переход от одной парадигмы к другой непрост, но, имхо, стоит того :)
Другое дело, что не все компании понимают необходимость таких переходов, но каждый сотрудник всегда оставляет за собой право голоса ногами, благо рынок (по крайней мере, технологический) позволняет
Да, соглашусь с вами, подходов понять, для чего всё затевается, много — начиная с классического вопроса и заканчивая техникой 5 why. Если начать хотя бы ими задаваться при планировании — уже должен быть значительный рост «полезности» планов :)
Конкретно эта статья мне понравилась тем, что кроме понимания базовых предпосылок и определения целей проектов она рассказывает ещё и об управлении идеями по достижению этих целей. И тогда фокус очень хорошо смещается с «надо придумать, что делать, чтобы разработчики не простаивали» к «надо выбрать, что делать, чтобы бизнес зарабатывал больше / рос быстрее / вышел из кризиса / etc.»
Продуктоцентризм про неопытных стартаперов, которые жгут инвестиции. В новых подходах (продвигаемых тем же ФРИИ) фокус смещён на пользователя и его боли, а не на продуктовые фичи. И питчинг происходит от болей, а не от продукта.
В банках же даже о продукте думают не так часто (про потребителя вообще молчу).
Улучшательство касается не только банков, а любой продуктовой компании и очень хорошо чувствуется в работе с фича-риквестами — сначала приоритетное внутреннее, потом, когда (если) руки дойдут до пользовательских просьб (что тоже оправдано, но это отдельный разговор).
Про требования и сроки уже писали выше, но даже само использование слова «требования» говорит о том, что банк хочет эксплуатировать стартап как аутсорс-компанию, а не как стартап.
В стартапах нет понятия «требования» — есть гипотезы, их нужно тестировать. А всё, что банк пытается продавить под видом экспертного понимания рынка и потребностей аудитории — иллюзии «бывалых», которые совпадают с реальностью не чаще, чем средние показатели по рынку (т.е. вероятность близка к нулю).
Стартапы тем и хороши, что не встраиваются в принятые «культуру», «бизнес-процессы» и «регламенты» — иначе стартап становится просто ещё одним подразделением со всеми проблемами банка
При старте проекта по локализации на арабский какие-то измеримые цели ставились (деньги, MAU и т.п.)?
Или это больше стратегический проект, на который не делаются какие-то большие ставки и проектные цели на уровне «сделать, чтобы было»?
Что вы вообще вкладываете в понятие RnD?
В каждой компании такие отделы отвечают за разное — от экспериментальных проектов до дата-сайенса, ваше видение не до конца понятно.
У вас в тексте:
RnD отличается тем, что разрабатывает продукты, ориентируясь на продуктовый роадмап, создаваемый в продуктовом подразделении компании на основании анализа рынка и потребностей клиентов в целевом сегменте. На основе роадмапа и продуктовых требований бизнес-аналитики создают требования для разработки продуктов.
Анализируя запросы, RnD определяет архитектуру, организацию всех наших продуктов. Разработка проудктов в RnD организована в двухмесячные суперспринты, к окончанию каждого из которых в продукте появляются новая функциональность на уровне системы. По их итогам RnD показывает демо для продуктовой команды.
В чём принципиальное отличие от «простой» разработки?
У нас 2 PBR по часу не всей командой, планирование час всей командой и дэйлики по 10 минут без шаренных.
Ретро 50-60 минут всей командой
По поводу необходимости технического бэкграунда у менеджеров уже сотни копий сломано, в том числе на Хабре. По своему опыту могу сказать, что мне лично навыки программирования помогают только в проектной части, а для продуктовой части менеджмента программерские навыки или фиолетовы, или оказывают негативный эффект.
Если рассматривать только одну сторону управления, то, конечно, понимание важности хорошей кодовой базы (~минимизированный техдолг) и опыт оценки сроков по собственному опыту программирования сильно помогает в организации процесса разработки.
Однако как показывает мировой опыт — одной только правильно выстроенной и успешно завершённой разработки недостаточно для успеха на рынке и статья как раз о том, чтобы оглядываться в первую очередь на бизнес-показатели продукта, а не на своё представление о нём и счастье пользователей
Для простоты — ваш пример Идея1:
Реализация X — N дней, A отдачи
Реализация Y — M дней, B отдачи
При этом в бэклоге есть и другие идеи:
Идея2 — O дней, C отдачи
Идея3 — P дней, D отдачи.
И в данном случае, если для Идеи1 варианты реализации оценены некорректно (прогнозируемая отдача не учитывала риски техдолга или «подготовительных работ», которые относятся к проекту по реализации Идеи1), то и матрица отобразит это некорректно.
Вообще матрица — это инструмент визуализации оценок и сравнения их между собой, однако если оценки сделаны некорректно, то матрица это не как не «подсветит». Вопрос «торгов» за выбор того или иного решения для оценки как раз и решается формулой с уровнем доверия. Если менеджер оценивает вероятность преимуществ рефакторинга как низкую, а разработчик как высокую, уровень доверия это решит.
Есть разные способы определения уровня доверия и в следующей статье данного автора один из способов описан (планирую сделать перевод позже). Основное преимущество этого способа в том, что он отталкивается от реальных данных, а не споров технической и бизнес-команд
Психолог Д. Канеман получил Нобелевскую премию за исследования в этой сфере, в них он опроверг все имевшиеся на тот момент предположения о рациональности людей, описываемые экономической моделью.
Нобелевку он получил в 2002, представленный вами документ датируется 1997 годом, поэтому игнорирует иррациональность человека и пытается описывать риски как матмодель.
У Канемана есть книга «Thinking, fast and slow», которая как раз излагает суть исследований и на примерах раскрывает ущербность теории о том, что люди рациональны
По примеру — именно для таких кейсов автор и предлагает вводить понятие уровня доверия, чтобы не гадать, что и сколько в каких перспективах принесёт — проблемы, упущенную выгоду или переработку т.к. космолётным решением никто не пользуется
Как альтернативу можно использовать и другой метод, конечно, однако в вашем предложенном методе проблемы, описанные выше, сохраняются — при оценке риска, эффекта и затрат проявляются те же когнитивные искажения, что так же влияет на всю оценку
Последняя формула выведена автором именно с учётом критики оригинальной матрицы.
Предложенная картинка выглядит интересно :)
Раскройте, пожалуйста, как на вашем графике учитывается уровень доверия? Плюс у вас не учтён вариант с «отрицательной ценностью», когда в результате релиза фичи компания деньги не зарабатывает, а теряет.
Плюс не очень понятно по самому графику — по Y ценность, по X трудозатраты? Выглядит так, как будто у вас это именно вектора, но я не уверена, что понимаю правильно
Банк Идей глобально — просто список идей (например, в Excel), а бэклог зачастую размещают в таск-трекерах / диаграммах Ганта / специализированном инструментарии для роадмапов. Я думаю, автор имел ввиду именно эту разницу — идеи ещё не обязательно будут взяты в работу в том виде, в каком записаны и предполагают лёгкую запись, расширение и т.п.
Если баг воспроизводится и тестировщик ставит задачу, но сам баг редкий / некритичный / по другой причине не приоритетный, то как определяется, когда (если) задача берётся в работу?
Кто «грумит» этот бэклог? Продуктовый менеджер? На основе каких данных?
Или просто фиксированный объём человекочасов в каждом релизе фиксируется для исправления багов из бэклога саппорта?
Как правило, самая сложная в решении проблема — не рассортировать таски, а выделить ресурсы (особенно если не всё соответствует стратегическим планам компании) — интересно почитать, как вы решаете именно эту проблему
И если не секрет, чем занимается компания? Технологическая?
Что касается пересечения фичей:
В большинстве компаний всё равно так или иначе работа ведётся над несколькими задачами одновременно (даже канбан-метод это позволяет), полностью вся команда одну идею не пилит просто потому, что специализацию никто не отменял.
Проблемы фокусирования вроде не должно быть — программисты пишут код по шаг-проекту для идеи №1, исследователи и продакт работают над сбором фидбека по шаг-проекту идеи №2 и т.д.
Есть ощущение, что во многих компаниях одновременно в работе и так большое количество проектов (что распыляет, конечно), поэтому если это будут более «обстуканные об рынок» проекты, то глобально ничего не поменяется.
Про«каноничный скрам» ничего не могу сказать, если мне не изменяет память, скрамгайд не регламентирует распределение задач внутри DevTeam и распределение задач внутри проектов (или шаг-проектов в случае GIST), поэтому противоречия вроде бы нет.
Как решить проблему набора в спринт Инкрементов (задач) из разных проектов (шаг-проектов) — команда сама решит на планировании и возникшие по ходу сложности разберёт на ретро.
Как-то так мне видится :)
1. Кто входит в продуктовую команду кроме продуктовых менеджеров? Исследователи (какие?), маркетинг?
2. Как решаете проблемы, связанные с заморозкой задач (изменились приоритеты, продуктовая команда изменила после исследований / действий регулятора / etc.)? Due date в этом случае на время заморозки как-то обнуляется?
3. Почему не формируете кросс-функциональные инженерные команды вокруг продуктовых команд? Как я поняла из текста, у вас сейчас матричная структура и проблемы планирования возникают именно из-за этого размазывания продуктовых задач по функциональным отделам.
4. Когда применялась схема работы №3, как были приняты решения о распределении квот между командами? Вычислялась ли какая-то бизнес-составляющая (доходность, перспективность, важность для пользователя и т.п.) продукта, что влияло на приоритеты в выделении инженеров?
Конкретно GIST хорошо ложится на OKR (что упомянуто как раз с примерами), а OKR сам по себе подразумевает бОльшую гибкость, переход от мышления вида «план-задача» в сторону «цель-задача», при этом ещё и задачу исполнитель сам себе ставит.
Начинать переход можно хотя бы с формулирования стратегии на год в виде целей, а не задач, пусть даже на первых порах задачи тоже будут спускаться сверху директивно. Это может быть больно, будет становиться заметно, насколько «верх» способен грамотно поставить директивную задачу, которая будет достигать заданной цели, что вызовет вопросы к компетентности. Возможно, в компании начнутся более глобальные изменения, которые повлекут изменение подходов…
В общем, переход от одной парадигмы к другой непрост, но, имхо, стоит того :)
Другое дело, что не все компании понимают необходимость таких переходов, но каждый сотрудник всегда оставляет за собой право голоса ногами, благо рынок (по крайней мере, технологический) позволняет
Конкретно эта статья мне понравилась тем, что кроме понимания базовых предпосылок и определения целей проектов она рассказывает ещё и об управлении идеями по достижению этих целей. И тогда фокус очень хорошо смещается с «надо придумать, что делать, чтобы разработчики не простаивали» к «надо выбрать, что делать, чтобы бизнес зарабатывал больше / рос быстрее / вышел из кризиса / etc.»
В банках же даже о продукте думают не так часто (про потребителя вообще молчу).
Улучшательство касается не только банков, а любой продуктовой компании и очень хорошо чувствуется в работе с фича-риквестами — сначала приоритетное внутреннее, потом, когда (если) руки дойдут до пользовательских просьб (что тоже оправдано, но это отдельный разговор).
Про требования и сроки уже писали выше, но даже само использование слова «требования» говорит о том, что банк хочет эксплуатировать стартап как аутсорс-компанию, а не как стартап.
В стартапах нет понятия «требования» — есть гипотезы, их нужно тестировать. А всё, что банк пытается продавить под видом экспертного понимания рынка и потребностей аудитории — иллюзии «бывалых», которые совпадают с реальностью не чаще, чем средние показатели по рынку (т.е. вероятность близка к нулю).
Стартапы тем и хороши, что не встраиваются в принятые «культуру», «бизнес-процессы» и «регламенты» — иначе стартап становится просто ещё одним подразделением со всеми проблемами банка
Или это больше стратегический проект, на который не делаются какие-то большие ставки и проектные цели на уровне «сделать, чтобы было»?
В каждой компании такие отделы отвечают за разное — от экспериментальных проектов до дата-сайенса, ваше видение не до конца понятно.
У вас в тексте:
В чём принципиальное отличие от «простой» разработки?