如何与PM愉快的相爱相杀?|洞见
一些背景故事
坊间流传着很多关于PM(Project Manager,项目经理)的笑话,在这些不无刻薄的笑话中,PM往往被描述成一个盲目应承客户,不了解实际情况而又喜欢指手画脚、专门坑开发的家伙。毋庸置疑,这些笑话当然出自那些“聪明的”开发(不过你得承认,这些笑话并非空穴来风)。
在智力工作中,对于开发的实际进度、开发速率等问题,具体着手做的人永远比在背后指手画脚的人更有发言权。软件开发正是一项智力活动,优秀的软件无法通过人力的堆积而产生。一个关于PM的经典的讽刺是:PM就是那些指望着9个女人在1个月内生出1个小孩的二货。乍看上去,这个笑话还真是一针见血。
我记得在刚加入ThoughtWorks的时候,私底下经常听到这种论调:PM基本就是项目上被人鄙视的角色,基本上负责团队建设去哪儿这种杂事儿就行了,团队的其他人员可以高度自治,并不需要被管理,项目就会如预期般按时交付。
这些论调在某些情况下可能是对的。但是如果放在国内项目的这个上下文里,倘若没有一个专业的PM来协助项目、控制需求、划定项目范围、与客户谈判等等,没有任何一个项目是可以真正成功交付的,指望高度自治的开发们来完成项目?咱们还是现实一些吧。
一个悲剧的事实是,开发人员往往都恃才傲物,有时还会带着一幅要拯救世界的心态做项目,这事实上和客户以及PM的期望是有很大出入的。在项目启动之初,PM会面临重重困难:首先,团队里的每个人都不好管,而且每个人都认为自己不需要被管理(当然这种想法在大多都是错误的);其次,PM需要和客户快速建立信任,并推动项目进入正轨;最后,他们也需要了解大量与项目相关的上下文(业务上下文,人员关系,资源协调等),最后留给自己的时间也非常有限。
除了催进度,PM平时还干点啥?
本质上来说,PM其实就是一个轮询器:识别所有的项目风险,然后不断跟进。项目风险可能是技术风险,比如某个技术上压根搞不定的问题。也可能资源风险,比如人手不够,或者开发者很多,但是没有足够的设计师协助,这些风险都会导致项目无法按时交付。一个客观事实是,所有项目都会变化,从售前到需求分析结束,项目的需求都在持续变化,如果不对报价做相应的调整,极有可能会亏本。
PM的一个重要职责就是在项目之初将项目范围定下来,这个范围的划分非常依赖经验:划得少了团队得天天加班,累得跟狗一样才能保证交付(据我的经验,虽然项目一般不会天天加班,但是总会有一些攻关、打补丁的事儿,最后还是会累成狗),划得多了客户不买单,意思是就这个小功能你要做两个月,绝对不行。
PM需要协调这些不一致,还需要和销售、客户等方面不断谈判、写方案、排计划,简而言之,也是累的跟狗一样。在此过程中,还可能被那些天真幼稚的开发坑——开发经常会高估自己的开发速度,反正我还没遇到过低估的,你见过吗?
我们每天看到的PM干的最多的事情就是:元芳,那个接口怎么样了?什么时候能做完,有什么blocker?李柯,昨天说的代理的事情怎么样了?小波,高保真什么时候出?何方,我们周三下午要showcase,麻烦你订一下会议室吧……
除了写代码,Dev平时还干点啥?
如果脱离PM的角度,做为一个孤傲的开发,时常会觉得“PM为什么老是问我进度?是不是怀疑我的能力?为什么监视我的工作?”相信我,其实他才不想监视你。但是你设想一下:如果你不参与代码编写,每天只是看旁边的哥们写,你如何知道他实际的进度呢?而且众所周知,开发很难准确更新自己的工作进度,而且遇到问题也很少积极主动的报告,通常都会自己埋头尝试解决。那么,轮询显然是一种成本最低,反馈最快的方法。
不主动更新进度是一个大问题,这个得单独说。关于更新进度,典型的场景是:早上站会的时候,开发目光呆滞的盯着某个卡片,努力回忆其中的验收条件以及自己当前的进度,如果恰好脑海中的技术细节和卡片描述在某个点上匹配了,他会迅速的告诉你,目前进展良好,今天上午应该就可以做完。开发在更新进度时,要么盲目乐观,要么就跳进太细节的地方进行讨论,最后的结果就是:跟没更新一样,白白浪费了10分钟。但是别忘了,PM会在15分钟之后再来轮询一次。
PM每周都需要汇总很多数字,比如本迭代完成的点数、剩余的点数、总体进度如何、有没有人准备请假、遇到什么blocker、每个blocker的具体原因、每个风险点的最终日期是何时等等等等。他肯定不能记住这些数字,所以可能一天之内向你询问数次。
PM的其他职责/技能
上边说到的其实只是描述PM的辛苦,而最微妙,最考验PM的是其“察言观色”的技能。这绝对是一个工作经验在10年之内完全无法获得的技能(而且是在国内项目上工作10年)。比如,在showcase的时候,有个客户说,“嗯,挺好,整个流程就是这样的,后续你们的UI是不是还会美化?”如果你遇到这个情况,请问,这个客户是什么意思?
如果你能回答上这个问题(而不是提出问题),那说明你还离PM差十万八千里。成熟的PM会先判断,提出这个问题的人是什么角色,以及他在系统中的话语权如何,还有其他人就此问题的反应如何等,然后找到一个合适的答案。
PM另一个绝技是扯皮(不是贬义),开发会花一个下午(我是说10分钟)去跟客户讨论需求的范围吗?或者会为5个人天来讨价还价吗?我想开发大概会说,“尼玛,找其他供应商吧,老子不伺候了。”
一个项目的成功,需要多方合作,这里说的合作并不局限在甲方和乙方之间,即使在乙方的团队之中,也需要很紧密的合作。比如项目经理和开发、设计师之间的合作。如果仅仅从开发的角度来看,PM有时候看起来就像和客户站在一起来整开发的一样,比如催进度,过分保守的估算人天(导致团队加班赶工)。PM需要释放团队中的负面情绪,保证团队士气,还需要做一些开发不屑于做的琐碎事情。
设身处地,替他人着想
从本质来说,每个项目都是一次生意。在去掉那些繁杂的流程和形式之后,做一个项目和你去菜市场买菜其实并无二致。根据传统,软件开发界特别喜欢找建筑行业做类比,我也找个建筑方面例子。
装修房子的时候,我们会要求施工方提供图纸(水电改造,基本设计等),按期交付(确定工期),同时会界定项目范围(比如刷墙,贴地砖,吊顶,封阳台等等),会要求工人按时来上班,正常出勤,认真工作,直到项目结束。过程中我们还会讨价还价,比如捎带着把栏杆拆除,捎带着敲掉一面隔离墙等等。在过程中,我们还会敲敲地砖,检查过门石,检查吊顶,测试水电等等。作为甲方,这些活动相信没有人会觉得过分。
但是一旦我们做乙方,也就是施工方的时候,情况就全变了。比如客户要求打卡,有人会觉得不爽,客户要求代码review,有人会觉得不爽,要求代码有设计文档,有人会觉得不爽,要求设计有多个备选方案,有人会觉得不爽。大多数情况下,这都是虚无缥缈的虚荣在作祟,这种情况在所难免,不过还不致命。
一旦涉及到讨价还价(不是商务上的讨价还价,而是和客户就工作量达不成一致,或者就某个技术方案达不成一致之后),开发全部歇菜,一言不合,转身就走,压根不具备讨价换件的能力,这样还怎么做生意啊?设身处地想一下,如果你是甲方,当提出了一些合理的要求(比如需要一方提供验收标准,通过验收测试等),结果施工方还一脸的“我不跟你说了,你就是以大傻B”,你能乐意吗?
如何合作?
说了这么多,这两种角色在同一个项目上要如何合作呢?我想,作为开发来说,有这样几点可能:
首先,理解PM的工作。
在很多时候,开发会有莫名其妙的优越感(其实每个角色都会有,比如销售看不上技术人员,技术Lead看不上PM等等),主要原因是坐井观天,对其他角色的辛苦和工作内容不清楚,错误的认为别人的工作都很low。
之前听一个同事讲过一个小session,里面有一点我印象非常深刻:不要因为一个人不会某个技术而鄙视他。就好比你不应该因为不会弹钢琴,而被一个会弹钢琴的人鄙视一样。道理很简单,但是开发在长期的“宅”生涯或者坐井观天中,进化出了这种非理性的观点:如果一个人连vim(此处的vim可以换成任何其他技术)都不会,就压根不足以谈人生。
其次,学习如何报告进度。
PM催你的根本原因是进度不明确,如果每一个潜在的风险都清楚的显示着进度,而且有明确的负责人,PM就会降低轮询的频率。这需要开发经过刻苦的练习才能达到:
站会前自己花3分钟整理一下昨天做的工作
根据story的验收条件(最好有和BA/QA一起的讨论需求),进行合理的任务划分(tasking技能)
可以借助便签纸等工具,帮助自己明确进度(划分了5个子任务,昨天完成了3个,那么可以粗略的估计为60%)
再次,合理估算。
有些时候,新人(来自于传统管理环境的新人)可能会误以为PM是一个管理的角色,或者处于某些考虑会在PM询问进度时做出一些错误的回答。比如PM在迭代启动会议上是问“这个迭代我们有没有可能做完所有计划内的任务?”作为一个负责任的开发,你需要在第一时间指出那些“非理性”的期望,以便PM进行更加准确的计划。
明确告诉PM,有哪些需求是不可能按时交付的,PM会根据实际情况来重新定计划,并和客户确认
明确告诉PM一些可能的风险,团队整体对交付负责,而不是PM,或者开发
按照经验,项目从来就不会按照计划进行,在做好一个粗略的计划之后,PM的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通,虽然可能短期来看可能会影响开发速度,但是从整体上来看,可以减少很多不必要的浪费。
简而言之,要站在别人的角度考虑问题:如果换做是你,你会怎么做?
- 相关阅读 -
点击[阅读原文]到洞见网站查看文章全部内容&绿字部分。
本文版权属ThoughtWorks公司所有,如需转载请在后台留言联系。