Comments 13
Приветствую!
Лучше осветите возможности Мерлина, которые отсутствуют в продукте от Микрософт.)
Лучше осветите возможности Мерлина, которые отсутствуют в продукте от Микрософт.)
Внутренний и внешний план — это так по-столичному… две непересекающихся реальности. Все потому что бюджет заказчику показывают совсем отличный от бюджета по себестоимости. И все потому что есть две ставки, одна для команды продажников, другая из ресурсного офиса. И в центре всего балета — шальная как ЭКГ маржа.
Спасибо за ваш комментарий.
Ещё раз пожалуйста прочитайте формализацию понятий «внутренний» и «внешний» тайм-планы.
Если вы можете за все неявные риски на моменте оценки в последствии костить клиента — это отлично. Но в действительности должен ли любой крупный клиент за вас сам закладывать риски в годовой бюджет на разработку?
И, кстати, «по себестоимости», наверное, это не про бизнес ;)
Ещё раз пожалуйста прочитайте формализацию понятий «внутренний» и «внешний» тайм-планы.
Если вы можете за все неявные риски на моменте оценки в последствии костить клиента — это отлично. Но в действительности должен ли любой крупный клиент за вас сам закладывать риски в годовой бюджет на разработку?
И, кстати, «по себестоимости», наверное, это не про бизнес ;)
Кстати, «команды продажников»/отдела продаж в компании AGIMA уже как, минимум, лет 5 — нет.
otherlight, спасибо! Кратко и по существу ) Есть небольшая боль с командами крупных брендов – принципиально не принимают тайминги НЕ в Excel. В итоге делаешь тайминг в Мерлине/ОмниПлане/Прожекте, а аккаунт для клиента всё равно в Excel перерисовывает ;)
UFO just landed and posted this here
Прошу прощения, но в статье уже содержится ответ на ваш вопрос в предпоследнем абзаце.
Предугадать все сроки никогда нельзя, но управлять требованиями, рисками, бюджетом и контрольными точками по продукту — вполне. Без предварительного тайм-плана это будет в разы менее эффективно. И чем более реален предварительный план — тем больше шансов на успех.
Данная практика была проверена на достаточно большом количестве действительно сложных и крупных проектов, но конечно же не может являться панацеей ;)
Предугадать все сроки никогда нельзя, но управлять требованиями, рисками, бюджетом и контрольными точками по продукту — вполне. Без предварительного тайм-плана это будет в разы менее эффективно. И чем более реален предварительный план — тем больше шансов на успех.
Данная практика была проверена на достаточно большом количестве действительно сложных и крупных проектов, но конечно же не может являться панацеей ;)
UFO just landed and posted this here
В целом гибкие методики скорее применимы когда нет точного понимания по конечному продукту и надо проверять бизнес гипотезы и подтверждать их количественными показателями. В других случая — в сравнение с водопадом, например, они будут в разы дороже, а речь всё-таки про коммерческую разработку где часто надо сэкономить бюджет заказчика.
К тому же, я считаю что есть необходимость и при использовании фреймворков гибких методологий, планировать и прогнозировать каждую итерацию разработки версии продукта для принятия тех или иных управленческих решений.
Если всё утрировать и обсуждать разработку сложного приложения в вакууме по гибким методологиям, то при наличие дорожной карты по фичам в разрезе версий — диаграммой Гантта, имхо, лучше всего планировать именно итерацию разработки версии. Версия содержит эпики, эпики в свою очередь спринты, спринты несколько стримов. При адекватной и устоявшейся команде разработки почти все риски являются явными на момент планирования итерации версии продукта, что позволяет достаточно точно определить критический путь этой итерации.
Диаграмма Гантта — это не про то, как точно определить даты дедлайнов. Это про то, как зафиксировать абсолютные контрольные точки по пути решения и далее уже работать с минимизацией рисков и другими параметрами проекта. Ресурсы, бюджеты и даты — всё относительно на Гантте, а вот майлстоуны — абсолютны!
К тому же, я считаю что есть необходимость и при использовании фреймворков гибких методологий, планировать и прогнозировать каждую итерацию разработки версии продукта для принятия тех или иных управленческих решений.
Если всё утрировать и обсуждать разработку сложного приложения в вакууме по гибким методологиям, то при наличие дорожной карты по фичам в разрезе версий — диаграммой Гантта, имхо, лучше всего планировать именно итерацию разработки версии. Версия содержит эпики, эпики в свою очередь спринты, спринты несколько стримов. При адекватной и устоявшейся команде разработки почти все риски являются явными на момент планирования итерации версии продукта, что позволяет достаточно точно определить критический путь этой итерации.
Диаграмма Гантта — это не про то, как точно определить даты дедлайнов. Это про то, как зафиксировать абсолютные контрольные точки по пути решения и далее уже работать с минимизацией рисков и другими параметрами проекта. Ресурсы, бюджеты и даты — всё относительно на Гантте, а вот майлстоуны — абсолютны!
Sign up to leave a comment.
«Идеальный» тайм-план в виде диаграммы Гантта