一、前言

今天重做了一遍项目的计划。
因为在我上周三离开项目组的时候，跟他们说要创建一个详细的项目计划，但是到今天我还没看到，于是手贱地自己上手做了个草稿。说明我想的项目计划是个什么样子，最后终于跟他们说明白了。

二、项目计划

由于整体项目计划过于宏大和细节，所以就截个片段做示例。

这个计划是一个草稿。是用来发给别人我想做的计划是要到什么程度的。

在我看来计划的作用是这样的：

1. 管理团队外事件的进度；（即是团队任务的依赖条件和前提条件）
2. 管理团队内事件的进度；（即是团队任务本身的进度）
3. 管理上层领导事件的进度和预期；（上层领导事件包括人员协调、资源协调之类的；上层领导的预期是指项目成员的产出，以及最终的结果报告）
4. 管理风险和资源；

性能实施的项目中，有的领导不太看计划（不是计划没有，而是不看计划），就是事情一件件往下推。事件到了眼前发现风险了就解决风险，这种管理的方式导致的结果就是：不停地在救火！
举例来说，在我的一个项目中，经常出现团队间用准生产环境冲突的问题。给性能的时间都是晚上。并且都被切分成了一天两天的，其他时间给其他团队用。但是性能的准备就需要时间，需要的还很长。一天可能环境都没准备好。下一次再轮到性能团队使用的时候，又要重新准备一遍。这就是很二的计划，屡次升级也没有用，因为其他团队的工作也是重要的嘛。在这种情况下，只能降低各个层面对性能结果的预期。如果这时候还有领导想要一个专业的结果，那这个领导就可以完全无视了。

三、管理团队间的事件

今天我跟团队成员聊天的时候，我是让他做计划的，他说：现在这进度根本没法保证，做计划有什么用呢？我跟他说明了计划的作用，就是上面的那几个。
性能实施项目和其他团队的沟通属于比较多的。有很多任务的依赖条件是其他团队，而在性能团队职责定义中，其他团队却大多数是支持的角色。这就导致了，有些其他团队成员认为这个事情不是他们的事，而是多出来的事。
所以性能实施计划中的依赖条件就必须在开大会的时候喊出来，并且要在后续的风险跟踪中不断地加强，也让各层领导明白性能要想达到好的效果，必须得到什么样的支持。

四、管理团队内的事件

对于像现在这样的一个大多数是新手组成的团队来说，团队内的事件进度受人员能力的影响太大。很多细节的问题会导致进度拖延。所以一定要显式地管理团队内的任务进度。
当发现团队内的进度因为人员能力不足，或技术原因等导致的进度延迟，得想办法找到解决的办法。像培训、师傅带徒弟、引入高级技术人员等，都是必须要考虑的。
我们现在的项目进度就明显受到了新手能力的影响导致进度变慢。我现在面对的问题就是要解决新手能力不足的问题，一方面推进领导来解决人的问题，一方面想办法解决团队内的技术不足的问题。

五、管理上层领导事件的进度和预期

人员问题就必须找各层领导解决。如果领导给不了支持，就要把项目风险事先声明。管理中不应该有惊喜的部分，一定是不停地铺垫，要预判到风险就开始铺垫。
同时也让领导们做好最坏的打算。项目延期导致的费用增加，甚至是项目的失败。
千万不要自己hold住问题。我们几千年的官本位思想又那么严重。有好多人在问题面前愿意自己埋头苦干，而不愿意找领导要资源。问题是结果也不见得会是好的。
一定要记得的是，不管是谁，只要是对你的职责范围内的事情有帮助的，就都是你的资源。推动这些资源解决你的问题，那你就是合格的PM。
不要担心会和领导吵架，有些架是必须要吵的。拍桌子瞪眼睛谁都会，关键的时候该瞪就瞪。大家都是文明人，不打起来就行了。

六、管理风险和资源

看好你的资源，管好你的风险。千万不要无视风险，不然风险也会加倍偿还于你。比如说，我最近面对的一个问题。有一个其他团队的小伙是给我配置监控平台的，我看他很努力干活了，但是由于他被压的事情过多导致承诺给我的权限拖了四五天都没给我。
这就是风险，于是上次在和各负责人开会的时候，我就提了这个风险。我说如果你们解决不了，我就把计划延期。这种广播的沟通方式来施压在有些时候是非常有效的。也就是提高我的事情在对方的任务中的优先级。

另外，管理是很考验个人的魅力的。对一些小肚鸡肠的管理者，怎么做也不能得到团队的认可。所以我推荐光明磊落的管理方式。也就是说把问题摆到桌面上，不要觉得不好意思。Put everything on table.

今天先絮叨到这里。