700字范文,内容丰富有趣,生活中的好帮手!
700字范文 > PM(项目经理)和Scrum Master(敏捷教练)不是非此即彼 也不应是隶属关系 应该有权利制衡

PM(项目经理)和Scrum Master(敏捷教练)不是非此即彼 也不应是隶属关系 应该有权利制衡

时间:2019-05-26 07:43:12

相关推荐

PM(项目经理)和Scrum Master(敏捷教练)不是非此即彼 也不应是隶属关系 应该有权利制衡

提到敏捷,就一定会想到:团队自制,每个迭代都交付可用的产品。这是纸面的敏捷,实际运行中的敏捷相信大部分不是这样的,这是个终极愿景,达到这个终极目标的门槛太高了。

似乎有点跑题,其实这是真实感受,后面的观点,恰恰是对破解敏捷开发不敏捷的思考。

敏捷更适用于长周期的,需求分阶段明确的项目

先说说项目的类型。笼统划分类两种吧:

一种是一次性项目,干完移交给客户/用户就完事了,没有延续;另一种是有继承性的,比如需要耗时几年的大项目,或者有持续发展计划的产品/技术开发项目,共同特点就是周期够长。

一般情况下,第一种类型的项目一般会有一名PM(项目经理)负责。至于第二种类型的项目就又有细分,一次性大项目一般要指派一位PM(项目经理)负责;有持续发展计划的产品/技术开发项目,这里就要引入另外一个角色PO(产品经理),总体负责长线产品/技术类项目似乎更合理(此时叫PM也无不可,职责明确就好了);对于比较大的产品,有必要切割成多个部分并行开发时,PO(产品经理)下会设置多个PM(项目经理)负责子项目开发。

对于第一类项目,当初始需求不明确时,一般会采用迭代的开发进程进行推进(瀑布过程模型适合需求明确的情况,而是迭代过程模型更适合需求不太明确的场景),很多情况人们会把应用了迭代过程模型的项目叫做敏捷,这里不过多比较迭代和敏捷,百度脑补一下就好了,两者有共同点,但绝不是一回事儿。敏捷需要逐步训练团队成员在项目中对能力的理解,一次性的项目做完就完事了,下一个项目还是不是这个效率受需求和环境影响很大,敏捷意义不大,但敏捷实践仍能够提供很多有意义的参考,比如敏捷会议。不要误解,这并不是说不可以用敏捷,可以视情况而定,不管黑猫白猫,抓得住老鼠就是好猫。

这里主要聚焦在第二种类型项目,对于周期比较长的项目,能够分阶段看到成果和矫正偏差,不至于到项目最后发现成果和需求不匹配而损失惨重,除了损失金钱,跟重要的是损失时间和团队士气,有不可取。因此,长周期的项目中应用敏捷,是个合理的选择。

PM(项目经理)和Scrum Master(敏捷教练)两种角色并存是一种事实

一般的习惯是,项目一定要有一个PM(项目经理),即使是敏捷项目。于是引出了很多争论,敏捷团队是自制的,不应该设置PM,Scrum Master就够了。不管怎样,在绝大多数实践里,PM(项目经理)是个必要角色,只不过在敏捷项目中,可能同时承担Scrum Master的职责,或者指派一位团队内成员担当Scrum Master角色。现实就是这样,PM(项目经理)和Scrum Master是并存的。

从敏捷里面看,PM确实与团队自制精神不符,但放大到组织层面,谁来为项目的成功负责,Scrum Master可以吗?回答基本上是否,因此两个角色并存是一种事实情况。PM负责项目的管理,对项目的成功付总体责任,关注的项目结果;Scrum Master为项目提供支持,引导和指导团队把敏捷时间作对,关注的是项目过程。

既然是并存,敏捷过程的质量,就需要PM和Scrum Master一起来保证了。这是就引出了两者的关系问题。

两者谁听谁的呢?有了这样的疑问,项目的敏捷之路注定不平坦。PM对项目结果负责,自然是PM话语权大,当感受到进度压力时,出现不顾项目过程直奔结果的情况自不可避免,出现项目暴雷的情况也就顺利成章了。

因此,个人认为,在敏捷中,Scrum Master除了支持作用,还应该给这个角色赋予监管的权利,以对PM的权利形成制衡。

Scrum Master(敏捷教练)应该对PM(项目经理)的权利形成制衡

实现制衡的第一要求,是Scrum Master不能是项目团队成员,与PM之间不应有隶属关系,否则很难按照独立的意志和要求完成其敏捷过程的引导职责。

同时,唯二的要求是,最好是Scrum Master隶属于PMO,项目QA同时担当Scrum Master的角色。这样,其对项目过程的引导接受PM的监督,同时反过来也可以避免PM的干扰来是项目过程执行到位。

如果QA人员的能力达不到Scrum Master的技能要求,对项目的监管工作可由QA执行,Scrum Master回归本职的教练工作,重要活动QA同时参加,使用QA的监管权对PM的权利形成制衡,对于运作不成熟的团队尤其如此。

敏捷不是目的,提高研发效率才是目的,因此敏捷不是要理想的按照纸面的规则生搬硬套,要循序渐进;同样,也不能因为敏捷推行的适应期内,因思想、行为的改变对研发效率造成了短期影响,就变得自我否定,认为敏捷不行,或者我做不了敏捷。这都是一叶障目。应该做好计划,按步骤推进,历史需要英雄,但绝不能把希望寄托在某个英雄身上,即使短期可以,长期也会难以为继,英雄终会老去。要通过体系的力量,影响人、感染人、培养人、激励人,组织赋能的敏捷更容易发挥作用。

以上为PM(项目经理)和Scrum Master(敏捷教练)的纸面探索,欢迎交流。如有幸被哪位已有践行的朋友看到,期望指教。

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。