今天的组织需要的是由一群平凡的人,做出不平凡的事。
Today's organization is needed by a group of ordinary people,to make extraordinary things。
——彼得·德鲁克(Peter Drucker)
做过项目管理的人,都肯定有所体会,这里面充满了坑点。
你以为会按时间顺利完成,但往往充满波折,甚至最后实现的东西,可能和你最初的设想千差万别。
比如:
项目准备得很充分,但是到最后却没有资源执行落地
评审完后,开发估计的工时太久或者太短,和真实情况差别巨大
你的方案考虑很周全,但是开发做出来和你想的很不一样
项目开发过程中,遇到方案修改、人员变动、突发事故,导致协作不畅,项目延期
你辛辛苦苦做出来的东西,业务方感觉不满意,弃之不用
....
项目落地,就是一次冒险之旅,任何地方都有可能出错。
绝对的完美实现不存在,我们在做项目之前,就需要有足够的预期。对可能遇到的问题,做足够的心理准备。
项目不顺利时,很多人都喜欢抱怨,甩锅给领导,甩锅给开发,甚至甩锅给项目本身。
但其实,项目组员都是普通人,我们也不应该期待别人有超人的能力。
比起责怪外界,倒不如做好自己可控的部分,让项目进展更可控、更顺利一些。
下面具体说说上述几个坑点的应对方法:
1、统一目标,调动积极性
做项目,最重要的就是让大家认可项目目标,觉得有奔头,这个时候大家才会全力以赴。
如果项目意义不大,或者大家一开始就不重视项目,甚至有反感情绪,那么项目再如何管理,都难以保质保量。
所以,作为项目负责人,通常在项目启动前,会拉一个立项会,就是在告诉大家,这件事情很重要,我们要认真开干了。
甚至还需要提供很多真实的调研信息、用户反馈、数据结论,来增加说服力。
此外,在企业内部,很多项目都是自上而下推进的,这个时候,由于领导的关注与介入,会使得项目具备额外的价值。
所以,如果能够在项目开始前,取得重要领导的认可,那么推进会顺利得多。
相反,如果领导不认可,那么推进会处处受阻。
举个例子,曾经搜狗王小川想做浏览器,领导张朝阳不认可,甚至还收回了王小川的管理权限,差点让这个项目胎死腹中。
好在王小川自己非常坚持,拉了一两个小伙伴,加班加点把东西做了出来,然后客观事实让张朝阳看到了机会,于是才重新授权推进浏览器项目。
人类都是追求意义的动物,有明确一致的目标,才能让大家力往一处使。
如果大家没有激情,不妨先耐下性子,做做目标统一的思想工作。
2、评审要沟通清楚
大部分的需求评审,产品都是自说自话,把内容一带而过的讲完,并不考虑开发同学是否真的听明白了。
但其实需求评审的核心目标,是让开发知道该做什么,标准是什么。
如果他们没听明白,就相当于白费功夫了,事后要花大量的时间来补。
所以一定要站到对方的角度,把需求的背景、目标、每个环节的重点注意事项都强调清楚,避免含混不清。
此外,还得积极回答各方提出的疑问,甚至主动引导对方提问,比如询问对应的开发,这块是否有不明确的地方。
会议还得有明确的结论和待办事项,比如多端合作接口的分工、争议功能的处理结论、会后确定排期的时间等等。
做到了这些,才算一次合格的需求评审,否则就仅仅是走了个过场。
3、拆分任务再评估
做项目的朋友,经常可能会有这样的疑问,明明感觉很简单的功能,开发给我排了2、3周的工作量,对方是不是在忽悠我?
在面对自己不熟悉的内容时,作为外行的产品经理当然没法准确预估工时。甚至有的时候,一些开发自己预估的时间都不准确。
这个时候,项目管理人除了讨价还价外,还有什么办法呢?
项目管理里有个WBS(工作分解结构)过程,可以帮我们把大的项目任务,拆分成小的、易于管理的模块。一般而言,任务的颗粒度细到3人日左右。
这个时候,由于任务拆分得足够细,因此开发评估起来会更加准确。
而且这个WBS需要发送给项目组留存,其他人也会看到,所以开发估时太久也会不合适。
此外,在项目进行的过程中,还需要回顾对比,因此忽悠排期的成本变得很高。
4、敢于去拍deadline
项目无限延期的一个重要原因,就是没有deadline。
正所谓deadline是第一生产力,有了压力,才有急迫感。
对于项目负责人来说,与其费尽心思,去督促下游执行者的各项过程,还不如直接拍一个deadline。
当然,自己臆想出来的deadline肯定没有意义,这个deadline一定要取得项目干系人的认可,并且是有可能实现的。
比如可以获得开发leader、项目领导认可,之后把这个时间公布给其他执行同事,这个时间就开始具备了真实效力。
善于使用这个方法,才能高效产出。否则很容易陷入无穷无尽的被动等待中。
5、定期review,及时反馈
项目管理非常重要的一个环节,就是定期review。
在项目中,问题一定会发生,与其期待项目完美执行,不如及时做出应对。
相反,如果不管不顾,让问题积少成多,事情就会变得非常难解,容易出现大规模的延期。
定期review,能让我们及时发现问题,比如项目延期、方案理解有误、实现方式调整等等。
因为足够及时,足够高频,所以无论是修改方案还是加班赶工,都很容易解决问题。
对于一些紧急项目,我们会每天开站会,就是在及时review。
review会上,我们一般会过一下上一天的任务、问题处理情况,有没有遇到什么新问题,需要什么样的帮助。
如果需要资源帮助,会快速对接解决。
把延期的风险处理,分解到每一天后,项目整体就会非常顺利了。
6、方案变更,要周知各方
项目变更是个经常发生的事情。比如技术方案调整、产品需求调整、人员调整等等。
变更不可怕,可怕的是变更后大家不知道,还按照原来的方式做。
因为信息不同步,所以大家做的东西就不兼容,容易出问题。
必要的做法,是在变更后清楚的告知各方,让他们明白的知道哪些东西变了。
重大的变化,还需要专门拉会同步。
此外,我们还要做好备忘记录,避免将来交接,或者查询历史文档的时候,出现误解。
写在最后:
墨菲定律告诉我们,凡事能出错的,都会出错。
从概率的角度说,这个定律并不正确。但是从项目管理的角度来说,墨菲定律非常具有指导性。
在项目管理中,我们不要期待完美实现的奇迹,不要过分相信执行者的完美表现。相反,要时刻做好最坏准备,应对突发情况,应对问题,应对延期。
用机制和流程,去管控项目进度,提前规避风险。
这样你才能有信心,说这个项目会圆满成功。
本文来自微信公众号“子勋说”(ID:gh_4b56b51f0b02),作者 子勋说。
管理圈经授权发布,如需转载请联系原作者。