На фейсбук много групп по управлению проектами, где сидят в том числе разработчики и внедренцы ПО. Подобные вопросы там обычно получают живой отклик, попробуйте.
Про управление выгодами слишком часто забывают от слова совсем.
В идеале их нужно намечать ещё до одобрения проекта, на всём его протяжении отслеживать, насколько это актуально и при необходимости корректировать, а после завершения проекта измерять выгода, предпринимать действия по их максимизации и, где требуется, минимизации негативных последствий, и коммуницировать.
Совсем в идеале делать это с планом управления выгодами (но для маленьких проектов это уже чересчур).
Тогда получится целостно и всесторонне.
На самом деле не совсем. Про это как раз Паркинсон хорошо писал. Если на задачу поставить больше людей, совсем не факт, что она сделается быстрее. Как минимум увеличится время на коммуникации, согласования, исправления и все прочие радости. Вместо простых решений команда будет выбирать более сложные, требующие больше времени и несущие больше рисков. В итоге команда станет больше, работать все будут не меньше, а скорость поставки не сократится.
Разумеется, это тоже не закон :)
А 100% загрузки можно избежать другими способами. Например, не придумывать задачи просто чтоб создать загрузку. И не играть в мультизадачность, где это можно избежать.
Думаю, к закону Парето тоже стоит применять закон Парето :)
Во всяком случае, применять его механически и доводить до абсурда точно не стоит.
Если кто-то продаёт квартиры и не собирается стоить дом, это больше похоже на мошенничество, чем на управленческую проблему.
А вот ситуация, когда команда создаёт продукт, но никто не задумывается о продажах, встречается довольно часто. Иногда действительно полезно напомнить, что доход приносит именно продажа и на неё тоже стоит выделять ресурсы.
Я бы не стал относить регистрацию к 80%.
К 80% я бы скорей отнёс скринкаст «как пройти регистрацию» или возможность авторизоваться через Одноклассники.
Заказчик может вообще не задумываться о том, что регистрация — это отдельная сущность, но если без неё невозможна авторизация, которая ему нужна, то это must и те самые 20%.
Честно говоря, в жизни иногда даже самого себя приходится в этом переубеждать заново.
Здесь лучший аргумент — собственные ограниченные ресурсы. Ну и опыт, конечно.
В русском написании всё-таки Гант чаще используется.
Вы можете ограничить применение Кабан таким образом, но зачем?
Очень спорное утверждение даже для предиктивного подхода.
Можно и нужно. Посмотрите, например, русский перевод Essential Condenced Kanban Guide.
В идеале их нужно намечать ещё до одобрения проекта, на всём его протяжении отслеживать, насколько это актуально и при необходимости корректировать, а после завершения проекта измерять выгода, предпринимать действия по их максимизации и, где требуется, минимизации негативных последствий, и коммуницировать.
Совсем в идеале делать это с планом управления выгодами (но для маленьких проектов это уже чересчур).
Тогда получится целостно и всесторонне.
Я бы перевёл «Работа занимает всё отпущенное на неё время».
У вас появилось время — вы довели до идеала и проверили.
Разумеется, это тоже не закон :)
А 100% загрузки можно избежать другими способами. Например, не придумывать задачи просто чтоб создать загрузку. И не играть в мультизадачность, где это можно избежать.
Во всяком случае, применять его механически и доводить до абсурда точно не стоит.
Если кто-то продаёт квартиры и не собирается стоить дом, это больше похоже на мошенничество, чем на управленческую проблему.
А вот ситуация, когда команда создаёт продукт, но никто не задумывается о продажах, встречается довольно часто. Иногда действительно полезно напомнить, что доход приносит именно продажа и на неё тоже стоит выделять ресурсы.
К 80% я бы скорей отнёс скринкаст «как пройти регистрацию» или возможность авторизоваться через Одноклассники.
Заказчик может вообще не задумываться о том, что регистрация — это отдельная сущность, но если без неё невозможна авторизация, которая ему нужна, то это must и те самые 20%.
Грань в любом случае искать придётся. Перегиб ни в одну сторону не нужен.
Здесь лучший аргумент — собственные ограниченные ресурсы. Ну и опыт, конечно.