本文作者将从三个角度说说如何关注和打造团队发展平衡的基础。

和谈恋爱一样，痛过苦（哭）过，后来，我们才学会如何去爱。我们做项目、做产品、拼世界的同时，永远需要另外一股力量，打造团队更坚实的基础，营造团队更温暖的港湾。这是产品老大们都要敬畏的生存现状，是团队都要注意的发展平衡，更是每个项目经理要固守的项目根本。

记忆里小说中的桥段：某潜力股青年，为了挣得让女友幸福生活的家产，在外打拼多年，成功归来却发现物是人非。输了你，赢了世界又如何，多么痛的感慨。

身边不少新闻中的段子：某公司年轻高管，坐拥千万乃至上亿家产，终因劳累过度，意外猝死。输了自己，赢了世界又如何，多么痛的领悟。

其实，我们做产品做项目的过程里也不乏这样的经历。

互联网世界，瞬息万变，每一个玩家都在玩命地快快快！每一块业务都在飞速发展！当你在风口上的时候，即使你比猪还胖，你也必须要飞起来！

这时候，所有的眼睛都盯着业务，盯着KPI，盯着发展；所有的需求都只能应对最重要的业务功能或者运营活动，影响稍小点的用户bug都只能靠边站；各个版本只来得及实现需求中最最重要且紧急的，并且还不断砍掉些看起来不那么重要的小点；运营也是忙得飞，用着虐心的后台也得把长长的内容给录入进去，还要上接用户下接供应商拢起无数条线头……加班，根本停不下来！~~~~>_<~~~~

有没有感觉我们在拼世界的同时，似乎忽视了什么？

忽然有一天，线上开始连着出事故，一看原来都是以前欠下的债！然后团队规模是之前的两三倍，但产能似乎上不去，比以前多干不了多少事儿，而且成天对加班怨声载道的。再然后，一个一个开始离职，核心功能开始无人能懂……

和谈恋爱一样，痛过苦（哭）过，后来，我们才学会如何去爱。我们做项目、做产品、拼世界的同时，永远需要另外一股力量，打造团队更坚实的基础，营造团队更温暖的港湾。这是产品老大们都要敬畏的生存现状，是团队都要注意的发展平衡，更是每个项目经理要固守的项目根本。

从三个角度说说如何关注和打造这样的基础：

有关人

指标：新老员工比例不应超过1:1，其中新员工包括正职/借调+实习生……

原因：无人指导和关怀的新人就是添乱，除了搞乱那本已有点乱的代码外，更容易造成老人烦躁，以及新人本身的诸多怨气最终导致不稳定。另外，当新人从人数和文化氛围上强过老人时，原有的文化会被颠覆，种种不和谐应运而生。

应对：不要在短期内招过多新人，招一批带一批，成熟一批后再招一批；每个团队都要建立自己的新人入门指南，每个新人要有正规的方式介绍给团队；从了解公司到权限申请到各种规范，都要有培训；每个新人都要确定一个导师，导师帮助新人制定上手计划，每周至少一次深入沟通，建议新人每周简单写一下心得，作为个人积累和问题反馈。对了，让新人成为导师所负责领域的backup，也是种不错的梯队培养方式。

有关事

指标1：研发规范的执行到位程度

原因：别以为上线申请或者更新交互稿少群发了一次不是什么大不了的事儿，也许正是因为一次少发，就会导致一个线上事故。千里之堤溃于蚁穴，研发规范执行的松散并非一日的倒退，缓慢而长期的倒退会造成团队的散漫，同时又给产品埋下了无数的雷。

应对：言必行行必果，项目经理必须对日常研发规范的执行起到强力维护作用，并根据实际情况不断优化。即便有某些做法已不再适合团队，也要正式将其退役，而非不了了之。从站会的频率和时长、周会周报的频率和内容，从策划交互稿的评审和群发，到提测和冒烟的执行、上线审批及效果追踪，虽然繁复但需坚持。产品线上无小事，意识都是点滴培养积累的。

指标2：研发效率/产能，不是团队负荷度，而是产能吞吐量。

不要在意每个人的负荷是不是满的，而关注相同时间内我们完成了多少需求量，或者需求的平均响应时间。

原因：把所有人都塞满的做法是不科学的，至少每个人都可以装作被塞满，这种非常被动不信任的执行方式副作用很多。产品真正需要的不是一堆加班的人，而是一堆好用的功能。所以，关注这些功能多久能被完成是更合适的。

应对：先记录，就能发现团队的问题。然后从流程优化、团队培养、技术架构这些层面就会引发更多的思考和改良，自然开始有“还技术债”的需求进入视野。另外，关注产能，还可以帮我们更快地消化需求队列。

指标3：版本中是否出现过技术优化需求

原因：没有不欠债的技术团队，但如果版本计划里已长期无法排下技术优化需求，那也就意味着技术问题长期堆积，架构风险日益增高，迟早有一天以重大线上问题的方式集体爆发。

应对：在提升产能指标的过程中，重要且紧急需求的响应加快，逐步会有空间来做重要的架构优化；另一方面，架构优化中重要问题要提升优先级排上来，整体的架构优化要排计划，并且获得产品老大的支持。

有关结果

指标：线上事故频率及严重度，修复速度。

如果说产能代表了速度，那么线上事故则体现了质量。两者并举才能做到又快又好。

原因：废话，不多说。

应对：做好了1和2，线上事故整体上会下降。当然，也需要针对性做些提高，比如上线流程、线上事故应对预案等。对所有的线上事故都要做记录、根源分析以及改进措施，当事故频率显著升高时，已经提示重大的研发过程问题了。

写在最后

当人和事指标出现偏差时，往往是问题早期，要尽快采取措施进行纠正；而当结果指标报警时，团队的健康程度已经发生了问题并导致了产品不良结果，更需要花大力气来拨乱反正了。

对事的问题要防微杜渐，对人的问题要心存敬畏，带着ta去打拼世界，才是长久之计！

作者：曹智清，网易杭研项目管理部总监。曾经感受过IBM的专业严谨，领略过ASK搜索的起起伏伏，体会过创业中的酸甜苦辣。目前致力于在线教育行业的探索，同时关注项目管理在互联网产品全生命周期的应用，专注于敏捷精神的渗透和实践。《网易一千零一夜》主要作者之一。

本文由 @网易杭研项目管理（微信公众号：NetEasePM） 原创发布于人人都是产品经理。未经许可，禁止转载。