2013.6.16 **一、萝卜+大棒失效了？** 是的，萝卜+大棒的简单易行的激励方法已然不能满足IT行业团队管理的需求。原因大概可列举为以下几点： **1、程序员是个特殊的人群**    程序员是一群喜欢自嘲，表面谦虚，但实际内心有追求，有坚持，甚至有一点孤傲的知识分子。我们在追求物质幸福的同时，也非常关注自身的成就感，成长性，前途等。激励本质是适时满足员工的诉求，因为程序员诉求的多样性，也导致团队管理肯定不会有一招鲜的方法。 **2、工作好找，员工对公司同样有选择权**    IT行业在最近几年处于中兴期，属于创意迸发的巅峰，与人们的生活越来越近，IT的很多细分行业都面临着重建，洗牌的过程，现有的很多IT公司获得了跨域性的成长，很多新公司成立。变革的新技术层出不穷，云计算，虚拟化，网络SDN，移动互联网，智能手机等等，这些都给IT从业人员创造了很多从业机会，人才的价值也是水涨船高。    这种大背景下的IT人员可选择性很强，跳槽通常能够带来薪资的大幅增长。公司都为留住核心及有潜力的员工绞尽脑汁，很多项目经理的考核中“人员流失率”就是关键项之一，这种情况下的大棒，实在难以高举。 **3、项目经理的权限不够，通常没有直接权限提升员工的待遇**  对于主流公司的组织结构里，项目经理都是从属一个部门，一个部门里会有多个项目，多个项目经理，员工的工资待遇存在项目组间的横比问题，所以员工的工资待遇的提升都是由上级主管进行，当然项目经理有建议权。 激励进入了困局，大棒无力，萝卜没有分量，还有其他方法吗？ **二、怎样更有效的激励员工？**    现在流行的激励理论有很多，包括：期望理论，成就理论，maslow需求层次理论，X-理论，Y-理论，赫兹伯格双因素理论等。在这其中我一直认为双因素理论是最适合IT行业。 简单介绍下双因素理论：    在双因素理论的主要研究发现，使职工感到满意的都是属于工作本身或工作内容方面的；使职工感到不满的，都是属于工作环境或工作关系方面的。前者叫做激励因素，后者叫做保健因素。    保健因素包括公司政策、管理措施、监督、人际关系、物质工作条件、工资、福利等。当这些因素恶化到人们认为可以接受的水平以下时，就会产生对工作的不满意。但是，当人们认为这些因素很好时，它只是消除了不满意，并不会导致积极的态度，这就形成了某种既不是满意、又不是不满意的中性状态。     那些能带来积极态度、满意和激励作用的因素就叫做“激励因素”，这是那些能满足个人自我实现需要的因素，包括：成就、赏识、挑战性的工作、增加的工作责任，以及成长和发展的机会。如果这些因素具备了，就能对人们产生更大的激励。   对应到项目团队的管理，保健因素项目经理要做到能赢得组员的信任，激励因素项目经理要去营造这样的团队文化。   1、赢得信任   赢得信任，意味着员工愿意在你的项目里出力，他们相信他们的付出会有相应的回报，并且他们相信长期跟随你，将在公司里获得好的发展。要知道每个人都有自己的口碑，项目经理的口碑也是一点一点积累起来的，没有其他捷径可走。要做到赢得团队信任，至少要做到以下两点：   **公平公正，奖罚措施透明化并且言行合一，**提前给大家设定明确的期望及奖罚措施，能够让大家知道达到什么样的程度算是合格、算是超预期，期望可以和大家一同讨论。在确定目标后在团队内公布，透明化的好处是去掉灰色地带，避免猜疑。猜疑是感情受到伤害的主要来源。  例如：小A在项目组内担任组长，组内一个组员工作没有做好，带来大量返工，小A很辛苦的加班几个星期和组员一起解决了问题，但是绩效考核时，小A的结果只是B+，小A认为很委屈，自己的编码工作完成的很好，其他四个组员也不错，虽然有一个组员出了问题，自己也辛辛苦苦负责任的和他一起完成，尽管项目经理强调，公司是以结果为导向，但是小A还是认为经理对他有偏见，故意找自己的小鞋。  言行合一讲得是“不轻诺，诺必行”，可以看看CSDN大家的水贴里有多少是抱怨经理们经常忽悠大家的。“嘴上一套，手上一套”是损害个人威信最快的方法，要相信群众的眼光是雪亮的，一切骗人的小技巧终有被揭穿之日。     不和组员争功，无论是做管理或是做技术，成就导向是一个优秀员工的基本素质。只有有很强的成就导向意识才能把事情做得超预期，才能追求卓越。刚刚上任的管理人员的思维方式往往还处于个人成就导向阶段，他们希望向外界发出一个明确的信号，团队之所以取得这样的成绩或是解决某个难题，是因为我的组织、领导。然而这种信号被团队成员多次接到后，会产生功劳都被头头拿走的感觉，从而导致团队的向心力下降。这时候的好的做法是：要保护团队成员的成就导向，并且进行鼓励，从而刺激大家的积极性。  例如：和某个团队成员共同解决了某个难题后，要弱化自己，而重点表扬这个团队成员对这个问题的贡献，这样这个团队成员下次再遇到某个难题时，才能保持一样或更高的激情。  只有将自己的成就感定位在团队成就上，才能站得更高，避免和团队成员产生直接竞争，从而有效的领导自己的团队。 2、团队文化建设    **建立双赢的项目愿景**，在《活法》稻盛和夫提出过这样的观点，大概意思如：工作和生活都是一种修炼，这种修炼让我们改进自己，完善自己，真正优秀的人往往不是聪明绝顶的人，而是肯耐下心，持续积累，持续改进的人。我相信任何工作，任何项目都能找到和大家共鸣的改进点，项目经理放大这些共鸣点，和大家一起成长，则是一个好的愿景。这个共鸣点可能是“成为某个模块的专家”，“做事更细心”等，并在项目计划里安排相应的培训、交流，则容易让大家对当前的工作感到有意义。      善用团队影响力，金钱上的奖罚，不好量刑，量刑太轻没人重视，量刑太重容易产生怨念。在《沧浪之水》一书中，作者曾说过，人活在世上的其中一个重要的意思就是被人看重，年轻人都有想出头的愿望，一个团队上的公开表扬，大家的认可度很多时候会超过2百元人民币带来的幸福。从项目开始我们在项目沙盘里我们讨论出哪些可以做的更好，然后奖励，哪些应该做好可能做不好的需要惩罚，以保证项目的成功。奖项的设置需要保证项目组的人人机会都是平等的，不能设定奖项时便倾向某个群体。     例如：开发指导测试最认真、负责的，由测试部评定出前两名研发进行表扬，在转集成会议上时，由项目经理或部门主管给予两张电影票进行奖励。     提交代码都编译错误的人员，累计两次后，给整个项目团队买饮料喝。      关注做“杂活”组员的贡献，项目组内总有一些工作是不容易看到贡献的，例如：搭环境， 合入代码等，被安排做这样事情的员工或多或少都会有一些不情愿，项目经理应该对他们投以一定的关注，他们的工作同样可以超预期，并且在公开场合认可他们的贡献，就很重要了。   高压力问题共同分担，在组员遇到疑难问题时，尝试无果时，应该由自己或安排技术专家同他一起努力解决，至少能够在思路上进行指导。当面对压力时，能够有个战友互相分担、讨论，并最终解决，本身是件很有成就的事情，但是如果只是一味独自承担压力，则会有崩溃的可能。   当整个团队面临重要问题时，项目经理应该身先士卒在最前面，例如：加班应该随同大家一起加班等。   **尊重员工的劳动付出，少些秋后算账。**项目经理要经常思考的事情是尽量让团队少走弯路，不能在自己没有想好一件事情怎么做的情况下，当组员做完后，大发雷霆。在组员开始做某件事情前，至少能够明确完成的标准和期望，如果当前不能明确，则过程中要积极查看并反馈，不能在员工付出劳动后，才说明自己的期望，然后来一招“秋后算账”。

2013.6.12 联调有3个目的： 1、将项目组的代码整合起来，这点在好的项目管理中编码阶段已经完成了大部分的集成工作。 2、保证系统的质量，避免后期的大改动，之后转集成阶段 3、进行质量评定以调整测试策略 按项目管理的五要素分解如下：  **1、干系人期望-目标**    编码阶段干系人的影响已经很小，先不讨论。      **2、沙盘-思路**   1） 代码覆盖率      只有被跑过的代码才是安全的，之前的任何假设只有通过验证才能得到结果。代码覆盖率是保证质量的一个基本指标，通常这个指标在85%左右。而更加严厉的指标是代码的分支覆盖率。当我们发现代码覆盖率不够时，可以使用调试单步执行，新的单元测试案例，新的测试案例来增加覆盖率。      2） 执行BVT      BVT是指系统、模块的基本功能案例，在联调阶段执行通过这些案例的意义在于：控制集成测试阶段的改动并防止测试阻塞。正常情况下，转测试后，每次bug的修复改动代码应在100行以内，改动太大会导致回归测试成本增大。      3） 性能测试达标      如果一个系统的性能指标不达标，那么及有可能会导致集成测试阶段的代码/方案改动不可控，因此性能测试达标应是系统进入集成测试的一道关卡。      4）冒烟自动化测试      联调阶段正是合适的时机准备和启动冒烟自动化测试，冒烟自动化的案例至少包含系统主要的BVT案例，当冒烟环境搭建成功后，每次重新打包后，这些自动化案例将自动执行。这样能够保证每次新包的基本质量，且能很快发现问题，而问题引入通常是当前包的改动导致，所以也缩小了代码的排查范围。 **3、计划制定**   1） 联调计划      根据编码阶段的情况，我们有可能需要适时调整联调计划，例如：模块案例执行的先后，个别模块要晚点集成到系统里等。 **4、风险管理**       1） 核心/基础模块阻塞      联调时当出现核心或基础模块完成进度延期，会导致其他很多关联模块无法继续调整，这时要立刻安排接口桩（接口可返回固定值），以便其他受阻塞的模块能够按计划联调。            2） 仓促转测试      项目当前的质量和进度是需要平衡的，项目经理对此要做到心中有数。这时候项目有两个因素需要考虑：      a、已经准备好的测试案例要执行一遍，如果风险可控，可以在这个过程中控制质量      b、bug的修复成本越到后期，修复越高。如果有大的质量问题导致返工，那么回归测试的工作量更大      新的版本经理往往迫于进度压力，会选择忽略当前质量风险，进入测试阶段，如此项目组将在测试阶段将承担很大的风险压力。而过于谨慎的项目经理计划在联调阶段消除所有的质量风险，这样会导致后期的案例执行压力很大。此时合适的做法是分析出高风险的地方，进行质量加强，例如：做专项审核，走读，加大测试力度等，将风险控制在可控范围则进入测试阶段。      3） 识别出风险模块      虽然管理上我们尽量消除所有风险， 但当精力受到制约时，我们也只能关注高风险区。世界不是完美的，项目中我们总是有机会遇到风险模块，在联调阶段要将他们识别出来，并制定改进方法，并辅以测试策略进行改善和控制。 **5、团队管理**       1） 项目组阶段总结      联调阶段是项目组的一个重要里程碑，意味着项目组已经完成初品，此时项目的质量、进度情况已经比较明朗。同时这个阶段也是一个转折点，联调之前的工作计划以开发计划为主，测试辅以缺陷预防，之后的工作将以测试计划为主，开发要进行积极配合。此时总结应分为两部分：       a、项目组总结            这部分通常由项目经理讲述，包括但不限于：项目整体的进度、质量情况、之前阶段的沙盘落实情况、下一步的计划与工作思路。      b、个人总结            个人总结的目的在于：总结之前的经验，听取其他人的经验教训，整理出下一阶段的具体工作思路。好的经验总结的内容应该包括但不限于以下点：             1、总结需求阶段，设计阶段，编码阶段，好的经验，坏的教训。             2、罗列出当前自己工作的风险，并给出措施，包括测试建议             3、整理出自己可以提高的地方             4、给项目组提出改进意见             **虽然愿望是好的，但是程序员很多时候不擅长总结此类经验，或是有总结习惯的不擅长表达出来，这里是执行的难题，后续会有章节专门分享如何让此措施更有效果**。       2） 里程碑庆祝点      如上第一点所说联调是个非常重要的里程碑，那么里程碑时进行庆祝及颁奖就是很必要的了。一个不会庆祝的团队是不会有战斗力的，这是激励的作用。在此时落实之前的对团队的各种奖项约定就是非常合适的，同时在颁奖之后可以设置后续阶段的奖项。至于团队庆祝方法可以选择喝酒，吃饭等，依照公司及部门文化而定。      **关于团队的奖项，很多时候项目经理苦于经费有限，无法开展此活动，因此放过了大好的团队建设机会。后面的章节计划分享下”如何以手头的有限资源最大化的激励组员“这个话题。**

     2013.6.11      如果说一个男人最有面子的事是身边常伴漂亮的女伴，引别人侧目。那么程序员最有面子的事，一定是写下的漂亮的代码，引无数草莽感叹。有趣的是，我们总是有机会看到这样的现象：一些老模块虽然设计不好，但是代码质量不错，所以依旧稳定，但是一些设计理念很好的模块，却被写得乱七八糟，漏洞百出。      代码是设计的最终产物，是一个程序员基本功，偷不得一分巧。如果一个人总是喜欢高谈阔论，那么去看他的代码，通常一眼看下去，就能知道他是“真正的高手”还是“空想家”。        项目管理的代码管理，通常期望达成以下几个目的：       1、避免出现杀手：“高手不是培训出来的，也不是管教出来的“，高手之所以视为高手，是因为其很少见，而成就高手的素质通常不是众生常具备的。但是项目组内的隐藏的杀手，却可以通过管理降低其出现的风险及危害。A/B角审核，签入代码控制等这些都是关卡。       2、保证代码质量：代码不一定能像高手写的那么极端漂亮，多一分便肥，少一分便瘦的地步，但是却可以通过管理保证大家代码的逻辑清晰度，可读性，减少边界错误，减少低级错误等。例如：工具扫描，单元测试，每日构建等。       3、培养人员：“近朱者赤，近墨者黑”，影响的力量是巨大的，通过编码阶段的互动交流，可以让一部分组员能够快速脱离”山寨“，进入”职业“状态，尤其对新员工有效。       按项目管理的五要素分解如下：  **1、干系人期望-目标**    编码阶段干系人的影响已经很小，可以先不讨论这节。      **2、沙盘-思路**      1）开始前挂牌讲解好的代码     同设计一样，很多时候往往不是大家不愿意写出好的代码，而是大家不知道好的代码是什么样的，因此在项目组开始编码前，讲解优秀的代码，会让组员开工之前，有一个学习的目标，会让编码工作变得更有意思。这里更好的做法找出那些和本项目组有关的优秀代码示例，更是事半功倍，例如：部门类似业务的好的代码。     2）公开走读计划     记得在管理上有个研究工作效率的故事，发现把工人召集到一个实验环境中，在设施完全一样的情况他们的工作效率和质量比平时都有大幅提高，逐个排除了很多影响因素，最后发现原来是”关注度提高“的原因。人都是有表现欲，当自己手头的上事被关注时，往往我们希望把自己最好的一面表现出来，人性如此。代码走读就是这个作用，大多数时候提前公布的走读计划比实际走读出那几个问题更重要。     安排走读计划时，需要注意到这几点;     a、走读成员要有威慑力和权威性，避免大家扯皮。例如：找专家，架构师，主管等     b、走读的结果无论好坏，都要公布，以便项目组形成一股良性氛围     c、当项目组模块很多时，可以抽查一定比例的模块走读，这样在走读计划公布时，不要明确模块，避免没有在走读计划内的模块作者，暗自庆幸。      3）A/B角审核     只有走读计划是不够的，因为走读通常要不少人参加，不可能将时间拉得过长，因此很多细的逻辑审核不到。另外走读模块往往是在这个模块代码已经或接近完成时，时间点偏晚，有些”木已成舟“的味道。和走读计划相配合的是进行A/B角审核，我们可以在设计或更早的阶段，明确项目组的A/B角关系。A/B角的好处在于，代码得到及时审核，测试阶段A/B角可以互担压力。     A/B角的常见组成方式如下：     a、项目组分成小组，组长担当B角     b、项目组有某些模块的专家，这些专家担当对应领域的B角     c、一个模块有几个人共同完成，他们互为A/B角     d、项目组不大时，由项目经理或质量经理担任B角      4）代码checklist及工具扫描     代码checklist是将大家常犯的共性错误集合成的检查表，例如：一些潜在的死锁风险，C++用法等。而工具扫描是为了排除一些低级错误，例如：内存泄露。 很多时候低级错误的排查bug的难度是不低的。      5）单元测试     做好的单元测试的核心在于两点：     a、要有好用，省时的单元测试案例编写工具，例如：C++ Test等     b、管理好单元测试案例，不能只做一次，而是每次代码发生变化，每次代码重新编译时，都能自动执行单元测试。如果单元测试只能用第一次，投入产出比，就会小很多。     c、能够在目标机上执行单元测试案例，这样能够避免大量打桩，导致工作效率下降。      6）代码签入控制     代码签入控制往往是强制A/B角的实施方法，即：收回A角的代码签入权限，只允许B角签入，如此能够保证B角的审核频率能够达到每个包一次.      7）每日构建     每日构建是指编码开始后，每天环境会自动从SVN/VSS上获取代码进行编译，并执行对应的单元测试案例，每天早上通报错误。每日构建的好处在于：系统在持续良性集成，避免联调开始后，大家一窝蜂的把代码签入，有大量的编译错误等，消除这些错误需要消耗很多时间，并容易犯错误。 **3、计划制定**   1） 代码走读计划      代码走读计划如上述第二点，需要提前预约专家，架构师等，并在项目组进行公布。      2） 配置管理计划      涉及到代码签入权限，编译环境维护权限等。例如：一个大项目组，如果编译环境没有控制权限，没有指定操作规范，很容易被大家搞乱套。      3） 单元测试计划      不是所有情况下，用单元都是合适的。例如：对于一个老模块的改动，此模块依赖很多外部资源，并且之前没有任何单元测试案例，这会导致编写对应改动的单元测试案例，成本很高，此时需要进行权衡投入产出，可能这时找此模块的专家进行审核是个更好的选择。 **4、风险管理**     1）编码进度不透明    大多数人都习惯先松后紧的工作方式。“犹记得大学时，老师布置了作业，两周期限，下课是交作业的最后期限，上课时，班上大多数同学们都是拿着借来的作业奋笔疾书”。编码阶段的时间在转集成前各阶段中，算上比较长的。而这个阶段的工作进度非常不好衡量。经常看到一个模块编码进度迅速从0%到90%，而后花了两倍的时间才从90%到100%，无法有效得知项目的进度，就是项目的风险。     这里有个好的做法可以参考，编码计划表从估算表中导出，因为估算表中每个估算项粒度通常不会超过2天。这样在编码进度表更新时，去除百分比，只能更新两种状态，未完成，完成，如此计算出的项目进度是比较准确的，同时也能够帮助组员理清当前自己的工作进度。   2）新员工代码质量    新员工的成长是需要团队付出精力的，针对他们我们往往要有更频繁的代码审核、指导 或安排责任心更强的B角。虽然新员工的操心在所难免，但是他们潜力也是无限的，耐心地培养后，总能从中收获到惊喜。    3）识别出风险模块     项目组的进度不同于齐步走，总是有前有后，质量同比也是有好有坏，那么在整个过程中通过上述的种种办法找出这些有风险的模块，进而采取调整措施是项目管理中不可缺少的部分。        4）需求实现有遗漏    任务分解时往往并不能完全根据需求进行，在代码实现时，因为大家的思维已经在很细节的层次，所以此时核对系统需求或需求跟踪矩阵，就很容易发现需求的遗漏项。 **5、团队管理**     1）每日构建有奖惩    有奖惩是为了提高大家对这件事的重视程度，当然每日构建通常犯的错误不是很严重，而且易于发现，针对这种场景，不适合采用过于严厉的惩处措施就不合适了。例如可以采用如下措施：    a、累计错误数，如果项目组整体达到5次，造成错误的同事请项目全体成员吃水果或喝饮料。    b、每天系统自动通告构建的结果   2）走读计划有奖惩    走读计划因为动用了外部资源，比较权威，惩处和奖励要重一些。例如：对于代码走读结果不好的组员，本季度取消得A资格，走读结果好的组员，给予奖品及季度优秀的考核。    3）进度在项目组定期通告    每周至少一次项目组在一起回顾上周的进度和下周的计划是很有必要的，这样容易让大家对整个团队产生归属感，并且能够得知其他人的工作进度，有个横比，从而能够自我进行进度调整。    4）严格执行计划    此阶段的项目计划的时间点是确定的，除非项目经理有把握控制后续的进度，否则尽量不要调整里程碑点。

2013.6.2 设计能力是技术人员水平的主要象征之一，项目组的技术人员跋涉了前面的各个阶段，终于迎来了由他们自己主导的时间。优秀系统的总设、优秀的模块的概设追根到底是设计人员的自己能力的展现，这要求他们有足够的视野，经验和思考。项目管理在设计阶段主要起到的作用是： 1、帮助设计经验不足的组员进行缺陷预防，保住设计质量的底线 2、给予经验丰富的专家以明确的目标，以便进一步提高设计的质量 3、降低返工的风险 按照项目的五要素，设计阶段分为以下阶段(图片可放大网页看)：  **1、干系人期望-目标**     在项目流程中划分总设，概设，详设的主要目的是：     总设：根据架构和需求将系统划分为多个功能和基础模块，并定义清这些模块的交互方法及接口。     概设：模块概要设计是将模块拆分成多个子模块，并定义清子模块间的交互方法及接口。     详设：将每个子模块的内部逻辑，流程图，甚至伪代码理清，为后续的编码直接服务。     在设计阶段常见的干系人：     1）主管/产品经理：他们主要期望产品的稳定性及扩展性，通常一个设计被大家认可，至少要包含这两方面中一个因素。           基础功能的稳定性能够迎来客户的好感，而扩展性能够降低后续再次开发的工作量，会被主管和产品经理所期望。稳定性通常在产品需求中会进行要求，          扩展性往往是可以获得亮点的突破口。     2）技术支持人员/客服人员：他们期望系统及模块能够被方便的调试排查问题，即设计的可维护性。     3）测试团队：测试期望开发在设计阶段能够考虑清自动化测试的方案，以便能够降低执行测试及回归测试的工作量。     4）项目经理/主管：在总设阶段能够抽出公共代码以便降低当前版本的风险及工作量，同时能够为后续的项目提供帮助。      **2、沙盘-思路**     1） 开始前挂牌讲解好的设计及槽糕的设计     能够做好一件事情的前提是，要当事人能够清晰“好”的判断标准是什么？如果要超预期，首先要当事人了解到“期望”是什么？因此对于新员工或是设计经验还不足的组员，能够帮他们理清“怎么样的设计才算是一个好的设计”至关重要，这样他们才能够在正确的方向上投入他们的精力。而做这件事情的一个最好的办法，就是开始设计前讲解当前部门或公司里的典型好的设计及坏的设计，如此这样能够让大家在出发前得到一个方向上的共识。需要注意的是：槽糕的设计教育的意义往往用处比好的设计更大，因为好的设计需要积累和灵感，而槽糕的设计往往是可以避免的，一个中规中矩的设计不是一个很高的要求。     2）健壮性分析     对整个系统及关键模块做健壮性分析往往非常有必要。因为当系统或关键模块遇到异常往往会给客户带来巨大的影响，甚至是不可恢复的损失。健壮性分析的主要的方法是罗列可能遇到的异常场景及系统或模块应该做出的处理如何。     例如：给客户提供用户认证的模块应该至少应考虑如下异常场景：               1）当系统内存不足时，如何保证认证的优先级               2）当进程出现假死后，如何检查出来，防止长时间无法影响认证请求               3）程序崩溃时，如何快速恢复进程               4）设备掉电或程序崩溃时，如何保证已经通过认证的客户，不用全部重新认证               等等           3）扩展性分析      扩展性对于可预计会经常变化的业务模块尤为重要。达成好的扩展性的方法是通过“高内聚，低耦合”，将业务代码和逻辑代码分离来实现。好的扩展性可以大大降低后续的开发成本，对于持续化的项目非常重要。      例如：做一个抓包的协议分析软件（譬如：wireshake），它的扩展性主要在于              1）后续可能会有更多的协议需要分析              2）后续可能会有更多的包分析结果的呈现方式              将这两部分做成插件式加载则是非常恰当的设计          4）可维护性分析（自动升级等）       可维护性设计通常包含两部分;        a、当系统或模块出现故障时是否容易排错        这里便要求系统或模块设计便提供方便的排错方法，以上面提到的用户认证为例:        例如：日志分级，我们可以将用户认证步骤分为12个步骤，并将每个步骤打印一条日志，则方便追踪问题。                   内存打印，从后台输入参数可以将指定用户或所有用户当前的内存状态打印出来。        b、当系统或模块出现故障时，修复成本及风险是否可控        对于做产品的企业，一个故障排查出来后，通常外面在使用有问题的产品的客户已经很多，这时候能否方便，快速的更新则非常重要。而能否方便和快速，取决于系统或模块的可维护性。         例如：一个产品本身有自动升级功能，当前排查的故障在于网络流量更新，导致插件功能失效，同时主程序对插件有强校验，这时候我们就可以快速得将新的插件更新到网络上。     5）自动化测试分析         好的设计应该从一开始就为自动化测试进行考虑。一个系统或模块能够方便编写出基本功能的自动化测试案例对于质量是件非常有益的事情。以协议分析软件为例，我们可以设计如下的自动化方法：        a、编写一个工具可以生成指定协议的数据包         b、系统可以从文件中直接load数据包，进行协议分析，并且自动校验是否与输入期望的结果相符     6）方案选型评审        在设计开始之前，设计者应该将自己的想法及方案讲述给专家，方案选型的文档不要求复杂，可以是一封邮件，可以是一张图，但是做了这件事，能够避免设计大量返工。不得不说在工作中，经常发生一些诸如此类的感慨：“这件事怎么想成这样？” “这个肯定要重做了”等，这些都是没有做好基本思路确认的问题导致的。 **3、计划制定**   设计阶段的评审工作量是非常大的，如果此时项目组需要很多外部专家的把关，则需要提前和这些专家协商出一个时间并统一制定出一份评审计划，以防止评审时间延拖，导致下一个阶段的工作无法完全启动。 **4、风险管理**     1）太重技巧，过度设计    不得不说确实存在这样一些同事喜欢滥用或是说过度追求设计模式，本来一个不复杂的模块，生生要套上几个设计模式，搞得继承，多态一大堆，代码可读性大大下降。所以这里要需谨慎，事实往往证明经常夸夸其谈设计模式、方法的人，通常或多或少都有过度设计的毛病。因此对不熟悉的组员，不能仅根据其言行，便主观降低他的设计风险。   2）逻辑不周全，设计不足    相对于上个风险来说，对于一些设计经验不足的同事，往往习惯把一件事情看得简单化，导致编码阶段有很多意想不到的“惊喜”发生。经过好的详设后编码应该波澜不惊，不能有大波大浪。对于这些组员时，有一个基本的设计方面的流程约束就显得很必须了。  例如：详设必须把主要的函数都画出流程图，经过评审。 **5、团队管理**    1）新员工有师徒制    新员工往往没有什么设计理念，这时候不仅仅是评审和理清思路就可以解决问题的。这时候他们需要更加细致的指导，因此给他们安排一个师父，就很必要了。    2）评审时指定负责的专家    大家很多时候对于和自己没有直接关系的事情，会抱着得过且过的状态。在设计文档评审时，也有可能发生这样的情况。因此在评审前明确哪个专家需要对设计负责，会对质量把关非常有益处。    3）严格执行计划    经过估算后，设计阶段已然有明确的计划。制定项目计划时我们要尽量民主，但是当计划制定下来后，要维护其严肃性，不能一味的调整。    例如：有计划延期，无法调整时需要加班解决，也是在情理之中的，否则项目计划很快会成为一纸空文。

**一、背景** 由于公司及部门的发展，项目经理已经开始面对人数众多，时间跨度较长的版本管理挑战。 如张湘辉（1994年加盟微软，现任微软大中华区CTO）所说： 以Windows 7为例，包含七八千万条甚至上亿条代码，五六千人同时开发，还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言，不能一眼盯到结果，不能像跑百米一样，始终盯着终点。我们的经验是盯终点肯定乱，因为要经历非常漫长的过程。 从心理上说，当发现离终点还很遥远时，人就会泄气，不能以那么快的速度玩命跑下去。最好的方式，是将事情分成很多步骤来做。Windows7从开始到完成可能要耗时两年，以两年时间为一个周期，那么前六个月团队就会被弄垮，所以你必须以也许每两个月为一个终点。就像跑一千五百米，我们要考虑第一圈跑多快，第二圈跑多快。 这就需要把每个终点区分得很好，设定有效的里程碑，在逻辑上要很精准，是不是到了这个里程碑，同样要非常清楚。这样每个里程碑达到时，大家可以庆祝一下，重又奔向下个目标。如同爬珠穆朗玛峰，没有说不断爬上去，而是先到大本营，再到第几个营地，最后才能登顶。 从过去的3.0，BM2.0等较长时间的版本管理中，能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分，例如：转测试，转联调等，项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准，满足则进入。总体来说项目还是以最终发布时间点为目标，这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法，产出里程碑管理的概念。 **二、目的** 里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果： 1、 使团队将长期目标划分为不同的短期目标，就像跑长跑一样，不是以5W米为目标，而是把目标分解到每一圈 2、 在里程碑处，团队进行有效的休整。就像队伍打仗时，一定要有休整，才能持续保证旺盛的战斗力 3、 促使组员进行上个阶段的总结，找出自己的不足，并吸取其他人的优点，从而让组员进行成长 4、 整理下个阶段的工作思路，促进大家进行整体思考，并对模块进行全面分析。 **三、具体内容**  1、给予项目组时间，进行全员总结，包括上个阶段的总结，下个阶段的工作思路，做成PPT 2、由每个人在会议上将自己的总结PPT进行分享 （做成ppt并在项目会议上进行分析，会引起大家的重视，自然效果会好） 3、进行表彰，表彰做得好的人员，由主管亲自颁发奖品（结合奖励措施） 4、用本小组经费进行欢庆，吃饭+KTV之类 **四、计划支持** 1、项目计划中安排好总结时间 2、制定里程碑奖励措施，并且在上个里程碑点处进行宣传，过程中进行相关数据统计 3、向公司提前申请所需的时间和金钱资源

知识型工作者只有让他们感到被尊重，被认可才能激发出他们的工作热情。制造业工厂监工式的管理方法，绝对量化的考核指标在知识型团队管理中将会失效， 这是管理人员面临的挑战，德鲁克也在《卓有成效的管理者》中对管理者和这种监工做了明确区分，其中的观点是监工是上司，但不是管理者。            一个抱着积极、认真负责，打拼事业心态的员工做事的有效产出和机械完成任务的人员的有效产出是多么的不对等，这里不需要再列举各类研究结果。尊重是激励文化构建的基石，如果没有尊重，激励就是空中楼阁亦或是短暂的激情。本篇笔记重点谈谈在项目管理过程中对如何给予员工足够的尊重。 **1、项目的意义**  成就感是让团队努力向前的最好激励方案，任何项目的成立都是有意义的，如果能够让整个项目团队时刻清晰的认识到自己是再做一件对部门、乃至对公司意义重大的事，则往往能够焕发出团队很强的战斗力。受到关注就会给人被看重感，人就感觉到要对事情付更多的责任。  推荐策略：1）项目启动时，高层领导进行动员，宣传项目意义                    2）项目中期，规划负责人/项目经理要能定期发出一些市场人员/客户对项目的期望                    3）项目结束后，高层领导要能够反馈项目获得的成绩 **2、项目时间估算**  我个人比较推崇的估算方法是自下向上的估算（具体可以上篇文章：时间估算的三步曲），自下向上的估算能够给予项目组员一定的发言权及主人翁感，并且能够调动大家责任心，通常大家愿意为自己的决定负责，但是如果是领导直接压下来的任务尤其比较紧急时，通常有些抵触。当然在自下向上的估算中，要有专家进行指导和把关，包括估算漏掉的哪些事情，项目组内例行需要消耗的时间等，并且针对”狮子大开口“的时间需要进行讨论，达成一致。  在这种估算方法做出的项目计划下，如果项目最后出现了问题，尽管项目经理要承担直接责任，但是项目团队成员通常会比较自主的愿意与团队共度难关。因为决策是大家一起制定出来的。   推荐策略：尽量使用自下向上+专家指导的方法进行估算，如果有人员到位或者估算周期的有限制，至少要保证关键人员的参与，而慎用自上向下的估算方法.   **3、善用加班文化**    IT公司加班是件很自然的事情，如果哪家公司没有加班情况，反而会让人感觉不正常。做为项目经理应该首先理解，加班虽然是IT公司的普遍现象，但是确实是组员为了项目做出了额外的奉献，他们牺牲与家人团聚的时间，牺牲了休息时间，甚至影响了健康。这种行为值得我们尊重，我们要小心使用这项权力。   1）不要动不动就抛出一句“这个今天搞不定，就打地铺解决”等，这种言论是对员工额外奉献的一个严重的漠视，而且带着很强的个人意愿   2）时时保证项目的进展的透明性，可以通过周会，日报的形式在团队中发布。当遇到赶工时，跟当事人讲解当前团队面临的困难，总之，加班是个艰难的决定，是为了整个团队的绩效，不是项目经理的个人意愿  3）任何加班时项目经理都应该尽量身先士卒带队  4）在一些公共场合，尤其有上级领导在时，公开表扬那些为团队做出很多额外贡献的人  5）绩效考核肯定以结果为导向，不能以加班多少论英雄，但要有其他措施安慰最辛苦的人  推荐策略：加班是一种奉献精神，我们要小心使用，认真对待。不能简单的当做管理者的权力，轻言肆用，否则久之必招其离心。 **4、开放沟通的团队氛围**   人都希望自己能够有发言权，能够对关心的事情产生影响。上至国家领导人的选举，下至日常的工作生活。如果发言权被长期压制，就会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后，项目经理总是能在一些讨论中，得到很多比预期更好的解决问题的方案。一个强权的管理者，容易获得一定程度上的执行力，但是容易被自己的盲点击败。而一个开明的管理者，往往能使用集体智慧，获得跟随者，更容易产生威望。    推荐策略：1）项目沙盘等关键策略制定时，要全体项目参与讨论                     2）项目经理鼓励大家发现问题，提问问题，对于好的措施，能够采纳执行 **5、责任到户 VS 大锅饭**  从头到尾的责任到户制应该是最理想的工作分配方式了，在这种分配方式下，团队成员有一块自己土地，通常愿意花更多的时间与精力去耕耘（例如：某个全新的模块），如果这个模块又是他一直想尝试的方面，那将会更加完美，我们有理由相信他将会在这里充满了激情。  然而世界上总没有十全十美的事情及百分百通用的方案，尽管责任到户制如此之好，但是在某些项目上我们达成不了这样的期望。  我所亲身经历过的两个版本就遇到了这样的状况。两个版本的共性是：在一个很大的系统上做覆盖面很大的，很多小点的修改（例如：更换所有UI系统），但是基于老系统的复杂性及历史问题，项目在中会遇到很多bug，各种各样，在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任，这种情况下责任到户制会出现失效。在面对系统这么多的bug时，项目经理很容易想到一种方法：“那就是给大家分配bug数，下指标，每天每人要解决3-4bug等”。两次项目经历中，项目经理确实都想到了这种方法，区别是前者实施了，后者被我阻止了。原因如下：  1）团队组员容易产生不被尊重感，被当成解决问题的机器  2）团队之间的协作会发生困难，而且过度强调这项指标，例如谁每天不修改完这个bug数，就要加班到10:00之类的，会导致部分组员开始取巧，每天争抢容易处理的bug  3）没法发挥人的主动性，将团队目标和个人目标相背离  这种情况下大锅饭的机制似乎更合适一些，如果团队没有达成目标则需要一起想办法或加班解决，而不是将这人归咎个某个人。  推荐策略：在正常项目中尽量使用责任到户制，而对于一些特殊项目，则选用大锅饭制，没有一成不变的方案，具体情况具体变通。

项目绩效的重要衡量指标之一便是时间，这里总结下亲身经历的三步曲.    第一个阶段：项目经理简单估算+倒推+部门预备机动人员      优点：估算速度非常快（很多时候，项目计划都是从上级给的发布时间倒推出里程碑）     缺点：计划非常不准，项目成功率不高。主要原因是：      1）项目经理个人思维限制考虑事情不可能百分之百周全，尤其遇到新的项目经理，项目成功的几率更是直线下降。      2）部门的人员总是要干活的，当项目发生风险时，原计划的机动人员总是不够用，或是不能停下手头的事投入项目中，如果遇到多个项目同时需要机动人员支援时，整体部门基本要全线加班，集体奋斗了。      3）项目组成员参与度不够，如果工作加班，有一定怨言     总体来说：还好每当这时候项目经理都能身先士卒加班，这时候部门的同事都是难兄难弟，总是很辛苦，但是项目结果总是不理想，不能按期交付。     **第二个阶段：公司级形成估算团队做专家估算**     为了改进估算，同时保证各部门绩效的公平性，公司针对A部门的项目会找其他的部门的专家参与估算，估算使用3点发计算出版本时间点，如果某个专家估算的不 准，则要求重新估算或当面讨论，最终取得一致后将成为项目发布的绩效点.    优点：相对公平，有一定信服力    缺点：              1）容易出现扯皮现象，项目估算时间很长，并且外部估算的时间计划难以转化为内部计划，工作量浪费很大。              2）专家质量与主动参与度难以保证，尤其是参加多次估算后，专家容易倦怠              3）公司不关注人员分配，不考虑具体项目的最长路径，计算时间公式为：工作量/人力=项目时间              4）项目组成员参与度不够，如果工作加班，有一定怨言      总体来说：公司级的估算是CMMI引进到公司的，起到了很大作用，但是一定程度上造成了公司级的RDM组织和部门的对立，能力强的项目经理能够做很多线下活动，从而得到自己的绩效时间期望。      **第三个阶段：部门自下向上估算+专家指导**      其实第二个阶段和第三个阶段在一定程度上是有重叠的，第二阶段中，有一些先知先觉的项目经理，在公司开始进行估算前，首先进行了内部自下向上的估算，这样自己知道了自己的底限，如果有关键路径消除不掉，则要在总工作量加大，以达成自己的预期.      第三阶段主要的特点是项目估算以部门及项目为主导，当出现关键路径后，部门或公司专家帮助消除，如果消除不了，以项目估算为准做绩效点。      优点：              1）能够保证信服力              2）鼓励项目经理一开始把版本事情考虑周全，如果项目计划可行性非常高              3）全体项目人员参与的估算，更加准确，并且成员愿意为自己估算的时间负责              4）RDM和部门关系形成互助关系              5）估算结束后，直接产出可执行的项目计划       缺点：               1）估算周期稍长，通常需求基线后1-2周能给出       总体来说：这种方法是我个人最推崇的方法，能够有效提高员工的参与度及估算的准确度，同时维持组织的互助性，对版本成功非常有帮助。 

2013.5.26           需求阶段的工作是项目经理最繁忙的一个阶段，也是项目能否做好的一个重要分水岭。通常此阶段要完成系统需求的编写，工作思路的整理，工作计划的制定，人员工作的分工，并且伴有大量的评审。如果稍有不慎就很容易被拉入到漩涡中，失去了自己，不停的被别人推着走，心情苦闷不说，还会为整个项目埋下层层地雷，才是真正的悲剧。     因为用户需求是由主管/产品经理编写，系统需求有项目组编写，因两个需求工作有着一定程度的并行，因此合在一章写。     按项目管理的五要素分解如下：      **1、干系人期望-目标** **用户需求：**    用户需求通常由主管或产品经理进行编写，主要目的站是在客户的角度上描述遇到的问题，并将其抽象为客户的使用场景及对应我们项目能够提供的解决方案。    用户需求文档在解决方案的描述通常粒度比较粗，因为在评审中解决方案的思路有可能被变更，过多的细化解决方案，工作量返工的成本会比较高。    用户需求的主要干系人：    1) 上级领导：评估该项目的价值，投入产出比是否合适    2) 行销部：评估该项目如何宣传，宣传的成本    3) 项目组：以用户需求为基础细化系统需求，并理解项目意义 **系统需求：**    系统需求通常由项目组提供，将用户需求评审过的解决方案具体化，此文档的主要干系人：    1) 主管/产品经理：系统需求是否能完全符合用户需求，是否有足够好的用户体验    2) 客服部门：技术支持是否便捷，成本如何    3) 开发人员：项目具体做成什么样子    4) 测试人员：项目如何验收，怎样算通过    文档要描述清，UI界面（及界面上约束）、关联功能影响，已知缺陷，异常场景，非功能性影响（性能，稳定性...）等。 **2、沙盘-思路**     1） 项目团队参加评审     在用户需求和系统需求阶段中，项目团队成员应该都参与评审，虽然评审过程中不一定发言，但是会有两个重要作用：       a、强烈的项目参与感       b、对项目原始需求的理解程度       c、对各干系人的期望的了解   2）需求质量保证       需求质量保证有两个很好的实践可以采用：       a、由下一阶段的模块作者编写需求文档       这样可以保证作者对需求的理解程度，同时在评审过程中能够纠正错误理解。由于下一阶段的作者通常来说更加熟悉改动或新增的模块，因此关联改动、已知缺陷发现比较容易被他们发现。       b、测试进行需求验收       记得前几年参加IBM的管理论坛，当时听到一个观点，深有感触。大概意思是：“只有可验收的需求才是完整的需求”。需求很难通过描述的粒度来判断是否完整，清晰，有看过篇幅特别长的需求文档，写了N多废话，但是仔细一推敲就能发现其中的很多遗漏点。       只有当测试的同事拿到需求文档后，能够清晰的知道如何来验收这些需求，没有任何二义性和模糊的地方，这样的需求才是完整，清晰的。       测试同事的项目全阶段的缺陷预防工作在我们公司推行已久，当目前为止还是需求阶段的缺陷预防产出最大。    3） 制定项目沙盘     项目沙盘有两个重要部分         a、干系人期望分析与落实方法          例：一个项目组为了更好的体验，翻新了系统的所有页面。那此时产品经理/主管的期望是很明确的，就是为了客户体验。                 此时项目组应该在需求讨论时（DEMO），界面已经初步完成时，功能都已经调通时，分别各安排一次体验，以此达成产品经理的期望。                          b、项目成功的关键因素分析        项目的成功关键因素可以使用鱼骨图进行分析，对于研发项目而言主要由3根大骨刺构成：人，流程，技术  例1：一个项目组主要都是有新员工组成，项目组面临的技术难度不大，这时候新员工的工作质量就会成为关键因素，此时可以做进一步分析。   例2：一个项目组性能方法改动和提升技术是最主要的瓶颈，进一步分析如下：  **3、计划制定**    1）使用估算清单      项目里总有一些例行工作，项目组在估算开始前应该整理出此清单，避免项目组成员遗漏估算项。      一些例行工作例如：环境搭建，每日构建环境的维护，迁入代码审核，评审时间，测试案例评审时间等      如果当前部门或公司已经提供估算清单，那只需要根据项目特点做下修改就可以了。      2）落实沙盘      想法和计划最大区别在于后者已经准备开始执行，不准备实施的想法终究只是想法。经过各种分析、各种集思广益得出的沙盘是智慧的结晶，需要将他们做到计划中。通常落实沙盘得到的计划就是项目组的缺陷预防计划。      3）自下向上估算，专家核对    估算的方法有很多，这是我所推崇的一种方法。详见下节：[http://blog.csdn.net/liangjingbo/article/details/9008735](http://blog.csdn.net/liangjingbo/article/details/9008735)      估算结束后应该产生项目的详细project及明确的里程碑。 **4、风险管理**       1） 复杂系统里的关联影响考虑不周       对于在现有系统新增或修改模块的项目，如果当前系统非常复杂，那么关联性问题将很有可能在此阶段被大量引入。针对这种情况可行的两种方法：        a、召集专家会诊        b、模块负责人提前分析（需要项目组给予时间）       2）估算项遗漏       估算项遗漏会直接导致工作量不准，这里常见的方法如：        a、使用估算清单检查例行工作是否有遗漏       b、使用需求根据矩阵核对需求是否有遗漏       c、专家把关估算表       3）需求评审变化，导致新增预研项       最令项目经理苦恼的问题之一就是需求的变化，其实有些时候变化的不是需求而是大家对于需求的理解。避免需求变化的带来的影响，需要做好两方面的工作：        a、需求缺陷预防，项目经理向组员传递良好的客户导向意识，将一些项目组自己能发现的不合理处尽量在前期提出，避免拖拉到后期带来更大的影响。       b、当需求变化不可避免时，要及时评估是否要进行补充预研，我看过很多心急的项目经理通常急于按计划推进阶段，结果在这上面吃了大亏。              4）团队的组织架构，不利于及时发现风险       每当我听到项目经理说“项目质量要等到转测试后才能知道到底怎么样”时，我都会给这个项目打上“高风险”“失控”的标签。打个形象的比喻，项目是开发团队的孩子，测试团队是医生，要想生个健康的宝宝，怀孕前期及期间的工作是最重要的。当一个孩子已经出生时，孩子的体制和健康情况已经有了基本定论，如果这时医生才检查出有严重缺陷（例如，某个模块的代码写得很差），那么已经很难补救了。因此项目组必须要时刻对项目的质量、进度有很准确的把握。       对项目的质量，进度的准确把控，对于大团队可能有多个选择，例如：       a、成立不同小组，由组长兼顾管理和技术。       b、独立出兼职的技术专家团队负责技术，项目经理负责管理       c、独立出全职的技术经理负责技术，项目经理负责管理       等...       组织结构的方法可以多种多样但是一个原则是要能够及时有效的发现风险。       在这方面我和我的搭档尝试过一种方法，可以作为一个实践供大家参考，我们当时制作了一个项目模块质量跟踪表，以及时发现风险。       跟踪表里的第一部分是：项目组的所有模块、负责人，涉及的专家名单                         第二部分是：对模块复杂度，难易程度的自评、专家评定                         第三部分是：对模块设计情况的自评和专家评定                         第四部分是：对于编码阶段的代码质量自评，专家审核评定                         ... **5、团队管理**       1）团队分工及成长计划       团队分工是项目需要和组员自身需求的平衡体，完全以项目为导向的团队会缺乏向心力和持续的战斗力。例如：       a、一个很优秀的组员，最近妻子怀孕临盆在即，那么项目组不应该给其安排工作量特别大的分工。       b、一个做技术很好的专家想转型为管理人员，那么继续安排他写代码也是不合适的。       好的项目经理应该了解项目组员的工作背景，家庭背景，工作诉求。团队分工时能够考虑大多数或是优秀人员的诉求，并同他们制定成长计划，这种激励是长期的。如德鲁克所说：“管理的本质是获得追随的人”              2）言路畅达（尊重）      发言权涉及到尊重他人的话题。想看下节：[http://blog.csdn.net/liangjingbo/article/details/9008761](http://blog.csdn.net/liangjingbo/article/details/9008761)       3）团队的口号、文化       团队的口号决定团队的文化，口号可以由大家一起讨论制定出来，好的口号往往是项目成功的最关键的心态因素的简写。我经历过两个项目组的口号如下：       a、细心，细心，我们再细心一些 （这个项目的特点是将近10个分支的代码合并到一起）       b、担起自己的责任  （这个项目的特点是模块关联性不高的新模块）              4）奖罚项       口号毕竟是虚的，设立了明确的奖惩措施后，比较容易让文化落地。奖罚项可以针对个人，也可以针对小组。例如：       a、强调细心的项目组，在编译打包出问题时需要犯错误那个人给整个团队买王老吉。                                             同样对于代码互审阶段做得最好的人，要给予奖励       b、强调担责任的项目组，在项目模块没有按期完成的情况下，模块负责人应该安排加班，优先自己搞定。       另外奖罚要做到对团队有更大的影响，需要做到短期，及时通报当前情况。        a、短期，就是奖罚的结果不能拉得过长，不能在项目结束时在评定，这时候木已成舟，对项目本身已经起不到作用。       b、及时通报，就是要按周或按天通报当前的数据统计情况，以便更大程度的影响大家的日常的工作心态          5）里程碑庆祝点       里程碑庆祝的重要性，想看下节：[http://blog.csdn.net/liangjingbo/article/details/9008789](http://blog.csdn.net/liangjingbo/article/details/9008789)[](http://blog.csdn.net/liangjingbo/article/details/7518505)       6）项目团队的例行日程       尽量将项目组能例行化的工作时间表明确下来，这样避免大家工作总是无规律的打断，影响工作效率。       例如：       a、项目组总是周五打包，打完包后验证基本功能，如果基本功能有问题，责任人需要当天排除出来，否则周末加班搞定。       b、每周日自动使用上周五的新包，升级所有测试环境       c、每周一项目周会，项目经理讲述项目当前情况       d、每天下班前，需要发送当天的日报给组长，组长在第二天早上10:00批复

2013.5.19 当从规划中分解到预研项后，我们将进行预研工作。此阶段的工作会对项目中的重大风险或技术方案的不确定性进行攻关，能有效率完成此阶段，是项目经理的一个重要挑战。我见过很多项目经理对项目整体管理把握都很好，但是由于对预研阶段的工作把握度不够，导致项目失控。 按五要素分解预研阶段的工作如下：  **1、干系人期望** 此阶段的干系人主要是预研人员和产品经理。 1) 预研的方案复杂度在规划预期内    所有项目都需要在投入产出比做权衡，在预研启动前，我们要知道主管/产品经理的心理预期，如果当预研的方案实现的复杂度会远超过预期时，需要及时提出，并安排讨论，必要时需要停止预研。 2）预研要消除实现风险    预研阶段的主要目的是消除整个项目的实现风险，预研阶段结束，大家会有个共识，那就是项目可以被实现出来，整个项目计划的工作量估算将也重要参考预研结论。 **2、沙盘** 技术预研要做好，首先要有两个前提：有明确的目标值，有可操作的验收方法。 1）有明确的目标     例如：预研一个方案，最后提交的方案需要占用1G内存，而这个内存消耗不能被接受，这时便会带来返工，同时预研人员会新生怨念，为什么不早说呢，害伤神，伤身。    因此这里通常的办法是预研开始前，下发预研目标书，目标书里包含对此项预研所能消耗的资源进行详细限制，例如：内存，cpu，稳定性等。 2）有可操作的验收方法     没有可操作的验收方法，目标就会得不到执行，变成空口白话或脱离本意。因此在预研开始前确认好验收方法至关重要。     例1：目标：新增加的预研方法对原有的系统的性能影响不超过5%               可验收的方法：加载此模块与不加载此模块，在3个相同的业务流里统计所消耗的cpu周期，来计算是否超过5%    例2：目标：前端一个复杂页面的响应速度在客户正常使用过程中3S内返回。              可验收的方法：在2个典型的客户业务流下，非cpu空载情况下测试页面响应速度。 **3、计划制定** 1）预研项的整体计划 预研阶段的整体计划通常很难定的100%准确，尤其对于风险较大的定制，但是一个整体的计划的参考时间点，会给人一个目标，从而得到方向感。 2）快速跟进 快速跟进是预研阶段最靠谱的跟进计划的方法。因为当方案等没有确认下来时，很难有准确的计划，但是通过快速跟进我们可以及时调整当前的计划--滚动式计划。 快速跟进常见两种方法：阶段性，时间性。 阶段性即：将当前预研分为几个阶段（例如：环境搭建，思路1尝试，思路2尝试等），每个阶段汇报和讨论工作情况。  时间性即：每2天，每1周等确认预研进展。 简单及思路明确的预研可采用阶段性跟进，复杂疑难的预研需要使用时间性跟进。当然根据所在项目要求可以调整使用两种方式的混合体。 **4、风险** 典型的三种情况： 1) 预研过度，常见于谨慎型或对技术缺乏自信的项目经理。他们要在预研阶段消除所有的风险，因为预研阶段的代码没有经过设计阶段，所以后续项目编码过程中很难复用，导致工作量浪费，从而导致整个项目周期变紧张。 2) 预研不足，常见于缺乏大局观或技术自信较强的项目经理，他们经常根据自己的判断在项目中选定出几个风险做重要跟进，他们经常不经意间忽略掉自己不擅长或不熟悉的领域的风险，导致项目进入后续阶段后，灾难频发，救火进行的总是如火如荼。 3) 预研思路不正确，导致工作返工较大。 消除这里三种典型情况的方法就是：在项目组中尽早形成良性的技术决策链，这里需要依靠团队管理提供基础 **5、团队管理** 1）团队组建 此阶段的项目核心人员应该已经或将陆续到位，这时候要开下项目启动会。主要要做两件事：  a、阐述整个项目的目标和意义     任何人都希望自己做重要的事情，而既然公司或部门决定投入人力去启动这个项目，自然是存在重要意义的，此时要将这个意义传达给项目组员，以便调动大家工作积极性。    如约翰·科特所说：“如果你想建造一艘船，首先要做的不是去采集木材、加工木板和分派工作，而应该去唤起人们对广阔无垠大海的向往。“    b、集中办公-座位搬到一起     大多数时候项目组的成员来自一个或多个部门，之前的座位不是靠在一起的，项目组成立后，应该要把座位调到一起，集中办公是交流方式最有效率的方法之一，没有其二。    c、 需要给预研人员讲解规划，让其了解此预研项的意义     这样做的目的，是为了让预研人员能够理解启动该预研的目的，通常当我们深入研究某件事情时，很有可能触发其他解决问题的思路。明确的目的能让有些时候预研人员自主变通。      例如：项目组安排给小吴预研目标是：验证网卡的MSI多队列能否在linux2.4内核上实现，目的：提高性能       小吴最后给出这样预研结论，网卡多队列完整移植到2.4上工作量很大，而且有困难，但是有折中的办法，移植一部分MSI的功能，将触发方式改为定时器实现，如此即完成提高性能的目的，又能节约工作量. 2）形成技术决策方式     预研阶段的技术方案跟进或其中的疑难问题如何跟进和处理，需要明确。这里明确的好处如下：     a、项目组员思路受卡时，知道向谁请教问题     b、如果不是项目经理自己跟技术问题，技术相关决策人能够明确自己的责任

2013.5.12 规划阶段通常是项目启动第一个阶段，在此阶段里产品经理会将项目目标传递给项目经理。 万事开头难，好的开始是成功的一半，此阶段里项目经理就应该打起精神，迅速进入状态，做好战事准备。 我将按项目管理的5要素来分解在此阶段中，项目经理应该重点关注的事项。  **1、干系人期望** 如下曲线可以看出，干系人的影响是随着项目进度的推进逐步变小的，如果在中后期干系人要进行相关变更，成本会比较高。 也就是“方向不对，越努力，结果越惨”，因此在项目前期管理好干系人期望至关重要。 在准备动手管理干系人期望前，需要知道项目存在的”三重制约“，即：范围，时间，成本。简单一句话概况：即领导通常希望项目做得“更多，更快，更便宜”，然而正常情况下，这三者不可兼得，此时理清项目的最关注点，便显得格外重要。  在规划阶段，干系人通常是产品经理、主管，客户。在我现在的公司常见是前两者，产品经理或主管通常会把市场目标转化为项目目标然后下派给项目经理。 这时的期望常见于3点： 1) 市场期望  能够明确此项目的使命和功能列表的优先级。  深刻理解项目对市场的意义，能够让项目经理更好的选择决策方式。     例1：    小赖带了一个项目主要是为了争夺一个细分市场的份额，此市场份额不大，但是当前市场没有产品满足该市场的客户需求，从公司角度出发项目投入产出比符合要求，所以启动了该项目。但是在项目预研过程中，小赖从网上搜集资料时，意外发现最近已经有一家厂商出了类似产品，经过自己的进一步分析，小赖认为这家公司的产品目标和自己的项目标是一致的，于是向上级领导汇报了该情况并加入自己的分析，最后项目及时被叫停，公司避免了损失，小赖也因此得到表扬。    例2：    小张带了另外一个大项目，项目里有很多功能要实现，但是由于预研时考虑不足，在一个功能的实现里遇到一个棘手的问题，此时有两种方法，一种花较高的代价修复这个问题，另外一种是使用规避措施绕过去，但是对该功能带来一个小的体验影响。因为在规划的定位里此功能优先级较低，所以小张决定和上级领导讨论下，最终项目采用了第二种方法。 2) 人力投入期望    投入产出比是任何主管都需要关注的事情，当一个项目的人力投入远超过预期时，可能该项目的重要性要重新评估。项目经理应该在项目的预研阶段及时反馈是否项目的方案已超过预期。 3) 时间期望   有时候有些是项目是有明确的市场时间预期的，这种情况下，项目经理应该有严格的倒推计划里程碑，当规划或预研时发现时间不可达时需要及时提出讨论，看是否分两期划分项目或是增多人力等。 **2、沙盘**  当规划评审确定下来后--即初步的目标已经明确，此时项目经理应该对项目进行下整体分析，理清出自己的思路，找出项目的难点和关注点在哪里。   例1：   小李接到了一个跨很多部门合作的项目，他思路是：自己先制定一份初步合作计划，里面包含各部门配合方式及考核方法分配，并取得公司认可，以此对推动项目进展可控打下基础。  例2：  小杨接到一个时间周期很紧张的项目，他的思路是：因为版本的各个模块的工作量分布不平均，为了充分利用时间，决定打破传统的瀑布式开发，选择迭代快速跟进，并在项目初期和公司流程团队和测试部取得一致。  例3：  小邱接到一个性能改进的项目，他的思路是： 1、因为部门之前对性能测试方法不规范，首先界定清性能提高的验证方法   2、涉及的硬件配置开始前和硬件部门讨论   3、和主管预定1个性能优化相关的专家  例四：  小吴接到一个将5个分支产品合入主线产品的项目，他的思路是： 1、将各分支产品之间和主线产品的功能影响细致的确认下来，将受到的影响的功能进行评估 2、项目开发过程中需要有机制跟进各产品的更新情况 3、开始合入前，评估各产品的代码质量及代码重复读，决定是否抽取公共代码或是重写部分分支产品 **3、计划制定**  计划制定主要是产出预研项，以便做对应项的预研计划。对于大项目（超过10人规模），分解预研项将面临遗失问题。如果规划阶段的预研项分解不完全，会导致项目后期有大量返工。    这里常见有效方法：   1、项目管理上重视，对于实现不清晰的地方不放过。   2、使用经验库   3、专家咨询 **4、风险管理**  这里的风险管理同第3点。 **5、团队管理** 规划阶段时，通常只有项目经理1人投入，对于一些项目是项目经理、技术经理2人投入。 此时的团队还处理组建阶段，这时候最主要的事情便是和上级领导做好核心人员的预分配，即什么时间核心人员需要到位。

2013.5.5 一个知识领域要系统的进行整理或说明首先要有其自己的框架结构，例如：CMMI有5个成熟度和22过程域，PMP有5大过程组和9个知识域。 我将项目管理知识分解为以下结构，后续文章将以此为基础。 **一、公司的主要框架**  公司在横向可以分为三个部分，创新过程，运营过程，服务过程。我们这里讲得项目管理将集中在运营过程，但是项目管理在其他两个过程的影响是至关重要的，往往随着公司的变大，各个体系，各个部门之间的会形成很厚的墙。如果每个体系及部门都各自为营，最终项目将很难在客户那里取得最后的成功。项目管理和其他过程的影响，我将在关系人期望及沙盘的2个管理要素中进行覆盖。 **二、项目管理的层面**       我理解的项目管理分为3个层次，    1、最高层是研发体系对于整个公司各个部门（产品线）的项目的管理    2、中层次是部门对于整个部门内的所有项目的管理    3、最底层的是项目经理对当前项目的管理    此系列文章将从最底层向上依次讲起。 **三、项目的主要框架**  **1、项目的主要里程碑和阶段**，可以划分为以下13点，13框分为4个颜色：        1) 蓝色:  规划，用户需求通常由项目外的上级干系人发起       2) 黑色:  技术预研通常发生在用户需求前，用以评估技术风险及可行方案       3) 绿色:  项目质量形成期，在开发团队与测试团队分开的情况下，此时往往以开发团队为主导方。       4) 红色:  项目质量检查期，在开发团队与测试团队分开的情况下，此时往往以测试团队为主导方。  **2、项目管理的5要素**         1）关系人的期望        我对于项目成功的定义是：满足客户需求，达成干系人期望。我对于优秀项目的定义是：在主要干系人的期望上有亮点（即：超预期）。        因此项目要做到优秀，首先要搞清干系人的期望，尤其是主要干系人。        例如：对一个开发核心功能模块项目，上级主管可能更加关注质量及其后续可维护性，          而对另外针对某一个具体客户的定制项目，上级主管可能更加关注进度的准确性及客户需求的符合程度。        2）沙盘        沙盘一词来源于战场，战场上将军需要依靠沙盘做出战术决策，或分而击之或围而聚歼。一个项目的管理如果指挥一场战役，你的思路将决定这场战役的成败。而每场战争都是独一无二的，因此针对每个项目，都需要找出它的三寸，集中精力击之，如此才能确保项目或阶段启动前我们已经在正确的方向上就绪。       例如：对于一个性能提升为主要目标的项目，性能测试环境的及时搭建，相关模块改动对性能的影响，性能在某些场景下未达标需要调优，这些问题的及时跟进将成为三寸之地。           而对于一个有很多新需求，界面改动量很大的项目，客户需求的完整和清晰度，对其他已有需求造成的影响，如何保证客户的体验，这些问题将成为此项目的主要关注点。      3）计划制定      项目计划是整个项目得以有序控制的基本手段。好的项目计划要达成3个目标：       1、项目计划具有可行性，不能做明知完不成的计划（有不少项目经理习惯通过制定一个不可达成的项目计划，向项目团队施压，其实这是一种打击团队士气及丧失公信力的坏方法，非常不推荐）       2、项目计划需要能落实沙盘       3、项目计划需要和团队成员达成一致。正如孙子兵法云：上下同欲者，胜。            4）风险管理      风险管理的两个核心点在于：      1、有机制能够及时发现风险      2、发现风险后要立刻采取措施      工作中发现大多数项目经理困于第一点，无法及时的发现风险，风险识别早晚将决定项目组需要付出代价的多少。而也有一些少数的项目经理，发现风险后并不能立刻采取措施，一味的妥协和自我安慰，导致项目最后失败。      5）团队管理      团队管理涉及到沟通、激励等项目经理的软技能，项目经理的软技能将决定项目团队的氛围，战斗力。     

2013.5.5 **一、为什么写这个系列的文章？**   1、自己的工作岗位发生变化有近一年了，有必要对前几年得工作心得做个系统的整理   2、工作有些时候像个魔咒，虽然不同的人的工作经历都是独特的，但是总有一些弯路被重复的走，希望此系列的文章能给予在路上不久的项目经理一些启迪。 **二、个人简短的经历?**   大学毕业后就来到现在的公司，有幸能和公司一同成长，在其中学到了很多宝贵的知识。在公司中先后担当过技术组长，资源组长，项目经理，开发经理，部门主管等职位，在项目管理方面参加过 CMMI的EPG改进，PMP培训及其他各种内外部的培训。 **三、该系列文章的竞争力？**   市场上现在有CMMI，PMP，敏捷开发等很多专业的书籍，相比这些，我这里所写的经验直接来源于实战，在这些年的项目管理中，我认为项目管理是有一些核心的基础，就像武林高手，内功练扎实之后，学习招式便能事半功倍，而空有其招式，顶多算是花架子。

> 原文出处：[项目经理修炼路](http://blog.csdn.net/column/details/liangjb1986.html) 作者：[梁景波](http://blog.csdn.net/liangjingbo) **本系列文章经作者授权在看云整理发布，未经作者允许，请勿转载！** # 项目经理修炼路 > 工作有些时候像个魔咒，虽然不同的人的工作经历都是独特的，但是总有一些弯路被重复的走，希望此系列的文章能给予在路上不久的项目经理一些启迪。