公司大了，人多事杂，如何落地项目制？

不少朋友都向我咨询过公司实行项目制相关问题，比如落地不顺畅，问题多多，怎么办？如何实行考核？什么时候应该项目终止？等等。于是我想干脆写篇文章供大家参考吧。

小公司人少容易聚焦，事情虽多但是没有那么复杂，同时并行的项目不会特别多，资源分配和冲突在面对面的情况下也很容易解决。

随着队伍的壮大，各产品线的建立，各类支撑系统的完善，并行项目越来越多，各方都在争抢资源，抱怨冲突时，我们就开始考虑管理项目了，而非单纯的项目管理。

很多公司都会采用项目制来解决上述问题，项目制就像是方法论，结合实际情况改造使用，生搬硬套一定会似是而非，怨声载道。能做得好的公司有很多，做得不够好，甚至不如不做的公司就更多了。

项目制落地恰当的话，不仅可以推进项目建设，将有限的资源使用到最需要的地方，还可以给有主动承担意愿的人提供机会，为公司培养和储备管理人才。

这里，就我的经验和教训，跟大家分享几个关键点：

成立项目委员会

后面写到的所有工作老板都能做，甚至需要老板来拍板，但是这些工作不能统统都甩给老板，老板会被累“死”的。项目委员就是把老板解放出来的虚拟组织，对项目立项和终止有充分的决定权，对项目执行过程有监督权。

委员应该包括产品、研发、HR、商务、运营甚至财务等各方面代表，从不同角度讨论项目的价值。

委员会应该有负责人，委员之间是平等的，委员会负责人具有一票否决权，因此负责人一般是公司高管或老板。

项目要分级

项目不分级，则没有分配资源的依据，也就没有项目目标设定的基础。

分级是为了更有效率的利用资源，提高生产力，少走弯路，同时还能直观的体现项目价值。

如果公司有关键指标，那么在进行项目分级时就会有比较客观的分级依据。比如用户打卡的项目可以提升用户粘性，预计七日留存提升 10%，假设公司的七日留存是一级关键指标，那么用户打卡项目立项时项目级别就很高了。

具体项目级别，可以自己定义，只要大家认同又能表达相应的含义，怎么写都无碍。

通常做法是划分 S/A/B/C 或者 P0-3 等不同的级别：

1、S/P0 代表公司战略目标，这意味着项目极为重要，成功与否直接决定公司战略能否达成或者直接对应公司一级关键指标。

2、A/P1 代表部门或者事业部的目标项目，这意味着可以完成部门 / 事业部一级指标，或者阶段目标的项目，或者公司二级关键指标。

3、B/P2 代表对产品或者内部系统关键指标有帮助的项目，对应部门 / 事业部二级指标或者公司三级关键指标。

4、C/P3 代表非重点项目，这意味着立项与否不会对整体产生重大影响，但可以在某些方面有一定提升，适合新人练手。

目标的设立

目标必须包括两个要素：可量化的指标和合理的周期。这应该是大家的共识，但是难点在可量化指标，这里的可量化一定是可以计算出来的，而不是靠猜测或者推导出来的，直白说就是要用数据说话，不要拍脑袋。

如果公司确实已经有关键指标设定，那么项目的目标设定就很明确了，只要围绕着关键指标来设定项目目标，就一定不会错。

反过来说，如果项目设立的目标，左看右看，都不能对关键指标有所帮助，也没有命中分级中的理由，则需要考虑是否有必要立项，是否要把有限的资源分配到这类看不清楚目标的项目。

有些时候，关键指标是随着公司阶段的变化而变化的，如果项目周期超长，有可能在项目完成时，已经失去了支撑指标的意义，那这类项目有两种选择：

• 要么精简聚焦，缩短周期到合适的时间短内；

• 要么放弃项目，资源转而投入到其他有价值的项目中。

不过，确实有些需要花很多时间来投入的重点项目，复杂且庞大，这类项目应该单独讨论。而单纯是工作量拼凑的项目，可以拆分为多个小项目依次或同时进行。

一般项目不要超过 8 周，最好控制在 2-4 周内，能够倒逼立项前拆解出精准有效的目标，并且能在小周期内降低项目失败的风险。

立项的工作

关于项目发起基本就以下两种方式：上级指派项目和员工自发项目。

上级指派项目也同样适用于项目制，指派项目后可以有人主动承担项目经理，也可以指定人员担任项目经理。

如果你想考察某个人是否有晋升潜质，可以委派其做项目经理。项目经理需要拥有上下沟通交流、左右支撑协调、内部质量控制、人员激励和安抚等能力，而这些能力都是写代码写不出来的。

回到正题，立项之前必须要回答清楚一些问题，即立项条件检查。这些应该是委员会和项目经理一起完成，立项条件大体应该包括以下几种：

• 项目的意义是什么？

• 指标是否明确量化？

• 项目级别是否设定合理？

• 需要哪些角色，核心关键是什么？

• 项目周期是否合理？

这里不再赘述项目目标，只说意义和价值，单纯提升指标却不符合公司价值观甚至违反规定的，这是不允许的，应深入思考是短期提升还是有长远价值，整体规划是否清晰。

即使是上级指派项目，也应该鼓起勇气提出疑问，不要强行解读项目意义，敢于提出自己的意见，无论是对公司发展还是个人提升都有长远的帮助。题外话，相信这一点有些公司是做不到的，没有提供这样的发言环境，虽宣称开放公平，却还是无人敢言，甚至强调僵化执行，至少这样公司就不要追求创新了，更不要提激发员工战斗力的“理想”了。

资源的分配

资源说是分配，更多时候是需要争取，谁去争取？项目经理。

争取什么样的资源？只要是对项目有利的资源，统统要争取。

资源分为人力资源和非人力资源，人力资源固然重要，但是有些时候非人力资源会收获意外的惊喜。

通过宣讲让大家知道这么个项目，勾搭有兴趣的成员加入，这种方式来的成员一般比较靠谱，但是组建效率不那么高，有些时候还需要去盯人（挖墙脚），一次两次不行，还要三次四次。

还有种方式是直接找老板要人，点兵点将，效率高，但成员相对比较被动，对项目经理激活成员主动性的要求较高，组建的团队账面实力越强，挑战越大，因此除非是非常重要的项目或者你对这个项目具有极大的“自信”，否则不推荐使用这种方式。

在非人力资源方面，项目经理还需要考虑到办公环境的问题。

大多数人都有过吐槽办公环境的经历，比如时常被打断工作去处理一些所谓的紧急事情，或者解答某些傻白问题，再或者是一些鸡零狗碎的确认回复。

因此，争取一个相对独立的，没有么多干扰的环境就显得很重要。另外，会议室安排、平行部门的支持、工作时间转变以及餐饮零食配置等等，这些也是考验项目经理是否具备为项目成员提供高效环境的能力。

一定要有开工动员会，仪式感很重要，应该项目经理主持，必要时或重点项目可以请老板站台打气，动员会内容至少涵盖三个方面：

• 项目宣讲

• 需求评审

• 计划概要

宣讲的目的是再次统一团队目标，不要稀里糊涂的就开干；有老板打气，士气自然是不一样的，但是也不能每个项目老板都去打气，一来老板很忙，二来显得廉价了。

需求评审一定要在打气时及时进行，因为这时士气最受鼓舞，思维最活跃，效率最高；再者，开工动员会如果只是打气，这种虚的东西久了必然会乏味，不如再加些实在的事情。

结果要考核

如果以为按时上线了就万事大吉了？错，项目上线并不代表结束——上线后的效果评估及项目的过程考核，才是结束。

考核可以打分制，打分的公式应按照项目等级、指标达成度、延期情况等各占不同权重进行计算。员工参与项目考核结果可以作为绩效的参考，参与高分项目的数量越多，说明这人抢手，属于潜力股，应该重点关注。

考核的是团队绩效，特别要注意，是团队绩效，奖惩都是针对团队全体而不是个人，若考核得分较低，也许是某成员的过失所致，但在考核得分上，与这位成员无关，应该所有人一起承担。

曾经有一位同事，主动要求做项目经理，结果没多久就开始吐槽团队不给力、需求实现有偏差、上线质量不过关等等。到项目结束复盘时，他把责任全部推给成员，自己一点过失都没有，而从团队成员反馈是需求变更频繁，实际上是边做边改，未掌握团队每个人的工作内容，出了问题找不对人，总是绕一大圈诸如此类。这位项目经理把自己摆到了团队的对立面，而不是团队的一部分，出了事情就是别人的责任，以后这位项目经理的项目再也没有人愿意参与。

如果项目有了好的结果，就一定要奖励，除了经济上的激励之外，还要做出仪式感的奖励，比如全员邮件嘉奖、成就徽章等等，也可以奖励一些有期限的特权，比如带薪假期、在家或远程工作等等。

项目进行到的最后一步是复盘，也是经验分享，好的经验继续保持，坏的经验就是教训，以后避免踩坑。

复盘的方法有很多，这里推荐使用 KISS 方法（Keep、Improve、Start、Stop），白板上画一个十字表格，分别代表 Keep、Improve、Start、Stop，所有成员要发言，做得好的要继续保持，不够好的要改进，没做好的要开始做好，坏的要停止。

复盘不能开成批斗会，就事论事，形成结论，归档到知识系统，以备参考。复盘中事故和过失一定要责任到人，但是公开文档中，责任人的字段要隐藏起来。

风险的控制

这里说的风险控制是委员会对于所有项目的风险评估，这个评估是动态的，随着时间推进、项目内外因素不断变化来综合评估项目是否存在风险，不是单一项目管理过程的风险控制。

委员会必须设定项目终止线，一旦触发，立即终止项目：

• 已经失控并无法挽回的

• 已被证明目标失效的

• 外部突发事件使项目无法继续的

举个例子，人心涣散，项目进度严重滞后，即使最终能上线也无法达到既定目标，这样的项目换人换帅、延长期限都没用，不如趁早停止，及时复盘总结，回收资源，转到其他项目。

项目立项之初，目标应该是明确的，但是在项目进行时，目标失效，这种情况极少发生，一年出现两次，说明公司目标还没有确定，处于不稳定的探索期，这样的公司要慎重。

外部突发事件的可能性就大的多了，比如平台玩法规则改变、政策改变、合作中断等等，目标没有失效，路径要求转换，这类项目要么终止，要么寻找突破。

内部斗争，不是不存在，各自为项目负责，争取一切资源时，不可避免地会出现冲突，这类冲突处理不恰当时就会产生人与人之间的斗争。这时，委员会的居间协调就显得相当重要，项目级别是可靠的规则，切不可只为息事宁人而和稀泥，这样会让事情越来越糟糕。

以上的内容是我这些年从实战经验中得到的心得体会，大家可以“开箱即用”，也可以按照实际情况改造后使用。总之，项目可以多头并进，大家愿意积极参与，资源能得到充分利用，成果可以不断产出，就是最好的结果。

作者介绍

张超，美篇首席架构师、机锋网联合创始人、TGO鲲鹏会会员，主要负责美篇的技术架构设计及技术团队管理工作。

TGO鲲鹏会，是极客邦科技旗下高端技术人聚集和交流的组织，旨在组建全球最具影响力的科技领导者社交网络，线上线下相结合，为会员提供专享服务。目前，TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名，60% 为 CTO、技术 VP、技术合伙人。

会员覆盖了 BATJ 等互联网巨头公司技术领导者，同时，阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀，成为 TGO 鲲鹏会荣誉导师。