Комментарии 18
Если абстрагироваться от конкретной проблемы с недооценкой/переоценкой и рассмотреть проблему глобальней, то получим следующее: хвост виляет собакой. Надеюсь, что ни для кого не открою секрета, что IT отрасль является прикладной. То есть должна прикладываться к чему-либо ещё, и помогать решать проблемы той области. И раз у нас всё перевернули с ног на голову, то получаются такие сферические кони в вакууме. Вроде выпускают прекрасную программу/фичу/плагин, а она никому не нужна…
Мне одному кажется, что в координатах «усилия — эффект» должны быть не прямоугольники, а что-то вроде этого?
И последняя формула
на это намекает.
И последняя формула
на это намекает.
Оригинальная матрица предполагает использование именно квадрантов (более подробно, например, тут: habr.com/company/hygger/blog/359208)
Последняя формула выведена автором именно с учётом критики оригинальной матрицы.
Предложенная картинка выглядит интересно :)
Раскройте, пожалуйста, как на вашем графике учитывается уровень доверия? Плюс у вас не учтён вариант с «отрицательной ценностью», когда в результате релиза фичи компания деньги не зарабатывает, а теряет.
Плюс не очень понятно по самому графику — по Y ценность, по X трудозатраты? Выглядит так, как будто у вас это именно вектора, но я не уверена, что понимаю правильно
Последняя формула выведена автором именно с учётом критики оригинальной матрицы.
Предложенная картинка выглядит интересно :)
Раскройте, пожалуйста, как на вашем графике учитывается уровень доверия? Плюс у вас не учтён вариант с «отрицательной ценностью», когда в результате релиза фичи компания деньги не зарабатывает, а теряет.
Плюс не очень понятно по самому графику — по Y ценность, по X трудозатраты? Выглядит так, как будто у вас это именно вектора, но я не уверена, что понимаю правильно
Y ценность, по X трудозатратыДа, это оси.
Отрицательная ценность — ну продолжим график вниз. Вот дорисовал:
Уровень доверия — можно вот так:
результат = (ожидаемый результат) * (уровень доверия).
В экономике есть гораздо интереснее методы, например риск-эффективность-стоимость. Там формируется наилучший портфель с точки зрения эффективности и риска. Эффективность = эффект / затраты.
В данной статье разобран наиболее популярный (по субъективному мнению автора) метод приоритизации бэклога, предложены способы улучшения этого метода.
Как альтернативу можно использовать и другой метод, конечно, однако в вашем предложенном методе проблемы, описанные выше, сохраняются — при оценке риска, эффекта и затрат проявляются те же когнитивные искажения, что так же влияет на всю оценку
Как альтернативу можно использовать и другой метод, конечно, однако в вашем предложенном методе проблемы, описанные выше, сохраняются — при оценке риска, эффекта и затрат проявляются те же когнитивные искажения, что так же влияет на всю оценку
Ну нет. Когнитивные искажения — это личное (субъективное) изобретение автора. Все что не очень известно — в экономике моделируется как риск (и если более глубоко, чувствительности к риску, но сперва — риск). Короче, тот метод о котором я — покрывает все когнитивные субъективные искажения оригинального автора.
Смотрите здесь.
Смотрите здесь.
В целом РЭСТ-диаграммы вместе с описанным методом построения
гистограмм эффекта дают достаточный набор средств для принятия
решений о выборе пакета мероприятий, обеспечивающих достижение
поставленной цели.
Когнитивные искажения — не изобретение автора.
Психолог Д. Канеман получил Нобелевскую премию за исследования в этой сфере, в них он опроверг все имевшиеся на тот момент предположения о рациональности людей, описываемые экономической моделью.
Нобелевку он получил в 2002, представленный вами документ датируется 1997 годом, поэтому игнорирует иррациональность человека и пытается описывать риски как матмодель.
У Канемана есть книга «Thinking, fast and slow», которая как раз излагает суть исследований и на примерах раскрывает ущербность теории о том, что люди рациональны
Психолог Д. Канеман получил Нобелевскую премию за исследования в этой сфере, в них он опроверг все имевшиеся на тот момент предположения о рациональности людей, описываемые экономической моделью.
Нобелевку он получил в 2002, представленный вами документ датируется 1997 годом, поэтому игнорирует иррациональность человека и пытается описывать риски как матмодель.
У Канемана есть книга «Thinking, fast and slow», которая как раз излагает суть исследований и на примерах раскрывает ущербность теории о том, что люди рациональны
Нобелевку дают после изобретения, через много лет. Что такое когнитивные искажения я в курсе.
Только вот не надо натягивать сову на глобус, теории Канемана в статье ноль повдоль и поперек. И еще, я нигде не утверждал что люди рациональны. Рациональны их теории, особенно те, которые обоснованы выводами — и способны дать применимый результат (в отличие от психологии Канемана).
Вобщем, за деревьями лес где-то есть, я вас обрадую (начинается он с того, что люди Канемана и риски проектов немного разные вещи). «Риски как матмодель» — привет из августа 2008 — основа экономики. Те кто ими пренебрегает, перестает быть экономическим субъектом (и становится предметом изучения Канемана).
Только вот не надо натягивать сову на глобус, теории Канемана в статье ноль повдоль и поперек. И еще, я нигде не утверждал что люди рациональны. Рациональны их теории, особенно те, которые обоснованы выводами — и способны дать применимый результат (в отличие от психологии Канемана).
Вобщем, за деревьями лес где-то есть, я вас обрадую (начинается он с того, что люди Канемана и риски проектов немного разные вещи). «Риски как матмодель» — привет из августа 2008 — основа экономики. Те кто ими пренебрегает, перестает быть экономическим субъектом (и становится предметом изучения Канемана).
Справедливости же ради отмечу. Сам пользуюсь примитивным ранжированием по эффективности с отсечением по затратам.
Это математически оптимальный способ формирования портфеля (если риск не учитывается, или учтен в эффективности — для этого тоже есть способы).
Если по шагам надо — есть однорукие бандиты. Вобщем много всего хорошего есть.
Это математически оптимальный способ формирования портфеля (если риск не учитывается, или учтен в эффективности — для этого тоже есть способы).
Если по шагам надо — есть однорукие бандиты. Вобщем много всего хорошего есть.
Из статьи непонятно, как дела обстоят с зависимостями в такой матрице?
«Быстрые деньги», как и «инкрементальные» решения могут повлечь за собой как плохое качество кода и архитектуры, так и создать для компании постоянные затраты в виде вынужденной бесплатной технической поддержки. Зачастую такие решения предполагают невозможность рефакторинга в будущем.
Часто бывает так, что одно и то же решение задачи может быть как в «быстрых деньгах», так и в «больших ставках». Думаю, менеджеры чаще будут выбирать «быстрые деньги» и расплачиваться в долгосрочной перспективе.
Приведу простой пример для маленькой компании. Сделать систему автоматического обновления ПО с затратами на серверную часть и оплату начальной настройки — это дорого. Релизы будут ручками создаваться и выкладываться на сайт. Но в перспективе на несколько лет время, потраченное на обновление ручками, может оказаться дороже изначального создания системы обновления. Но реализовывать систему всё равно придётся, поэтому затраты получатся намного больше. При этом стоит учесть, что время потраченное на создания обновлений ручками — это ещё и упущенная выгода, т. к. часть времени разработчиков была потрачена впустую, из-за чего продукт недополучил какую-то фичу.
- От реализации задачи из «денежной ямы» может зависеть реализация задачи из «больших ставок».
- Несколько задач из «быстрых денег» могут сместить задачи из «больших ставок» в «денежную яму» или того хуже, — в зону убыточности.
- Часто реализуемые «инкрементальные» задачи могут смещать все остальные задачи по графику в разные места. При этом эти задачи могут быть даже опаснее всего в долгосрочной перспективе.
«Быстрые деньги», как и «инкрементальные» решения могут повлечь за собой как плохое качество кода и архитектуры, так и создать для компании постоянные затраты в виде вынужденной бесплатной технической поддержки. Зачастую такие решения предполагают невозможность рефакторинга в будущем.
Часто бывает так, что одно и то же решение задачи может быть как в «быстрых деньгах», так и в «больших ставках». Думаю, менеджеры чаще будут выбирать «быстрые деньги» и расплачиваться в долгосрочной перспективе.
Приведу простой пример для маленькой компании. Сделать систему автоматического обновления ПО с затратами на серверную часть и оплату начальной настройки — это дорого. Релизы будут ручками создаваться и выкладываться на сайт. Но в перспективе на несколько лет время, потраченное на обновление ручками, может оказаться дороже изначального создания системы обновления. Но реализовывать систему всё равно придётся, поэтому затраты получатся намного больше. При этом стоит учесть, что время потраченное на создания обновлений ручками — это ещё и упущенная выгода, т. к. часть времени разработчиков была потрачена впустую, из-за чего продукт недополучил какую-то фичу.
Отвечу по пунктам:
По примеру — именно для таких кейсов автор и предлагает вводить понятие уровня доверия, чтобы не гадать, что и сколько в каких перспективах принесёт — проблемы, упущенную выгоду или переработку т.к. космолётным решением никто не пользуется
- Если использовать матрицу для приоритизации продуктового бэклога (приоритизация проектов), а не проектного (приоритизация задач), то внутри проекта задачи из «денежной ямы», требующиеся для реализации задач из «больших ставок» относятся к одному проекту и оцениваются совокупно.
- Не очень понятно, что вы имеете ввиду под «могут сместить» — приведите пример.
- В рамках именно приоритизации с помощью матрицы инкрементальные задачи должны «заполнять пустоты», а не быть самодостаточным проектом. Для решения проблемы смещения по графику как раз и предлагается более трезво оценивать сроки
- При оценке сроков подразумевается оценка реализации в целом, при этом низкое качество кода не навязывается матрицей, если разработчик оценил сроки с плохой реализацией, то матрица в этом точно не виновата :)
По примеру — именно для таких кейсов автор и предлагает вводить понятие уровня доверия, чтобы не гадать, что и сколько в каких перспективах принесёт — проблемы, упущенную выгоду или переработку т.к. космолётным решением никто не пользуется
Не очень понятно, что вы имеете ввиду под «могут сместить» — приведите пример.
Тут на хабре была очень интересная статья на эту тему "Чёрные треугольники". В реальном мире далеко не всегда решают создавать фреймворки или движки. А без них большая часть возможностей будет попадать в «денежную яму» или в «убыточность».
К примеру, есть задача открыть какой-либо файл (что-то сложное, например, 3D-сцена) и отобразить его содержимое на экране. Клиент уже готов платить. Можно взять за основу библиотеку для работы с этим форматом и завязать на неё отрисовку. Но другой клиент хотел более сложный формат файла, для которого нет библиотеки. Её будут писать и скорее всего завяжутся на уже реализованный функционал. Форматы могут сильно отличаться. И скорее всего реализация будет упираться в неудобства завязки на первую библиотеку. Неудобства в данном случае будут выражаться будущей поддержкой кода. Получается две задачи, одна в «быстрых деньгах», другая — в «денежной яме». Но если сделать абстракцию над библиотекой и свой движок вывода («денежная яма»), то на момент окончания реализации обе задачи перемещаются в категорию «быстрых денег». То есть все задачи в совокупности окажутся в категории «большие ставки». И тут дело уже за менеджерами, нужны ли им «быстрые деньги», либо быстро развивающийся продукт.
У меня уже большой опыт управления маленькой командой, могу сказать, что подобный выбор приходится делать постоянно. Часто делаются быстрые решения ради увеличения продаж, а рефакторинг откладывается на неопределённый срок. Но его приходится всё равно делать, чтобы увеличить скорость разработки новых функций. И получается, что огромная база legacy-кода удаляется в итоге в счёт универсальных решений. А в совокупности универсальные решения перерастают в собственный удобный фреймворк.
Приведённый вами пример как раз к оценке сроков и относится. Матрица обычно используется не для принятия технических решений, а для выбора, какую из идей брать в работу / не брать в работу.
Для простоты — ваш пример Идея1:
Реализация X — N дней, A отдачи
Реализация Y — M дней, B отдачи
При этом в бэклоге есть и другие идеи:
Идея2 — O дней, C отдачи
Идея3 — P дней, D отдачи.
И в данном случае, если для Идеи1 варианты реализации оценены некорректно (прогнозируемая отдача не учитывала риски техдолга или «подготовительных работ», которые относятся к проекту по реализации Идеи1), то и матрица отобразит это некорректно.
Вообще матрица — это инструмент визуализации оценок и сравнения их между собой, однако если оценки сделаны некорректно, то матрица это не как не «подсветит». Вопрос «торгов» за выбор того или иного решения для оценки как раз и решается формулой с уровнем доверия. Если менеджер оценивает вероятность преимуществ рефакторинга как низкую, а разработчик как высокую, уровень доверия это решит.
Есть разные способы определения уровня доверия и в следующей статье данного автора один из способов описан (планирую сделать перевод позже). Основное преимущество этого способа в том, что он отталкивается от реальных данных, а не споров технической и бизнес-команд
Для простоты — ваш пример Идея1:
Реализация X — N дней, A отдачи
Реализация Y — M дней, B отдачи
При этом в бэклоге есть и другие идеи:
Идея2 — O дней, C отдачи
Идея3 — P дней, D отдачи.
И в данном случае, если для Идеи1 варианты реализации оценены некорректно (прогнозируемая отдача не учитывала риски техдолга или «подготовительных работ», которые относятся к проекту по реализации Идеи1), то и матрица отобразит это некорректно.
Вообще матрица — это инструмент визуализации оценок и сравнения их между собой, однако если оценки сделаны некорректно, то матрица это не как не «подсветит». Вопрос «торгов» за выбор того или иного решения для оценки как раз и решается формулой с уровнем доверия. Если менеджер оценивает вероятность преимуществ рефакторинга как низкую, а разработчик как высокую, уровень доверия это решит.
Есть разные способы определения уровня доверия и в следующей статье данного автора один из способов описан (планирую сделать перевод позже). Основное преимущество этого способа в том, что он отталкивается от реальных данных, а не споров технической и бизнес-команд
Если подытожить, то матрица не учитывает альтернативные решения. А решения задач должны учитывать все риски, которые могут впоследствии возникнуть. Задачи всегда разбиваются не множество мелких, а вручную учесть и оценить обобщающие задачи будет практически нереально.
Как по мне, так матрица не жизнеспособна. Нужен менеджер, который, например, уже является профессиональным программистом, если речь о программировании. И нужно ПО, которое умеет распределять задачи между людьми и выдавать оценочные суммарные сроки. К сожалению, я пока такого ПО найти не могу.
Как по мне, так матрица не жизнеспособна. Нужен менеджер, который, например, уже является профессиональным программистом, если речь о программировании. И нужно ПО, которое умеет распределять задачи между людьми и выдавать оценочные суммарные сроки. К сожалению, я пока такого ПО найти не могу.
Если на матрице не размещать альтернативные решения, то она не будет их учитывать, конечно :)
По поводу необходимости технического бэкграунда у менеджеров уже сотни копий сломано, в том числе на Хабре. По своему опыту могу сказать, что мне лично навыки программирования помогают только в проектной части, а для продуктовой части менеджмента программерские навыки или фиолетовы, или оказывают негативный эффект.
Если рассматривать только одну сторону управления, то, конечно, понимание важности хорошей кодовой базы (~минимизированный техдолг) и опыт оценки сроков по собственному опыту программирования сильно помогает в организации процесса разработки.
Однако как показывает мировой опыт — одной только правильно выстроенной и успешно завершённой разработки недостаточно для успеха на рынке и статья как раз о том, чтобы оглядываться в первую очередь на бизнес-показатели продукта, а не на своё представление о нём и счастье пользователей
По поводу необходимости технического бэкграунда у менеджеров уже сотни копий сломано, в том числе на Хабре. По своему опыту могу сказать, что мне лично навыки программирования помогают только в проектной части, а для продуктовой части менеджмента программерские навыки или фиолетовы, или оказывают негативный эффект.
Если рассматривать только одну сторону управления, то, конечно, понимание важности хорошей кодовой базы (~минимизированный техдолг) и опыт оценки сроков по собственному опыту программирования сильно помогает в организации процесса разработки.
Однако как показывает мировой опыт — одной только правильно выстроенной и успешно завершённой разработки недостаточно для успеха на рынке и статья как раз о том, чтобы оглядываться в первую очередь на бизнес-показатели продукта, а не на своё представление о нём и счастье пользователей
Если на матрице не размещать альтернативные решения, то она не будет их учитывать, конечно :)
У меня сейчас одна из задач разбита на примерно 15 покрываемых тестами подзадач. Каждая задача по времени для одного программиста займёт от пары недель до пары месяцев. Но на самом деле то же самое можно сделать ещё тремя путями (один из которых — дорогостоящее сопровождение legacy-кода). Так вот, если менеджер не будет разбираться в программировании, то может понадобиться создавать по матрице на один такой альтернативный вариант (тоже трудозатраты). А если менеджер — хороший программист, то все остальные варианты отсеются на этапе совещания с командой.
Я хорошо знаю, что такое работать под началом человека, который умеет неплохо программировать, но профессионально этим не занимался, а команда сама ещё даже неопытная. И как потом происходит революция снизу вверх, чтобы реанимировать разработку проекта. Но если бы не было грамотного и инициативного человека в команде, проект так или иначе умер бы. Зачастую в таких ситуациях люди будут получать зарплату и молчать, если она их устраивает. А когда совсем припечёт, — просто уволятся.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Почему приоритизация по трудозатратам и ценности не работает