最近的一次敏捷项目Scrum经验总结
Team刚刚完成了一个敏捷项目，做一下项目总结，以备以后借鉴和提高。
需求 - 沟通 – 人 - 过程 - 工具
项目要成功的最关键因素是什么？软件要快速高效又高质量的提交靠的是什么？有人说最关键是项目经理，关键是沟通，有人说是技术设计，有人说是对需求的把握… … 从我看来，都是盲人摸象，项目要成功，软件要快速高效又高质量的提交，靠的是多重因素的整合和平衡；首先要对需求的准确理解和把握，贯穿全流程的沟通，做项目靠人，对人/士兵的管理（物质、心理），适合组织的先进的过程（开发，测试，评审，组织，考核），还有工具的运用和整合大大提升组织效率，缺少那一样都是不行的。成功的模式只有一个，而失败却有各式各样，就是这个道理。
沟通，随时随地，全方位立体的，有效的，及时的沟通
沟通，沟通，随时随地，全方位立体的沟通。面对面、站立会议、咖啡间、IM、Email、文档、电话。上下级、跨部门、客户，沟通，直到双方的理解没有Gap（鸿沟），没有Misunderstanding（误解）。主动沟通，有问题随时反馈。对被动的同事，主动问他。注意沟通的效率和时间表，不要一个会议开两个小时。如果有必要，尽量让少的人参与，除非是kick-off会议。此外，沟通会影响时间表，比如你有个问题要问某人，而这个人下周开始休假了，要早做预防。否则，吃亏的是自己。
白板，任务板，Sketch，Prototype
Team位置必须坐在一起，最好是圆圈式的座位，旁边有玻璃白板，上面画好下一个里程碑和Release的Roadmap，玻璃白板便于马上沟通。任务板便于大家清楚当前致力的目标和Release。对于Sketch要用好，在产品或者功能还没有做出来以前，先把Sketch或者Prototype发给客户看一下是否认可，获得用好Remarks，然后再开始动手；毕竟动手了再修改代价就更大了。所以一定要用好Sketch草图。
Stand up meeting要不要
很多人说到Scrum就要每日晨会Stand Up Meeting，但我们Team的实践来看，并不是必须的，其实敏捷也是根据组织和项目实际情况因人而异的（有人说敏捷对结对开发人员的能力要求很高，我觉得敏捷是一种境界，良好的架构，代码规范，成员间非常好的默契，才能敏捷的起来）。不能拘泥于形式主义，我主张实用主义。现在不是有反敏捷、有瀑布敏捷（Water-Scrum-Fall）、实用敏捷吗？关键是我们还没有领会敏捷的深刻内涵和思想体系，不会用敏捷的思想和思维方式高屋建瓴的思考我们的开发流程，而只是依葫芦画瓢学个一招半式，那就真的不是敏捷了。我听到有人说，敏捷只适用于产品型公司和小型项目，还有人说敏捷只适合于需求不稳定的项目，还有人说敏捷了就等于速度快，就等于客户报价可以低一些，还有人说敏捷说的什么迭代持续集成和重构都是理论，没有考虑到实际执行起来的风险……都没有错，关键是我们还没有领会敏捷的深刻内涵和思想体系，不会用敏捷的思想和思维方式高屋建瓴的思考我们的开发流程，而只是依葫芦画瓢学个一招半式，在这儿讨论，说白了还是理论，坐而论道不如起而行，所以积极实践，加深对敏捷内涵的深刻理解，寻找适合自己组织的最佳敏捷实践方法才是良策。这样子思想理顺了，我们就不会拘泥于Stand Up Meeting到底要不要的问题了。
保证代码质量
如何获得高代码质量？打个比方，现在要打仗了，如何打个漂亮的胜仗。我想你肯定知道答案了。那就是你的队伍必须各个是精兵，能力强，平时训练有素，而且还有实战经验，这样的一个兵强马壮的精兵队伍你拉出去，只要指挥好，士气高，就能打漂亮的胜仗。OK，现在你明白了，软件开发何不如此？你手下的程序员是不是技术能力很强，是不是平时就对技术研究很深，对某科技术有很深的理解，还有很多项目经验，是不是干劲十足，是不是对他们做了培训，是不是做了编程规范的要求，都明白了命名规范、异常处理、日志处理、安全性、用户权限、配置文件、设计模式、线程安全、单元测试、调试技巧、条件编译等项目标准处理；如果还没有这些标准的贯彻，那你的士兵还需要培训（训练），这样子上战场会很危险。当然，有个变通办法，让资深程序员带小弟，小弟在一边看着，下个项目备用。当然。除了培训以外，分享、知识库都是团队很重要的机制。
基础不扎实的程序员代码质量不会高起来，比如有的C#程序员根本理解Task.Factory.StartNew这句话是异步执行的线程池起线程，就把它放到同步的循环里面，导致问题。再比如，有的程序员用匿名函数，不懂闭包，导致放在循环里面每次取到的都是最后一个值。再比如有的程序员不深刻理解Session，就认为浏览器关了Session就没有了。再比如有的C#程序员不理解GC以为一个类只要实现了IDisposable接口就一定会内存释放……举不胜举，都是项目中遇到过的（注：对基础不扎实的程序员进行代码Review管用吗？我们项目实践来看不管用，因为资深程序员很忙，不可能一行一行去看去调试。）……所以，优秀的程序员都是建立在对该技术的深入理解的基础上的。优秀的成熟的程序员员工都有专业化（技术方面）、职业化（服务意识、协作能力、解决问题的能力和态度）和商业化（替客户思考和解决问题）多方面的优秀特质，才能真正的为业务创造价值。
保证代码质量的另外一个非常重要的方面就是测试，一定要写单元测试，使用Moq做单元测试。这可以培养程序员面向接口的思维方式，如果代码不能做单元测试往往是耦合度很高的代码，所以单元测试能发现代码质量的问题。此外，测试组的工作要及早介入，对业务的深刻理解，重复利用bug管理工具，敏捷测试。
为需求变化和维护早作准备
在系统设计的时候，要考虑到未来可能的需求变化，做好面向变化的架构设计。但不要过度设计。（这需要深入理解商业需求）
为维护早作准备，意思是说，在编码阶段，就要考虑到系统的可维护性，设想你自己就是将来维护这个系统和这段代码的人，这种意识很重要。有的程序员以为系统提交了上线了就没他的事情了，结果到头来上线了出现问题，系统又没有很好的log和trace，导致问题极难线上调试，而线下又不能模拟真实的环境，这种情况下必须为维护而设计，提升系统的可维护性、可追溯性、可管理性。
不要过度设计和过早优化
过度设计是敏捷开发应该避免的，很多工程师都有过度设计的冲动。例如，在一个web系统还没有看到被大规模使用的曙光以前，就设计了系统规模化，什么集群、负载均衡、读写分离、分布式缓存系统……说真的，这些*西确实是好*西，但也很贵。在系统还没有被大规模的用户接受和喜爱之前，这样做是否会抵消了我们把专注点放在核心功能和简练和简单的努力呢？时间是有限的，投资也是有限的。我们必须把有限的时间和有限的金钱用在当前最核心的功能和体验上。有时候系统初期，可能一两台服务器就足够了。只有在看到产品有被大规模使用和用户喜爱的曙光之后，才来增加功能和规模量。当然，你的网站功能，在你只有 10 万用户的时候，可能和你有 1 亿用户的时候会很不一样。所有太多太早太频繁的架构上的大动作可能会适得其反。这一点上，你要小心判断。系统架构需要及早规划，但不要提前实施和过早优化。
关注非功能性需求
也许大多数客户和咨询师也会听说过神马TDD、迭代、原型、持续集成和持续部署、Agile等时髦的词语，这些也让管理者很兴奋，以为软件产品是可以在很短的时间内高质量的完成的，即使完不成也可以在后面用TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。这听起来好像很美好。但其中有个很大的陷阱，那就是客户和咨询师，还有原型、TDD大都只关注功能性需求，而忽略了非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。客户和咨询师在项目前期闭口不提这些或很少提及，但一旦功能性需求都做完了他们就会抱怨这些隐藏的非功能性需求。而像性能问题，高可用性问题，系统维护问题（模块的耦合问题）等并不是很容易重构，往往涉及到Re-design, re-architect；因此这些问题往往都在后期会成为重构噩梦，甚至可以让你的软件设计重新来过！更加糟糕的是，大多数客户不愿意为这些隐藏的功能重构而付钱。笔者曾经遇到过前期只注重功能性需求而后期发现性能不好而进行re-design, re-architect，这对项目管理来说有很大的挑战，因为不单单是程序和架构重构的困难，还要面对时间和人力成本的增加，最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。这是一个很大的陷阱。
所以，前期就要关注非功能性需求，不要急于动手，如果你能有多一些时间去和客户讨论一下需求和未来可能的变化，去调查一下实现的技术难点和细节，去和其他有经验的人讨论并推敲一下架构和设计，去思考设计上的缺陷，那么，你的coding会变得非常地直，直到你一眼就看到尽头，你的测试案例也会写得非常地好，你会几乎不需要重构，于是，你会在未来少写很多代码，从而你的软件开发会越来越轻松，直到技术开始换代。这就好像我们修路造桥一样，我们需要花大量的时间勘测地形地质，分析数据，思考可能出现的各种问题（各种自然灾害），评估不同的设计方案，而不是先尽快建好再说。(：磨刀不误砍柴工) 说到这里，有些反敏捷（反Scrum），没错，好的程序员要会做权衡/平衡，好的架构师要会做平衡，好的项目经理也要会做平衡，这非常重要。
再补充一点，有资深经验的工程师/架构师对非功能性需求的设计和平衡很有经验，这些经验对系统设计和项目成功至关重要。如果你很不幸，手头没有这些有经验有价值的人，而只有一堆码农，那么恭喜你，你可以在一张白纸上画画了。就开发他们的潜力吧，做好这个项目给他们积累经验的心理准备吧，量力而行吧，小马过河吧……实在不行你就自己上吧，毕竟公司要求用最少的钱在最短的时间内出来最优秀的*西；如果你有话语权，那就把你的困难及早让上层知晓。
严格控制需求和范围，和进度权衡，不出现资源空闲
领导一般会给项目经理压力，要求在什么时间提交一个版本赶进度等，这时候项目经理要么能调整一些需求和范围（Scope），要么就把可能出现的问题进行报忧，因为现在如果不这样做，你就等着现在报喜，后期报忧吧。所以项目经理一定要严格控制需求和范围（scope），和进度，和质量权衡。同时要合理调配资源，不要出现项目进行中资源空闲的情况（这个在Project工具中可以看出）。
项目风险管控
项目经理要有项目风险管控能力，及时在项目进行的各个阶段进行风险的预识别和管理。项目一般是前期工期松，风险低；而后期工期紧，风险高。所以项目经理要尽可能在项目早期能列出大部分的风险，这样在项目的风险应该是倒三角形状的，就是前期风险多，后期风险少。要预先把下阶段可能的风险明确告诉客户，让客户提供帮助来控制风险的发生，同时迫使客户加强风险意识，不让需求任意扩散和蔓延。在各个阶段都要有双方风险认知的会议纪要记录。一般情况下，项目的外部依赖条件是最不可管控的风险（比如要和第三方联调，要第三方提供API等）。其次是需求的不明确和需求蔓延的风险（需求问题占项目成功的40%因素以上，你能控制需求，你就成功60%了）。然后还有资源的可用性（如：项目进行中核心人员流失，要知道项目进行中间换人和加人都很是问题）。
资源提供者和问题解决者
大家都知道，打仗的时候什么最重要？对了，补给（后勤保障）。士兵上战场了，谁做后勤？项目经理。每天都要问大家，你下一步需要什么，你还缺什么输入？你有什么问题需要我这边配合的？程序员旁边有垃圾了，项目经理去扫一下地，这就是后勤补给。所以管理者首先要理顺管理者和人的关系，调整好服务的意识，做好资源源源不断的提供、帮助大家解决问题，系统就有了润滑剂，有了源源不断的输入，就能顺畅的开展。否则，千里马到你手里也跑不快的。
管理用户期望
对每一个Sprint提交，谨慎选择功能集合，多和客户沟通，管理好用户期望，他下一阶段希望有什么功能，这些功能的优先级如何，实现难度如何，及早告诉他下一个版本会友什么，不会有什么。
增加团队成员之间的亲密感
有时候如果一个团队成员里面有多个牛人，大家都是很有主见的人，就很容易在一些问题上争执，甚至产生内部竞争。两个聪明人意见采取谁的呢？紧张关系在所难免。这种纠结的合作和竞争关系是同事关系的主线。但要保持合作为重点。所以，要把这样的状况保持在一个健康的状态，需要加深团队成员的亲密感。具体来说，坐在一起聊天、吃午餐、喝咖啡、散步、打球、打牌，都是增加亲密感的方法，这样拉近人与人的距离，就不会觉得有什么竞争的紧张感了。
管理团队目标和情绪
Scrum有一个优点就是短周期快速迭代，每周大家都有明确的目标，因为Release周期很短，大家Vision很明确，所以为什么Sprint就是冲刺的意思。管理好团队的目标、Vision，有明确的目标，有冲刺的干劲。及时发现团队的情绪波动，采取应对措施（休整，腐败，激励）。
保持耐心，不断调整
技术上要重构，架构改进和提炼等。信任程序员，给他们时间来重构，来调整和优化架构等。管理上要重构，代码促进委员会，评审组等等。改进适合组织规模和业务发展的流程，目标是获得持续、快速、更好质量的交付产品和更好的客户满意度、更低的成本和更高的效率。总之，要不断努力，不断调整，不断尝试新的方法，做的越来越好。要保持耐心，给员工/系统的成长/成熟一点信任和时间。
项目经理的人格魅力和以德服人
作为项目经理您必须与同事以团队合作方式才能保证项目的顺利完成，如何鼓舞团队成员的士气？让大家心甘情愿的与你朝着共同的目标努力。要做到这一点，人格魅力非常重要。但要让大家真正服你，真正的服是以德服人。比如，你要求所有的手下都主动配合你的工作，但是你自己如果没有首先要求自己主动配合大家，你就不会赢得大家的尊重。这只是一个例子而已，很多点滴细微之处会让大家感觉到你的人格魅力，究竟是一个值得尊敬的人，还是一个不值得尊敬的、自我的、高高在上的发布命令者。总之，做人是最要紧的，做人没做好，做事肯定做不好了，项目多半要搞砸。
但就项目经理的项目管理能力来说，也关系到项目的成败，比如能否引导客户需求、对问题的透彻理解、对复杂的任务紧密跟踪并设定轻重缓急、利用各种渠道和方法来沟通解决问题、有能力做出适当的取舍、说服客户或领导的能力、推销自己解决方案的能力、突破性格制约的沟通技巧、面向全局思考的思维方式、如何合理动态分配大家的工作项使不被Block住……
总结
先写这么多吧，想到了再补充。
Update：现实项目管理中的一些实际矛盾
没有可用的测试团队或测试人员，在很多小型开发团队和小公司都普遍存在测试资源不足的问题，甚至在某些大公司也可能出现。严格的成本控制，导致测试资源相对不够；失败的项目开发计划会导致压缩测试的时间来保证研发的时间；到了测试的时候，就肯定出现你们现在这样的情况。最后的结果呢，是所有人都得不了好：领导会因为客户的投诉而头疼甚至被老板骂；项目经理会对质量负主要责任，对整个项目负主要责任。如果有测试团队，测试会对质量控制负主要责任。没有，项目经理负主要责任。
应对办法有以下几个：让开发人员做测试；让有限的测试人员只测试主要核心功能点；项目经理死扛，自己亲力亲为；降低软件质量；让领导充分意识到这个矛盾的风险。
2. 项目日程表异常紧急和按时上线的矛盾
这类项目最大的问题是时间成本。时间成本越紧，失败风险越大。要提高这种项目的成活几率，只有一个办法。砍范围。把所有可有可无的需求砍掉，放到下一期去实现。确保团队能够以合理的生产率产出成果。项目经理要做的最重要的就是，想尽一切办法，把优先级低的功能砍掉。集中资源保证高优先级需求的产出。要随时告诉明白客户，团队最大的产出是多少，团队正在做哪些功能。及时让客户进行确认和调整。让客户明白风险在哪里有多大。这是非常考验项目经理沟通、谈判、组织协调能力的。能把客户啃下来，保证团队正常工作，还有1、2分活的可能。不然，最后就当替罪羊吧。团队、老板、客户，都需要你承担责任。
3. 团队的生产率严重低于估计和项目按时上线的矛盾
项目竞标的时候是公司专家组资深架构师按照已有生产率来进行项目估时和报价的，但项目开始以后出现资源不足问题，例如：原来C++团队的资深工程师走光了，只有两个新人可用。原先是按照资深C++开发工程师的生产率来估计的时间，现在给你这样的一个团队，生产率和资深C++开发工程师相差很多倍。项目日程表却异常紧急，这怎么办? 没办法。这种项目的失败风险是极高的。解决办法只有找外援或者项目经理死扛了，否则这类项目失败是必然的。团队人员突然离开是项目的一个极大的风险，特别是核心资深开发人员，公司往往处于成本原因不可能对每个人有一个备份的人员，所以核心资深开发人员突然离开往往使项目处于高危状态。
4. 项目经理兼任Team Leader的矛盾
项目经理和Team leader这两个职位貌似是一样的，其实不一样。项目经理的职责包括：项目进度控制，成本控制，需求控制，风险管理，配置管理、任务分配以及与客户相关的沟通和交流等。而Team leader的主要职责包括技术方案确认，开发计划制定和跟踪，技术架构设计，重要技术问题攻关，核心代码编写和技术指导以及开发团队管理。对于小公司来说，为了节约成本很可能把两个角色让一个人来承担，这样的混合角色对个人能力要求非常高，需要两方面的专业知识，两方面都得一手把握，压力很大。现在很多大公司基本都将这两个角色分拆了，项目经理就是管进度，做协调，Team Leader就负责开发相关事宜，另外还有一个角色，叫Product Manager，这个角色主要是市场和开发之前做协调了。按照我的理解，项目经理需要对项目功能和需求（产品）有非常深入的了解，对软件开发过程相当有经验，同时具有很强的沟通能力，因为客户都是牛的一塌糊涂，你要引导客户的需求，那是沟通功夫了得。另外，项目经理是项目总负责人，对领导对跨项目和部门也需要及时的沟通协调以获得最佳的资源，以解决过程中的问题。而Team leader需要控制开发过程中的系统性风险，总体架构把我和关键核心部分开发。软件开发过程有很多的环节，任何一个环节出现大的差错都会导致焦头烂额并最终项目失败。但是在大多数公司，我们都不会称其为失败，一般会说：项目延期，好的延期半年，差的甚至有的延期1年！核心竞争力：开发管理＋过硬的技术能力。
5. 有限的资源和时间与按时上线的矛盾
分配任务的核心原则，就是先分清轻重缓急，作为管理者，一定要将它养成习惯。
Update：优秀项目经理必备素质
1. 交付能力
项目经理是项目的负责人，不管发生了什么，都能按时交付，优秀项目经理要具备这个素质。充分理解需求和范围，充分和客户明确详细需求和期望，充分考虑自身团队的技术能力、项目依赖、队员排期冲突、负面情绪、技术方案风险、未预知的技术障碍、需求变化等。具备为功能的设计做取舍的能力，但功能取舍并不以牺牲产品的核心愿景为前提。具有极强的交付能力的前提是具有极强的责任心。有了责任心，你会把项目当成自己的孩子，倾注你的全部心血，即使出现极端困难的局面也会死扛。责任，会驱使你关注项目的进度，千方百计去寻找各种资源，推着项目往前走。甚至吃饭、睡觉，走路、坐车，都想着整个项目团队，想着他们还在加班加点，你可能很自然地给他们带点夜宵、冲杯咖啡，犒劳员工。有了你这样的项目经理做表率，整个团队会鼎力支持工作，士气非常高，技术问题也迎刃而解，得到领导称赞和客户肯定，项目将朝着预想的方向发展。许多开发人员抱怨项目经理一天没干多少事情，而工资还挺高。其实，项目经理一刻都没闲着，他总在想着怎样更好的执行项目计划，调整项目进度等，脑子一直在不停地运转，所以说项目经理是真累。
项目经理上有老板、客户，下有项目组员，属于夹板层，沟通不好，容易出事。PMBOK(项目管理的知识体系)指出，项目经理75%～90%的时间用在沟通上。沟通的对象不同，方式也有多种（正式非正式）、技巧也很多、沟通的媒介也多种（Email, SNS，电话，视频，面谈），但最终的目标是沟通必须能让对方接收、理解并和你取得一致。
3. 引导客户的能力
“客户是上帝”，但客户不一定全对，而且有的时候是错的，尤其在项目还没开发出模型的时候，客户有时根本不知道自己需要什么样的*西。所以，在项目启动会议后，双方要“把丑话说在前面”，分清责任。项目经理要站在客户的立场，努力满足客户的业务要求，让软件真正为客户创造价值。但是，如果项目经理总被客户牵着鼻子走，就很容易陷入被动的局面，结果是客户的需求一直在变化，造成程序不停地返工，项目总在原地打转，很难推进，久而久之，大家筋疲力尽，积极性严重受挫。最后，项目做得一蹋糊涂!对于客户提出的需求，项目经理要凭借优秀的技术水平、充沛的业务知识快速估算需求的变更需要多少开发工作量，有没有更好的解决方法。理想的情况是程序基本不做改动，又能满足客户的需要。但笔者往往是采用变通的方法，换一种方式实现客户的需求。这种情况下，需要项目经理对系统结构有全局的认识，尺寸一定拿捏得很准。项目经理有时充当白脸、有时是黑脸，但无论如何，一定要维护组员的利益，笔者经常看到很多项目经理有意无意地在客户面前说开发人员的不是，遇到客户不满意的地方，就指责开发人员。这种方法欠妥，笔者一般是跟客户表态，向客户承认“错误”，回头再找开发人员讲道理，做到“内部的问题内部解决”。
Update：敏捷项目中的风险管理
How does Agile address these particular five areas of risk? Let’s discuss...
- Mitigating schedule flaw is the biggest risk out of the five risks in terms of its planned versus actual performance. Estimating is a guess, a forecast. It is not an exact science. Scrum provides feedback loops to mitigate invalid guesses. Teams update the release plan at the end of every sprint with the emerging information gained from their last sprint timebox. Traditional projects take an estimate early in the project and don’t look back as they trot to the finish line - even when the guess (estimate) is discovered to be wrong. Agile gives you the feedback loops to refine the plan as the project moves along through prioritizing the product backlog to deliver value sooner (based on value, not time) by looking for early release opportunities (combining value with time).
- Mitigating Specification Breakdown is resolved in agile by having a product owner to communicate the customer needs and decisions about what the product should do. Stakeholder expectations can be overwhelming for delivery teams if they don’t have a dedicated product owner to help point them toward what the customer needs. A scrum delivery team will work collaboratively with the product owner to ensure alignment between what is requested and how it can be delivered.
- Mitigating Scope Creep is part of every scrum ceremony. The product owner, and other stakeholders, will discover new things to include in the product as they see progress from the delivery team throughout the sprint. During the demo at the end of the sprint, feedback from attendees will generate new backlog items. The product owner will evaluate the new product backlog items and decide what action to take: add, delete, trade-out in priority with other product backlog items.
- Mitigating Personnel Loss on agile projects involves having self-organizing teams involved in focusing on work and problems to solve, thus resulting in higher morale. Traditional projects that focus on “death marches” to deliver the work experience with low morale and a higher risk for turnover. Working in persistent teams does not mean that you are signing a contract for life to never leave the team. There will be turnover in any team. I am saying the turnover will not be based on traditional project “death march” criteria - low morale.
- Mitigating Productivity Variation is the difference between the assumed and actual performance of the team. In agile projects, we extend this variation to include the performance of the product. Scrum delivery teams address the performance of the team at the end of every sprint as part of the sprint review. Mitigating or correcting the difference variation happens in the next sprint. If a team is failing to meet its commitment, they will look to commit to less work on the next iteration. If the product is failing to meet the customer’s needs, those issues will be corrected through the product owner’s managing of the product backlog. Teams guess on how much work they can do in their first iteration. After three or four iterations, teams establish a low confidence, medium confidence, and higher confidence velocity. Velocity - the amount of work done - for an agile team acts as an indicator that teams can use to forecast work past a single iteration and can be used to help mitigate productivity variation.
- Integration Management
- Scope Management
- Time Management
- Cost Management
- Quality Management
- Human Resource Management
- Communications Management
- Risk Management
- Procurement Management
Update：项目管理简图
Update: 海尔集团的PDCA管理法
- 在计划阶段，要通过市场调查、用户访问等，摸清用户对产品质量的要求，确定质量政策、质量目标和质量计划等。它包括现状调查、原因分析、确定要因和制定计划四个步骤。
- 在执行阶段，要实施上一阶段所规定的内容，如根据质量标准进行产品设计、试制、试验，其中包括计划执行前的人员培训。它只有一个步骤：执行计划。
- 在检查阶段，主要是在计划执行过程之中或执行之后，检查执行情况，看是否符合计划的预期结果。该阶段也只有一个步骤：效果检查。
- 在处理阶段，主要是根据检查结果，采取相应的措施。巩固成绩，把成功的经验尽可能纳入标准，进行标准化，遗留问题则转入下一个PDCA循环去解决。它包括两个步骤：巩固措施和下一步的打算。
上海通用汽车公司成功地把此方法应用于自己的经销体系中，极大地改善了经销商的服务。在其近100家经销商中，上海通用奉行的政策是，对一些业务表现不好、不能完成上海通用的要求、不能在市场上进行有效的开拓，或者在售后服务方面不能够完全按照上海通用的理念和规范去操作的经销商，会先给他们做一个PDCA改进计划。完成了这个计划性的四部曲后，经销商的整个市场营销的管理工作应该会随之步入一个良性循环的轨道。如果还是不行，经销商就会被淘汰掉。
由上可知，PDCA管理法的核心在于通过持续不断的改进，使企业的各项事务在有效控制的状态下向预定目标发展。
Update: 几大令人头痛的管理难题
1. 如何激励团队？
金钱并不是所有的因素，如何给团队注入正能量，给予下属充分的肯定，甚至是冒险的空间。这是个问题。而如何持续给团队注入正能量的活力则是一大挑战。
2. 如何解决团队合作问题？
你把整个团队看成一条船，制定一个明确的航行目标，明确规则和职责。要知道，职责不明往往带来各种扯皮。而且，不同部门的不同人都有各自的利益，要事先未这类冲突想一些解决方案。
3. 如何管理更有经验的人？
让更有经验的人来挑重担往往能降低风险，谦虚些没什么错，不妨多听听他们的意见，但也要自信别怯场，相信自己肯定有过人之处，你必须不断学习新知识，但也要想办法多发挥有经验人士的才干。
4. 如何在团队中建立信任？
一个不公平的领导是不值得跟随的。关键是要保持客观、中立、判断力，不要轻易判断是非。也不必刻意掩饰失误。让你的同事相信你在努力，你是客观公平的，并且有解决问题的能力。
5. 如何和其它部门协作？
部门协作往往是完成公司更高层次的任务，每次多做点功课，知道每个部门的长处和特点，尊重各自的主管，明确自己在大任务里面的职责和责任对象，遇到矛盾先冷静。
6. 如何处理团队动荡？
你可能面临流动性的挑战，因为一个组织里总有经验比你丰富的人，或价值观与你不同的人，不过这对你是个好机会，你可以重建符合你价值观的人员体系，组织也更加稳定。不过，要做好核心人员流失的预案和多米诺效应，这就是平时的功底了。
做好PM的几个关键点（转）
在项目过程中，通过观察，感觉做好PM这个角色需要做好以下几点：
- 对项目关键点的细节要足够了解
虽然PM可以不参与具体的编码工作，但并不等于不需要了解具体的实现细节，特别是一些影响项目成败的关键点。有些PM离技术越来越远，远到一些功能是怎么实现的、用的是什么技术、有哪些地方需要特别注意都不清楚，这会非常影响他的决策力和判断力，特别是在处理突发事件时会手足无措。在现阶段，特别是项目规模不大的情况下，感觉PM兼任架构师比较好。 - 对项目各个阶段的时间点要足够清晰
PM头脑得时刻有一个清晰的项目roadmap，并对每个时间点做好准备，比如在项目立项前，预估好工作量和资源分配，与其他团队协调好时间点和容错方案；在需求评审前得组织项目骨干了解需求并做好架构设计，与PD深入探讨，避免业务上走不通；在设计评审前，得评估出所有风险点和合作方，并完成设计文档，与合作方充分探讨合作细节，并达成一致；在提交测试前，关注各个任务的进度，特别是有风险的，并为测试准备好环境；在开发联调前，与各个参与方的接口人联系好，并准备好环境；在发布前，做好发布计划，预估出发布风险点。总之，需要对各个关键时间点有清晰的认识，提前做好准备，控制好风险。 - 处理好与其他团队的关系
一个项目的成功不是只靠自己这个团队就能做到的，需要所有团队的通力合作，因此，非常有必要学会与其他团队处理好关系，而与其他团队沟通的接口人主要就是PM，PM对于团队之间的合作是否顺畅起着决定性的作用。首先需要弄清楚什么是原则性问题，什么是可以退让的，在有分歧的时候，要立即判断出是否可以出做让步。再则，一定得把问题想在前面，提前沟通，只要大家都是为了把项目做好，并在出现分歧前，就把这些可能的分歧点讨论清楚了，就没什么很难处理的关系。最后，学会与任何类型的人打交道，林子大了什么鸟都有，沟通不是为了争个输赢，而是达成一致，这方面的技巧就多了，需要学习和积累。 - 调动组员的积极性，尽量把事情让他人去做好
在以前待过的一个项目里，PM非常敬业，很多事情都是自己去做，结果出现一个很不好的现象，每天晚上，他的项目成员都走光了的时候，就留下他一个孤独的身影，奋力拼搏，结果每次发布的时候问题多多，惊险不断。这说明一个问题，你不是一个人在战队，并且你不应该冲在第一线，PM的成就感不应该是你自己把事情给搞定了，而是在你的策动下，你的组员把事情搞定了，只有这样项目团队才有战斗力，并且其他成员都希望在项目过程中体现价值，你需要学会锻炼和培养其他组员，发挥他们的最大潜力，这也是为什么在发挥同样出色的情况下，纳什比科比更容易获得MVP的原因了。 - 处理好风险点
PM可以把不影响项目成败的点扔给你信任的人，但对于那些会导致失败的风险点必须给予足够的重视。我以前带过一个小项目，其他什么都完成很好，事情做得很漂亮，bug也没测出几个，但没有review其中几个比较容易出错的SQL，但QA告诉我没bug的时候我也没去多看两眼，结果它隐含了一个比较深层次的bug，在线上暴露了出来，造成了不小的损失和不良影响。其实，后来总结的时候，发现这个SQL存在明显的疏漏，如果当时认真地review，并审视测试case，是应该能发现问题的。PM必须对各个风险点心里有本帐，项目可以做得不漂亮，但如果在风险点上有任何疏忽，那就是失败。 - 安排好任务，并清晰了解任务的进度
PM需要对自己团队的组员深入的了解，了解他们的能力和兴趣点，把任务交给最合适的人，并保持与他们的深入沟通，了解他们面临的困难，你虽不是直接去完成任务的人，但一定是帮助别人完成任务的人。任务墙是个不错的方式，能让自己和他人清晰看到各个任务的完成情况，便与跟进 - 保持清晰的思路，储备应对各种突发事件的措施
项目里最需要保持思路清晰的人是PM，别人可以乱，但PM一定不能乱，特别是在有突发事情发生时。因此，PM有必要有意识地锻炼自己抗压能力，比如多做项目发布、设计评审和数据订正的工作，并且要有意识地储备一些应急方案，比如代码回滚，紧急发布等等。另外，要清晰地弄清楚团队之间和系统之间的依赖关系，往往这种依赖性是引发事件的根源。 - 保持平和的心态，多站在他人立场考虑问题
项目会进行地风风火火，项目成员之间也会争论得很激烈，往往这种时候，保持一个平和的心态很重要。不平和的心态往往会导致不平和情绪，不平和的情绪就会导致更加混乱的局面。保持平和心态的办法很多，很重要的一条是多站在他人立场考虑问题，一旦为他人体谅后，激烈的情绪会消退不少，并且在这种沟通态度的促发下，分歧方也会不由自主地为你考虑，非常有利于解决问题，达成一致。 - 加强项目自动化方面的能力
项目各个细节如果全都靠人肉去完成，会极大增加控制风险，而减少风险的最大利器就是用成熟的自动化方案去完成一些工作，特别是项目构建、持续集成和发布等工作。PM应该在怎样让日常工作流程化和工具化方面多动一点脑筋，而这方面敏捷开发提供很多很好的思路和方案。 - 共识和决议要通过邮件发给相关人
在项目过程中会产生很多变故，需求和设计文档里定义不了所以问题，为解决变故而形成的临时决议一定要通过邮件发给相关人，不光是知会，更重要的是为决议提供证据，这些临时的决议往往会引发问题，当问题产生追溯责任时需要用到这些证据 - 注意倾听组员的意见，给他们留出足够的发挥空间
特别是在大公司带项目，组员都算是开发的精英，都不是甘于做个机械的coder，因此学会倾听他们的想法，深入了解他们想得到的，尽量满足他们成长需求，就算是由于项目客观原因，没法采纳他们的建议，也得和他们把道理说清楚，不合适用强势方式来决断，毕竟技术人员的需求和管理不同一般 - 不以个人意愿为基准，凡是以大局为重
PM也是人，在平时工作过程中，难免会带有个人情绪，但PM应该清醒地认识到自己身后还有一个团队，大家的情绪和状态与自己息息相关，所以说话做事一定要三思而行，考虑清楚对别人的影响，切勿乱放炮，失去同仁的信任
