浅谈项目管理——《项目管理修炼之道》读后感

项目管理是一复杂的活，需要将经验、思想、方法、流程等拧成一股才能搞定，一直以来接受的项目管理方面的理论都比较零散，没有太多的系统性，这有坏处也有好处，坏处显而易见，无法有一个完整的项目管理理论的学习，更别说形成自己的风格；好处也有很多，至少接受了很多不同的思想，因为所有的思想道（这里道指本质）是相同的，只是路和方法不同而已，所以某种意义上说接收了一些很多家的思想、方法和对流程的处理经验，就算不能说掌握，但了解起来总相对轻松点。最近看《项目管理修炼之道》，作者的姓名一般都记不得了，只记得是个女士（女士一般都比较细腻），花了两个下午看了前面的6章，感觉还真不错，作者只在意项目的成功，而不在乎使用哪个流派的思想、方法和流程管理，一个项目过程中在不同时期和情况下会使用很多种的方法来进行管理（当然也有一些自己的喜好，比如作者就好迭代这口），想想自己虽然境界不高，但看了此书后还真有些感悟和共鸣，就迫不及的拿出来和大家分享或许对别人会有些帮助也未可知，当然这些感悟和共鸣只是在我能力范围下的理解，肯定会有不够透彻或有问题的地方，希望大家不要拍砖（非常希望能给予完善），我也只是存着抛砖引玉的一份心思。
1、项目的管理是面向对象的管理，而不是微管理。
项目管理是对人物的规模、进度、以及任务间的依赖关系的管理（不全，但只是针对这点来说），而不是对怎么做的管理，也就是只管谁在什么时候完成什么任务，而不管此任务应该怎么完成，如果熟悉编程的人应该知道这是面向对象管理的一种体现，任何的道理都是想通的，从这点也进行了佐证。《项目管理修炼之道》一书作者强烈建议不要进行微管理（即介入怎么完成）。这里引《一分钟经理人》的一些思想，认为经理人只需要在开始时与下属沟通好一段时期的目标（即下属什么时候完成什么），后面的事情都与经理人无关，让下属自行完成，这个观点看上去实在太理想化，但却反映出一个趋势和观点：要面向对象的管理，相信团队成员有能力知道怎么完成（如果实在不清楚，经理人可以帮助团队成员分析理顺，但记住千万不要去代他（她）完成）。面向对象的管理能提高团队成员的自信和能力，让团队成员在项目过程中快速成长（会有压力，但学着去管理压力）。这点要完全做到当然会很难，这需要项目经理去了解团队成员，他们各自的当前能力、擅长、经验、学习能力等，这就需要真诚和沟通。
2、必须了解和明确项目背景、价值、因素优先级、目标和发布条件。
首先要明白项目的背景和价值，需求方为何要建设此项目，项目对需求方而言价值在哪里，为什么一定要明确这看似和项目实施无关的东西，因为从因果关系上来讲，这些东西是因，项目实施是果。这对理解需求方意图，引导项目向正确方向发展具有指导作用。
项目铁三角：成本、时间和质量，项目中影响项目的因素基本是从这三个因素衍化而来，时间进度、项目成本、项目功能、项目质量、项目资源（人力等）等，必须要和需求方和公司高层确认这些因素的优先级别，排定什么最重要（关键驱动因素），哪些需要满足（约束条件），哪些可以商量（浮动因素），一般来说一个项目在存在一个关键驱动因素，1-2个约束条件，多个浮动因素时比较容易成功。比如某项目必须在8月15日上线投产，上面最多只能给你10个人，需求提出的功能必须都要实现，如果时间上不允许，则性能调优则放到下个项目中实现。这些因素对项目非常重要，尤其是在项目不能按时交付时，这些因素的优先级别将帮助项目退队决定先保证什么，以达到项目价值最大化。在上面例子中，假设8月15日不可能完成项目，那这时，这些因素的优先级排序将成为项目决策的依据：放弃部分功能的实现，而保证8月15日必须准时投产。
在我理解中，目标是对项目建设的一种较高期望（较低期望是按时交付），本质是一种突破，如果按时交付，就算达不到目标项目也算成功。
发布条件指项目在满足哪些条件的情况下可以发布版本，交付系统上线投产。发布条件定义了项目成功的最基本要求。发布要求必须是可测量的，比如“bug数低于10个”这样的发布条件是合理的，而“首页性能非常高”这样的描述因为不可测量是不可理的，应修改为“首页显示在2S内”。另外对发布条件的确定，必须要考虑整个项目环境，而不能只根据QA的标准，之前有个项目因为小bug很多，QA死活不同意上线，但因为此项目涉及到上面考核检查必须在指定时间前上线，而且项目虽然小bug多但不影响使用，客户也已经同意上线，所以在这种情况下需要适当放宽发布条件。
上面的这些因素，都是项目中很重要的一些信息，在明确后需要在整个团队中宣贯，让大家都了解明确（我相信现在去问很多项目的团队成员，为什么要建设这个项目估计很多人都回答不上来或不完整）。这些项目级别的重要因素，个人建议通过项目墙或者项目网站的形式发布，整个团队在任何时候（至少在想知道的时候）都能知道这些因素。
3、选择项目的生命周期（项目开发模型）。
以我之前的经验，一般会先稳定系统的架构，在架构测试通过稳定后，选择按功能来迭代。根据团队成员的规模，会分成2-3个小组（每小组一般2个开发人员，1-2个测试人员，技术经理在各个小组间共享以指导业务和设计），每个小组负责一块功能，以2-4周左右为迭代周期，在周期中期开始采用每日一编（构建）来产出系统交付物，以让项目经理能一目了然的知道实际进度（查看交付物）。测试人员一开始就介入，与开发人员同步进行（用例设计和测试），在一个迭代周期中，完成对本周期内产出功能的测试。另外，在架构成型时，如果具有可视性交付物（比如portal框架），则应提交客户测试（主要就功能、界面、使用方便性等测试），提出改进意见。在每个迭代周期后期，如果时间上允许，建议引入客户参与功能测试，尤其是功能的操作方便性，流程合理性，界面美观性等。
从我们公司目前的应用开发来讲，系统架构一般都已经基本成熟完善，比如信用卡新系统架构已经定型，之后开发应用系统将会在沿用此架构和一些基础框架。
这里还有一点个人觉得很好的建议，即建议在迭代过程中，不要认为迭代周期短，功能比较清晰就采用模糊的进度管理（即完成30%，80%等），这样做很容易陷入“90%完成”的怪圈。应要求团队成员将功能分割为一个个的“小石子”（即原子任务，一般1-2天就可以完成，只有完成和未完成状态，没有完成百分比），这样完成了哪些“小石子”，还有哪些“小石子”待完成，对项目经理来讲一目了然，进度风险将大大降低。
项目的构建同样非常重要，因为构建出来的是最终项目交付物——系统（而不是一堆无用的文档或进度表上的70%这样抽象的数字），构建出的系统是项目经理判断项目进度的最直接和最准确的依据（如果进度表告诉你完成了90%，而构建出来的系统中100个功能中只完成了70个，那可以肯定的说进度表在说谎了），而且构建出的系统也是客户介入测试的前提（客户介入测试将提前识别风险）。
没有放之四海皆准的项目生命周期，不同的项目需要选择不同的生命周期，但一般来说大多数的项目还是可以有模式套的。
4、波浪式规划。
规划是在当前了解的情况和数据分析结果的基础上，对未来情况进行预测和安排。波浪式规划的依据是在没有对应的数据分析和情况了解，预测越久远的情况，与实际情况的偏离会越大；而因为有当前情况以及数据分析结果的支持，短期内的预测结果一般来说会较符合实际的发展趋势。当然可以在项目一开始时就完成整个项目周期的完整精细的规划，但既然时间距离较远的规划是不符合实际情况的，那又何必现在将时间浪费在这个上呢。个人认为，规划首先需要确定里程碑（当然也不可能很精确，之后可以做微调），里程碑可以认为是项目规划的骨架；然后采用波浪式规划来规划短期（2-4周左右，可以一个迭代周期作为一个规划周期），短期会相对精确（任务、资源等情况相对比较清晰）。波浪式规划提倡拥抱变化，根据实际情况的变化而改变自身，以适应当前的环境，这也契合了风险控制的本质。波浪式规划的好处在于避免了过度规划导致的时间上的浪费，项目的时间是很紧张和宝贵的，浪费不起的。
5、工时评估和日程安排。
日程安排不是项目经理一个人的事，而是全体成员的共同任务。项目经理需要召集所有项目团队成员（如果项目较大，则召集项目小组长）召开日程安排会议。首先每个项目团队成员各自识别任务（任务规模适中，最好在一个迭代周期内），并将识别出的任务记录到黄色即时贴上贴到日程墙上；接着确定各任务的次序和依赖关系，在确定次序和依赖关系过程中，成员之间会通过交流来确定任务的次序以及与其他任务的依赖关系，根据次序和依赖关系，调整日程墙上黄色即时贴的排列顺序（按照时间次序和依赖关系，从左到右排列），直至所有成员都一致认同此任务次序和依赖关系，类似日程墙上的日程图如下：

 

在日程讨论过程中，随着任务之间依赖关系等的清晰，风险会被进一步识别，我们在墙上开辟一小块地方专门存放识别出的风险和问题，以便在之后工作中考虑、解决或规避这些风险或问题。在完成任务识别及排序后，接下去对各个任务进行工时评估（如果项目较大，则由每个小组长会同小组成员对各自负责的任务进行工时评估）。针对每一个任务，需要分割成一个个“小石子”来评估工时，比如一个模块有几个功能，每个功能中包含增删改查以及批量导入等子功能，我们可以将每个子功能作为一个“小石子”，然后对这些小石子进行工时评估。工时评估有多种方法，近似类比法和扑克法较常用，估算也比较准确（《项目管理修炼之道》建议以人时来作为工时单位，因为团队成员在一个工作日不可能工作到8小时，一般开发人员在5-6小时左右，技术经理和架构师在3-4小时左右，其他时间消耗于沟通和任务切换损耗）。对工时的估算需在团队中达成一致，并将工时规模添加到之前贴在日程安排墙上的黄色即时贴上，这样一幅完整的项目日程图就完成了，可以通过拍照来记录快照。从此日常图上可以看出关键路径、任务依赖关系、项目大致规模、大致完成时间等项目信息，如果有需要，可以将此图转化为甘特图。日程安排会随着项目进展过程中实际情况变化而发生变更，需要不断对此日程图进行调整，一般1-2个迭代周期调整一次，不超过1个月。
几个很重要的建议：1、使用黄色即时贴来完成讨论和日程安排，相比电脑工具团队成员会有更好的参与和互动性。2、对每个任务都分解为一个个“小石子”去评估工时，这样会相对准确，也更容易在后期控制进度。3、在项目日程图完成后需要让整个团队成员知道和认同，如果可以保存在项目墙上或发布到项目网站上。4、日程图会根据项目实际情况不断的调整，不要害怕和担心调整。
6、沟通。
在项目过程中，项目经理上需要向出资方、需求方、高层领导汇报沟通，下需要与项目团队成员讨论交流，是项目中沟通的中心点。在大范围上讲，沟通是解决一切问题的钥匙，在项目管理中同样适用。
项目的背景、价值、因素优先级、目标、发布条件、日程安排、项目进度以及一些项目级别的决定，都必须要在整个项目团队中宣贯和发布，在项目团队中达成一致。这点非常重要，这是将整个团队的力量凝成一个方向的箭头。
另外还有一些必要的沟通技巧：
在获取项目关键驱动因素时，如果需求方或领导不直接提出关键驱动因素，则可以试一下假设法。试着问需求方或领导假设当前项目已经临近计划发布日期，不可能在发布日期完成，这时他们会怎么做，是延后发布日期，还是放弃部分不重要的功能，还是增加人力等等，从这些问题的回答中获取需求方或领导对项目因素的优先级排序。
在上司要求提供项目精确日程安排时，可以采用引入信心范围的做法或渐进法来做出回应，以避免在过早时做出盲目的承诺。
在与团队成员交流时，忌讳使用自己的想法去驳斥对方的想法，而应该顺着团队成员的想法，首先肯定自主想法，如果事情影响比较大，则需要试着去说理让成员理解团队整体的想法，如果实在不行再行使项目经理的权力也不迟。如果事情影响比较小，则建议帮助分析团队成员想法中的风险点，让他考虑和注意这些风险，并支持团队成员按他自己的想法去做。
对项目过程中比较重要的决定，或定稿的文档，原则上需要以邮件形式发送出来，并抄送相关领导。
7、风险管理。
风险管理贯穿整个项目过程，不断的识别和规避风险，去管理风险而不是逃避风险，积极的态度和思想对风险的管理非常重要。个人概括，在项目过程中风险的识别一般来自以下5个方面：
项目经理及团队的经验，包括通过数据分析识别的风险。
开发人员设计开发过程中的反馈。这一般是技术风险。
测试人员在测试过程中的反馈。进度风险为主，也有技术风险。
客户（使用人员）在测试和使用过程中的反馈。主要是界面、流程等方面风险的反馈。
交付物（文档、系统）的反馈。产出及时性、完整性以及质量上的风险。
迭代的开发模式、测试人员尽可能早的介入、阶段性客户测试反馈、以及基于交付物的规划和每日一编等风险控制手段的重要性不言而喻，分析方法和工具在风险控制中也非常的重要（比如挣值分析）。

上面几点是我的一些想法和共鸣，其中必定有很多的谬误，还请包涵。最后想用一句话对项目管理做个概括和理解：以拥抱变化的思想作为指导，充分沟通，积极管理风险，以迭代的模式管理过程、管理任务。

最近和一前辈交流了一下关于项目管理方面的一些看法。谈了很多，从一开始的计划和日程安排到项目管理的本质，从小石子到因材施教般的团队成员管理，反正谈了蛮多。前辈多次提到项目管理的本质是资源管理、沟通、和熟悉事情的轻重缓急，将资源优先使用于重要事情任务，优先保证重要事情和任务的进度推进，并通过迭代来推进项目，过程中还有一个非常重要的点就是不断的对工作进行总结，比对项目计划于实际进度之间的差异，并找出差异的原因，识别出风险，并执行一些措施来规避风险和解决问题（找原因和解下措施是最重要的）。并且告诫我：管理是活的，而规则是死的，不要被教科书上的条条框框给框死了，要懂得变通。前辈的一席话对我的帮助很大，想把这些金玉良言记录下来，为以后的发展能起到帮助。下面就几点说明一下交流明细和我的一些思考：
1、计划和日程安排。我的理解计划是里程碑和较大颗粒的任务，说明了项目进度过程中的一些主要时间点，阐述了大致在什么时候可以完成什么任务这么一种概念；而日程安排则是一种细粒度的任务执行顺序，定义了资源、任务和时间三者的关系，阐述了谁在什么时候完成什么任务这样一个概念。前辈认为计划可以分为高阶计划和比较细的WBS分解计划，高阶计划是一些里程碑和较大粒度的主要任务，和我的理解比较吻合。我们都认同计划里程碑和主要的任务（即高阶计划）是需要的，这就好比是计划的骨架（骨架是可以调整的）；在骨架基础上再进行波浪式规划，规划处每个迭代周期的WBS分解计划，无需浪费时间在未知的计划上。project的mpp文件包含了计划和日程安排，是计划和日程安排融合后的共同体。
2、目前大部分人对项目管理是处于对事情的管理，也就是如果管理的项目是熟悉和精通的，则管理起来得心应手；但一旦管理的项目是陌生的，则管理起来会碰到很多麻烦。这就是典型的处于事情管理的阶段，对事情熟悉程度和控制情况决定了项目实施的难易和成败，小项目容易成功，但大项目管理起来比较吃力。而比管理事情更高的一个境界是对资源（主要是人）的管理，在这个境界的项目管理者，能很好的协调项目内部甚至项目外部的资源为项目所用，项目经理可以不清楚一些任务的细节（因为项目经理的主要精力不可能到达这个程度，而且团队中自然会有人来搞这些细节），在这个阶段的项目管理者，主要是协调资源和建设自己的团队（因为需要了解的团队成员来完成正确的事情）。
3、接着又谈了对将任务都分解成小石子的看法，前辈认为如果项目经理去分解，则项目经理没有这么多的精力，如果让团队成员自身去完成分解，则无法保证分解的正确性。我在事后也好好的思考了这个问题，因为限定在一个迭代周期中，需要迭代实现的功能不会太多，所以相对来说，容易分解，我们对小石子分解做适当的改良，使用有时间盒来限制花费的时间（半天内），按功能进行分解，如果是较大的项目，则必然会有好几个小组，则由小组长组织小组成员分解自己负责的功能为小石子；如果是较小的项目，则由团队成员分解自己负责的功能为小石子，并由技术经理（或项目经理）指导或复核。这样的做法我个人认为还是可行的，既不占用项目经理或技术经理的大量精力，同时又能避免过度分解、浪费时间的问题，又可以保证分解出的小石子的基本正确性。这个想法还有待实践的检验。
4、然后谈了沟通的重要性，尤其谈了对团队成员的分别式沟通和管理，即对有不同特点不同能力的团队成员做不同的管理，比如对细致有余而全局观不足的团队成员，需要经常与他（她）交流，让他（她）认准大方向，不要迷失于细节中；而对技术习惯比较粗糙的团队成员，则需要通过提醒让他（她）认识到质量的重要性，并通过review来避免不必要的风险；而对能力出众又知道目标的团队成员，则只需要确认目标（在什么时候完成什么任务），给他（她）最大的自由去完成任务，而不要管的太细。当然这种分别式沟通和管理做起来是不容易的，这需要项目经理了解每个团队成员的特点和能力，这需要平时的不断沟通和了解。
5、最后谈到了进度的控制，一致认为使用交付物来判断进度是最好的（这也鼓励在规划时使用交付物产出作为规划的依据），前辈认为在WBS计划分解时应说明产出的交付物（这样才能在计划执行时能得到产出交付物的反馈）。但在迭代的早期，一般无法产出交付物（比如迭代的第一周，很有可能还无法产出可视化的交付物，当然代码是可以产出的，但从代码中很难判断进度），这时如何判断进度会比较困难，前辈认为根据团队成员提供的进度来确定项目的进度（这要求信任成员的判断，带有一定的主观性，当然如果是对很了解的团队成员这么做完全没有问题），我提出建议认为可以引入小石子方法（即之前第3点中阐述的对任务分解为小石子），以一种量化的方法来评估尤其是迭代前期的进度。在迭代后期因为有产出的交付物，将相对来说比较容易判断项目进度，同时提倡每日一编（构建）的做法，有较多的好处。