Я полагаю что такое сокращение в том числе связано и со стандартным когнитивным искажением название которого не припомню, но в книге «Сила воли» в одной из глав о нем много говорится. Суть в том, что мы склонны переоценивать себя в будущем. То есть когда люди записывались к вам в основном они игнорировали все свои предыдущие неудачные попытки и прочие факторы с которыми они сталкивались и твердо были уверены что в этот раз точно получится. Ну и по динамике вы видите что чуда не случилось и все такое.
По моему опыту помогает делать картинку не такой грустной встраивание в курс/продукт инструментов рефлексии, которые помогают юзерам задуматься и понять что изменилось в их жизни с появлением у них вашего вот это всего. В плане Agile полагаю сквозной проект на какую-то важную для пользователей тему на котором они могли бы учиться и реально ощущать от этого пользу мог бы помочь.
«Диетическое мышление — основанное на мифах и легендах и не имеющее научных обоснований следование пищевым ограничениям, которые якобы поддерживают стабильный вес и способствуют здоровью»
Елена Мотова «Мой лучший друг — желудок»
В иерархии ценностей «отвечать за свои слова и прочее» выше чем «вливаться в текущий коллектив». Идея удовлетворять кого-то (большинство или меньшинство) — утопична по своей сути.
Появилось впечатление, что на проекте существует какое-то кол-во работ которое не связано никак с потребностями/ценностью для заказчика и странно было видеть WIP в %.
Что касается применения CFD для отслеживания ценности… Не знаю даже. CFD — отличный визуальный инструмент для отслеживания здоровья kanban-проекта который объясняется за 2 минуты и действительно позволяет по картинке сделать вывод о том что и где подкрутить (например youtu.be/eo2uv8avEsU). То, что описано у Вас я не сильно понимаю как и зачем применять на проектах. Есть доска с ежедневной работой команд(-ы) которую нужно оптимизировать по lead time, wip и т.д., а есть roadmap в котором запланированы значимые для Заказчика проектные достижения. Доска и дорожная карта синхронизируются периодически и рассказываются Заказчику. Зачем их скрещивать не понятно.
У меня на проекте, например, есть крутой тестировщик, которому я делегировал 90% обязанностей владельца продукта (оставшиеся 10% это то, что приходит мне от заказчика, а я уже передаю своему коллеге)
Эммм… Простите, но это не так работает в аутсорсе. Если вы пилите с заказчиком что-то по скраму, то роль РО — это только заказчик. Он накидывает в эклог требования, он их приоритезирует, он принимает у команды работу на sprint review. Ни Вы, ни QA не могут выполнять эту роль. Обычно Заказчику продают в помощь бизнес/системного аналитика, который прорабатывает бэклог и доводит юзер сотри до состояния ready for refinement/planning. Это удобно и Заказчику (у него по требованиям single point of contact) и команде — они задают вопросы по требованиям человеку в команде.
Дело в том что, когда оцениваете таски в часах, то часы получаются у всех разные, у кого-то уйдет 6 часов на создание доменной сущности (условный таск), у кого-то 7, у кого-то 8. В стори поинтах же у всех будет одинаково = 8.
Вы не совсем поняли что такое оценка сложности насколько я понял из написанного. Сравнивать часы и сотри поинты это сравнивать мягкое с кислым. Могу порекомендовать книгу Кона «Оценка и планирование Agile проектов».
Не нужно работать по вотерфоллу или по скраму, чтобы управлять проектами успешно. Нужно работать круто. Только и всего.
Спасибо огромное. С большим удовольствием прочитал Вашу статью. Системно, подробно, полезно.
огромное спасибо за ссылку, чудесный обзор
очень согласен. ни один венеролог не переболевший раз 5 сифилисом в жизни не поможет больному.
По моему опыту помогает делать картинку не такой грустной встраивание в курс/продукт инструментов рефлексии, которые помогают юзерам задуматься и понять что изменилось в их жизни с появлением у них вашего вот это всего. В плане Agile полагаю сквозной проект на какую-то важную для пользователей тему на котором они могли бы учиться и реально ощущать от этого пользу мог бы помочь.
Елена Мотова «Мой лучший друг — желудок»
Что касается применения CFD для отслеживания ценности… Не знаю даже. CFD — отличный визуальный инструмент для отслеживания здоровья kanban-проекта который объясняется за 2 минуты и действительно позволяет по картинке сделать вывод о том что и где подкрутить (например youtu.be/eo2uv8avEsU). То, что описано у Вас я не сильно понимаю как и зачем применять на проектах. Есть доска с ежедневной работой команд(-ы) которую нужно оптимизировать по lead time, wip и т.д., а есть roadmap в котором запланированы значимые для Заказчика проектные достижения. Доска и дорожная карта синхронизируются периодически и рассказываются Заказчику. Зачем их скрещивать не понятно.
Эммм… Простите, но это не так работает в аутсорсе. Если вы пилите с заказчиком что-то по скраму, то роль РО — это только заказчик. Он накидывает в эклог требования, он их приоритезирует, он принимает у команды работу на sprint review. Ни Вы, ни QA не могут выполнять эту роль. Обычно Заказчику продают в помощь бизнес/системного аналитика, который прорабатывает бэклог и доводит юзер сотри до состояния ready for refinement/planning. Это удобно и Заказчику (у него по требованиям single point of contact) и команде — они задают вопросы по требованиям человеку в команде.
Вы не совсем поняли что такое оценка сложности насколько я понял из написанного. Сравнивать часы и сотри поинты это сравнивать мягкое с кислым. Могу порекомендовать книгу Кона «Оценка и планирование Agile проектов».
А чтобы не болеть — живите здоровыми.