Comments 5
Я так и не понял как оценивать проекты. Как это все переложить на доступные производственные мощности? Как оценить проект, если в нем 50% ресерча? Какой в этой системе смысл?
Ну, это довольно логично, поскольку я писал не про то, как оценивать проекты, а про то, как оценивать задачи :) Проект, если под ним подразумевается блок работ с единственной целью, с проектным управлением и top-down декомпозицией, оценивается так:
Беретё вашу WBS, разбиваете до уровня задач в компетенции одного разработчика и оцениваете каждую из этих задач. Если метод сигнализирует скрытый объём части задач — переразбиваете. Далее делите метрику на скорость (в моей жизни, переходный коэффициент получался примерно 10 для опытных разрабов и 5 для новичков), получаете пессимистичные оценки времени. Оптимистичные оценки получаете другим способом экспертной оценки. Запускаете PERT, выделяете критичные пути, назначаете ресурсы, имеете обсчитанный проект. Проверялось в масштабе до года.
Что же касается чистого ресерча — не программистского «ресерча», когда мы боремся с техническими проблемами и пытаемся побыстрее выдать готовый код — а исследования рынков, выявления потребностей заказчика, каких-то инновационных R&D начинаний — такой ресёрч, конечно же, посчитать этим способом нельзя. Я, собственно, и не обещал :)
Беретё вашу WBS, разбиваете до уровня задач в компетенции одного разработчика и оцениваете каждую из этих задач. Если метод сигнализирует скрытый объём части задач — переразбиваете. Далее делите метрику на скорость (в моей жизни, переходный коэффициент получался примерно 10 для опытных разрабов и 5 для новичков), получаете пессимистичные оценки времени. Оптимистичные оценки получаете другим способом экспертной оценки. Запускаете PERT, выделяете критичные пути, назначаете ресурсы, имеете обсчитанный проект. Проверялось в масштабе до года.
Что же касается чистого ресерча — не программистского «ресерча», когда мы боремся с техническими проблемами и пытаемся побыстрее выдать готовый код — а исследования рынков, выявления потребностей заказчика, каких-то инновационных R&D начинаний — такой ресёрч, конечно же, посчитать этим способом нельзя. Я, собственно, и не обещал :)
Хороший подход, сроки он не даст, но общую сложность задач покажет. А уже из сложности можно вывести коэффициент на который нужно умножить сроки, после того как их примерно прикинули :)
Я это понял так:
Есть 3д куб где оси:
X — кол-во задач (размер ТЗ)
Y — кол-во различных технологий которые нужны для реализации
Z — отсутствие опыта/информации/техподдержки по используемым технологиям/библиотекам
все грани от 1-5
по простой формуле x*y*z получаем объем задач где учтены ресерч и тех риск.
Из этого числа X — это та часть айсберга что видна, а все остальное под водой.
Я это понял так:
Есть 3д куб где оси:
X — кол-во задач (размер ТЗ)
Y — кол-во различных технологий которые нужны для реализации
Z — отсутствие опыта/информации/техподдержки по используемым технологиям/библиотекам
все грани от 1-5
по простой формуле x*y*z получаем объем задач где учтены ресерч и тех риск.
Из этого числа X — это та часть айсберга что видна, а все остальное под водой.
Sign up to leave a comment.
Как научиться оценивать задачи, если не умеешь: 4 фактора сложности