读书笔记——漫画中国式项目管理

引子

1. 项目经理必须学会从“业务”的角度去思考问题，而不是技术实现
2. 对项目管理来说，所谓的成功追求的不是100分，是可以复制的80分
3. 有问题：先搞清楚出了什么事，为什么会出事，有什么样的影响，你打算怎么做，你的计划是什么，你正在做什么，你需要什么资源，当然最重要的是，你希望他出面帮你做什么。

项目需求篇

需求分析是“业务导向”的

项目经理一般都有很好的技术背景，但项目经理不是总工，不是架构师，不是程序员，而应该是一个“业务层面的管理者”。项目需求的切入点必须在业务层面。

请问，我们为什么要建立这样一个办公管理系统？
我们当前遇到的主要业务问题是什么？
您最希望通过这一系统解决哪些业务问题？

老板说的话一定靠谱吗

论证项目的可行性，把老板（客户）的想法落地，是项目经理的首要任务。

老板（或者你的客户）告诉你的，有的时候只是一个想法、一个思路。并不是说老板没有你聪明，而是看问题的角度和你不同。你需要帮助老板（或客户）去论证这种想法的可行性。
如何做：和所有人沟通，形成自己的思路与想法。将老板的想法当做需求。

需求是需要确认的

总之，不管用什么办法，在项目开始之前，主要的项目相关方（Sponsor）要对目标、需求达成一致。

我们真正想要的也许并不是他的签字，而是逼他认真考虑项目问题。很多时候你不逼他，老板是不会认真替你考虑问题的，最终的责任还是在你。

谁是真正的Sponsor

多数情况下，需求并不来自技术部门，而是来自业务部门。作为项目经理，一定要能够把自己提升到业务的高度，有能力和业务层面的人直接进行沟通对话。

沟通需求，针对的必须是项目的Sponsor，即使是间接的，你也必须要能够和这些人对上话。

需求阶段的争吵和争论

真正错误的做法是，你知道客户有这种需要，但并没有加以明确，而是把这个需求“虚”在那里。也许客户并没有强烈要求把这一点写在合同里，但在项目开始的时候对这一点并没有达成一致。

有时候谈清楚是技术，不谈清楚是艺术。

关于合同的“敞口协议”

项目合同中一定不能存在所谓的“敞口协议”，也就是无法量化进行验收的条款。

需求必须是量化的、可操作性的。比如“该系统应保证200人同时上线操作”
典型的“敞口条款”有：客户满意、快速响应、稳定运行、有效控制…

表面原因与深层次原因

在需求过程中，你需要的是耐心，技巧和深层次的沟通，搞清楚客户的真是想法。一定不要试图从技术层面上去“说服”对方，也许问题本身并不是技术层面的。

需求过程中最重要的是沟通技巧，是引导和聆听，阐述自己的观点只能是辅助性的。

项目计划篇

项目的渐进明细

在项目开始的时候，要舍得花时间进行论证和规划，要不厌其烦地和所有相关方沟通，要顶得住压力把模糊的问题谈清楚。

里程碑点比验收节点更重要

验收节点带来的压力，属于“硬性”压力，没有回旋的空间，而“里程碑节点”有时是“软性”的，不属于“燃眉之急”。但是忽视项目的里程碑，则是一个将压力积累，将风险坐做实的过程。
“里程碑达到率”是项目经理绩效考核的一个重要依据。

项目规划应该是非常现实的

项目的计划是非常“现实”的过程，不要用“理想”的假设来骗自己。
当所有人都在逼你尽快启动的时候，你要顶住压力，和大量的人沟通…
当别人没有想到你要能想到，当别人认为无所谓，你要非常重视。

项目计划中的资源冲突

完全避免冲突是不现实的，但如果你能提前发现问题，总是有办法可想的。如果事到临头才知道，就只有看你的运气了。

关键的两点

1. 项目计划阶段，将资源“正式”落实到人（这有时是一件招人烦的事）
2. 提前预见到可能的资源冲突。（如闲聊）

资源是要去争取的

一个好的项目经理，有时候会显得很“强势”，因为你始终在争取资源。当然“强势”不代表“强硬”要学会掌握好方法与火候。

你要让项目团队中的人都看到，你是在为大家努力争取资源的，否则你会一点点丧失威信。
要学会和掌握资源的人打交道，不只是在你需要资源的时候，而是和他们始终保持良好的沟通。

你认为正确，还是大家认为正确

绝对共识是不可能的，但在项目的计划阶段࿰