Комментарии 5
Каким образом или по каким критериям Вы планируете определять альфы в контексте OMG Essence? На примере упомянутого supplies. В Essenсe Kernel где есть альфа – System Software, предполагается что она описывает наш разрабатываемы продукт и его жизненный цикл, созданием которого мы управляем и потом передаем заказчику. Для управления работами по созданию нашего продукта есть альфа Work или, в вашем случае Delivery, где в т.ч. и должна быть одна из активностей по закупке (supplies). Получается что альфу Supplies имеет смысл выделять когда это является отделяемым продуктом/сервисом который потребляют наши заказчики и который имеет свой жизненный цикл, но не так как планируется у вас.
...
Спасибо за опыт.
Для меня эта история больше не про то, что вы использовали подход OMG Essense, а просто оцифровали работу с проектами в компании по всем кубикам, начиная от ее оценки и финанисрования до контроля исполнения.
Однако самый любопытный вопрос остался за кадром: дашборд все показывает красиво, когда он хорошо настроен на необходимые учетные системы.
Откуда берется информация о:
процессе бюджетирования - интегрировано с какой то внутренней системой или ведется вручную?
контроля бейзлайнов и текущих работ (Гантт) - интегрировано с внешней системой или является частью вашего продукта?
контроля рисков - берется из внешней системы или ведется в этом продукте? кто заполняет риски и кто определяет их вес для системы?
вы помянули коннектор к JIRA для получения данных по задачам, а для чего вам эти данные и как вы связываете план и факт в системе?
Спасибо за интерес.
данные поступают из собственной системой бюджетирования
является частью продукта
часть берётся из JIRA, там риск - один из типов задач, поля заполняются вручную владельцем проектной роли Risk Manager; часть - выявленные несоответствия между статусом проекта и стадии альфы
для каждой вехи (полоски в Ганте) через поисковый запрос к JIRA определено множество задач, закрытие которых необходимо и достаточно для выхода на эту веху. система строит burndown для таких задач с учётом ресурсного плана проекта, отпусков, вероятных ошибок в оценках и множества других факторов. через этот burndown анализируется динамика списаний трудозатрат и закрытия задач, рассчитывается прогнозная дата завершения работ, которая отражается в Гантт на dashboard (конец красного участка) и соотносится с плановой датой (начало красного участка). как-то так, если кратно
Проектный офис «Рексофт» внедрил в производственный процесс приёмы ситуационной инженерии методов