优秀的项目管理与糟糕的项目管理

软件工程里面很重要的一环就是项目管理。理想状态下的项目管理可以参见各种教科书，然而在真实工程中永远无法达到教科书中的理想环境，因为管理的核心是人，所以照本宣科谈管理都是纸上谈兵。下面就从项目管理实施的每个环节上入手，描述一下我在从业过程中遇到的优秀与糟糕的项目管理场景。

首先从需求管理谈起。

我想每一个软件从业者都见过以下这张图：

这是教科书里面的图，以前我每次对学生们讲，学生们都不以为然，对内部员工讲，员工更是早已麻木（员工内心ps：“老子上学的时候就见过这张图，你还讲个毛线！”）。然而几乎所有失败的项目都是因为-----需求失控！

需求失控有两种可能：1：对用户需求完成理解错误。 2：用户想要整个世界，但需求人员无法引导用户。

需求是软件企业与外部客户之间的交流，如果这一关做不好，后续就等着扯皮吧：需求人员一肚子火（我明明很累，我做了很多，该交流的都交流的，是客户没说明白，是开发没听明白）；开发人员一肚子火（领导直接开骂，明明不是我的原因，我加班加点做了很多东西，到最后告诉我需求变了？）；客户一肚子火（什么玩意，什么公司，都是坑我钱）。更可怕的是责任说不清是谁的，相互扯皮，永远没完没了，所有的能量全部消耗到了扯皮中，每个人都苦不堪言。

需求管理的方式有很多，教科书式的理想案例不表，贴一个优秀的图：

axure 原型图：

生成的html静态页面

与用户确认的需求

需求做到了这种程度，项目想要烂都难！这是优秀的需求管理。

与之相对的极端糟糕的需求管理就是没有用户交流，关起门来自己做，闭门造车，这种情况下想要得到认可简直是天方夜谭。一般决策领导层把所有的精力放到了商务运作或者自认为简单没有与用户确认需求，就会导致需求混乱。

第二个要来看的是项目规划：

项目规划是很有意思的一个环节，有的公司压根没有规划，走哪算哪；有的公司老马识途，胸有成竹；有的公司东施效颦，规划了各个节点各个里程碑，结果根本执行不下去，无疾而终。

第一种走哪算哪的公司一般属于初创型公司，成本制约、公司还没有形成经验知识库。

第二种老马识途的公司早已专业化、流程化、制度化。

第三种处在第一种与第二种之间，是极其纠结的一类，也是最常见的一类。造成无法执行计划的原因很重要的一条就是：没有考虑技术因素、人员因素、客户因素的情况下使用了理想状态下的配置对项目进行了规划，更有甚者一拍脑袋：就这么定！并且这么安慰自己：“现在先公布执行下去，到时候执行不下去在改动，不会有没有完美的计划”。可知狼来了喊多了，大家也就麻木懈怠了，也就么人拿规划当正儿八经的事了。

07年我开始做的第一个项目“****CRM系统”，100多个开发人员，project画的满天飞，只用了不到2个月project就彻底废弃了，对客户一套进度汇报，对内一套真实进度。后来项目经理切入到了每天的开发、每天工作量后才好转。

显然假大空的项目规划，只能感动自己的项目规划没有任何意义，项目规划执行落地才是规划的真正目的，说道落地就要说第三个具体的开发流程监控了。

三：任务开发跟踪监控。

项目的管理的主要内容是成本、进度、质量。抛开三者谈项目管理都是耍流氓。

糟糕的项目监控大体有三类：1：“老油条”型；2：劳模领导型；3：把自己当“领导”型。

“老油条”型的项目监控人找各种理由推卸责任，常见的有：开发人员水平不行，要招大牛才行；任务我都分配了，开发人员做不出来怎么办；我都跟开发人员讲清楚了，这有什么办法呢；一般在一个环境中工作久了，个人满足现状，公司如同一潭死水，就会有这样老油条的人。

劳模型是项目监管人负责了几乎能负责的所有工作，而下面的员工却很清闲。一般一线劳模新晋项目监管人的时候喜欢做这样的事，这是把一线的劳模成功经验错误的复制到了管理上。

把自己当领导型的更可怕，认为自己是领导，甚至摆摆官架子，这种情况在软件这个行业中比较少，属于奇葩型。

14年我带了一个比较有特点的项目：我半场加入项目管理，工期特别紧张，而人员都是新手，没有太多经验，需求多变，计划不能落地。经过交流基本得出的结论是：成本不能再继续增加（无法提供更多的人加入，这是我加入项目的先决条件），进度要求在3个月内必须完成，最迟3个月交给客户上线使用。

在这种情况下我做了个艰难的决定：每天监控、协助开发人员完成每天的工作；不编写任何业务代码，全身投入开发管理；对每个人每天的工作及代码进行审查，所有优劣问题暴露给工资体现。

当时还做了一个表格：

计划不能落实->开发人员水平不高->有问题无法解决->交流占用太多时间：那么我来负责解决技术上的疑难杂症。

计划不能落实->客户反复交流->需求多变：具体需求人员联系客户，不怕需求多变，但要求移交给开发的需求必须是确认的、甚至是签字的、有人对此负责的。

计划不能落实->开发过的功能反复出错->程序代码有错误：每人没做完一个功能，立刻审查代码，代码审查不通过的，今夜不下班。

计划不能落实->我完成不了这个功能：每天任务分配让开发人员确认是否能够完成，每天至少监控3-4次，在监控到第二次的时候基本就可以判断能否完成及存在的问题。等等。

管理的工作看似很繁重，其实万事开头难，只要人员有了惯性，管理是一件越来越轻松的事情。

越是工期紧张，越是容易混乱，对混乱的控制、对资源的把控是管理的价值。

最后简单说一下测试管理：

测试管理主要分为：功能性测试、系统性测试。系统性测试又包括了：性能测试、安全测试等。两者都需要有回归测试。

一般项目型软件产品功能性测试是重中之重，直接关系到用户使用。性能与安全测试由于目前大部分软件架构都比较成熟，相比较功能测试来讲并不是重点，有很多企业把性能测试与安全测试外包给各个质保中心进行测试并出具项目测试报告，当然如果项目特殊，对性能与安全提出了很高的要求，这个要求到了另一个维度，这自然要另当别论。

功能性测试一般与需求密不可分，想象一下一个不了解需求的人去做测试，他测什么？

测试管理的工具有很多，开源的也很多，最早我用的TestDirector，目前国产的开源工具也有很多，不在赘述。

写着写着没想到已经很晚了，最后的最后做个简单总结。

一个成功的项目背后必然是一个优秀的项目管理支撑，必然是依据其个性化的环境量身打造，换一个环境未必能够照搬，但只要想着避免失败的关键坑点，落实到具体细节上，那么总有一天能够拨乱反正，回归正轨。

冰冻三尺非一日之寒，立竿见影的效果我们很难做到，但是坑再多，只要有恒心，总能填满。

真正正确的事可能会迟到，但永远不会缺席。