Управление операционной деятельностью
Как вы знаете, проектная деятельность противопоставляется операционной, которая соответствует тем признакам, которые Вы указали. На мой взгляд, имеет смыл использовать УП, если Вы собираете исправления в блоки и исправляете блоками.
RE: Применение управления проектами в задачах сопровождения ПО
По моему опыту применение средств планирования в узком, специализированном подразделении, которое занимается сопровождением ПП не имеет смысла. Здесь более актуальна задача учета расхоода ресурсов и оптимальное их распределение при хаотически возникающих задачах.Единственное "за" использование системы планирования таких как MS Project (+ MS PRJ Server - обязательно) это когда группа занимается разработкой новых продуктов и сопровождением версий находящихся в промышленной эксплуатации. Тогда есть возможность отслеживания изменения календарных сроков работ по новым проектам и анализа изменения этих сроков. Работы по сопровождению, как правило, имеют более высокий приоритет - удовлетворение запросов заказчика. RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Немного не так. Вы разрабатваете проект по созданию нового ПП. При планировании работ (я Вам рассказваю как это делается в MSPRJ+PRJServer) вы заранее планируете процент занятости ресурсов на новые разработки, например 70% 30% оставляете на сопровождение. Или заводите циклическую работу - сопровождение модуля Х для кождого члена команды. Далее дело техники. При возниконвении непредвиденных работ с высшим приоритетом участник проекта заводит в WEBе новую работу. Она автоматически попадает в Ваш проект после утверждения руководителем проекта. Эта работа заставит перераспределить ресурсы в проекте и проанализировать сдвижки календарных сроков разработки новых версий или продуктов. Далее вы можете проанализировать причины срыва сроков работ по плану и перераспределить резервы ресурсов на сопровождение. Для этого можно активно использовать baseline.
RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Нет наоборот. Вы все работы концентрируете в одном проекте. Дальше идут подпроекты. Более того вы должны заранее продумать классификацию работ (аналитику) проектирование, анализ, кодирование, исправление ошибок и т.д. Для этого предлагаю Вам использовать outline code.Тогда Вы в любой момент можете произвести группировку своего отчета по введеным аналитическим признакам. Например посмотреть какие работы Вы в группе проводили по исправлению ошибок - это и есть сопровождение. Терминология уже - Ваше дело, это как принято в Вашей команде. Значит вы легко получите данные и по расходывание ресурсов на сопровождение. Если Вы введете и другие аналитические признаки по задачам (работам) Вы сможете очень быстрро почти мгоновенно получить отчеты по расходу ресурсов на опредленного клиента, модуль, и т.д. А это деньги. RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Господа, дискуссия мне кажется странной. Ну конечно же сопровождение слабо отделимо от разработки следующих версий и представляет собой типичную проектную деятельность, хотя больше напоминает не проект, а программу (конец никогда не виден). У себя мы держим горизонт планирования 2 года (rolling wave planning) и используем Spider Project, а не MS project. И конечно управление ведется ресурсами и приоритетами задач, и конечно здесь риски и неопределенности и возникают непредвиденные задачи (и фазы), которые встраиваются в проект в соответствии со своими приоритетами. Но как же иначе?
RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Еще одно замечание. Для получения анализа перегрузки по совокупности проектов Вы должны использовать общий пул русурсов. Есть такое понятие в MSPRJ. Это файл MS PRJ в котором заведены все ресурсы вашей команды людские и материальные. При создании нового проекта вы назначаете ресусры не в ручную а вибираете из данного пула. Тогда Вы лего получаете общую загрузку ресурса по всем проектам и быстро разрешаете кофликтные ситуации - перегрузку ресурсов.
RE: RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
А чем Вас удивила данная дисскусия. Почему мы используем MSPRJ а не Spider. Дело не в продукте а возможности в организации что то использовать. Да сопровождение ПП делает планирование работ в проекте постоянной работой)). Есть такое дело. Но проект начинается и заканчивается. Сопровождение постоянно. Приходится эту бадягу тянуть из проекта в проект. Для получения отчетности для этого и используется общий пул ресурсов. Я не знаком с Spider Project может в нем все проще. Расскажите RE: RE: RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Николай,дискуссия меня удивила потому, что мне кажется, что проектная природа проведения любых изменений очевидна. Спайдер и Проджект здесь ни при чем. А какой инструмент лучше использовать зависит от вашей потребности моделирования ресурсов. Никогда не кончается программа, которая состоит из проектов. Про Спайдер на этом сайте выложена статья [ссылка...] Если будут вопросы - задавайте. Всего наилучшего. RE: RE: RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Конечно не зависит.И является ли сопровождение проектом или подпроектом зависит от компании. Для разработчика - подпроект, для дистрибьютора - проект. А точнее - программа. И дискуссия на тему - отдельный ли он, не имеет большого смысла. Управление организацией - это мультипроектное управление и использование общих ресурсов эти проекты связывает. Всего наилучшего. RE: RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Николай,управление организацией - всегда мульти-проект с общим пулом ресурсов, в котором еще полезно и рутинную деятельность этих ресурсов прописать. Надо отметить, что мультипроект практически всегда велик и эффективность управления ресурсами сильно зависит от возможностей пакета моделировать их реальную работу. Добавлю, что в мультипроекте важно, чтобы в отдельных проектах использовались общие подходы и аналогичные оценки аналогичных работ, т.е. использовались корпоративные стандарты описания работ проектов. RE: RE: RE: RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Спасибо за ссылку.
RE: RE: RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Я с Вами полностью согласен. С точки зрения теории и правил использования продукта (в данном случае я имею в виду MS Prj) Вы абсолютны правы. Но в нашей действительности можно наблюдать что угодно. Каждое поразделение живет своей жизнью а руководство хочет видеть сводный отчет. Дело доходит до моразма. Каждое подразделение планирует свою деятельность самостоятельно, без учета загрузки общих ресурсов с другими подразделениями. Потом представляется отчет по УСТАНОВЛЕННОЙ форме руководству. Дальше еще веселее - секретарша НЮРА))) сводит все отчеты в общую Excel табличку, распечатывает и лолжит на стол РУКОВОДИТЕЛЮ. Это реальные пример из жизни, я это лючно лицезрел.Спрашивается почему так? Да очень просто - систему планирования украли, ну в крайнем соучае как то ее получили. А средства в методологию и обучение сотрудников никто не собирается вкладывать. Вот и получается система планирования))) вроде как бы и есть. что касается вопроса автора этой темы. ДЕЛАТЬ отдельные проект по сопроводению или вести в общем. НА мой взгляд - проект должен быть общим. Или на крайний случай состоять из залинкованных проектов. Это на мой взгляд обязательно. Тогда руководиель подразделения более легко получить весь список работ сотрудника и легче перераспределит ресурсы Но это только мое мнение)) Успехов. RE: RE: RE: RE: RE: RE: RE: RE: Применение управления проектами в задачах сопровождения ПО
Система будет работать при наличии общего языка и культуры. Если этого нет, то никакой пакет не поможет.Всего наилучшего. |