引子
- 项目经理必须学会从“业务”的角度去思考问题,而不是技术实现
- 对项目管理来说,所谓的成功追求的不是100分,是可以复制的80分
- 有问题:先搞清楚出了什么事,为什么会出事,有什么样的影响,你打算怎么做,你的计划是什么,你正在做什么,你需要什么资源,当然最重要的是,你希望他出面帮你做什么。
项目需求篇
需求分析是“业务导向”的
项目经理一般都有很好的技术背景,但项目经理不是总工,不是架构师,不是程序员,而应该是一个“业务层面的管理者”。项目需求的切入点必须在业务层面。
请问,我们为什么要建立这样一个办公管理系统?
我们当前遇到的主要业务问题是什么?
您最希望通过这一系统解决哪些业务问题?
老板说的话一定靠谱吗
论证项目的可行性,把老板(客户)的想法落地,是项目经理的首要任务。
老板(或者你的客户)告诉你的,有的时候只是一个想法、一个思路。并不是说老板没有你聪明,而是看问题的角度和你不同。你需要帮助老板(或客户)去论证这种想法的可行性。
如何做:和所有人沟通,形成自己的思路与想法。将老板的想法当做需求。
需求是需要确认的
总之,不管用什么办法,在项目开始之前,主要的项目相关方(Sponsor)要对目标、需求达成一致。
我们真正想要的也许并不是他的签字,而是逼他认真考虑项目问题。很多时候你不逼他,老板是不会认真替你考虑问题的,最终的责任还是在你。
谁是真正的Sponsor
多数情况下,需求并不来自技术部门,而是来自业务部门。作为项目经理,一定要能够把自己提升到业务的高度,有能力和业务层面的人直接进行沟通对话。
沟通需求,针对的必须是项目的Sponsor,即使是间接的,你也必须要能够和这些人对上话。
需求阶段的争吵和争论
真正错误的做法是,你知道客户有这种需要,但并没有加以明确,而是把这个需求“虚”在那里。也许客户并没有强烈要求把这一点写在合同里,但在项目开始的时候对这一点并没有达成一致。
有时候谈清楚是技术,不谈清楚是艺术。
关于合同的“敞口协议”
项目合同中一定不能存在所谓的“敞口协议”,也就是无法量化进行验收的条款。
需求必须是量化的、可操作性的。比如“该系统应保证200人同时上线操作”
典型的“敞口条款”有:客户满意、快速响应、稳定运行、有效控制…
表面原因与深层次原因
在需求过程中,你需要的是耐心,技巧和深层次的沟通,搞清楚客户的真是想法。一定不要试图从技术层面上去“说服”对方,也许问题本身并不是技术层面的。
需求过程中最重要的是沟通技巧,是引导和聆听,阐述自己的观点只能是辅助性的。
项目计划篇
项目的渐进明细
在项目开始的时候,要舍得花时间进行论证和规划,要不厌其烦地和所有相关方沟通,要顶得住压力把模糊的问题谈清楚。
里程碑点比验收节点更重要
验收节点带来的压力,属于“硬性”压力,没有回旋的空间,而“里程碑节点”有时是“软性”的,不属于“燃眉之急”。但是忽视项目的里程碑,则是一个将压力积累,将风险坐做实的过程。
“里程碑达到率”是项目经理绩效考核的一个重要依据。
项目规划应该是非常现实的
项目的计划是非常“现实”的过程,不要用“理想”的假设来骗自己。
当所有人都在逼你尽快启动的时候,你要顶住压力,和大量的人沟通…
当别人没有想到你要能想到,当别人认为无所谓,你要非常重视。
项目计划中的资源冲突
完全避免冲突是不现实的,但如果你能提前发现问题,总是有办法可想的。如果事到临头才知道,就只有看你的运气了。
关键的两点
- 项目计划阶段,将资源“正式”落实到人(这有时是一件招人烦的事)
- 提前预见到可能的资源冲突。(如闲聊)
资源是要去争取的
一个好的项目经理,有时候会显得很“强势”,因为你始终在争取资源。当然“强势”不代表“强硬”要学会掌握好方法与火候。
你要让项目团队中的人都看到,你是在为大家努力争取资源的,否则你会一点点丧失威信。
要学会和掌握资源的人打交道,不只是在你需要资源的时候,而是和他们始终保持良好的沟通。
你认为正确,还是大家认为正确
绝对共识是不可能的,但在项目的计划阶段