锐客网

  1. 首页 > it技术 > >

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

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

    推荐阅读


    上一篇：软件测试管理者会遇到哪些工作上的问题（新梦想软件测试）

    下一篇：新学期感赏