临危受命 — 对错之间的电话会议

 

对错之间的电话会议

 

在这个持续的5周时间里面,有几次交付。每次交付,我们除了提供版本包以外,还会提供一份已知缺陷列表 — 没有哪个软件是0Bug的。

在某次交付之后,美国的产品总监第二天又发了一份缺陷列表,说这个是他在这次交付里面“随手”点出来的,并且带着质问的口气问我们的开发团队为什么还会让这些缺陷留在软件里,另外我们的测试团队为什么没有将这些缺陷找出来。最后他期望在第二天早上他们的9AM也就是当晚我们的9PM好好的讨论下这些Bug。

美国产品总监的为人我已经早有所耳闻,而且经历过几次。所以当他带着强烈质问责备的语气去提出他的缺陷列表的时候,我第一时间就是去分析他的缺陷列表是不是真的如他所说的那样,而没有沉湎于他强烈问责中而不安,更没有直接和他理论“怎么可能发生这样的情况”,因为在这样临危受命的大背景以及他是我们的上司的情况下这些情绪上的对抗毫无意义甚至会让状况变得更糟糕。

我花了一早上的时间一个个看他报过来的Bug,并且和工程师一个个确认,然后从他那凌乱的缺陷列表中找到和我们的已知缺陷列表中对应的Bug。最后我将每个Bug加注了相应的评论,并且给出总结。总结用数字说话,告诉了哪些Bug已经在我们的已知缺陷列表中,哪些Bug其实是新的需求,哪些Bug是用户体验方面的Bug — 现阶段大家先完成基本功能为目标,用户体验方面稍后,哪些Bug根本就不是Bug等等。

随后这份报告发给了我们的软件开发总监A,接着他给出了他的一些评论,我根据他的评论改善了报告。最后这个报告发给了USP,他根据我们的情况也加注了他的评论,我又根据他的评论改善了报告。

就这样,几乎每个人都预测到,晚上的电话会议一定是腥风血雨,我们需要接受美国方面的严格的盘问。我们为这次电话会议做了一整天的准备。最后我小心翼翼再三查看并静心写好邮件后在电话会议之前将报告发给了美国。

晚上,气氛紧张的电话会议开始了。美国方面那个凶神恶煞的产品总监跟着我们一起过Bug,并且我们共享着桌面和Mac,可以让他现场看到我们部署好的环境。针对每一个问题,双方细细地推敲。遇到他误报的问题,他一带而过;遇到我们的问题,哪怕不是现阶段应该注意的问题, 他会严厉指责为什么没有做好。总监在会议室里面转来转去,他屏气听着我们的对话,他并不在这次电话会议上出现,所以他会按下静音间告诉我如何回答电话中那无赖的指责,然后由我来回答。

照理说我参加过很多电话会议,但是这样子各种大佬参加,维护团队甚至公司声誉级别的电话会议我才是第一次参加。会议后,我发挥地并不好,虽然我感觉和平常的电话会议我发挥的一致,可是得到了软件开发总监的批评。那天给我感触很大,夜晚天开始下雨,我和同事离开公司分开后没打伞走了回家。雨越下越大,在暴雨中行走也可以好好地反省一下。

这次电话会议虽然过程很痛苦,但是收获也颇丰:

Reputation很重要。Reputation,就是声誉、声望。人是一种很奇怪的生物,就算一群很严谨做技术的人,你会发现在他们身上发生的事情并不是各自独立的。

比如说,如果你们在讨论10件事情,如果你第一件事情就处理地很失误,或者说你马虎了,或者说你说的话明显有问题,那么你们在讨论完第一件事情后,后面的9件事情对方都会用一种质疑的心态跟你讨论 — 对方会想后面的事情很可能和你的第一件事一样也会出错。正因为此,我们需要在一个电话会议前,一次交付前,做任何一件事情之前保持严谨的作风,并且充分准备,否则你的Reputation,声誉和声望就因为某件事情全毁了。记得一个场景吗,路人甲跟路人乙说:那家奶茶店不干净,上次我看到他们里面把掉在地上的水果加到奶茶里。估计不论是路人乙,还是作为路人丙的你,都很难再去那家奶茶店了吧。

电话会议往往也是团队作战。根据上面的第一点,当遇到讨论技术细节的时候,PM可能并没有具体的工程师清楚,这样不妨让工程师去回答而不是PM直接去回答,虽然PM的英语可能比工程师好。为什么?因为这样的技术细节,如果PM答错,或者说很多无事实根据的推断,很容易造成Reputation降低。这样不妨让工程师代劳,如果工程师说错,PM可以再接话过来说事后可以再讨论。这样有利于维护己方PM的Reputation,从而PM可以在其他方面更容易地维护己方利益。

电话会议,其实是跟人打交道的。虽然是讨论技术,但是如果你是一个天使类型的技术人,很有可能你在电话会议中并不那么占有便宜。如果是跟人打交道,那么还是需要懂点丛林法则。工程师思维容易认错,说这是我的责任。没错,当然你可能负上主要责任,但是如果你直接交枪,那么对手接下来会把本来不是你的错,或者你只负有一点责任的事情往你身上推。这些虽然很“邪恶”,但确是事实。我们需要尊重事实,所以也需要聪明一些地维护自己的利益。在坦诚自己错误的同时,也要想想对方是不是也有做得不对的地方,勇敢说出来,就不会让你处于过度被动的地位。

这次电话会议让我明白,现实并不是非黑即白,同样的情况在不同话术的牵引下,结果会导致不同。如果说现实就是一个灰色空间,那么一个合格的PM,首先守住做人和做事的底线 — 即不欺骗讲诚信,然后应该在某些时候变身一个恶人,凶恶的善良人,因为你不能让你的团队和周围的人受到不必要的伤害。

临危受命 — 再论角色扮演

角色扮演

 

09年的时候,我写过一篇软件开发的角色扮演(点这里),那里主要是叙述在通常情况下每个岗位的人一般如何各司其职。接下来要说的是在这个临危受命的项目中,观察到的一些角色扮演,有的是对已知的角色补充,有的是介绍一些新角色。

1. 项目经理

项目经理是项目的直接负责人,对项目的成败直接负起责任。在项目经理的这个角色上,需要有很强的主人翁意识和自我驱动力。简单地说,你要视你的项目为你的孩子,静心打理,这个项目交给你,你就需要操所有的心。你需要很清楚地知道达到项目交付需要干些什么,你可以听从别人的建议,但是如果只跟着别人的指点自己没有主见,那么项目很有可能在你手上砸掉。

项目经理最主要的工作就是掌控对项目的进度,追踪项目的状态。思考一个问题:你说你在做一个项目,那么这个项目的状态是什么?

我在这个项目中扮演这个角色的初期,我经常会用“感性”去描述:现在比以前好多了,很多模块都可以用了……但是实际上这会让很多人迷糊,因为他们不知道你的感觉到底是个什么样的程度,你的感觉准不准。

所以需要用一些理性的数据来描述,而数据是需要填在一些框架里的,于是就会有需求列表,时间线,Bug列表,问题列表等等一系列的框架。这些框架依照现实填满了数据后,就可以提炼成一些数字。比如说,需求列表当前显示一共300条需求,完成了160条,另外30条需求还有bug,还有50条直接做废了,剩下的没有做;时间线显示开发者A进度落后了3人天的量,离交付还有5人天的工作量但是实际上还有3天了;Bug列表显示P1的Bug还有3个,P2的Bug还有5个,P3的Bug有12个,我们需要在交付前全部修复他们;问题列表显示还有5个需求是有问题的,其中的2个会影响到下一个交付……

这样就会让自己还有任何人,对这个项目的状况清楚。

然后就是一些日常管理杂事,比较琐碎,但是就好像玩游戏里面的微操一样。只有一点一滴都做好了,你的项目才不会危险。这其中包括:客户沟通,控制交付流程,需求分析,组织人员做估算,分配Bug。

突然问一个问题:如果有个技术问题一直困扰着你的技术人员,你该怎么办?不要说这是技术人员的事情,不是项目经理的事情。 — 在项目中任何事情都是项目经理的事情,所以项目经理需要对所有事负责。技术人员只是代理你做技术这一块的事情,如果这个技术问题解决不了,你可以找人求助,卷起袖子自己干,替换掉这个技术人员,告诉客户这个需求在下一次交付里面包括等等用一切你能用到的手段推动项目前进。有句俗话:人挡杀人,佛挡杀佛。描述的就是项目经理的霸气。

2. 开发

开发除了写功能外,还要的是修复Bug。这两样除了写代码外,就是需要做估算。估算,应该由开发这个功能和修复这个Bug的开发自己给出,而不是项目经理。项目经理往往之前是开发,然后加上项目的压力,往往让开发做估算的时候会抢着说“这个明天做完没问题吧”。建议的是由开发自己说需要花多少时间,如果有分歧项目经理可以和开发稍微探讨一下实现方式,总之尊重开发自己的承诺。但是开发一旦承诺,就务必做完,超出的时间需要自己花额外时间补齐,以便不会影响到其他的进度。

3. 测试

测试方面,除了写测试用例和跑测试用例外,也是需要对时间进行估算。和上面开发一样的原理,项目经理需要尊重测试给出的承诺。有稍许不一样的是,有的时候项目时间线压力大,往往在交付前留给测试的时间相对较少,测试可能测不完全,那么只好是测试了多少就算多少,尽量保证所有的功能都覆盖到,然后项目经理报Known Issue(已知错误)以及说明情况以调整客户的期望。这里的意思是,测试需要在给定的时间内最大程度的测试。

测试还可以定义Bug的优先级,这个往往直接决定交付。通常来说,一个交付里面应该不会含有P1到P3的Bug,否则交付会受到影响或者说不能交付。一般来说,P1的Bug会被修复掉,因为太明显。P2的Bug也会被基本扫光,P3的Bug可能还会剩。所以这要求测试对Bug的优先级定义要尽量准确。

测试还可以标明一条需求是过还是不过,因为一条需求可能对应一个功能点,而一个功能点又可以有多个Bug。一般来说,一个功能点有一条P1到P3的Bug就可以标这个需求是不通过的。在这样的判断标准下,测试需要保留自己的独立判断权。

4. 乌克兰同事

乌克兰的两个同事实际上也是开发者,和我们的开发者身份一样,也是做部分模块。在项目开始的时候,我们也是第一次和他们一起工作。当时有个不太正常的关系是,因为乌克兰同事所在的公司是我们所在的公司的客户,所以我们的团队成员就把他们也当“客户”。毫无疑问,这样的关系是不健康的,因为我们所做的事情一样,为什么需要像客户那样供着?不卑不亢,平等合作才是正道。他们依然是属于项目经理的管理,所以中国的项目经理需要摆正心态。

5. 美国的同事

其实美国那边也有两个开发,他们也是项目组成员,只不过他们在美国产品总监身边,所以有的时候并不太买中国项目经理的账。具体的表现并不是“项目经理让他做什么他不做”,而是他可以直接做美国产品总监分配的任务而不告诉项目经理。曾经还一度出现,乌克兰的同事突然之间在做其他的事情,然后项目经理仔细一问,乌克兰同事在做美国同事跟他商量好的东西,在Skype上面商量了就直接干了。

6. 项目总监

他给整个团队的方向定基调,是项目经理汇报的对象。在公司层面,他的压力来自于公司高层,让他紧盯这个项目,于是他会参与我们的Bug分配,参与我们的交付。但是他一般不会直接做事,而是让项目经理完成他的指令,以及指导年轻的项目经理怎么处理难缠的客户。

7. 临时加入的外援USP
帮手还是累赘,看你怎么用?他的身份决定他不会由ownership,你来驱动他做事,虽然他比你官大几级。

在项目最焦头烂额的时候,公司高层那边介绍了一个USP,就是在公司美国总部的人。介绍的理由是他了解iOS项目,可以给我们一些指导。那个USP来了之后就想要搭各种环境,以便看到App效果,而这些环境又在我们内部网络他不能直接访问,于是我们只好在美国找到一个服务器忍受龟速的网络跟他搭了一个环境。心中觉得憋屈在于,他对于客户不可见,但是我们在本来焦头烂额缺人手的时候还需要花费额外的功夫帮他做一些事情。又不知道他对于客户不可见对我们有什么积极的意义。

最后,项目的最后,他总算提出了几点iOS App的建议。

不过回想起来,他的身份决定了他在这个项目中属于顾问的角色。如果他被高层指派到项目组中提供帮助,那么项目经理不能不招待他,但是招待他的同时,项目经理需要打好算盘怎么来利用好这个钦差的角色,让他要么对客户,要么对团队有积极的帮助。否则只能损失一些招待的成本。

8. USP老大
一个老头子,多次电话会议参与讨论。沟通极其棒,他很明确自己的角色,所以当其他人说你要不要看看App长什么样子,他说他不用看,因为很多人在看,他只关心项目的进度。所以这就是他拿着我的手机号的原因,随时打电话我“现在多少Bug了”,而作为项目经理,我也就因为他养成了将项目状态放在心中的习惯,时不时去看看实际的状态然后做出调整,否则就会被他骂。

“我问你的是一个很简单的问题,很难回答吗?。。。。”