写点什么

公司大了,人多事杂,如何落地项目制?

用户头像
树上
关注
发布于: 2020 年 04 月 24 日

写在前面,不少朋友来咨询公司实行项目制,落地不顺畅,问题多多,怎么考核?什么时候应该项目终止?干脆写篇文章供大家参考吧。


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


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


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


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


这里,就我的经验和教训,跟大家分享几个关键:


成立项目委员会

后面写到的所有工作老板都能做,甚至需要老板来拍板,但是这些工作不能统统都甩给老板,老板会被累死的;


项目委员就是把老板解放出来的虚拟组织,对项目立项和终止有充分的决定权,对项目执行过程有监督权。


委员应该包括产品、研发、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,所有成员要发言,做得好的要继续保持,不够好的要改进,没做好的要开始做好,坏的要停止。


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


风险的控制

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


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

  • 已经失控并无法挽回的

  • 已被证明目标失效的

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


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


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


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


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


以上是这些年实践的一些心得体会,大家可以开箱即用,也可以改造适合实际情况,总之,项目可以多头并进,大家愿意积极参与,资源能充分利用,成果可以不断产出,就是好的结果。


发布于: 2020 年 04 月 24 日阅读数: 166
用户头像

树上

关注

文字简单,却有干货 2018.04.08 加入

青年程序员,前美篇首席架构师、机锋网联合创始人。

评论

发布
暂无评论
公司大了,人多事杂,如何落地项目制?