登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 专题 > PMO > 甲方IT部门PMO与需求管理

甲方IT部门PMO与需求管理

返回>

2019年01月25日    作者:乔东    来源:微信公众号“IT管理工匠”

A-A+

  在这里首先直接提出我的观点,用简单的一句话来概况就是,在甲方IT部门中,组织级的需求管理与项目管理职能应该合并在一起。

  

  这里为什么要特别强调“甲方”。在IT行业中人力资源的流动性还是非常大的,在甲方、乙方之间也有很大的流动。从甲方单位下海,或者从乙方单位上岸,都非常多。在这种角色转换当中,很多人对于甲方、乙方的工作特点还是认识不够清晰,很多外行领导、非专业人士也不清楚,总是拿甲方的IT部门与乙方的IT公司做简单比较,甚至还提出过是不是把自己的IT部门撤掉直接把IT都外包了这样的想法。所以在这里首先说一下甲方IT部门和乙方IT公司的几个主要不同点,其中最大的差别就在于,甲方IT部门将技术作为解决业务问题的手段,所交付的不只是软件系统,而是甲方的业务服务能力。

  

  我们许多负责应用研发管理的科技部门领导,经常面临要解决内部、外部的各种疑问。经常让科技部门领导比较头疼的几件事包括:


  在信息技术部门内部,能够对所有开发任务都安排的有条不紊,面对众多的需求与系统交织在在一起的开发任务,希望能理清各项开发任务,使开发、投产的工作都井井有条。


  忽然被更上级的领导或其他部门领导问起,某个需求进展怎么样了,为什么到现在还没开发完,什么时候能完成?


  很多时候需求部门之间扯皮很长时间,最后只留给技术部门一点点的开发时间要求限期完成,如何能够反映出时间主要都耽搁在哪里了,不同需求部门之间的分歧是什么?


  企业的财务管理部门、审计部门和信息技术部门自身,都希望能够弄清楚,使用了不少的外部资源,投入了这么多的成本,那么这些人都在做什么,使用是否合理?


  从企业的高层领导来说,如何说明大量软件研发的投入与业务发展的产出之间的关系?


  ……


  这些问题表面上看涉及范围很广、分散,但实际上是有着内在联系、相互影响的。经过长期的实践,我们深刻的感受到,要回答这些问题,需求管理是一个很重要的主线,是连接企业管理层、业务部门和技术部门的纽带,因为他是唯一的各方面都能够听得懂的共同语言。因此,需要一个整体的管理模型建立起各方面因素之间的逻辑关系,以系统化的方法来解决,头疼医头、脚痛医脚的做法是不行的。

  

  抓住需求管理这个关键纽带,我们建立了一个多维度的需求交付管理模型,从需求出发,建立了需求与各个相关的工程技术和管理要素之间的多重的组合关系。


  在这个多维模型中,也有事实和维度,各个维度上也有层级和成员。具体来说,中心是具体开发任务,五个维度分别是:


  需求:业务需求、软件需求

  系统:系统、子系统、模块

  时间:年、季度、月、日

  资源:供应商、产品组、人

  部门:业务部门、业务处室


  按照这样一个模型,从最初需求的提出、到需求的技术开发、到投产交付,在各个具体的工作过程中不断产生相应的管理信息,这些信息按照这样一个模型组织起来,不仅在交付过程中能够发挥作用,还能够回答更多的管理问题。

  

  通过“需求、系统、时间”三个维度的矩阵关系,可以看到在某一日期将要联合投产的所有需求与系统,以及这些需求与系统之间的关联关系。万一在投产前发生范围变更,或者在投产后需要做版本回退,那么其影响范围可以一目了然的分析清楚。

  

  通过记录外包人力在各项开发任务上投入的实际工作量,可以按照需求维度对这些工作量进行统计,再根据这些需求所归属的业务部门,能够使科技部门的这部分直接研发投入与业务需求和提出这些需求的业务部门建立直接对应关系,从而回答“钱都去哪了”的问题,而不是一味的解释开发了哪些技术模块、发布了哪些软件版本。

  

  再来看一下组织级项目管理体系中PMO的角色。


  在实践当中,我们看到组织级的PMO往往有两种不同的作用,一种是决策型,真正能够指挥项目,能够比较深的参与到项目当中,根据整体需要对项目进行监督和指导。另一种是协调型,主要就是办理项目的各种管理流程,收集、跟踪项目信息向领导汇报,我更习惯称之为秘书型,这种PMO总是让人感觉对项目的管理犹如“隔靴搔痒”。


  许多在PMO当中工作的朋友,其实都希望PMO能发挥更大的作用,愿意成为决策型而不只是秘书型。从领导的角度来看,当然也希望有个更加强有力的PMO能帮助管好项目。要想达到这个目标,PMO就需要具有需求管理的职能。

  

  项目管理与需求管理这两个职能,实际上是密不可分的。软件研发项目的核心目的,就是需求的交付。项目管理当中的范围、时间、资源、成本、干系人等,无不与项目中的业务需求密切相关。需求变更对项目的整体影响也是有目共睹的。

  

  在我接触过的许多IT部门中,都分别设有需求管理团队和PMO。很多PMO只负责管理正式立项的项目,而立项项目不能覆盖全部开发需求,还有其他大量的开发任务不在PMO的管理范围内,PMO难以起到组织级的整体协调作用。同时,PMO不直接管理业务需求,也难以详细、及时的掌握项目中需求内容要求,难以及时、主动的管理项目。项目进度信息主要报送PMO,需求管理团队需要另行跟踪需求交付的进展情况,经常出现PMO与需求管理团队对项目进展的重复跟踪。特别是当发生需求变更时,容易产生需求团队和PMO的信息不对称造成工作脱节。


  需求交付的过程更多具有工程过程的性质,项目管理工作更多的属于管理过程的性质,这两类过程本身其实就应该是全程配合的。从需求管理角度来说,项目是需求交付的主要组织方式,从项目管理来说,需求交付是项目的目标和各项具体工作的主要内容。

  

  通过以往多年的实践,在甲方的软件研发工作当中,平衡矩阵是最适合的管理结构。其中,负责不同应用系统的开发组/产品组/开发部,这是纵向的维度,有明确的、相对稳定组织和管理方式,而项目和需求则都是横向的维度,需求管理团队和PMO是这一维度的管理机构。如果能将PMO与需求管理在组织上和人员上合并,同时负责组织级的需求管理和项目的管理,将对两方面工作都能起到促进作用,增强对这一维度的管理力度。


  在前面的多维度需求交付管理模型中,处于模型中心的具体任务,其实就是项目当中的各项开发任务。

责任编辑:王兴钊

标签:PMO
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
官方新浪微博
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3

京公网安备 11010202007990号


PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设