项目管理系统对于实际管理需求的对应

刚刚和软件部门的部门经理进行了一会儿的讨论。
部门经理提出了他在今年的管理思路,然后想询问目前的项目管理系统如何对应。
管理思路如下:

整个部门会分为若干个项目团队,每个团队有唯一的负责人。
每个团队会同时负责多个系统/项目,每个项目的有唯一的负责人。(我建议项目的负责人就由团队负责人兼任)
各个系统/项目的需求来源会是多渠道的,有可能是不定期的。
部门经理日常既需要按照项目团队来管理人力资源,有需要按照系统/项目来进行业务管理。
部门经理需要看到针对团队和项目的不同层次的规划。
鉴于目前公司使用的REDMINE系统,我提出的对应方案如下:
针对每一个项目团队,在系统中建立单独的项目。团队负责人即是项目经理。
针对每个团队同时负责的多个项目,在系统中以issue catalog进行区分。
由项目经理负责将各个渠道的需求条目进行汇总,进行管理,并协调确认优先级。然后即可以采用SCRUM方式进行项目流转。
项目经理在规划时:
  1. 季度级别的规划以子项目的形式体现。(这个稍微有点别扭)
  2. 迭代周期级别的规划以version的形式体现。
  3. 迭代周期内部,使用issue进行任务分配。
这样,按照系统中的项目看来,项目组成员的工作量是饱满的。然后可以按照issue catalog进行过滤,观察某一个系统/项目的情况。
鉴于redmine非常强大的issue自定义过滤功能,因此可以很好的满足软件部门经理的管理需要。
而zoho project和activecollab该如何对应呢,正在考虑中……

activecollab:
只有单层的milestone功能,而没有子项目管理能力。因此对于多层次的规划需要对应比较困难。
ticket有category功能,但是其过滤查询功能显然没有redmine强大。


zoho project / 百会项目:
里程碑分为两个层次,多种类型,完美对应规划需求。这点,比redmine强。
对于任务没有分类功能。
没有子项目功能。
任务查询功能不强。

猜你喜欢

转载自redouble.iteye.com/blog/1026616
今日推荐