张传波（网名：Fireball，大大大火球）

计划赶不上变化，计划还要不要写呢？项目工期限死，估算有什么价值呢？只有项目经理紧张项目，其他人是打工心态，怎样办呢？PMP的知识能搭救项目吗？如何才能做出一个按期交付的完美计划呢？所有问题，将在这一篇中大爆发！

安装部署系统、培训客户使用系统、推动系统上线等工作就是实施工作。实施工作的重要性有点象足球比赛的“临门一脚”，前面所有工作都做好了，如果临门一脚特别臭，前面的工作都会付诸一炬。实际上实施工作需要从项目一开始就要进行，并且对实施工程师的要求很高，除了技术要求，还有业务以及商务上的技能要求！

直到最后几天，测试工程师们才能见到软件的“庐山真面目”，但是不见不知道一见吓一跳，软件的问题巨多，甚至很多功能没有实现，然则距离“项目死期”（交付日）已经没有几天了！难道测试仅仅是项目后期的事情？曾经何时作为程序员的我是看不起测试的，不少程序员也不屑于去做测试这个职位，难道测试工程师真的比程序员低人一等？

有一句古语“少壮不努力，老大做IT”，做IT确实挺悲剧的，但最悲剧的是做码农（程序员）！烂代码直接产出来软件，而烂代码是怎样产生的呢？是烂程序员吗？大部分程序员是追求进步和高质量代码的，往往是烂的管理方式、无节操的项目工期而导致程序员不知所措、疲于奔命、为赶工而写代码。当加班成常态，你还跟我谈什么代码质量呢！程序员们是可爱的群体，编码是高难度高技术含量的活，希望我们的编码工作能变成富有激情和战斗力的工作吧！

六西格玛被网络炒作得太厉害了，我一直没有能找到一篇能通俗说明六西格玛基本原理的文章。我们公司通过了CMMI5级了，但我还不时会遇到推销六西格玛培训的事情，这些推销者可能不知道要过CMMI4级，不精通六西格玛是不行的。

软件开发人员加班是家常便饭的事情，曾听说了一个朋友近一个月连续加班，日夜颠倒，没有周末，过着“暗无天日”的生活。我曾经问过另一个朋友他所在公司如何控制项目的进度成本的，他们公司非常“黑”，每隔一段时间公布一次加班龙虎榜，看谁加班最少，搞到他们不好意思不加班。通过不断的加班来保证进度了，通过加班不给加班费来控制成本，软件开发变成了“人间煎熬”。如何才能有效地度量项目的进度与成本呢？如何少加班最好不加班，就能按期并在预算内完成项目呢？

我们为什么要进行软件规模度量呢？目的无非是：1. 作为报价或者决策的依据。2. 安排具体的项目进度。3. 可以作为组织的生产力数据，可以有很多用途，如：各项目间横向比较，供以后项目参考等。基于不同的目标，我会为大家分享不同的实用度量方法。

公司的效益指标的度量是任何公司都可以做的，而且应该是第一时间就要做的度量，并且要持续地做的。公司所做的任何工作，市场活动、过程改进工作、度量工作等等，最终目的还是为了提高效益指数！而度量公司的效益指标，其实一点都不难！大多数软件公司都会有一套管理缺陷的系统，我们应该如何把缺陷度量做得更好呢？我们需要目标驱动地把度量工作做好，首先有两个最基本的要求：1.缺陷被准确的记录和跟踪。2.客观地依据缺陷状况对软件发布进行决策。

这年头IT界流行“用数据管理过程”、“用数字说话”，软件度量成为热点话题！一方面一堆专家在“哗众取宠”，而另外一方面企业在推行软件度量的实践中遇到了各式各样的问题，软件度量在软件企业中的实施效果不甚理想。一个软件企业应该从何做起度量工作呢？这是本系列文章的第1篇：度量陷阱及什么是度量？如果有人给你一个度量任务，要求你度量水的温度，你会怎样做？你会不会马上想到用温度计？不好意思，如果是这样，你就落入了度量的其中一个陷阱了。你应该先问，为什么要度量水的温度？不同的目的，做法是不一样的。

挣值管理将项目管理工作数字化、可视化，很多第一次学习挣值管理的项目经理会兴奋不已，想马上在实际项目管理中用上，但往往实际效果不甚理想。下面我列举一下常见的情况：项目计划与项目计划跟踪工作没有做好，就没有做挣值管理的基础，这可能是最常见的情况了。很多软件项目，没有文档化的计划，没有详细的进度计划，很多工作通过开会、口头布置等方式落实。项目成功的关键在于项目组的整体能力水平和知识水平，在于工作的条理性和严谨性。你觉得项目管理有问题，其实问题可能不是因为没有应用挣值管理，而是项目组的水平不够，工作没有条理。挣值管

PV、AC、EV这三个概念是理解挣值管理的最基本概念，而CV、SV、CPI、SPI、EAC这些都是最开始那三个概念的衍生。一开始你可能会被这些衍生概念搞晕的，你需要先回头将最基础的三个概念理解好，特别是理解好前文的那个图以及那几个问题。

总结一下第一篇关于搬石头的故事，计划与计划跟踪我们要关注的三大方面：1.计划好每项的任务、任务的先后顺序，期望的任务完成程度。2.实际投入情况，如实际投入了多少时间、花费了多少钱等。3.任务的实际完成情况。上述三方面表示的方法有很多，而从老板的角度，他其实最关注的就是钱，挣值管理的三个指标 PV、AC、EV ，就是以钱为单位，分别以量化的方式表示上述三个方面。

要考PMP（Project Management Professional ），挣值管理是必考的知识。软件项目有很大的特殊性，不少人认为挣值管理不太适用于软件项目。挣值管理相关资料也比较超多，但一般都难以读懂，我将会分4篇文章为大家分享，并且会以轻松、易懂、实用的角度为你讲解，这是第一篇！

MSF的软件生命周期模型与螺旋型很相似，同样也是多版本螺旋前进，只是每次螺旋（每个版本）阶段划分不太一样，而且每次螺旋都会有至少5个大里程碑。实用软件生命周期模型应该有这样的特点：1.需求应当在项目初期至少明确80%以上。2.采用多版本方式逐步满足需求，让已确定需求尽快稳定，并尽快搞清楚未确定的需求。3.需求、设计、编码、测试、实施等工作应一步一脚印做好，文档应及时评审并要及时更新。实用软件生命周期模型并不存在固定的模式，我们需要理解上述各种模型的特点，在实际工作中不断体会项目管理的奥妙，灵活应用上述模型。

螺旋型可以说是综合了以上各种模型优点的一种模型，同时它加入了风险管理的内容。前面提到增量、进化、螺旋的共同特点是多个版本，而每个版本可以认为是一个“小瀑布”，对于每个版本，我们可以认为还是要先完成前一步才能做下一步。而RUP认为项目中的工作可以分成好几类，而每一类工作在整个项目周期都是持续进行的，只是不同工作在项目的不同时期比重不太一样。

进化型和增量型类似的地方就是都是分多个版本发布，但区别就是项目初期无法获取全部的需求，用户对需求其实也没有全面了解，需求获取是一个重复的过程。第一个版本实现的是客户的初步想法，然后后续版本不断地调整。原型就是在客户有初步想法的时候，就“快速设计”和“快速编码”地做出一个可供演示的系统（即原型），用来更好地获取和理解客户的需求。

瀑布型是我们说得最多的模型，也最容易理解，但在实际工作中最不能执行。我们普遍会认为，大型的、严谨程度高的项目应该采用瀑布型，恰恰相反，往往是规模很小的项目才适合这样做。增量型的特点是一次性地获取全部的需求，然后做出分版本实现各需求的计划，每个版本只实现一部分需求，通过多个版本逐步实现全部需求，而每个版本可以认为是一个“小瀑布”。该模型的好处是可以尽快让系统上线，让客户先使用部分功能，尽早实现系统的价值。

软件项目经理往往是权力小而责任重大，软件项目的“两不明确两大限死”特点，让我们做项目犹如走钢丝，而且要高速地走钢丝！你的综合实力决定你能否成为优秀的项目经理，项目经理是练出来的。

计划做出来不是用来看的，而是要执行计划！跟踪计划执行的难度和工作量比起做计划要高出好多倍。计划跟踪并不是对照进度计划，按时间检查每个人的任务完成情况这么简单，本文将为你分享：1.建立便捷的项目组内沟通机制；2.建立项目组成员的自信；3.质量投资，减少返工；4.不断思考减少工作量的办法；5.密切留意需要客户和第三方完成的工作。

计划不是摆设，上篇我们说了计划应该有什么内容，本篇将会分享如何写出实用的计划。写计划的几个要点：1.要站在战略的高度；2.明确计划的“输入”；3.用估算来控制计划，由计划来调整估算；4.制定可执行可检查的进度计划；5.细化近期计划，定下远期计划大节点；6.让项目组各成员详细计划自己的工作；7.持续更新计划。

我们会常说“计划赶不上变化”，我们写出来的计划往往只有一个版本，写完就完了，没有更新，也没有人去用这个计划。计划不是纸上谈兵，更加不是写了就不变，计划其实就是应对变化的最好方法！我们做软件项目，首先要保证我们是在做正确的事情，然后才是如何正确高效地做事情。项目计划是保证我们做正确事情的重要手段，我们先来看看项目计划应该有什么内容，下一篇介绍如何写出这个计划，再下一篇是如何执行和跟踪计划。

估算的方法有很多，什么代码行法、功能点法、Delphi法等等，有时候觉得估算这个问题搞得太复杂了，各式各样的方法是不是太夸张了？其实最简单的方法就是让负责该项工作的人自己来估计工作量，微软的由底而上的估算方法就是这样做的，可谓返璞归真啊！

很多人问如何才能做好估算？这个问题是问如何正确做事情的问题，而实际上要回答好这个问题，先要回答估算要估算什么内容的问题，也就是什么是正确的事情问题。

大家都喜欢用建筑工程与软件工程做比较，但我们常常所说的建筑工程只是指建筑施工部分，而不是一个完整的建设项目。一个完整的建设项目，由甲方提出需求，设计院根据需求设计出图纸，再由造价公司进行估价，然后公开招标，最后由建筑公司承担建设，建筑工程是典型的“瀑布模型”。而我们的软件项目管理可能是最复杂的一种项目管理，因为我们的软件项目需求不确定，设计（技术）也不太确定！

项目天天救火，疲于奔命，项目健康状况到底如何呢？我总结了11个问题，供大家自测一下，看看你的项目是活得舒适，还是要投胎转世呢？当然要诊断项目的健康状况，11个问题是远远不够的，但这11个问题应该有足够的代表性，希望对大家有帮助。

“三边”是指：边计划、边实施、边修改，“六拍”是指：拍脑袋、拍肩膀、拍胸口、拍桌子、拍屁股、拍大腿！“三边六拍”很形象，引人深思！“三边六拍”并非本人原创，最开始我是从我的领导那听到的，我觉得很有意思，很形象，很贴合实际。下面介绍一下什么是项目管理“六拍”，以及我的一些感受；然后介绍“三边”和我的体会。第一拍：拍脑袋客户领导与软件公司领导在一起，“拍脑袋”确定了一个项目，于是项

软件设计是为软件服务的，要服从项目的商业目标。一味追求所谓的优雅设计，项目可能会死的很惨。客户购买的是软件而不是你的设计。如果你在客户面前介绍你的设计如何精妙、如何OO、如何依赖注入？那客户只能当你是火星人看了，客户并不会因为你的设计如何精妙而原谅你的推迟交付和增加费用。如果为了节省时间，忽略设计或者粗略设计，项目同样很可能会死得很惨！没有想清楚就动手，就相当于冒着大雾往前走，可能走错方向，可能跌入悬崖……

摘要：知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享，本篇是需求篇。什么叫挨踢项目？IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项

摘要：知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。什么叫挨踢项目？IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：1.需求

摘要：知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。 什么叫挨踢项目？IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大