IT项目管理就那么几招：开场

前言

如何管理好一个项目，或者说如何管理好一个IT项目，是一个值得好好掰扯掰扯的话题。但是呢，关于这个话题已经有了很多的资料来说了，不管是一些应试的资料，比如PMP考试，国家的软考等等；或者说是各大企业中的管理办法，比如现在比较流行的华为项目管理办法等；还有各位管理大师写的一些书籍，比如德鲁克的管理哲学相关的书籍，这些资料都对项目管理，甚至是管理本身做了足够深入和足够广度的讨论。
而我想写的是试图从另一个角度出发，从一个程序员的角度来看一看和讲一讲项目管理的事情。毕竟作为一个大龄的IT从业人员，如果不想35岁了就去送外卖，还是得考虑下转型的问题。
当然，作为一个新入行或者入行不久的程序员，我也还是建议你想一想和了解一下项目管理的事情，毕竟，不是每个人都可以一个人开发出一套足够牛逼的系统来实现财务自由的。我们还是需要和团队合作来完成一个一个的项目来实现自己的小目标，自己理解了项目管理的一些东西之后，不管自己是不是会转型做项目经理，最起码可以更好的理解你自己手头的事情，况且万一哪天要转型就能用得上呢。
在这一篇中，先提出一些对项目管理中的典型场景作为开场。让大家对项目管理先有个感性的认识和引起一些共鸣。然后在后续的文章中将项目管理的每个环节拆开来说一说，来讨论一下这些场景中的的可能解决方案。

各种项目过程场景

场景1: 项目延期

一个项目眼瞅着不能按计划完成了，怎么办？很多人就会选择一个最简单粗暴的方式：增加人手。但是这个方式往往不能起到任何的作用，反而可能会进一步的延迟计划。这是为什么呢？因为项目管理着忽略了一个原则：
软件项目开发是一个智力要求很高，创造性要求也很高的事情。大部分的时间其实不是在开发代码上，而是在相互沟通并让彼此达成共识上。只有达成共识并以约定好的方式方法进行开发，才能让多人团队协同好。
而增加不熟悉项目情况的人手，必须花费核心成员大量的时间去和新增人员沟通，并让这些人员充分理解项目的目标，设计理念和代码逻辑。否则新增加的代码很有可能会破坏以后的结构。从而让核心人员花更多的时间去填坑，从而陷入一个恶性循环中，最终导致项目严重延期。
那么项目要延期了，有什么更好的办法？

场景2: 需求打架

计划是越快越激进越好么？每个程序员都会碰见过这样一个场景：项目上线后有一些问题，需要安排补丁修复。因为是商用系统，只会有固定的时间窗来升级补丁，于是产品经理和项目经理们和抢春运火车票一样都去抢着把手里的需求尽可能多的塞进这个补丁中，导致每个补丁版本都塞了一大堆的需求进去，远远超出一个补丁范围的工作量承载能力，导致研发测试不停的加班，最后大概率的还会导致补丁发布失败。
时间只有那么多，怎么安排？很多情况下就是谁的嗓门大听谁的，谁的官大听谁的。

场景3: 救火队员 vs 保安队长

在公司中，经常可以看到这种现象：半夜里，线上系统出了问题了，一堆人急的团团转，突然一个人跳了出来找到了问题所在并解决了问题，整个团队皆大欢喜，这个人称为了拯救团队的英雄。
但是，想象一下你的团队维护了几十套或者上百套的线上系统；或者说你的团队同时在进行几个项目的开发。每套系统或者每个项目都出现这样的情况的话，这个救世英雄就成了到处灭火的救火队员。不仅这个人本身会疲惫不堪，这样的团队和项目结构也是非常脆弱的。
而我认为项目过程中要尽量减少这种救世主的出现，而是需要一个类似保安队长的角色，时时刻刻守住项目大门，不让项目或者系统出现问题或者是提前发现问题。
值得深思的事是往往救世主或者救火队长的角色更容易引起关注从而得到更好的收益。而默默解决问题的保安队长往往都会沉默在大多数人中。
这里借用一个非常有名的故事：
魏文王问扁鹊曰：「子昆弟三人其孰最善为医？」扁鹊曰：「长兄最善，中兄次之，扁鹊最为下。」魏文侯曰：「可得闻邪？」扁鹊曰：「长兄於病视神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於闾。若扁鹊者，鑱血脉，投毒药，副肌肤，闲而名出闻於诸侯。」

场景4: 需求变更

先祭出一张图：

你作为一个程序员，从项目经理或者产品经理处领导了需求，也搞明白了需求，回到自己工位上，打开IDE工具，擦擦手掌，开始码代码。半天之后，正码的开心呢，产品经理或者项目经理召集一个会议：咱们的需求变了，我们来论证下可能性和工期，有没有想一板砖拍过去的想法？为什么不早说！？
换个人重演下这个场景：产品经理或者项目经理刚整理完需求，原型图和工作计划整理完毕，和码农们也沟通完成。美滋滋的靠在工位上，想着后续只要跟踪进度就好。一个电话过来：客户想法变了。赶紧出方案和调整计划。你是不是有WTF脱口而出的冲动？
咱再换一个人重演一下，我是牛逼哄哄的甲方爸爸。乙方的产品经理和我说好了系统的样子的操作。感觉挺美的，东西出来之后发现，怎么感觉和我想象中的大不一样啊，那不行，这帮乙方忽悠我，不行，得赶紧让他们改！
你处于哪个位置？是不是感觉哪个位置都不爽？为什么会出现这种情况？

场景5: 他怎么不知道？

项目发生变更了，作为程序员的你收到了变更需求。吭哧吭哧的改完需求，代码一把commit到代码库。结果下一次代码构建的时候发现若干出编译错误，更可怕的是编译没问题。上到线上之后发现各种报错。仔细一定位，发现是你的上游模块或者下游模块没有同步修改。你气冲冲的冲过去质问他为啥不改，他一脸懵逼的看着你，表示他根本不知道这个变更。
你接着去找产品经理或者项目经理，项目经理表示，我哪知道你们的模块是怎么分的，哪个函数是哪个程序员负责的。难道你们自己不内部沟通么？
那我们怎么能保证所有的变更能精准迅速的同步到需要知道的人呢？

场景6: 需求变形

贴上一张经典的图：

这个不需要多说，常常都是现场客户的需求到最终交付出去的东西大相径庭。
这样的返工就会浪费大量的人力物力，导致项目延期。

下一步

上面提到的场景还会有很多很多，但是上面提到的应该是所有的程序员百分百经历过的事情。那么这些问题怎么解决呢？个人觉得，学好项目管理的基本理念和一些基本工具，可能是一个较为靠谱的解放方案。
但是我想讲的和写的不是照搬项目管理的那一套教材的理论，而是想试着从解决上述问题的角度来讲一讲，项目管理的基本理念和使用办法。
希望自己能完成这项有挑战性的工作。