输了你,赢了世界又如何(——论项目管理人、事和结果的指标体系建立)

??我失去你,赢了一切却依然如此冷清。输了你,赢了世界又如何! 面对互联网的瞬息万变,在产品发展中,我们往往一心盯着业务,盯着 KPI,然而对于一个产品来说,用情怀呵护,营造一个温暖的团队后盾 同样很重要。
??最近看新闻碰到一个桥段:某潜力股青年,为了挣得让女友幸福生活的 家产,在外打拼多年,成功归来却发现物是人非。输了你,赢了世界又 如何,多么痛的感慨!
??身边不少新闻段子:某公司年轻高管,坐拥千万元乃至上亿元家 产,终因劳累过度,意外猝死。输了自己,赢了世界又如何,多么痛的 领悟!
??其实,我们做产品、做项目的过程也不乏这样的经历。
?? 互联网世界,瞬息万变,每个玩家都在玩命地快快快!每块业务都 在飞速发展!当你在风口上的时候,即使你比猪还胖,你也必须要飞起来!
??这时候,所有的眼睛都盯着业务,盯着KPI,盯着发展;所有的需求都只能应对最重要的业务功能或者运营活动,影响稍小点的用户Bug 只能靠边站;各个版本只来得及实现需求中最最重要且紧急的,并且还 不断砍掉些看起来不那么重要的小点;运营也是忙得飞,用着虐心的后 台也得把长长的内容给录入进去,还要上接用户下接供应商拢起无数条 线头……加班,根本停不下来!
??有没有感觉我们在拼世界的同时,似乎忽视了什么? ?? 忽然有一天,线上开始连续出事故,一看原来都是以前欠下的债! 然后团队规模是之前的两三倍,但产能总上不去,比以前多出不了多少 活,而且大家对成天的加班怨声载道。再然后,一个一个员工开始离 职,核心功能开始无人能懂……
??和谈恋爱一样,痛过苦(哭)过,后来,我们才学会如何去爱。原 来我们的产品在拼世界的时候,永远需要另一股力量,打造团队更坚实 的基础,营造团队更温暖的港湾。这是产品老大们都要敬畏的生存现状,是团队都要注意的发展平衡,更是每个项目经理要固守的项目根本。
??现在从三个角度说说如何关注和打造这样的基础。
一、人
指标:新老员工比例不应超过1:1,其中新员工包括正职/借调+ 实习生 原因: 无人指导和关怀的新人就是添乱,除了搞乱那本已有点乱 的代码外,更容易造成老员工烦躁,新人本身的诸多怨气最终导致不稳定。另外,当新人从人数和文化气场上强过老员工时,原有的文化会被 颠覆,种种不和谐“应运而生”。
应对:不要在短期内招过多新人,招一批带一批,成熟一批后再 招一批;每个团队都要建立自己的新人入门指南,每个新人要有正规的 方式介绍给团队;从了解公司到权限申请到各种规范,都要有培训;每 个新人都要确定一个导师,导师帮助新人制订上手计划,每周至少一 次深入沟通,建议新人每周简单写一下心得,作为个人积累和问题反 馈。让新人成为导师所负责领域的助理,也是种不错的梯队培养方式。
二、事
指标1:研发规范执行到位的程度 原因: 别以为上线申请或者更新交互稿少群发了一次不是什么大 不了的事儿,也许正是因为一次少发,导致一个线上事故。千里之堤溃 于蚁穴。研发规范执行得松散并非一日的倒退,长此以往会造成团队散漫,同时又给产品埋下无数的雷。
应对: 言必行,行必果。项目经理必须对日常研发规范的执行起 到强力维护作用,并根据实际情况不断优化。某些做法如已不再适合团 队,就要正式将其退役,而非不了了之。从站会的频率和时长、周会周 报的频率和内容、策划交互稿的评审和群发,到提测和冒烟的执行、上 线审批及效果追踪,虽然繁复但需坚持。产品线上无小事,意识都是点 滴培养积累的。
指标2:研发效率/产能,不是团队负荷度,而是产能吞吐量 ??不要在意每个人的负荷是不是满的,而要关注相同时间内完成了多 少需求量,或者需求的平均响应时间。
原因:所有人都被工作塞满的做法是不科学的。每个人都可以装 作被塞满了,这种非常被动不信任的方式副作用很多。产品真正需要的 不是一堆加班的人,而是一堆好用的功能。所以,关注这些功能多久能 被完成是更合适的。
【输了你,赢了世界又如何(——论项目管理人、事和结果的指标体系建立)】应对:先记录,就能发现团队的问题。然后从流程优化、团队培 养、技术架构这些层面引发更多的思考和改良,自然开始有“还技术 债”的需求进入视野。另外,关注产能还可以帮我们更快地消化需求队列。
指标3:版本中是否出现过技术优化需求 **原因: **没有不欠债的技术团队,但如果版本计划里已长期无法排 下技术优化需求,那也就意味着技术问题长期堆积,架构风险日益增高,迟早有一天以 重大线上问题的方式集体爆发出来。
应对:在提升产能指标的过程中,重要且紧急需求的响应加快, 逐步会有空间来做重要的架构优化;另外,架构优化中重要问题要提升 优先级排上来,整体的架构优化要排计划,并且获得产品老大的支持。
三、结果
指标:线上事故频率及严重度、修复速度 如果说产能代表了速度,那么线上事故则代表了质量。两者并举才能做到又快又好。 原因: 废话,不多说。
应对:做好了1和2,线上事故整体会下降。当然,也需要针对性 地做些提高,比如上线流程、线上事故应对预案等。对所有的线上事故 都要做记录,分析根源,以及提出改进措施。当事故频率显著升高时, 其实已经提示有重大的研发过程问题了。
?? 当人和事指标出现偏差时,往往是问题的早期,要尽快采取措施进 行纠正;而当结果指标报警时,团队的健康程度已经发生了问题并导致 了产品不良结果,需要花更大力气来拨乱反正了。
?? 对事的问题要防微杜渐,对人的问题要心存敬畏,带着团队去打拼 世界,才是长久之计!

    推荐阅读