More Related Content
Similar to 《PMBAR》二期2012 (20)
《PMBAR》二期2012
- 1. 第二期
Apr.2012
[ 季刊 ]
专业源于实践
PMBar
中国IT项目管理第一实践社区
实践 - 健康 - 创新 - 家园
www.pmbar.net
- 2. 卷首语
群思荟萃 有一种胜利叫撤退
微观点
项目案例 项目管理中遇到的最大的挑战是什么?
重大需求变更该谁审批?
项目收尾中的需求管理
题外话:如何准备应聘企业信息主管?
PM 成长 我的PMO十年
我的PM成长之路
管理体系 如何用Enterprise_Architect进行
需求管理和追踪变更
PMBar动态 PMBar牵手ITIL先锋论坛
PMBar出版物《项目管理那些事儿》
PMBar
PM 人物
专业源于实 践 轻松一刻
中国IT项目 管理第一实 践社区
- 4. We are PMBar team
致谢!
我十分惭愧,愧自己的疏于沟通、放任进度;愧于自己才学疏浅,还不知道推托,勇敢来篇开场白;
十分欣喜,有那么多热心人,恺墨大哥、老张、马总、记忆、老谷、Richard……
推荐专家:吴浩刚,徐锋,在接到电话后,响应迅速,还有新加入的Frank,雅静,艳春……
都是十分给力的好伙伴。
编辑团队在这一期起,试行分组稿、编辑、美编组,欢迎更多伙伴加入,
以你我的热爱,将PMBar E刊进行到底。
PMBar,有你有我!
镜子
Apr.2012
PMBar - 需求 4
- 5. PMBar IT项目管理公益实践社区
网站:www.pmbar.net
微博:@pmbar
PMBar IT项目管理公益实践社区www.pmbar.net,由一群专注于项目管理、研发管理、IT服务管理、团队管理等IT管理领域的业内专家自发
组成,目前已有全国各地千余名IT领域的项目经理、项目总监、CTO及CEO。PMBAR定期的开展线上线下交流,线上"项目管理MSN群"每周二
中午13:00-14:00进行项目管理专题讨论,并在新浪微博 @pmbar 同步,目前已经进行近110期。
PMBar社区使命: 使项目管理在IT领域普遍成功,建立适合中国特色的IT项目经理选拔与培养方法论。
PMBar社区愿景: 打造国际国内公认的首屈一指的学习型IT项目管实践公益社区,为IT人提供全方位的创新性项目
管理服务。
PMBar社区宗旨: 营造一分享、交流、互动的IT文化平台,学习研究和普及项目管理相关体系知识,分享项目管理
成功经验,启迪项目管理中种种困窘的解决之道,推动项目管理的创新。
PMBar社区口号: 让IT项目管理在中国普遍成功
PMBar 社 训: 实践,健康,创新,家园
- 8. 项目场景
1.这是一家大型的创新型业务公司,市场销售尽管在初期探索阶段,销售部门认为急迫需要
开发一套销售管理系统,通过IT的方式将业务销售管理起来,否则在信息化管理的今天跟不上
时代潮流;
2.这个基本功能包括销售渠道管理、经纪人管理,薪金管理,佣金管理。由于销售模式的不
断变化,使得该项目的需求变化显得特别突出。
群英 项目问题
1、该系统一期按照计划本来已经结项,但开发依然遥遥无期,
荟萃
2、项目延期、乙方大多开发人员撤离。
3、甲方依然不断的新需求提出、此时甲方业务人员提出开发该系统二期的功能
新接任的项目经理小Z原来认为只需解决一些开发计划的协调跟踪即可解决问题,随着项目
了解的深入,发现远没有那么简单。。。
有一种胜利叫撤退
马兆林
2012/3/26
PMBar - 需求 8
- 9. 经过一段时间的了解,小Z发现:
1、甲方业务人员与业务模式都在发生变化
销售模式在尝试,由于新兴业务拓展不顺利,销售基本法在时刻变化调整,渠道人员管理模式都
处在不稳定的状态中,同时,由于业绩的压力,使得该系统的需求人员和系统使用人员在流动,往
往使需求提出人员和验收时不同的人,对销售基本法有不同的认识和执行,甚至主管销售的总经
理也在变化.
2、原来甲方项目经理非常不负责
需求整理、审定、开发计划基本全部依赖乙方团队,甚至一些不合理的小概率事件的功能需求
没有进行时审查(如:“培训人员”的管理功能),使得乙方开发人员觉得没有合理需求,就
不向下开发,而甲方项目放任之,往往业务人员认为已经进入开发计划,但系统也迟迟没有交
付,造成该项目满意度相当差;
群英
3、乙方项目经理和开发团队撤离
由于该项目开发后迟迟没有验收,乙方大部分人员撤离,只保留一人进行需求整理和对接工作
这种情景使小Z陷入了两难的处境,一方面甲方需求人员非常不满意目前的进度,而乙方开发
荟萃
人员已经基本离场了,这个项目将时刻成为烂尾工程,渣子工程。
多年的项目管理历练使得小Z立刻提示自己要冷静下来,好好的进行一个分析:
1、站在立项的角度,这个项目的开发存在着相当的风险,业务部门为了系统而系统,没有成
熟固化的流程,业务发展模式和规章时刻在变,使得功能需求、开发付出的代价很大(无法
可依)
2、在实施过程的角度,由于前任项目经理的不负责,使得一些不合理需求纳入开发计划,使
得乙方开发成果往往效率很低,没有成就感,开发完毕没有及时验收,甲方项目管理的职责
有一种胜利叫撤退 存在了很大的缺失
马兆林 3、进行两种决策的趋势分析
2012/3/26 A、继续开发、需求在不断变化,无法控制风险,费用上会陷入无底洞,并不能解决满意度
B、中断开发,只有部分功能可以投入使用,需要做工作完成项目的验收和费用支付
PMBar - 需求 9
- 10. 决策标准,公司利益上控制风险,控制满意度的不断恶化
1、在一个时间内,需求是否清晰,并保持一定的稳定性
2、需求是都有“法”可依据,支持
3、能否看到阶段性的里程碑结果
所以没有迟疑,小Z只有选择:B
中断开发,停止项目
我们可以想象,做出决定容易,在任何一个甲方执行这一个结果还是很难的
小Z首先向IT部门领导作了汇报,取得了部门领导的支持,然后和业务部门需求主管进行了一次
群英
深入交流,共同分析了这个项目的现状和未来,这里有一个优势,他们是老乡。而且,销售部
门负责人刚离职,可以定向为后果的承担者。此时,这个需求主管也确实被这个系统搞的焦头
烂额,首尾不顾,看来只好这么处理。
乙方那边答应他们配合好一些功能验收后,可以结款项,前提是做好一些功能部署的扫尾工作
荟萃
,当然,验收签字工作由甲方业务部门需求主管牵头完成。
这样经过一个多月的进度,完成了部分功能的上线工作,这些功能是一些可以目前固化有经常
使用的部分,而其他需求由于存在很大变数或者不合理,统统停掉了。
验收一个月后,乙方验收前收到了双方谈好的尾款。
在公司层面上,这个项目在内部继续进行需求讨论,为二期开发做准备,实际项目已经停止了。
案例解析
有一种胜利叫撤退
有一种失败叫占领,有一种胜利叫撤退
马兆林
如果没有把握赢得这场战争的时候,撤退也许是一种保全自我的很好的方式
2012/3/26
PMBar - 需求 10
- 11. 我们看到这个场景中:
小Z能够毅然的中断项目,既要冷静的判断力,还需要项目管理的实践历练,包括扫尾工作的沟
通能力,都是PM最佳实践的厚积薄发的体现。
这里面的最大难度在于说服甲方需求主管,这里小Z利用了“老乡”, “销售部门负责人离职”
等因素,四两拨千斤的化解了需求部门的坚持,我们会有人讲,这几个有利因素怎么都让小Z碰上
了,实际上在最佳实践中需要你去发掘,分析有用的细节和因子,求同存异,为我所用,这是故
事这个段落想表达的沟通技巧 。
最后讲讲这个案例中的“道、法、术”:
这个场景里的道,就是这个项目能否顺利进行的几个因素,我们看到小Z分析的过程;道路不通,
项目失败。
这个场景项目里的法:就是销售基本法,通常我们讲的需求流程,业务规则。由于市场销售模式
变化,使得销售基本法也在变,实际这个项目是无法可依,失败亦然
术:由于在本场景中,乙方的开发技术不是问题的重点,关注最少。
我们看到,通过道、法这两个方面的分析,是这个项目失败的核心问题。
群英 后续故事:
三年后该公司又启动了该系统的开发(传说中的该项目二期,不过是个新的系统和开发商),
荟萃
小Z已经是IT部门主管级别的干部了,这时的甲方项目经理小H是个富有激情和责任感的青年人。
经过三年的发展,该公司的销售模式有了基本的固化,但也只限于少数渠道,增加了很多分公
司等的层级销售人员管理。
进入这个项目后,小H的脑海里经常浮现的几个词组就是“悲催”,“苦B”,经常有一些没干
过一线销售和管理的女孩过来和他讨论需求……
小H发现经常对他们的需求说“可以开发”并不能带来他们的满意度和自己的成就感,因为按照
他们需求开发后,一些原来的规则破坏掉了,系统不流畅,好在公司有了相当的业务使得该系统
能够发挥一些价值……
由于小H的态度和努力,他获得了公司年度最佳员工的奖励,相信他还在探索IT项目管理的最佳
有一种胜利叫撤退 实践之旅,和我们一样,在路上。
马兆林 祝福他吧,也祝福我们自己……
2012/3/26
PMBar - 需求 11
- 12. Mars_Lee_Dw (鼎为通讯科技有限公司 客户项目中心 总监)
需求管理,不是拒绝或满足需求,而是如何把实实在在的优秀需求进行筛选开发,不浪费时间在
没有价值的需求上面,好刀能用在刀刃上,帮项目赚钱才是王道。
王晓明同学 (知名敏捷咨询专家,敏思特咨询首席合伙人王晓明)
什么是有价值的用户需求? 符合以下6个条件才算:
1.本身是一个产品或服务;
2.有用户需要,并解决他们的问题;
3.有销售渠道并且价格公道;
4.用户对该产品、服务有购买意 向;
群英
5.有清晰的市场定位;
6.优于竞争对手的特点。
不是所有“需求”都make sense。开发人员应多质疑,
帮助产品和需求经理优化需求管理
高宇-胡言亂語 (二十一世纪空间技术股份公司 高级软件开发工程师)
CMM只是关注需求活动的过程,而不是需求分析技术本身。要提高软件需求文档的质量,要最大
限度地减少用户需求分析活动中的遗漏、变更和误解,这样就必须不断积累需求分析的能力,提早
挖掘客户需求中的变化因素,努力成为客户领域内的专家。显然,这种积累不是一时半会可以做好的
荟萃
杰子
微观点
需求管理#做 项目最难把控的就是需求,BI项目更是如此。曾有人用“尿频,尿急,尿不净”来形容客户 Micro-Points
的需求,非常贴切。需求把控是关键,不能一味地听从客户,要提出 改进建议,帮助客户把不成熟的
想法成熟起来,而成熟需要时间的,这样就能在一定程度上不那么“尿急”!如果做得好,还能“尿
得更干净”!
PMBar - 需求 12
- 13. 冯国馨PMBar(联合永道副总兼CTO pmbar项目研发管理公益社区创始人)
对于项目型企业,需求变更是一个系统的生态链。没有无缘无故的变化!
要强调的是一定要从经营角度看变更,是客户内部矛盾演化的变更,是没
有经过有效咨询疏 导而在操作中渐进明晰演化的变更,是突发事件如政治
任务引起的,还是技术难关引起的变更等等等等。找到原因后,办法总比
困难多。
mibystander 《浅谈需求变更及其对策》
诚如IBM的广告——我们提供的是随需应变的解决方案,如果我们意识到IT服务的本质就是应对
群英
变化,其工作的核心内容不是生产而是设计,那么我们就最终理解了诸如持续改进的意义所在了。
网龙网络有限公司副总裁 唐兆希
需求没有规则只有变化,市场没有问题只有机会
用户是没有责任,也没有资格提供需求,用户只有自己的痛点或者涉众利益。 需求是开发方的来
根据涉众利益排座整理出来的。如果需求直接来之于用户,很可能需求就是假的,更糟糕的是,
后面的需求变更才是噩梦的开始 一开始不理解,现在逐步理解一点了
荟萃
Alex_wang__ 微观点
Micro-Points
需求变更的根源来自哪里? 这和需求的级别有关 第一稳定的需求级别是用例,基本很少变化 第二
稳定的需求级别是路径 第三稳定的需求级别是步骤 第四稳定的需求级别是补充约束。 补充约束的
变更往往容易较多。 所以,解决需求变更的问题,实际上就是检查上述4个有没有遗漏的。
PMBar - 需求 13
- 14. 项目管理中遇到的最大的挑战是什么?
重大需求变更该谁审批?
项目收尾中的需求管理
题外话:如何准备应聘企业信息主管?
需求管理,需求开发,计划赶不上变化?
系统做好了客户不肯签验收报告?
项目进度一拖再延不受控制?
很大部分原因是
不确定的需求,善变的需求,无边界的需求……
你遇到的最大难题在哪?
管理,控制,变更,谁说了算?
合同需求界定不明,客户胡搅蛮缠如何应对?
最真实的现场,观点,为你奉献
- 15. 项目管理中遇到的最大的挑战是什么
这是一次非正式讲座,由Frank同学提出问题,大家一起讨论而成
Frank-项目主管-上海 says (11:58):
活跃人物
Frank-项目主管-上海、超-技术负责-深圳、seplves1-PM-北京、Heard-IT Consultant-singapore
fan-sr.e-sz、max-打杂-sh、东倒西歪-供应链-BJ、mazd-Melody-PM-上海、Richard李明-项目主管 需求多变,协调困难,边界界定?
Ivy-pm/QA-shanghai、Michael-PM-厦门、龙小宝-pm-bj、Frank-项目主管-上海
以各位的经验,项目管理中遇到的最大的挑战是什么?
超-技术负责-深圳 says (11:59):
人的因素吧!和人有关的一切。边界就和业务有关,但最终是人。
公司对这个职位的定位和主要负责的工作。
seplves1-PM-北京 says (11:57):
项目团队人力资源管理、项目沟通,项目整体的把握。
我觉得也可以说是资源,包括人力资源。看做的事和所支配的资源,剩下的就是效率。
Heard - IT Consultant - singapore says (11:58):
team!我前一个team遇到的最大问题是沟通..... 人分布在三个国家。
fan-sr.e-sz says (12:00):
我觉得最难是需要完成的任务,超过了项目经理的权力范围。
如果组织本身是在震荡阶段,这里的项目经理应该是最惨的吧。
max-打杂-sh says (12:01): 东倒西歪-供应链-BJ says (12:02):
最大的挑战是项目经理自己,哈哈。 我觉得最大的挑战就是项目经理没事干
mazd-Melody-PM-上海 says (12:05):
不同的组织结构,项目经理的职责范围不一样,挑战也不一样。要看这个项目经理的level。
Richard李明-项目主管-北京 says (12:30): Ivy-pm/QA-shanghai says (13:00):
最大的挑战是对习惯的挑战。 在对外项目中,客户关系也是一块吧
Michael-PM-厦门 says (13:11):
我觉得最难的是风险管理,风险即不确定,
不确定意味着被动,无从下手。 龙小宝-pm-bj says (13:14):
风险我觉得好难操作
按照PMBOK说的,最重要的是计划、计划、计划
Frank-项目主管-上海 says (12:58):
继续刚才的问题,有几位同学的观点,我总结了一下:项目管理最大的挑战在人,团队建设、沟通管理、资源协调,无不与人密切相关。
最大的责任:项目范围边界的界定,项目进度计划的控制。
PMBar - 需求 15
- 16. blue-pm-bj说:
重大需求变更该谁审批?
活跃人物
blue-pm-bj、Hawk-PM-苏州、pinky-pm-gz
邓超-开发-上海、超-技术负责-深圳、Frank-项目主管-上海
Hawk-PM-苏州说:
重大需求变更该谁审批应该由CCB或发起人,项目管理办公室或发起人,来负责。需求变更属于范围变更的部分,有时需要发起人来同意。一般情
况下,发起人会是CCB的一份子。
我们公司也没有CCB,不过,涉及范围的变更肯定要发起人签署。我个人观点:项目经理未必是CCB成员之一,发起人肯定会是CCB成员之一。
项目经理通常是CCB成员之一,发起人未必是CCB成员之一。
PMBar点评 变更很可能是某个具体工程师提出来,而具体工程师通常不是CCB成员。
blue-pm-bj说:
我们公司没有CCB。
pinky-pm-gz说:
我们的CCB都是例行工作,或者只是参与,没有决定权的。PMO是不是也监管CCB?我以前的公司有CCB部门,他们是例行的文档管理部门,记录
变更的是配置管理部门。他们没有决定权,都是发起人来确定是否变更。基本是高层说了算,但是没有说一定指定哪些人。
邓超-开发-上海说:
CCB不是部门,是每个项目定义的,在项目立项的时候根据变更的可能影响范围定义的组织。CCB的职责就是估计项目变更的影响,所以是有审批
权的,一般重要的干系人都会在CCB里面。
那么,是不是每个项目都有一个CCB?而且是不同的人?答案是肯定的,是不同的人,但是技术专家可能是共享的,或者高层经理也是共享的。说
个简单的,项目延期针对项目计划变更,如果没有客户或者高层经理的审批,这个变更做了也是白做。提前定义CCB,相当于是一个立约,所有干
系人都同意,出现问题的时候这几个人有权力如何解决问题。
我所在的项目里面,配置管理员只是负责对变更产生的变更申请、纪要、对基线的改动做归档和记录,但并不负责审批 ,审批还是CCB来。应该也
要和项目经理探讨一下,变更管理还是要慎重,尤其是范围变更和需求变更。所以CCB的定义还是蛮重要的,项目经理肯定是CCB成员之一。
我们公司没有CCB组织。这个东西有时候包括配置管理这块,除非很大的项目才要,一般小的项目没有那么细化的。很可能都是身兼多职,更多情
况下是先做出来再说,但是就理论上来讲,这些东西都要学到或者知道的。毕竟规范细化好了,才可以更好的做事。
邓超的说明非常到位! PMBar点评
PMBar - 需求 16
- 17. blue-pm-bj说:
重大需求变更该谁审批?
活跃人物
blue-pm-bj、Hawk-PM-苏州、pinky-pm-gz
邓超-开发-上海、超-技术负责-深圳、Frank-项目主管-上海
Hawk-PM-苏州说:超-技术负责-深圳说:
我觉得关键讨论的是前期工作中加入应对变更的部门或者人员,以便变更出现时,有确定好的流程去应对。
超-技术负责-深圳说:
我们不用去纠结CCB的组成人员是否包含发起人,但是项目的发起人属于高层。从干系人管理上看,应该要包含在内,即使不包含,有些东西也
是要得到高层的支持的。
邓超-开发-上海说:
发起人可以是、也可以不是CCB成员,但是变更的过程,他是肯定会参与的。就审批权限而言,发起人可以拥有这个权限CCB成员,当然也可能
只是描述问题和影响并没有决策权(非CCB成员)。理想情况下是所有干系人来参与对需求变更的审批,但是实际中只能是在利益比较大的几个
方面选出代表。这个就是CCB。
Fenny说:
我是在電子行業做PM,有CCB,每個禮拜都會發生。CCB既然是change control board,就應該有一個人在主導。其實就不是什么leader的說
法,而是誰來做主導,讓大家去執行。
【PMBar点评】全员参与决策是一种理想状态,这与企业管理文化和成熟度息息相关,通常可执行的方法是选出有专业背景、有决策能力背景的
各方代表加入到CCB中。
项目经理通常是CCB成员之一,发起人未必是CCB成员之一。
PMBar点评 变更很可能是某个具体工程师提出来,而具体工程师通常不是CCB成员。
PMBar - 需求 17
- 19. 项目收尾中的需求管理
IT01-打杂-东北区 说:
分阶段的话就怕客户的思想老变。
河边草herbacon-pm-深圳 说:
前期规划沟通的问题。
hitbird开启尘封的记忆-无聊中-北京 说:
一个是,变更控制没做好;另外一个,项目验收估计没有确定好,是不是合同里规定的优点不够准确?
不胜人生一场醉-打杂-海口说:
一般情况下系统验收规划的是1个月,实际上可能3~6个月,预留好时间。和客户说做个系统预验收,然后建一个跟踪现存问题、扩展问题、完善性问题之类的
让客户在上面提,不要一个个的口头或发邮件。
月亮-pm-bj 说:
我们这次又新接到一个项目,我怕到时候又像其他的项目一样。。做完了,一直在让他们试用。。需求有时候直接跟我们开发部门说。我们这也有技术支持部。
也有市场部。。是人才派遣系统。。我们这次是先画了原型,然后写了详细的需求,拿着这个需求跟客户对。。。 商务收不回来钱,就说我们做的系统不行。这
样老板找我们,客户找我们,然后商务还有理由找我们。
上次调研需求,他们公司内部有个活动,然后耽误了1周,我们说时间紧张,是不是延期一下。。他们提前都没说过。。
IT01-打杂-东北区 说:
没用。遇到强势的用户,想到哪做到哪。 客户只能引导,不能说服。
PMBar点评 客户再强势也是需要完成项目,乙方最低限时放弃项目,这个他们也很害怕的。关键是要在前期培养客户接受双方
约定的应对变更的方法和流程的意识,余下需要销售做好客户关系运营。
mazd-Melody-PM-上海 说:
没有明显需求框架,纯粹是按照客户感觉走,客户又多头管理,你们搞不定客户,肯定验收不了的。
itpub id 中惠李-打杂-dg 说:
需要跟客户确认你们的蓝图设计。
不胜人生一场醉-打杂-海口说:
一般情况下 客户也有上线时间要求和上线压力。 上不了线,他也会着急。你的问题是说服他和你站一条线, 年底不上线他没绩效,控制进度、需求也是他的责
任。 作为pm应该把这些不利于自己的证据保留下来,以便以后的谈判。 客户内部原因,设备原因,网络原因,都可以作为有效的理由。 感觉,商务渗透不够,
商务对技术配合支持不足。
PMBar - 需求 19
- 20. 项目收尾中的需求管理
seplves1-PM-北京 说:
项目干系人一般不止一个,客户之间也不是铁板一块,逐步突破。
mazd-Melody-PM-上海 说:
一开始做的一切就是为了验收,前面按阶段都完成了,验收自然就顺利, 不能只是为了验收而验收。 做事是底下人在做,签验收是头在验收。。头不看系统,
就问底下人,系统行不行。。 底下人都不敢保证行,都说现在没问题,不保证以后没问题,然后他们领导就不签验收。
客户需求多,大部门是因为他们自己也不知道想要的是什么东西。先让客户内部形成需求团队,指定接口人收集需求,然后你们接收需求,需求筛选,合理的
接受,不合理的说明原因,最终形成文档。同时,配合你们的原型系统对客户进行引导。 还有,关键要跟客户方能有拍板能力的人搞好关系,让他跟你们站在
一边。
Richard李明-项目主管-北京 说:
看来你那边是问题挺多, 控制需求不但是你,还应让商务的也来做。 客户的预算也可能有限,先把需求分优先级,次要的等二期。需求把握控制好范围,保
持在一定的限度内变动。 每次的变更你要记下来,分析一下对现在项目进度的影响,告知用户。 这样,他们再变的时候就会进行变更,那么进度方面会不会
受到很到影响, 他们必须要知道带来的后果。
做好的东西及时让用户了解,争取做好一个让用户接受一个,等到最后验收那就很容易了。
毕竟他肯定过的东东,到最后他不会否定他自己把情况及时通报。
记得变更要写成文档,然后就是变更要不要执行的问题了。
pw-PM-CD 说:
不了解具体情况,但如果让客户早一些加入到项目的开发过程中,早一些提出改进意见,或许可以减少后期变化的可能性。你们有原型设计,这个是个好的机
会让用户提出意见。
蔡晓东-技术主管-it-福州 说:
电话说过的事情,我们一般的做法,是随后再发一封邮件。
PMBar - 需求 20
- 24. P M 成长
我 们一直 在关注...
我的PMO十年
我的PM成长之路
- 25. chuner_wang-PMO-北京说:
1)协助项目经理监控项目进度;
我今天的交流主题是,我的《PMO十年》,我2001年12月加入
2)向上和向外汇报项目进度;
同方,一直在PMO里担任不同的角色,从项目协调员,到进度
3)作为与用户方、咨询方或监理方的沟通接口,协调项目内外关系,
管理工程师, 再到项目管理工程师,最后到PMO主管。对PMO
处理信息的收集和反馈 。
,我有我的热爱,也有我的期待……
4)配置管理(CC)。
今天,本着我个人的经历,今天主要跟大家交流下我的PMO发
5)协助处理项目日常事务,如组织例会、来往公函的起草和收发、
展历程,其中有收获,也有困惑,与大 家分享。
项目费用记录、组织项目 建设活动等。
有一个一直一来的疑问:PMO是助理机构,还是管理机构?它
职责上看,以协助项目经理为主。
与EPG和QA有什么区别?
我也一样,在不断的“惑”与“解惑”中,做过了是助理机构的 我的PMO十年
chuner_wang-PMO-北京说:
PMO;也做过了是管理机构的 PMO;也做过了做过程改进的
此时,PMO共4人,PMO主任下设一名进度管理工程师、配置管理
PMO…… 其实,我更期待,PMO的下个时代,可以是决策机构...
工程师和项目助理各一名。除主任外,对其它人员项目管理系统知识
下边我就重点跟大家交流下我的PMO的前两个阶段:助理机构和
的要求不高 。
管理机构。
这期间,从管理角度最大的收获,或说项目管理比较有效的方法是:
1)项目进度日跟踪、进度上墙(一大幅RPOJECT的进度计划表,相
从助理机构到管理机构的转变 当于20多个A4那么大)营 造一种透明、相互赶超的氛围和压力。尤
其在项目的关键阶段,很有效。
chuner_wang-PMO-北京说: 2)PMO作为内外沟通的唯一接口,确保了信息的完整性、及时性和
首先说,我的PMO实现 从助理机构到管理机构的转变,我们用了3 可追溯性 。不通过PMO的所有项目信息,都视为无效,这个条款,
年多的时间。成功转变也缘于PMO成立后承建的第一个项目,它引 与众不同的被写在了SOW里,双方签署!尤其这个可追溯性(全有
入IBM作为甲方的管理咨询方。IBM负责协助、 指导甲乙方项目监 记录),到了后期产生合同纠纷时,立下了汗马功劳。
控和管理工作。与他们的合作中,我们学习和吸收了大量IBM优秀 3)签署清晰的SOW,用1个礼拜,双方封闭编写。详细约束各方职
的项目管理思想,为以后的成功转型打下了良好的基础。 责、活动和产物。这个也很有效,避免双方扯皮,也带动了客户的主
在PMO作为项目“助理型”机构时,我们以单个项目为主线,一对 动性
一跟踪、服务。重点在进度 监控和汇报上。那时候,我们事业部同 4)用ClearCase做配置管理工具,这个大家都基本清楚,其好处就
时在建的项目少,尤其初期,基本上一两年就承建一个项目 项目规 不用多说了,用过这么多配置工具,CC还是最强大。
模:周期2年 ,合同金额8千万,项目成员100左右。所以,PMO的
全体都按不同分工,扑在一个项目上。
我的PMO十年 邓超-开发-上海说:
对不起 我有个疑问: pmo里面会有客户方的人员吗?
Richard李明-PMO项目主管-北京说:
还没有太多的资源竞争吧?
我的PMO十年
chuner_wang-PMO-北京说:
没有。
chuner_wang-PMO-北京说:
没错,所以那时候,进度监控是重点! Richard李明-PMO-BJ说:
助理型PMO的主要职责是: SOW:Statement Of Work工作说明书
PMBar - 需求 25
- 26. chuner_wang-PMO-北京说: 工作,比如实时了解公司每个人的工作情况,包括状态、饱和度、
这是PMO作为助理机构的总结…… 胜任能力……
在这里,没有人事上的绩效考核,是依据一些产出数据及经验评估。
邓超-开发-上海说: 此时,PMO共5人,PMO主任下设项目管理工程师2人、进度管理员
好的 谢谢 我是看到“不通过PMO的所有项目信息,都视为无效,这个 、配置管理员。原则是,分工 不分家、互为备份、各有侧重。
条款,与众不同的被写在了SOW里,双方签署!” 这个觉得有这个疑 对人员的要求比较高,其中三人,都经过专业的项目管理培训……比
问的。 如:PMP 。
chuner_wang-PMO-北京说: 这期间,从管理角度最大的收获,或者觉得比较有效的项目管理方
随后,事业部同时在建的项目越来越多,项目流程的规范、项目间的资 我的PMO十年
法是:
源共享、项目间横向比 较、决策等需求变得越来越突出,这也就要求 1)任何方法和机构设置,没有最好,只有最适用。比如,在开发阶
PMO组织对项目管理的职责要更丰富。 段,且计划变化较频繁时,优秀的360和平衡计分 法等考核办法,竟
传统来说,PMO更关注人力资源的冲突和共享……其实,真正对企业有 然比不上看上去有些老“土”的表彰与惩罚制度更有效……说白了就
价值的,是如何共享各项目的软件资源,继而抽取出来,复用。这个, 是贴小红旗。这在很大程度上刺激了项目成员的荣誉感和自尊心,任
在PMO成为管理机构后,也成了研究的重心 务执行力得到了很大改善 ,值得一提的是,小红旗可以贴在PMO,
于是,我们积累之前项目管理的经验和教训,结合IBM和同方专家顾问 也可以贴在项目的“作战室”,呵呵……
组的优秀的管理思想, 开始编制项目管理体系,制定项目绩效考核制度 2)客观的执行数据,是监控和决策项目最重要的依据。无论多大的
,由“服务”开始转向“管理”。 项目,最基本的数据必须 注意在过程中收集,如工作量、进度……。
只有这样,才能清楚偏差,才可以预测。
管理型的PMO 3)主动汇报,向领导,向客户,尤其是向客户……。我们有个项目,
每周与客户开例会,一 月一小报,一季度一大报,不管客户要求不
chuner_wang-PMO-北京说: 要求。事实证明,这样做的好处是,成果共享,压力均摊。客户配合
管理型的PMO,主要的职责包括: 力度明显高于汇报少的项目。
1)制定并持续改进项目管理体系,规范项目管理流程。这个与现在很 4)沟通时,能见面,就不要打电话,能打电话就不要发邮件。最终,
多人在做的CMMI也没什么大的差别,只是那时候,我们没有引进什么 不管什么形式,必须落 实到字面上。往往你会发现,某一个看了的人
标准和模型,全靠经验。但实践证明,与CMMI什么的,没有多大出入。 ,会给你反馈非常重要的信息。1+1绝对大于2。
2)收集项目执行数据并分析,考核项目。需要一提的是,除了以产出 5)要求项目经理做什么,不如先让项目经理知道,你能为他提供什
为导向的考核办法外在一段时间,我们还使用了以具体任务为案例的表 么。 “管制”项目经理不 是初衷,最重要的是为项目经理提供必要
我的PMO十年 的支持和指导,使项目最大限度的贴近成功。
我的PMO十年
彰与惩罚制度,按某一个“任务单”为考核 单位,以月为单位统计表彰
与惩罚的积分数。 6)推广项目管理体系,我觉得“小步快走”、“细水长流”更有效。
3)为项目经理提供项目管理咨询及支持。不是助手,是“技术支持” 我们从开始编制管理体系到推广,用了一年时间,让大家吸收、执行
4)编写重大项目的项目管理实施方案。 ,用了一年……让大家将执行规范流程形成一种“习惯”,用了两年!
5)协调整体资源,确保项目投入。 以上是管理型PMO的一些职责和工作中的收获……
这个就是刚才有人说的,处理资源冲突……项目组的人力资源,都需要 看过有的文章,说如果项目数量少,公司规模小,就可以不设置PMO
PMO审核确定,包括过程中的人员调配 当然,这需要PMO做一些基础 。其实我觉得,这只是PMO 的机制设置问题,根本不是是否有必要
PMBar - 需求 26
- 27. 设置PMO的分水岭。它可以大,也可以小,可以是助理,也可以是管 nancy-咨询-北京说:
理,甚至参与决策。但是,我的经历告诉我,这个机构是项目所需, 参与项目的具体需求调研工作?
是公司发展所需……
也或许,它都可以不叫PMO...只要合适。 chuner_wang-PMO-北京说:
最后,我更想说的是,我的PMO已经从助理机构华丽的转为管理机构 而且,我们也必须大致清楚项目的技术架构,需要知道项目需要配
,我期待,我的下 一个PMO,可以成为决策机构。真的与企业运营目 置什么的技术人才 。KM的问题……组织机构上,我们归总经理直接
标挂钩,不是从受理项目管理任务开始,而 是从决策是否要立项开始。 管辖,对项目客观评价……另外,授予我们权力,可以调配资源……
PMO的价值或大或小,终归离不开5大过程,9大领域。但其实现的价
值如何,却总是事在人为。 nancy-咨询-北京说:
时间有限,其中很多问题没有很细致的展开,如果可以,我们以后可 我的PMO十年
你们管项目成本吗?预算?决算?成本控制?
以深入交流,期待大师们 的指教。
chuner_wang-PMO-北京说:
Q&A 甚至,还可以考核项目经理。哈哈,搞不好,也可能因为我们的某
个评价,项目经理换人啦 ,成本这块,我们针对单个项目做,只负
责管理和监控,单个项目的预算和支出,适时预警 ,至于事业部成
Richard李明-PMO项目主管-北京说:
本运营那部分,我们不涉及 。项目的每一笔支出,包括商务费用,
在CC有什么样的制度?
我们要盖章,记账……
nancy-咨询-北京说:
开启尘封的记忆-KM-北京说:
想问一下,你们的PMO人员对公司业务是否熟悉?就是说除了纯粹的项
那你们的PMO,会对项目和项目经理进行考核,你么你的考核,他
目管理,对项目本身的业务了解多少?我觉得这是将来具备决策只能的
们是否认可?那这种认可和制度,是如何推行下去的?
一个关键,管理了那么多项目,对公司的项目实施能力是否已经非常清
楚?对于公司能否承担什么样的项目,公司需要什么样的资源做项目是
chuner_wang-PMO-北京说:
否已经了如指掌?
项目策划时,要制订项目预算,并每月细化 。KM:我们的考核数据
会实时反馈给项目经理,不会等到最后汇总时他们才知道……所以,
chuner_wang-PMO-北京说:
这个最难的,就是考核办法……我们试过很多中考核方案……最后,
我们有clearcase管理制度,包括日常操作的、资源出入的。基本上,都
发现,贴小红旗最有效……
是按照clearcase的规范来……
期间,也有争执和分歧,但一般会消除在过程中……我们的原则是,
我的PMO十年 处罚不是目的,引导正确的方向才是主旨……
我的PMO十年
开启尘封的记忆-KM-北京 说:
说起来。PMO在你们内部是一个管理机构,那你们内部,对这种管理机
nancy-咨询-北京说:
构的定义是什么呢?和助理机构的最大差别是哪里呢?
项目经理是否只有PMO考核?
chuner_wang-PMO-北京说:
不同的是,我们设置封闭的开发环境,只有一个人有资源出入的权力。
超-技术负责-深圳说:
nancy的问题,我们PMO人员要了解业务,要参加需求调研,但我们不
你们比较关心项目经理上报的哪些信息?或者你们选择项目经理时,
一定很专业,但主体业务流程都必须熟悉
PMBar - 需求 27
- 28. 综合考虑的是哪些方面
开启尘封的记忆-KM-北京说:
应该是个质量部门吧?
chuner_wang-PMO-北京说:
不是,我们不是人事那层面的考核……我们只以项目绩效为出发点。
nancy-咨询-北京说:
至于其它的,还有一年一度的人事考核 。超:基本上,关注项目经理上
呵呵,你们总经理管得还真不少,相当重视管理啊!
报的进度、任务完成情况、技术难题、项目问题……
当然,数据采集是双向的。
chuner_wang-PMO-北京说:
后来,就没有了,把评审这部分归到PMO,测试单独一个部门
开启尘封的记忆-KM-北京说: 我的PMO十年
那你能不能用个比较简洁、形象的比喻来描述一下你们PMO与项目、项
一骑满尘(微博)-QAM-北京说:
目经理的关系是怎么样的呢?
不跟项目走?
chuner_wang-PMO-北京说:
chuner_wang-PMO-北京说:
我们有项目管理工具做辅助,可以看上报来的数据,也可以自己采集数据
对,算是重视……但也可能是因为外部环境驱使吧?第一个项目,有
IBM加入……第二年的项目,来个监理,第三年,又来个代建……
Richard李明-PMO项目主管-北京说:
项目管理工具?选哪种了?
超-技术负责-深圳说:
那QA部门的相关工作如何和项目同步呢?
chuner_wang-PMO-北京说:
KM: PMO是PM的助力!推动项目成功;PMO也是总管,代表公司客观
chuner_wang-PMO-北京说:
评价,综合协调项目间的资源。李明:开始用的是projectser ver,后来
哈哈,这三大角色,全部关注我们的管理……我们不重视也难啊
是漫索系统 ,上海漫索系统
蔡德辉-PMO-大连说:
Richard李明-PMO项目主管-北京说:
PMO管理多少个项目?
感觉后者更好用么 ?
chuner_wang-PMO-北京说:
chuner_wang-PMO-北京说:
超:我们的qa跟着项目走,我们同时在建项目少。蔡总:最多时候,
后者现在还在用……只能说是一种辅助……还需要人工处理
我的PMO十年
同时管四个。大小规模不一样
nancy-咨询-北京说:
你们除了PMO,有QA吗?QA在哪个部门?
我的PMO十年
超-技术负责-深圳说:
有没有你觉得好的资料,可以分享一下的,就是你曾经读过的觉得
对你们工作产生过切实帮助的书籍资料,可以公开的不涉及公司商
chuner_wang-PMO-北京说:
业机密的那种。
有一个时期,除了PMO,还有一个QA部门 ,但那个部门是负责做测试、
评审这类的工作,也是独立的,总经理直接管
PMBar - 需求 28
- 29. chuner_wang-PMO-北京说: PMO会出什么报告?
我就是觉得PMBOK挺好,哈哈。还有《IT项目哪些事儿》……
chuner_wang-PMO-北京说:
蔡德辉-PMO-大连说: 项目状态月报、季报
从整体上来说,刚开始是作为项目经理的辅助出现的
蔡德辉-PMO-大连说:
chuner_wang-PMO-北京说: 你可以再大点看,揉在一起的,还叫PMO。定性的还是定量娥?
哈哈!我读书不多。
chuner_wang-PMO-北京说: 我的PMO十年
蔡德辉-PMO-大连说: 报告内容有以定量为主……大部分是数据统计,加上一些从管理角度
后来又了几个项目了,就有了整体协调了。 的分析……领导的指示,我们基本上不下定性的结论,用事实和数据
说话 。蔡总,您说的对,也许不出两个月,质量管理部就改名PMO
chuner_wang-PMO-北京说: 了,哈哈
对,是这样的
nancy-咨询-北京说:
蔡德辉-PMO-大连说: 很高明的领导
有质量部门嘛?我不指测试人员
蔡德辉-PMO-大连说:
chuner_wang-PMO-北京说: 如果有几十,上百个项目,应该如何办
后来有质量部门……专门做CMMI、GJB9001B之类……对项目的过程和
工作产品实施规范性审查 chuner_wang-PMO-北京说:
4个能管,10个也一样可以管……方法一样,只是执行时稍有变通……
蔡德辉-PMO-大连说:
和PMO什么关系? 蔡德辉-PMO-大连说:
定量的数据,主要有哪些?
chuner_wang-PMO-北京说:
揉在一起了 chuner_wang-PMO-北京说:
如果同时管10个,是不是人手也得多些,辅助工具更好使些
蔡德辉-PMO-大连说:
我的PMO十年
哦,明白了
我的PMO十年
蔡德辉-PMO-大连说:
工具的问题,也是很多企业的问题
chuner_wang-PMO-北京说:
没有独立的PMO了……哈哈 chuner_wang-PMO-北京说:
工作量、工期偏差、进度偏差、投入产出比、生产率、缺陷密度、
蔡德辉-PMO-大连说: 用例数、类数.....甚至,文档页数
PMBar - 需求 29
- 30. 蔡德辉-PMO-大连说: nancy-咨询-北京说:
这些数据是你们自己采集,还是项目组报上来的?还是质量部门收集 神州数码以前的PMO里也是有QA,项目监理等
来的?
蔡德辉-PMO-大连说:
chuner_wang-PMO-北京说: 我觉得所有企业的难点:体系部署、数据收集、资源调配
最小业务流数
chuner_wang-PMO-北京说:
蔡德辉-PMO-大连说: 体系部署指什么?
还是使用漫索 就能统计出来? 我的PMO十年
蔡德辉-PMO-大连说:
chuner_wang-PMO-北京说: PMO的工作呢,与质量管理不一样的地方,PMO是为了 赢而来,
大部分是自己采集。漫索只能统计工作量、工期、进度之类。其它,需 以风险管理为驱动 。质量管理体系也好,项目管理体系也好,都是
要到产出中采集 。 比较难的,涉及到人的习惯改变。
蔡德辉-PMO-大连说: chuner_wang-PMO-北京说:
谁去采集的呢? 没错…… PMO是为赢而来,呵呵,收了这句……
chuner_wang-PMO-北京说: 超-技术负责-深圳说:
质量管理部 说到风险管理,那你们在体系里是如何运作风险管理这块呢,能否
详细说下
蔡德辉-PMO-大连说:
我们现在从集团层面来说质量管理与项目管理也是和在一起,但职责是 蔡德辉-PMO-大连说:
有不同的,这也叫因人设岗吧 。我们的PPQA都归到各个业务部门的 我想,还是要先想想,主要风险在哪里。不是指风险管理,作为流
PMO里面。 程或者管理领域本身。有的企业,主要在需求控制,有的企业主要
在人员能力。不同的情况,重点就会随之改变……所以有的PMO,
chuner_wang-PMO-北京说: 会重点抓售前时候的Review,不好的项目,不妨进来,或者提前做
对,其实目标都一样,只是分工问题,适合机会行 好预防。有的PMO,重点在过程中的监控。
我的PMO十年
蔡德辉-PMO-大连说:
这样也方便大家做工作 ,难点还在用数据说话。 我的PMO十年
chuner_wang-PMO-北京说:
我们没有分那么多层……就一个PMO,跟到底。
PMBar - 需求 30
- 31. 我的PM成长之路
Richard
Richard
与绝大多数项目经理成长道路类似,我也是从技术出身的项目经理。
在刚开始工作的时候,也只是一名软件开发者,随着工作经历的增加,才转变成为项目经理。
在大学选择的专业还不是计算机方面的。我对计算机方面的兴趣还是来自于在大学时候接触
的游戏“红色警戒”,那时候国内还没有互联网,有的也是校内计算中心的局域网和PC机。
学校里面教授的计算机开发语言也只有BASIC和C(^_^估计很多人都不知道BASIC 啦),另
外也会讲些数据结构和硬件方面的知识(像单片机什么的)。源于个人兴趣,我自己又在校
外学习了汇编语言,那时候接触操作系统有各种版本DOS系统和微软的window32系统。
(哈,够啰嗦了,简单些!)
毕业后凭借专业背景,我进入了一个大型国企研究所,如愿以偿的做起了软件开发,主要开发的是实时监控系统。
那时候开始接触C++,开始是跟着研究所几个牛人边学变干。从最初的与用户讨论需求,再到设计和代码实现都完整的经历过
(感谢国企的培养机制啊,现在很多公司都不重视培养员工)。
在跟着别人做的时候,也逐渐开始考虑这个任务的分解是否合理,分配给某人去完成是否合适,要是我来做的话会不会能做的更好,
怎么样保证任务能够准时得到交付。在后来我负责带着一组人马单独完成一些项目开发,从开始需求到设计,再将任务分配出去,
并在开发中指导和监督组内人员的工作,最后获得想要的结果。
那时候,世界范围内都开始关注软件出现的质量问题,因此,如何做出一个可靠的软件成为极为关注的一件事。我在书店刚好看到一本介绍软件
工程的书,讲解如何用工程化方法构建和维护有效的、实用的和高质量的软件。通过在项目开发的试用,我发现软件工程的确可以极大提高软件
产品的质量和开发效率,减少维护的困难。
PMBar - 需求 31
- 35. 如何用Enterprise Architect进行需求管理和追踪变更
张权 中科软科技
一、阐释变更的代价
欲阐释变更代价,就要分析变更带来的影响,就需要有方便的手段浏览对象间的关系。Enterprise Architect提供三种方式,即:
.使用图(Diagram)来创建和浏览关系。在图中元素之间的关系很容易使用工具条中定义的标准关联关系来创建。
. 使用关系矩阵来创建和浏览关系。关系矩阵是一种提供了不同包间的元素创建和浏览的关系的方法,这些定义的包可以是独立的。
. 使用层次关系视图(Hierarchy View)来浏览关系。层次关系视图提供了跟踪所有选定元素关系的功能。
1.1、使用图( Diagrams)创建关系
手工方式,直观地建立对象间关系:
. 创建新图(diagram)
. 从 Project View 拖到图(diagram)上,尽管元素可能分属不同的包。 [图三]
1.2、关系矩阵
关系矩阵是另一种浏览和建立需求间关系的方法,我们有两种方法创建之:
1, 通过超级链接
2, 屏幕顶端的视图菜单 ( View | Relationship Matrix…)
[图四]
关系矩阵(跟踪矩阵)是CMMI认证的基础要求。
它可以应用到任何一种元素,比如图5即是表达了需求和用例图之间的关系:
[图五]
PMBar - 需求 35
- 36. 如何用Enterprise Architect进行需求管理和追踪变更
张权 中科软科技
1) 对于大型的软件系统,各种需求和约束常常被分别被定义在不同的包和图里。业务需求和用户需求之间,用户需求和功能需求之间,功能
需求和非功能需求之间,关系矩阵都可以用来浏览和设置这些元素间的关系。
2) 在开发阶段,需求之后的各种元素,比如用例、类等等,需要与需求保持可追朔跟踪能力。
1.3、使用层次关系窗口的可跟踪能力
层次关系视窗( hierarchy window)可以浏览需求间的关系。它可以浏览对需求管理有用的其他UML元素。
打开层次关系窗口(View | Hierarchy 或 Ctrl+Shift+4),选择其中一个元素,元素关系显示在层次关系窗口中。
[图六]
二、更改控制
Enterprise Architect 提供了丰富的追踪需求变更的功能,这包括审计,基线管理,以及Change(改变)和Issue(问题)。
2.1、审计(Auditing)
审计功能可以让你记录Enterprise Architect中的模型变化。它将记录谁修改了一个元素,什么时间和怎样修改的,并附有这个元素之前的
状态。这在记载需求模型历史方面极为有用。
为使用这个功能:
1. 从主菜单选择: View | Audit View,将打开下列视图:
[图七]
2. 选择 Audit Settings (审计设置)button。
3. 弹出Audit Settings 窗口:
[图八]
PMBar - 需求 36
- 37. 如何用Enterprise Architect进行需求管理和追踪变更
张权 中科软科技
4. 在审计设置窗口,设置: Enable Auditing (启用审计)。
接下来,我们就可以设置过滤器,浏览变更历史了。
2.2、使用基线
Enterprise Architect提供了基于配置管理的模型版本差异,笔者还是比较喜欢
EAP内部的管理基线( Baseline Management)功能,可以设置全模型的基线
,也可以设置某一个包的基线。
[图九]
2.2.1、何时打基线
. 在需求阶段、设计阶段和开发阶段,通常是按阶段或迭代打基线,细化一块就打一条基线
. 维护阶段,通常是每周或每月搜集一次需求,可以周期性打基线,比如每周或每月
. 也可以按版本或Build打基线。
有了基线,我们就可以比较当前的模型状态和合并变化了。
2.2.2、查看区别
点“Show Differences”就可以查看区别了。
[图十]
2.3、更改外部需求的请求和问题
Enterprise Architect有两种方式记录需求变更:
a) 使用 Maintenance View针对每一个元素 列出缺陷Defects,变化Changes,问题Issues和任务Tasks。
b) 使用常规元素类型“Issue” (问题)and “Change”(变化)链接到变更的外部需求。
PMBar - 需求 37
- 38. 如何用Enterprise Architect进行需求管理和追踪变更
张权 中科软科技
下面是它们使用的简略不同:
使用维护视图( the Maintenance View)
[图十一]
Maintenance View 可被用来记录针对元素和包的变化。这提供了列表:
o 元素缺陷Defects
o 元素变化Changes
o 元素问题Issues
o 元素任务Tasks
这些区域用来记录“被谁?在何时?”,这些请求被产生和完成,如:状态,优先权,描述和历史。
由于Maintenance View是针对某一元素的,其他图无法引用到,所以笔者更喜欢第二种方式,在维护模型中,针对某一版本发现的缺陷,
用元素类型的“Issue” (问题)and “Change”(变化)记录变更或者导入,可以拖拽Issue和Change其他“图”以标示这一块是因什
么而变化。
[图十二]
三、结束语
其他UML工具也提供了类似的需求管理和追踪功能,笔者抛砖引玉,希望看到更多关于需求管理方面的经验分享。
PMBar - 需求 38
- 40. PMBar牵手ITIL先锋论坛 PMBar特约记者 陋室北京报道
2012年2月9日晚20:00-22:00,PMBar IT项目管理公益实践社区与ITIL先锋论坛联合举办的“ITIL握手PM”YY语音在线沙龙活动圆满结束。
IT项目管理专家、PMBAR创始人@冯国馨PMBar(谷雨霖)老师,ITSM业内知名专家杜肖辉老师联袂出席沙龙主题分享及互动。沙龙由ITIL
先锋论坛发起者之一刘杰老师主持。
沙龙就以下三个方面开展了探讨:
1、 ITSM及PM的发展前沿和未来趋势;
2、 ITIL与PM的融合;
3、 ITSM与PM的职业发展选择;
首先,杜老师从自身多年ITIL咨询、实施及培训经验出发,就ITSM的发展前沿和国内现状进行了介绍。其中,总结到:国内能够有效开展
ITSM咨询和实施的单位,多数为国企、大型企业和外资企业。这些单位有一定的管理成熟度和较大的资金实力,对客户和内部的服务质量
需求较高,有发展ITSM的动力。对大多数国内企业来说,ITSM的发展之路还很长。
接下来,PMBar社区创始人冯老师先简单介绍了PMBar社区的基本情况:PMBar IT项目管理公益实践社区www.pmbar.net,由一群专注于
项目管理、研发管理、IT服务管理、团队管理等IT管理领域的业内专家自发组成,目前已有全国各地千余名IT领域的项目经理、项目总监、
CTO及CEO。PMBar定期的开展线上线下交流,线上"IT项目管理MSN群"每周二中午13:00-14:00进行项目管理专题讨论,并在新浪微博
@pmbar 同步,目前已经进行逾110期。
接着,冯老师从项目管理国内外现状谈起。他谈到,项目管理是一个基本技能,美国从幼儿园时期即培养大家项目管理能力,项目管理理念被
广泛认同。从项目管理认证体系上看,有美国PMI的PMBOK知识体系及PMP认证,欧洲的IPMP/PRINCE2等认证,国内有工信部发起的系统
集成项目管理师等认证。在我国,项目管理刚刚被大家认知,但在实际工作和生活中还没有广泛被应用和实践。
然后,冯老师从组织级、项目级和人员级三个层面,就项目管理现状进行深入分析:
1、从组织级体系上看,项目管理被融合到ISO、CMM、IPD、敏捷等模型和方法论中。而国内IT项目管理的水平整体相对比较低,从管理成熟
度来说大多集中咋2级-3级。项目可重复成功的能力不足,10年前普遍存在的项目管理问题、10年后的今天依然很普遍。
2、从项目级上看,国内大多中小企业没有建立可以依循的项目管理体系,没有基本的配置管理、质量保证等管理手段,项目历史数据没有收集
和整理,过程管理、过程改进更无从谈起。
3、从人员级上看,国内成熟的项目经理屈指可数。大多数IT项目经理从技术人员直接提拔上来,没有得到认真的选拔和系统的培养。中国的项
目生态相对复杂,甲方管理不成熟、强势,乙方企业生存环境恶劣,IT项目经理发展面临巨大的挑战。时下流行的PMP、Prince2等认证,并不
能解决项目经理一线实践操作中面临的困惑。为此,项目经理的自我修炼和组织系统培养非常重要。PMBar社区努力从这个角度多展开一些实
践和探索!
PMBar - 需求 40
- 41. PMBar牵手ITIL先锋论坛 PMBar特约记者 陋室北京报道
ITIL专家杜老师和项目管理专家冯老师的精彩开场,把参与沙龙的社区会员积极性调动了起来,大家纷纷踊跃提问。
话题一:ITIL与PM是否有融合的点?在哪里?是否具备可操作性?
PMBar冯老师认为:任何事情都可以拆分为项目来运作,ITIL管理者更需要项目管理知识来武装。ITIL管理通常属于人员少、任务重、业务复
杂的工作,项目管理能让大家更有序。奥运会售票系统、铁道部网上购票系统等上线崩溃,很大程度上是项目管理失误。北京奥组委在总结北
京奥运会运营经验教训中,重点提出中国在项目管理人才方面培养不够,并把项目管理写进了十二五人才纲要中。
话题二:作为一名IT从业人员,是否需要同时学习掌握ITIL和PM两套知识框架?
PMBar冯老师认为:项目管理是一种通用管理技能,ITIL是专业管理技能。国内ITIL运作优秀的企业,如国资委、外企、联想神州数码等国企的
ITIL专家都要求有项目管理技能,有的企业甚至要求高级管理者需要具备工信部项目管理师、PMP等认证。
话题三:ITSM和PM哪一个更适合作为职业发展的方向?如何根据个人的条件进行选择?
PMBar冯老师认为:他们之间没有直接的可比性。职业发展规划的核心,是需要个人问清自己要什么?所谓,我想成为什么样的人?技术职业
发展通常有以下4类:
技术工程师
开发
测试
质量保证
美工
架构师、系统分析师
管理类
项目经理
产品经理
部门经理
市场类
售前工程师
售后工程师
每个需要依据自己的实际情况来确定自己的发展路线。就项目管理而言,一名合格的项目经理,从性格特质、专业技能、学习能力、决策能力、
沟通能力等方面都有一定要求。好消息是,项目经理往往是通用管理者的阶梯。
最后,PMBar创始人老谷分享了PMBar社区近期动态:
1、PMBAR第一本经典著作重磅出击《IT项目管理那些事儿》热销!
a)8月中旬上架,目前已销售5500册,第二版印刷已完成。
b)策划敏捷实践书籍,预计今年7月上架
PMBar - 需求 41
- 42. PMBar牵手ITIL先锋论坛 PMBar特约记者 陋室北京报道
c)下半年策划CMMI实践书籍,预计2013年上半年上架
2、PMBAR项目经理电子杂志试刊首期—敏捷VS传统 隆重推出!第二期 “需求管理”专辑进行中。
3、与ITIL先锋论坛合作,启动YY在线语音沙龙活动。
4、每月举办地面项目管理沙龙活动
5、建立PMBar项目管理培训体系并举办公开课
6、启动PMBar项目管理工具开发及试用
7、开展社区项目管理知识沉淀工作
此次活动取得了远远超出预期的效果,受到了来ITIL和PMBar社区成员的高度赞誉。此次活动的成功举办,标志着PMBar在IT项目管理领域的
公益实践更上了一层楼,开辟了实践社区合作的新形式,为推进“让IT项目管理在中国普遍成功”向前迈出了坚实的一步。
后继:“ITIL握手PM”活动开启了PMBar与ITIL两个实践社区之间在线语音沙龙的合作之旅。目前,已成功联合举办2期活动。
3.22 PMBar第1期暨ITIL先锋第20期歪歪语音沙龙:《项目管理和谐之旅》--恺墨 成功举行
3.29 PMBar第2期暨ITIL先锋第21期歪歪语音沙龙:《说说IT项目管理工作死角那些事》王艳春chuner
参考链接http://www.pmbar.net/read.php?tid=1432和http://www.pmbar.net/read.php?tid=1453
附录: ITIL先锋论坛论坛网址:www.itilxf.com
ITIL 先锋论坛是国内最大的IT服务管理专业社区,自2010年底成立以来始终致力于
以ITIL为代表的信息技术科学方法论在国内的推广与落地,
目前已发展论坛 会员近7000人,15000多微博粉丝,6000多名QQ群友,40000多
条帖子,10000多分可供下载的管理及实践资料。ITIL先锋论坛在各位 版主及广大
网友的共同努力下,将继续为IT服务管理初学者提供入门的引领,为IT服务管理实践
者提供落地的支撑,为IT服务管理业界提供沟通交流的平台。
社区口号:ITIL先锋,你我同行。
PMBar - 需求 42