项目管理的是与非

软件项目管理是一项复杂的活动，它涉及到计划、组织、实现、度量等方方面面，始终围绕着时间、成本、范围、质量等因素团团转

　　子张向孔子请教仁，孔子说："要是能够在天下实施五种品德，就是仁了。"子张请教哪五种品德？孔子说："谦恭、宽厚、信诚、敏捷、施惠。谦恭就没人欺侮，宽厚就能获得群众，信诚就能够得到别人的任用，敏捷就做事有功，施惠就足以使唤人。" ——引自《论语现代版》

　　软件项目管理是一项复杂的活动，它涉及到计划、组织、实现、度量等方方面面，始终围绕着时间、成本、范围、质量等因素团团转。表面上看好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但当它们相互纠缠、累积在一起时，整个团队的行动就会越来越慢。我们所面临的挑战和任务是在实际的进度和有限的资源范围内，寻找解决实际问题的切实可行方案。提起软件项目管理，我们大多数人脑子里想到的都是一些基于文档方面的文案工作(进度表、状态报告、会议计划、进度跟踪记录、里程碑报告等等)，然而，最容易被管理者忽视，但却是非常重要的两个因素是：对人的有效管理和对项目风险的有效管理。

　　作为公司或一个团队的管理者，你需要通过员工的进取去实现经营目标。然而，如果没有激励，员工的士气就无法振作，你的目标就会变得虚妄。因此，在一个以人为本的企业文化中，胡萝卜几乎无处不在，并且表现出各种赏心悦目的形式，令人热血沸腾。同样地，你也需要一些胡萝卜来营造一种积极的团队文化，包括那些不花钱的胡萝卜(既感情投资)。有效的授权不仅是一种激励员工进取的胡萝卜，往往能够实现员工与企业的双蠃，一方面可以满足员工建功立业的个人追求，另一方面也是实现公司战略规划的一种必然选择。否则，员工会不思进取，而作为管理者也会陷入俗务之中不能自拔。——引自《水煮三国》

　　管理学特别是对人的管理学，早在几千年前，人类开始群体生活，形成早期社会时就已经开始形成了。作为一名优秀的管理者，你必须面临四大要素：一、选择正确的人。二、为他们分配正确的工作。三、保持它们的积极性。四、帮助团队凝聚起来并始终保持团队的凝聚力。作为一名项目管理者，你的主要工作可能会是为团队创造信任、公开、积极交流的环境，并能有效地消除团队成员之间的隔阂和冲突。作为一名合格的管理者，你的脑子里始终应该清楚的明白一个道理："你的部属乐意并且积极的为你工作，不是因为你的个人魅力，也不是因为他们喜欢你，而是因为你喜欢他们。你喜欢、尊重为你工作的每一个人，你关心他们，爱护他们，他们的问题就是你的问题，他们的担忧就是你的担忧。你的胸怀像天空一样宽广，在一个人真正证明自己的能力以前，你就信任他，你让他们觉得你把他们当成一家人，这才是他们喜欢始终跟随你的原因。

　　"这就是所谓"得道"，让部属与领导者的价值观相一致，这样部属就会与领导者同生共死，不会畏惧什么困难和危险，表现出崇高的献身精神。"智士不为暗主谋"，在一个昏庸的管理者周围，不可能留住高洁的人才。如果你不关心别人，不照顾别人，就别想让他们为你做一些不同寻常的事情，即使你手中掌握着权力也无济于事。如果要让他们改变，就必须去了解并赞赏他们的过去，并相信他们现在的能力。要记住你的团队成员们会很在意你的反应，他们看到你的反应将决定他们对项目的状况及未来的发展是否有信心。在其它成员面前指责另一个成员是一种冲动的行为，事后你会为此而后悔，尤其是你还没有把所有真相弄清楚之前，一定要事先考虑一下后果，从理论上讲，只要不超过做决定的日期，晚些做决定会更好，因为那时你会得到更多的信息，如果你发现做了一个错误决定也应该心甘情愿马上把它纠正过来。

　　另外，管理中的愤怒和羞辱是会传染的，如果高层管理者喜欢骂人，低层管理者也会照着学。如果希望用辱骂来作为一种刺激，可以让员工提高效率的话，那就大错特错了，没有人在被辱骂之后还能做得更好的。通过辱骂的方式只能表现出经理的无能，而不是员工的无能。需要补充一点，企业文化中的马屁文化也是会传染的，如果高层管理者喜欢阿谀奉承者，低层管理者不仅会有模有样、照单全收，还会学会媚上欺下。如果这样的话，下面员工的座右铭就会变作："好风凭借力，送我上青天"在这种文化中，人们学会的只是趋炎附势，专注于捕捉任何一个飞黄腾达的机会，再不会努力工作。而这一切，这是作为一名项目管理者应该知道的，了解了这些，便拥有了可以组成一只优秀的，有凝聚力的核心团队所必须的条件。作为一名管理者：你必须学会用心来领导、相信自己的预感、构筑团队的灵魂、训练一个能识别出谎言的鼻子。

　　薪酬管理难道真是用"最低的人力资本"去购买"最高的营业绩效"码？难道打工族的劳动力真的仿佛集贸市场中可以讨价还价的商品吗？当然不是，它忽略了下面三个问题：第一、劳动力是一种特殊的商品，在打上价格标签时需要顾及人的尊严。第二、提供劳动力的人追求的不仅仅是被老板视为成本的工资，还有职业生活的快乐。第三、每一位员工都希望能够与老板分享公司的营业绩效，因为其中浸透了他们的情感。如果你在薪酬管理中忽略了员工的情感，就另指望员工热爱他们的工作。于是，劳资关系就变成了买卖关系，一边是讨价还价、斤斤计较，一边是缺斤少两、以劣充优，利益相争，各有所图，就象菜场买菜和卖菜一样。因此，以人为本的薪酬管理会关注员工的情感需要，会把"绩效分享"作为薪酬管理的主题。于是，劳资关系就变成了伙伴关系，利益相连，目标一致。——引自《水煮三国》

　　软件开发是一项复杂的、创造性的协作式游戏。作为游戏它自然存在着乐趣，所以程序员们才会乐此不疲，前仆后继。首先、这种快乐源于一种创造事物的快乐。其次、这种快乐来自于一种开发出对别人有用的东西时所带来的满足感。第三、快乐源自开发过程中，亲眼看到软件按自己预先设想的那种效果运行时所带来的迷人魅力。第四、快乐源自开发过程中持续学习的快乐。最后、快乐源自开发过程中，我们能象诗人一样，仅凭自己的想像，来建造自己的城堡时带来的快乐。编程的快乐在于它不仅满足了我们内心深处进行创建的渴望，而且还唤醒了每个人内心的情感。不幸的是，同样作为游戏它也有苦恼的一面：首先、苦恼来自追求完美主义。其次、苦恼来自总是由他人来设定目标、供给资源、提供信息。第三、苦恼来自于寻找琐碎的BUG却是一项枯燥的、重复性的活动。第四、人们通常希望在项目接近结束时，能收敛得快一些，然而，情况却是越接近完成，收敛得越慢。最后、苦恼来自当投入大量的辛苦劳动后，产品发布时却面临着陈旧过时的危险。作为软件开发者，我们别无选择，只有适应它们，就这样痛并快乐着地面对每一天。

　　来自领导的信息只有25%被下级知道并正确理解，从下到上的反馈信息不超过10%，平等交流的信息则可达到90%以上。平等造就信任，信任增进交流。有效地进行适当的意见交流，对一个组织的气候和生产力会产生有益和积极的影响。使顾客满意并和他们面对面地交流，才是蠃得市场的关键。 　——引自《管理智典》

　　管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是"遭受损失的可能性"，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：

　　第一、风险识别：

　　从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。

　　第二、风险分析：

　　对风险出现的可能性和潜在的危害性进行量化分析。

　　第三、应急计划：

　　如果识别出的风险真的出现，你将采取的应急措施。

　　第四、风险缓解：

　　为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。

　　第五、持续的监控：

　　跟踪需要管理的风险，寻找风险出现的迹象。

　　项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：

　　第一、缺乏合理的进度安排

　　这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。其次、它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。

　　第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。

　　最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。

　　第二、需求的变化

　　从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。

　　第三、人员的变更

　　在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。

　　另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。

　　同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。

　　第四、规约崩溃

　　这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。

　　第五、低效率

　　对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。

　　正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。

　　精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。 　——引自《最后期限》

　　企业的最大风险则与价值相关：在低价值的项目上浪费资源，付出高价值的机会成本，就这是企业最大风险。勇于承担风险是好事，但必须由收益来导航，愿意承担多少风险，必须取决于能获得多少收益。真正的项目评估不是倾向于不断削减成本，来提高价值，而是在风险与价值之间取得平衡点。通过不确定的价值和不确定风险组合效果的净收益图，来指导你把资本投入到最适当的地方。我们每个软件从业人员都必须明白：顾客真正需要的，是我们能够给他的、某种他想得到的利益。