**公司研发项目经理研讨会
成果汇集
PSMT 质量和流程管理部 整理
**技术有限公司
版权所有 侵权必究
目录
2.2.1 估计人员经验不足或对系统要完成的内容、要求理解不充分；... 6
2.2.3 估计人员乐观，导致估计结果不准，怎么办？... 8
2.2.4 代码本身开发工作量不多，但其他要做的工作，如测试、学习的工作量多； 8
2.2.5 项目经理认为领导分配给项目的人和交付时间已经确定，估计也没有用处。 8
2.3.2 产品迫于市场压力，1/2级计划已确定，项目级计划无法进行变更调整... 9
2.3.3 开发和维护人员重用，突发维护工作量大，计划效果不佳... 10
2.3.5 如何配置不同层次的开发人员，以求得最高效率？... 11
2.3.8 产品中经常有计划倒推的现象，该如何应对？... 12
2.4.3 人力资源不能及时到位；人力变更比较频繁（生病，请假，辞职等）；... 16
2.4.4 任务的监控粒度如何确定？到周OR天？... 16
2.5.1 领导发个邮件说需要增加几个需求，不知实现是否是客户需要的？心里没底。。。。 18
2.5.2 需求增加，项目范围改变，目前的资源不够用了! 18
2.5.3 开发中增加新需求和新特性，使工作量增大，可是项目交付的时间又不能延迟 ….. 18
2.5.4 需求变化，原来的设计要大改，如何保证设计质量呢？... 19
2.5.5 需求变化了，原来的设计要返工，开发人员士气受到影响... 20
2.6.6 是否过程活动做到位了,该阶段质量是否达到要求？如何进行评判？... 24
2.7.2 如何应用质量目标来进行项目控制？（规模偏差、生产率、缺陷密度）... 26
2.7.3 阶段交付件评审、检视发现的缺陷密度达不到质量目标，该阶段是否结束呢？ 26
2.7.4 项目组内大部分是新员工，项目质量是否能够保证？... 27
2.8.3 新项目成立时，如何快速凝聚团队，让大家尽快进入状态？... 30
2.8.4 项目延迟情况下，如何激励？（员工士气低，压力大，工作无激情）... 30
2.8.6 任务很多，要安排加班，如何才能不影响士气？... 31
2.9.2 进度要求很紧,开发工作量大，但很多的工作流程、新技术没有时间学习？... 37
2.9.3 给我的工作中,有很多是我们不懂的新技术... 38
2.10.1 当本项目组任务已经很饱满，但上司仍要求新增任务时，如何和上司沟通？ 40
2.10.2 当下属认为本身工作量已经饱满，但PL又需要再给下属增加工作任务时如何沟通？ 43
2.10.3 如何给员工设定工作目标？如何确保项目组每个成员清楚工作计划、要求或目标？ 43
2.11.1 对考评结果为“C”的员工如何沟通？... 43
2.11.2 如果刚进来的员工，该打B,但结果只能给他打C,怎么办？... 43
2.12.1 新技术/新芯片的应用，无法预期的问题出现，如何识别、评估和控制风险？ 43
2.12.4 已经制定了风险列表，但效果不大，到底该如何进行风险管理？... 43
为响应各产品线总裁提出的“提升班、排、连、营等各级的执行力”的要求，从2004年12月开始，PSMT质量和流程管理部联合各产品线质量部组织了一系列研发项目经理研讨会，截止2005年12月，共召开17期，覆盖了深圳、北研、上研、西研、南研等共400多人次。项目经理研讨会以“从实践到实践，形成华为最佳实践”为宗旨，通过对项目开发中典型场景的研讨以及开发代表/优秀项目经理经验介绍和互动交流，有效促进各产品线之间的项目级管理经验共享。为使研讨成果更广泛地得到传播和应用，现将各期研讨会的研讨成果予以汇总整理，以飧读者。
| 场景类别 | 场景名称 | |
| 项目计划 | 估计困难——怎么办？ | 如何有效制定项目计划？ |
| 项目控制 | 如何做好项目跟踪和监控？ |
|
| 需求管理 | 如何有效进行变更控制？ |
|
| 质量管理 | 如何开展REVIEW？ | 如何进行质量管理？ |
| 团队建设 | 如何激励项目组成员？ | 如何提升员工技能？ |
| 沟通管理 | 如何进行任务沟通？ | 如何进行考评沟通？ |
| 风险管理 | 如何进行风险管理？ |
|
2.2.1
l 对被估对象进行分类（如按难度），预先对不同类别或不同等级给出基数值，即建立基线，并提供估计CHECKLIST，以保证估计结果不出现大的偏差；
l 估计要参考历史数据、经验，特别是同类项目的历史数据；
l 估计前通过培训和陈述的方式，增加对被估对象的了解；
l 先讨论方案实现的思路，再进行估计。参加估计的人要多，将整个流程都串通起来；
l 系统组先出个实现方案，再与估计人员、局方沟通。要求系统组的人员参加估计活动，只答复估计人员的疑问，但不进行估计；
l 降低估计的收敛标准；
l 进行集体决策；
l 对系统进行逐层细化，层层分解，细化到能估计的程度再行估计；
l 协调骨干或有经验的专家参与，选择合适的专家；
l 及时进行重估计，不断细化、调整，即时调整计划；
l 做好风险管理计划，做到提前预防风险；
l 对估计方法和流程进行培训；
l 估计人员参与前期工作，加深对系统/特性的理解；
l 对估计结果请合适的人员评审；（考虑实际开发组的现实/背景情况，包括产品实际情况以及人员技能情况）
l QA对估计过程进行监控；
l 对前期工作（如TR2前的输出）要有一个评估，提出验收要求；
l 根据估计人员情况选择合适的估计方法；
l 估计要考虑隐性需求；
2.2.2
l 对新技术，可先预研再估计，先做一个原型，这样对于业务也有一个经验数据，再将经验数据用于估计；
l 安排项目组成员每人学习一部分新技术或系统，总结成培训胶片，集中学习后再进行估计；
l 在估计时除了考虑功能工作量，还要考虑性能工作量；
l 启用外部专家力量，来对新技术的估计提供分析思路或参与估计；
l 对于界面开发规模难以估计时，可以先按界面功能折算成代码，再估计有多少个界面；
l 按阶段进行重估计，不断修正估计结果和计划；
l 项目组骨干提前介入系统分析；
l 提高内部人员的技能或开展技术交流、探讨；
l 详细分解特性，重点估计关键特性；
l 参考业界或其他项目组的经验数据；
l 可以通过上网等各种途径获得资料、信息；
l 通过高层协调专家参与估计；
l 把各种结果文档化，形成基线等；
2.2.3
l 要求估计人员讲解估计思路；
l 乘以比例因子，降低乐观估计的风险；
l 把估计的理由文档化，并把此用于经验传递；
l 将代码开发和其他工作分开，根据经验各估计其工作量；
l 项目经理不能讲面子，而是要根据项目实际情况（如人员技能）进行工作量估计，也即要选择合适的生产率（降低生产率）；
l 估计时应充分考虑风险；
l 人力分配上避免交叉投入，实发任务提前预估；
l 借鉴相关历史项目经验值，在计划中考虑进去；
2.2.5
l 有必要进行估计，通过估计做到心中有数，便于做计划和风险管理，差距大时，要尽早向上汇报；
l 若是一个不可能完成的任务，则项目经理一定要及时提出；
l 以评估/估计为依据，说服领导增加资源；
l 先按正常的估计，再与领导进行沟通，将不可达的任务变成可达的或有挑战的任务。
l 如果领导不接受估计结果，等项目结束后对估计偏差进行总结，再与领导沟通，以避免以后还有重复的事件发生。
l 对全部需求估计完成后，对需求进行分级，必要时根据计划和工作量进行裁剪。
l 通过质量部协调；
l 进行人力、进度、质量三方面协调；
l 可以将某些特性分阶段、分版本（砍需求）实现；
l 请领导参与估计，要让领导知道压缩需有理由；
l PL制定计划前一定要了解项目背景和需求。
Ø 实践：我参加产品的所有的评审会议，如果不参加的话，没办法在项目中做决策，开发人员问一个问题时，不能总是问CCB或SE。比如DB这个模块，你不能只了解DB，需要了解DB的来源，业务是怎么回事。参考历史数据，可能的设计变更都考虑到计划中。对于制定好一个计划，PL需要建立一个规范化的团队。如果你不建立起来，诚信是没法建立的。
l PL制定项目计划一定要实事求是，要建立在我们项目能力的基础上。不能由于压力，制定一些超出项目组能力的计划，否则没有什么可操作性。
Ø 体会：有一次去跟IBM的顾问交流的时候，问起市场很紧急，人就这么多，我怎么样去搞定它。顾问回答：“Don’t ask them to try to be a hero.”不要要求你的员工去当英雄。如果每个人都成为英雄的话，华为公司就不知道是啥样了，毕竟英雄比较少。
l 内部进行周期性的重估计，逐步优化；
l 向关键路径要时间，向非关键路径要资源；
l 对项目开发中的一些新技术，在开发过程中一定要把它提出来，如有一些关键技术能不能用，对项目的执行影响较大，可以在项目中单独安排人员处理（启动攻关）。
2.3.2 级计划已确定，项目级计划无法进行变更调整
l 弄清楚源头（技术、市场的）需求，掌握底线，再和领导协调，制定出切实合理的计划；
l 与领导明确不要压任务下来（能不能完成任务，需不需要完成，不能一人做决策），并帮助其纠正、确认某些需求；或者拒绝不合理或影响太大的需求；
l 项目组提前介入，争取时间；
l 及时沟通。计划过程中发现一些风险，要及时提出。
Ø 案例：比如有个产品市场需求非常紧迫，发现计划执行不了，去找IPMT协商，IPMT去跟市场了解情况，经过沟通发现市场需求要求两个月以后交付。
l 计划的延期是可以的。但计划的变更要建立在相关人员彼此认同的基础上。
l 依据以往项目度量数据和经验，和RDPDT进行双向沟通，达成共识，合理调整计划，因此也要求先建立分类基线，直接使用业务部基线太粗；
l 若不能调整进度要求，可适当裁剪一些管理活动；
l 申请增加资源；
l 通过合作或外包解决部分人力；
l 从全流程的角度合理压缩各环节的进度，而不仅仅是开发环节；
l 需求分批实现，划分版本；
l 尽量使用CBB模块、成熟技术，或集成、重用第三方交付件；
l 特别要挑选有能力的项目经理（要求沟通能力强），组建项目组时要有机搭配资源；
l 用较少的工作量开发提高效率的工具；
l 适当让员工加班，但同时注意不断提升员工士气；
l 与产品经理/开发代表商量，对确实进度很急的项目，可以启动紧急项目，拟定出适当的质量目标（适当降低质量要求）；
l 分析产品策略，明确是进度优先还是质量优先；
l 当进度和质量都要保证时，只能先停掉其它项目组或放慢进度，增加人力（注意：要考虑人员增加是否有效）；
l 活动并行，加快进度；
2.3.3
l 开发和维护分离。
Ø 体会：项目组会有一些非常紧迫的维护工作要做，但专职开发人员是不应随便抽掉的，抽去支持两天维护工作其实不能解决很多问题，但是却打乱了开发组的计划。
l 让开发代表来做决定，如果开发代表决定先实现维护，则对应把项目计划推迟，这种情况，应该多和开发代表沟通。
2.3.4
l 交付件区分轻重缓急，如维护指导书等，不是紧急需要的文档可以稍微延迟；
l 项目组士气很重要，要充分调动积极能动性；
l 前期少做PCR，尽量通过自身努力赶进度，以避免士气影响以及考评影响；
l 要及时知会相关人员，特别是领导以及受影响的组；
2.3.5
l 人力交叉。
Ø 实践：在作计划时，把模块相关的人力交叉备份，一个人做某个模块的概要设计，另一个人做该模块的详细设计。这种方式对进度没有太多的提高，但保证了个人能力的提升和交付件质量。
Ø 体会：人力交叉一定要明确各自的权责。交叉可能造成权责不明确，如果两个人都很强，在项目中都有自己的观点，甚至摩擦也特别大，如果出了问题，到底找谁。为了避免这些风险，人力交叉要考虑到主次，主体是能力很强的人，用一个新员工进行备份，把新员工带起来。我是开发人员，如果出现交叉，要我去做测试，但开发人员对测试的敏感度达不到测试人员的标准，所以觉得人力交叉要慎用。
l 老员工做需求（效率高），新员工写编码。
2.3.6
l 制定计划时，进行双向确认，根据员工能力，进行有效沟通，考虑计划的可执行性和员工个人能力。
l 新员工技能不足，培训有针对性，新员工培养有专业方向，培训划分知识点，并对输出严格要求。
l 老员工把关，专门安排REVIEW检视，管理质量。
l 建立专家组(包括本部门及周边部门员工)。
l 项目内根据模块分组，每组有专门计划和安排。
l 新员工日报制度，了解监控每位员工的进度和完成情况。
l 建立求助渠道，利用公司平台、资源。
l 文档化的经验传递、案例传递。
2.3.7
l 计划要做细，甚至到天、到小时。
Ø 实践：首先花费两三天制定一个计划。开发代表一般来说从TR2到TR4，把项目的整个工作量估计出来，然后计划出每个阶段有多少时间，比如SRS阶段，把每个需求每个功能分配到每个人，计划日程，详细到小时。我每天早晨看一下大家的交付件是不是已经完成，交付件要求放在配置库上，能让所有的项目成员看见。项目经理每天可以知道哪些人做得快，哪些任务没有完成，遇到什么样的问题，可以实时调整。在开周例会时，我按照计划进行跟踪，哪些任务已经完成，哪些任务还需要多少工作量，采用这种方式进行跟踪，每个阶段基本上没有偏差。每个交付件需要计划评审时间。我的项目计划没有把周六计划进去，否则当出现意外情况时，就没有什么余地了。
l 实时跟踪、调整。
Ø 实践：我制定完计划，跟每个组员承诺，这周的任务是不是可以完成，并且每天进行跟踪，看是否存在问题。
l 分析计划紧的原因，考虑关键依赖。
Ø 实践：有时候项目可能会出现前松后紧，要分析紧的来源是什么，我们在制定计划时，很少考虑关键关联或依赖，比如跟其它单板联调跟其它产品联调，当依赖的交付件延迟时，我们要进行专门的跟踪，如果没有进行跟踪，会导致另外的项目受到很大的影响，这些东西要事先表示出来。项目开工会时，大家可以一起考虑这些依赖事件。跟单板联调，联调的时间点，及联调技术对个人也要求很高。
l 首先要分析需求范围、需求来源，并确定需求的优先级，划分不同版本，紧急和重要的需求提前实现，不紧急的需求推迟实现。
l 及时沟通，对需求/特性进行适当裁剪；
l 与客户协商，出Demo版本，Demo版本的特性和质量可适当降低；
l 与产品讨论分阶段补充人力的可行性（可以考虑从其它产品线调人），并将其作为风险进行监控；
l 按PCB制定正向的计划，找到正向计划与倒排计划的差距，寻求可解决的方案，如加班；
l 要进行正确的估计，可借鉴经验数据，如可服务性需求的代码可以将估计的结果乘以3，协议类需求可以将估计的结果乘以1.5；
l 项目管理的三角形：所有项目都具备的四个主要目标，这四个目标互相牵制。
|
| P(Performance)－达到预期的绩效 C(Cost)－在费用（成本）和预算约束范围内 T(Time)－按时 S(Scope)－符合制定的工作范围大小 四个变量相互联系：C=f(P,T,S) |
l 首先向团队成员解释为什么要倒排计划？争取团队成员的理解和支持。
l 在第一时间捕捉到项目组有哪些问题，通过具体分析，找出解决措施，并尽快解决；
l 计划要细致，甚至可以做出每一天的计划；
l 倒排计划需考虑人员能力的差异，老员工分配重要任务，新员工分配次要任务等等；
l 找到关键路径，对关键路径重点关注；
l 压力传递到下属员工，充分沟通；
l 与市场部沟通寻找客户期望的短期替代方案，真正的解决方案按估计进行，如利用开局版本和正式版本的时间差合理计划；
Ø 案例：来自市场压力，需要提供开局版本，而完成该任务，时间太紧，需倒排计划。采用的策略是利用提供开局版本和正式版本间的时间差，制定项目计划，该计划分两条线，一条线满足市场开局，利用倒排计划提供开局版本，另外一条线，按照正式流程开发，按计划提供正式版本。
【案例】多管齐下完成“不可能的任务”
问题：来自市场压力，GSM的一个产品需要在指定时间内提供可用版本，需要倒排计划。
解决方案：
按照估计结果，在指定时间内完成版本是个不可能完成的任务。采取措施：1）和市场进行沟通，采取分阶段版本发布的策略。将一些基本的重要功能规划放在第一个版本实现，某些功能放在后续版本提供。2）采取了成熟的平台共享技术，减少了15％的工作量。3）为了保证方案的可行性，采取先用原型机验证的方法，证明了方案的可行。 通过种种努力，最后在规定时间内成功的推出了版本。
l 纳入风险管理，制定风险计划和规避措施。
Ø 体会：把一个很重要的模块给一个员工来做，如果这是一个关键路径，要重点关注这一块，识别相关风险，如果这个关键路径达不到，可能会影响其它的进度。
l 组间沟通、承诺计划。
Ø 体会：项目计划除了跟员工双向沟通以外，还要跟其它的项目组进行一个横向的沟通。各个组之间，有接口的承诺，按模块按要求完成了，如果另外一个组进度没有完成，也是达不到要求的，所以你的计划要得到其他组的认可。
l 上层（如开发代表）协调、牵头管理。
Ø 体会：在两个组制订计划时，要寻求更高一层来协调，因为软件组和硬件组之间不能相互约束，它涉及到双方利益，一方是不能制定计划的，所以应该由高层协调两个组之间的计划建立；
Ø 实践：有一个产品对依赖关系的做法，由开发代表把这个版本所有的PL组织起来，大家一起来看依赖关系，所有的时间点都敲定。项目经理分散在各个办公区，他们之间的沟通也不一定方便，如果开发代表亲自组织就比较好。
l 多层次沟通：PL，PM，SE，开发、测试，PDT，公司等进行不同层次的沟通；
l 多方式的沟通：整理问题列表，会议，邮件，报告；
l 要有专人负责定期跟踪（一般是QA），保证口径一致，信息传递不能失真，最好能按团队运作；
Ø 案例：项目开发中涉及西安和深圳两个项目配合开发，主要问题：两方问题都无法及时响应，而有时一方无法及时响应，将影响另一方进展。解决方案为：（1）从产品经理层面就要协调好两方计划；（2）两方业务组要指定问题接口人，接口人负责推动问题处理，及时通报问题解决进展。这样对接口人有比较高的要求。两方需严格遵守配合时间点。
l 当合作方出现问题时，不应只有指责，应该站在同一立场，帮助他们解决问题，作好风险规避和预评估。
l 计划制定之后会不断更改，不断滚动，但是我们不能想怎么改就怎么改，所以就需要有一个相关的计划监控组织，要不断地进行跟踪、采取监控措施；且计划变更后，要及时通知其它项目组，以便其协调给出相应控制；
l 对项目建立一个关键点/关键路径，通过对关键点的把握能够更好的落实计划监控到位，关键点必须要到位，然后计划滚动必须得到控制；每个任务的关键部分都要落实到具体的人，方便跟踪、落实；
l 定期的交流会议，不同组间的交流会比较重要，通过交流之后协调滚动；
l 实施早例会，如：第天早上9：20开始，开发代表或产品经理提出问题，当场就可拍板怎么做，如果需要协调资源，就去协调资源。
l 计划评审，定期在高层会议上跟踪进度（比如PDT例会）；
l 建立问题沟通渠道，指定有效的接口人；
l 延长移植时间跨度；
l 互相检视、互相渗透；
l 接口定义要明确，要文档化，如果发生变更，要及时通知到受影响组。接口核对工作例行化。
l 向上级主管求助；
l 尽量在前期做出有效计划或方案减少对其他项目组的依赖；
l 组间协调任务或问题的分层：对于有结论的、易解决问题可以指定普通员工跟踪；对于无结论或难解决协调的问题，请高层领导出面跟踪、解决；
l 计划阶段应明确组间协调计划；
l 对于测试依赖问题：需求阶段考虑可测试性，尽量减少依赖；
l 各小组应主动跟踪组间依赖问题，对于无法解决的问题及时上报；
l 考虑配合关系，合理计划；
Ø 案例：某产品需要启动两个项目，其中一个项目依赖于另一个项目，需要移植另一个项目的很多模块。解决方案是：两者应有1-2个阶段延迟，即该项目应晚于被依赖的项目1-2个阶段。
l 多项目组共同开会，通报进度和困难；
l 关键点计划细化到每天，以晨会方式跟踪；
l 交付件方面，应制定详细的交付件标准、交付进度过程规范，并参与质量评审把关。
l 分析前期延迟的原因，对症下药，如若是新员工多的原因，则要进行培训，或请SE进行需求规格串讲；
l 如果是技术风险无法解决，则需要寻找替代的解决方案；
l 如果是由于需求的原因：控制需求，分阶段实现；
l 如果是人力的原因：向上求助，进行组间资源协调，加大人力和资源投入；
l 可以采取加班的方式弥补进度；
l 对人员进行激励；
l 计划的延迟应作为风险来管理；
l 合理调整计划；
l 及时向上级沟通、反馈；
l 后期或相关活动提前并行开展；
l 制定更详细的计划，加大监控力度；
l 重要阶段出现延迟不要急于赶进度，不能为了进度放弃质量；
l 不重要的活动可以选择不做或压缩；
l 考虑本项目组做的部分，有没有与其他项目组共同协作的可能；
【案例】：把握重点、细化管理，追赶测试进度
问题：XXX R5版本测试中遇到困难，测试版本比原计划延期1个月交付，TR4A点不能变更，测试计划已安排的非常紧。在项目启动后，发现进度延期比较大，在一周内延期将近30%，且项目组新员工人力占2/3。
解决方案：
a) 加强监控力度，由原来的按周监控，更改为按天监控，员工每天报告进度；
b) 新员工比较多，老员工逐个指导新员工进行设计，使新员工效率普遍提高；
c) 对测试用例删减，把握重点测试用例，非必要功能删减测试。
l XX项目中变动了3人次，解决方法是开发人员相互备份。
l 技能高人员带动技能较低人员。
l 交叉培训,在新员工多的情况下，让新员工先学习，针对技能不足的点再培训。
l 员工尽早投入，提前熟悉。
l 一带多，老员工多把关、少参与开发。
l 人力不足时，及时有效的监控，及时发现问题，提供相应的帮助。
l 求助，向其它项目组寻求经验。
l 制定合理的计划，在计划中体现上述工作的成本，获得上层认可，实现人员培养。
l 加班，但要避免出现加班多、人员负荷大、有怨言影响士气的情况，项目经理要提前沟通、觉察，解决员工思想上的问题，让员工理解，便于员工监控。加班不能做为长期的不间断的方法，只能有限使用。
l 人员变更频繁会容易导致没有归属感，可以在项目组中提出“每次上班像回家一样”的口号。
l 人员离职时，给项目组成员交接，把最精通的部分写成一个总结，给项目组人员进行培训。
l 通过领导协调，确保资源投入。
Ø 实践：对于人力资源得不到承诺的问题，我说一点。产品线经常会需要相关组给予支持，一般开始时承诺的都很好，但在开发过程中，各个产品线进度都很紧张，很可能得不到及时支援。怎么办，把问题列出来，责任人定为领导，不断发邮件等催促实施，这就是让领导为我们打工。
2.4.4 天？
l 在监控时根据规模和紧急情况确定监控粒度：对大规模项目，按周跟踪，对小项目或紧急项目/攻关项目，按天跟踪。
l 一般周期为1个月内的项目要以天为单位。
l 人力为零点几时，需采用任务监控方式。
l 监控的粒度在项目过程中是可以变化的，要根据项目实际情况考虑。
Ø 案例：有个项目，规模3KLOC，C语言，老员工开发，技术难度很高，开始为按周跟踪，在LLD结束后，改为按天跟踪，特别是UT阶段，每日一报。
l 过程中要及时总结哪些监控有问题，及时调整；要给出明确的需求验收；跟踪问题直到关闭；关键模块人力优先满足；
l 正常监控方式可以通过定义监控模板，小组成员自动上载。
反面案例1：项目未有效监控和沟通，最后员工离职。
描述：刚刚担任PL的时候，上面根据项目给员工分配任务，没有进行沟通去了解他的能力，在执行过程中，我没有关注阶段点，也没有对员工进行引导，去提高他的能力，或者在这个阶段我补充人力加大项目的投入，这些工作都没有做好，导致计划拖延，这个员工比较内向，也没有及时反馈问题。计划一直执行不了，也完不成。当时我可能态度不好，也没有给他缓解压力，这时我沟通不了了，找PDT经理解决，也没有办法沟通，最后让他自动离职了。
反面案例2：计划沟通时未倾听员工的真实想法，导致执行偏差。
描述：制定项目计划后，需要跟员工有效的沟通，当时我们有一个很难的模块，分配给了一个技术能力很强的人去做，但还是有挑战性。在制定完计划后，我跟他沟通时，说项目多么多么紧，把压力传递给他了，跟他说我们要求在这个时间点交付，你觉得你能不能完成。他想了一下说可以。我们就这样决定了。过一个阶段，发现有一点延迟，我就把计划往后调整了一下。我再去跟他沟通，说我们就决定这样了，不能再调了，你看行不行？他又想了一下，说可以吧，挑战一下，加加班。但最后还是一拖再拖。作为PL，跟员工沟通时，要想听他的真实想法，不能把这种压力传递给他，否则，他会给出一个不切实际的承诺。
l 要求必须走正规电子流，正式下发，禁止邮件发送，对客户需求走需求变更电子流，对研发内部需求走规格更改电子流；
l 必须有CCB裁决机制，CCB评审人员要包括SE、RDPDT、测试、市场、QA以及相关组成员；
l 对需求变更进行影响分析（风险、人力、计划、进度等），在CCB裁决前PL可以先预估一下；
l PL应对新需求进行过滤，未讨论清楚前，不要下发到项目组成员；
l 多和Marketing人员沟通，Marketing要对需求把关；
l 变更结果及影响要反馈到相关人员；
l 迂回策略，通过周边资源如QA督促变更规范性；
l 加强变更规范性宣传；
l PL与RDPDT、SE等沟通，达成对新需求的一致理解；
l 加强前期需求包的评审，减少需求变更的发生；
l 对技术风险较大的需求，可以先采取技术开发或测试单板的形式；
l 重新评估，调整计划、进度，考虑推迟或减少规格；
l 人力协调，争取增加资源，可以协调外部资源；
l 合理安排任务优先级；
…..
l 做计划时提前预估会增加/变更哪些需求，预留余量。
l 考虑实际情况，裁剪已有需求。在项目过程中，可能会遇到突然加几个需求，有些需求并不是那么紧迫。
Ø 案例：有一位PL提到，他们项目刚开始有10个需求，中间又来了5个新需求，如果按照这个计划，他们很明显就做不了。他们跟开发代表交流后，把原来10个需求排序，把不紧迫的需求先不做，保证了进度。
Ø 案例：在我的一个项目中，我们设计的IMS2.0功能中，支持IPV特性，原来这个是必须的，其中一个组件有个Bug，一直过不了，现在TR4很快就要过了，经过沟通，把这个需求改成可选。
l 重新评估关键路径，调整资源；
l 争取更多资源；
l 压力传递到项目组和相关人员；
l 和RDPDT协商，是否可以适当降低质量要求，下一版本升级；
l 区分需求的重要度和紧急度，分版本开发；
l 提高效率，并行操作；
l 过程裁剪；
l 推动开发代表调整1/2级计划；
l 加班；
l 前期控制需求；
Ø 案例：对于需求、质量进度变化大这个问题，我们产品线进行了需求的前期控制，而不是后期。将技术骨干、系统组成员和项目经理都到一起开会对需求进行前期讨论，彼此深入沟通。这个方法很有效，产品线大约96个需求，只有1、2个有需求变化，还是在开发过程中我们自己为了完善功能进行的修改。
l 需求变化后一定要合理估计、调整计划。
Ø 案例：有一个项目分配33个需求，时间点要在3月至8月完成，当到了LLD阶段时，又增加了一个需求约1万多行的代码，我们调整了计划，但很快发现原有的项目没有做好，新的需求分析也不透彻。这时QA帮助分析做了估计，如果这样根本完不成任务，于是和开发代表协商，最后决定新需求重新立项，后来两个项目都圆满完成。
Ø 案例：有一个项目在需求分析时，通过跟运营商交流，发现一个新需求没有加进来，于是加入，重估计代码量增加了30%（人力不增加），QA发现后，建议调整计划。我们将需求逐步细化、排序，重要的完成，相对不重要的二期项目来做，这样避免了进度延期问题。
l 重新讨论评估设计方案，调整设计策略；
l 修改要受控，要注意配套更改；
l 加强评审检视，对变更部分重点关注；
l 做好需求跟踪；
l 搜索是否有CBB或类似产品设计可供参考；
l 协调相关部门优先支持，如工程设计人员等；
l 针对性培训；
l 主要性能重点监控；
l 知会到相关环节；
l 原有的设计也需要进行总结，或可形成CBB，作为后续参考；
l 重新评估计划是否需要调整，包括进度、人力等；
l 项目组内任务安排考虑重新调整，重新评估关键路径，安排有经验人员完成；
l 鼓舞士气；
l 及时沟通，多激励，多赞扬，前景描述
l 领导慰问；
l 荣誉奖；
l 分析困难点，寻求理解；
l 说明原因，通过回溯区分责任，肯定前期工作；
l 需求分析时项目组成员提前参与；
l 前期对需求进行评估，提前识别风险大（有变更可能）的需求；
l 即使被砍掉的项目也应有机会参与某些荣誉奖项的评选，如团结协作奖等；
l 需要进行项目总结，肯定对后续开发的作用；
l 被砍掉的项目也可能产生专利等技术成果，要及时予以肯定、奖励；
l 后续更改更要慎重（开发人员可以接受一次打击，若再打击，则什么手段都难起作用）；
l 要避免互相抱怨，包括组间、部门间抱怨，要有大局观；
l 对个别员工投入很大也因此打击很大的，要进行个别沟通、重点沟通；
？
2.6.1 计划？
l 评审计划提前确定，并协调好资源，获得相关组的承诺；
Ø 体会：在本项目组或相关项目组评审时，我们要心里有数。我要预支的话——可能要参与哪些外部评审，这时我们要思考项目组该怎么去做，同时把这些工作列到我的周工作或月度计划中，以保证工作的落实，而且要和相关的检视者初步沟通——你可能会参与我的检视。
Ø 体会：其实现在我们有些专家不是不愿意投入，可能时间比较少，他为什么不愿意投，是有原因的。就是说REVIEW评审我也愿意投，但是没法投，为什么呢？因为项目组没有提前跟我预约，这是个突发事件，这样专家就很难抽出时间。所以我们在评审之前，要把评审专家的资源在计划里都做好，就是说我们提前1-2周与评审专家预约，如果他有时间就把时间定下来，如果他不能参与，就联系其他专家，以保证评审时的专家投入。
Ø 体会：计划不如变化快，如我做了6天计划，里面也包括参加评审，但到了评审时我可能参与不了，这可能跟公司的现状特点有关系，如果我保证了评审的工作，但可能又保证不了其他的项工作。一个人的资源有限，如何提高评审效率。方法：让大家的工作量减少，可能让大家多些时间投在重要的工作上。
l 每个阶段做下个阶段的Review计划，并列出下阶段所有的交付件，包括一些帮助文档，指导书，接口指南等，都需要安排负责人处理。
l 评审计划纳入开发计划中；
l 计划提前通知，明确专家任务，帮助专家节省工作量；
l REVIEW的几种方式（建立过程节约成本），根据不同方式制定合适计划；
Ø 基本排错型的评审；
Ø 思路决策型评审，我做了一个方案，我想看看技术取向对不对；
Ø 项目组内的评审
Ø 覆盖型的评审
Ø 高危、重点产品的评审
2.6.2
l 建立一个角色列表，明确哪些评审该由什么角色参加
l 定义需参加评审的角色的最小集和最大集
l 成立专家团
l 邀请评审专家时要考虑产品差异、复杂度
l QA审核把关
l 在项目开工会上就要明确责任主体；
l 产品公布任命书；
l PL提前协调沟通，可单独预约专家；
l 自己和专家一对一沟通；
Ø 体会：我们为什么会采取这个方法？因为我们在申请专家预审的过程中，很难把专家集中，刚才那个组提到了集中评审，集中评审就要求专家在相同时间都有时间参加这个会议，这些专家不能同时集中的话有什么办法？那我们项目经理或文档作者就会事先找专家一个个提前进行沟通，沟通以后，他可以提出一些问题和意见出来。
l 找评审专家的主管协调；
l 通过专家协调员（部长级）解决资源冲突，专家活动透明化；
l 上级制订规划，帮助协调；
Ø 实践：沟通评审时间技巧。如我预先请外部专家时，特别是不是很准的专家时，我们在评审前要对大家的时间有数，然后再请相关的专家进行沟通、交流，确保专家有时间投入；另外一方面可以通过上层决策，如我们协调比较困难时，就可以通过上面的开发代表或PDT经理的把困难往上传，让上面的领导沟通后把相关的高层领导将这个工作落实下去，然后再请相关的评审专家进行沟通，这样效果可能就会比较好。
l 小的方面：当模块、变更、移植对代码产生变更时，大家可以找当时的作者或对作者产品比较熟悉的人员提一些意见。
l 专家不足，可以项目组内部培养；
Ø 实践：内部专家培养，大家不要光考虑从外部请专家。像系统组、测试组，虽然我们在计划开始阶段我们会请他们参加REVIW，但我们主要的评审力量还是在项目组内部。项目开工以后，可能有些模块大家都不熟，一开始1个熟，这时我们就可以培养一些人做模块备份人员。在前期备份人员可以作为补充，在后期测试人员比较忙的时候，一般还是以备份人员来评审。
l 和测试组、系统组协调人员；
Ø 体会：在项目计划中包括质量保证和质量控制活动，这些活动包括评审计划的制定（制定详细、完整的评审计划），如REVIEW包括测试组和系统组；并获得相关组的承诺，可能最终的投入与计划有偏差，但是一定要先把它纳入计划。如系统组和测试组保证不了投入时，我们应该在计划阶段把压力往上传递，不要等问题出现以后，再去进行协调，要提前纳入到计划中。
l 根据评审对象特点组织评审活动；
Ø 实践：参与度不高的原因，有些是对这块工作不熟悉，有些是确实比较忙，比如说，我们在评审界面时（界面中的用户设置、资料、测试方面关注得比较多），大家提出的问题不多，这可能是因为他们比较忙，或根本没看，这时怎么办？可以通过把大家聚在一起进行小的会议，或通过作者/设计者的讲解，让大家提意见，现场看看这个产品有什么问题。因为你让他自觉的做事情很难，但是现场让他做可能就好控制些。
l 可以把相关的工作分模块，让专家把文档过一遍先熟悉一下，然后再进行集中检视。
l 把模块的重要程度和优先级分出来，要做到先提前检视，再集中检视，同时PL要监控到大家责任心不足的问题。
l 关于评审粒度：文档40页之内，代码不超过500行，公司是有数据的。但是像1000或2000行以上的就得放大粒度来看。
l 多次评审，先进行内部评审，发现低级问题，再提交给专家评审，提高专家评审效率。
l 集中人员在固定时间内检视，封闭检视或周末集中评审；
l 注重检视的介绍会议；
Ø 实践：在准备会议之前，可能由于预审专家对我们产品领域不了解，可先开一个介绍会议，给他们介绍我们产品领域的相关产品、相关知识，当他来评审的时，就会清楚他评审的重点在哪里，而在会上我们采取集中评审的方式，而不是分开的去解决问题，这样效果可能会好些。
l 事后及时与专家沟通确认；
l 评审的结果最后一定要知会专家，让他感到工作得到认可；
l 建立奖惩制度，专家的工作量要给予肯定，与考评挂钩；
Ø 实践：我们把大的评审、检视作为个人考评的一项，把它与工资或奖金挂上钩，或者在PBC里明确定义下来——它与你本季度最终的结果是相关的，以保证相关工作的到位。有时候评审投入不高是因为他们认为与自己项目组没什么关系，通过这种绩效的方式可以保证他们的参与度。
Ø 实践：我们可以采取量化考核的办法（量化考核公司有流程），现在质量和系统部都有一个联合系统部，联合系统部对SE有考核，SE必须参加有软件需求的文档。同时，我们部门对资料检视也有一个排行（是针对专家的），比如说REVIEW的规模是多少，REVIEW了多代码、文档、检测出来多少问题，对REVIEW专家有量化的考核，可以保证专家的投入，管理上也会容易些。
问：SE本人知道考核的事吗？
答：知道，公司是有规定的，我们部门的KPI指标中专门有对SE考核有内容，包括他对评审的内容、参与文档评审的数量，质量部门对SE有这么一项考核。
问：对其他人员有这种指标吗？
答：没有。
l 质量部对评审资源池做审计，评估专家任职；
l 产品线内对各次评审参与专家及发现问题数进行公示、排序，建立专家参与评审的档案，定期通报参与情况；
Ø 实践：如排行榜。我们是把大家抓BUG的数量进行排行，让大家主动发现问题。
l 建立专家评价制度，专家评价要以发现问题数量和质量作为客观依据；
l 通过质量回溯，加强执行力度，落实到人；
该阶段质量是否达到要求？如何进行评判？
l 主审人把关初稿质量；
l 最好召开评审会议，会议前要充分准备；
l 加强CHECKLIST应用，适当裁剪，责任人提出优先级；
l 通过签字制度明确责任；
l 对评审的问题数和密度进行度量，过高或过低的均需要再次评审；
l QA关注过程，PL关注评审重点；
l 建立问题跟踪确认机制，确保及时解决问题；
l 进行度量分析，通过问题数和工作量投入等评判；
2.6.7
l 邀请测试部参加代码REVIEW，提前公布修改点，再进行测试。
l 先出优化设计方案；
l 先出检视方案，再进行代码检视；
l 这里主要讲代码承诺，当代码规模比较大时，挨个去检视效果肯定不太好，所以就要先出承诺的检视方案，大家针对检视方案进行评审，然后再对代码进行REVIEW；
l 对规范性的改动，如对存储过程，应该有CHECKLIST；
l 代码改动太多的，针对具体特性、优化，PL组织项目组内2-3个专家REVIEW；
l 集中项目组人力对所有问题单进行REVIEW，让新员工了解，对新员工培养很有帮助。
2.7.1
l 要符合公司既定的质量策略和质量方针。
l 参考能力基线。质量目标不是凭空制定，制定质量目标要参考组织能力基线，看看质量目标是否合理，然后进行调整。
l 考虑风险。既然是质量策略，应该考虑如何达到质量目标，出现问题后，怎样来弥补。
l 考虑可操作性。如我们在某个点要做什么样的活动，以使质量策略真正达成目标。
l 需求的稳定度。需求非常不稳定，突然之间来了个用例冲击了一下，又要调整项目人员的分工。需求的不稳定对项目的冲击，要考虑到质量策略里面。
l 考虑项目类型，并选择适合的开发模型。不同的开发模型制定的质量策略是不一样的。是开发项目，还是增强项目，还是维护项目，选择一个开发模型，并考虑是否裁剪，如在设计阶段，要不要进行HLD，LLD，还是把HLD和LLD合并，只做一个SD。根据项目进度考虑到人的因素，选择合适的项目开发模型。
l 资源。如果项目中需要一个试验设备，如果不早期采购的话，在做测试的时候，发现设备要申请，要申购，资源不能保证，质量也不能保证。
l 项目成员的技术经验情况。
Ø 实践：项目组中是新员工，还是老员工，还是专家，从质量方面考虑都不一样，包括质量活动。如果很多都是新员工，在质量监控方面可能要考虑，这样质量目标要分解到各个阶段，要进行监控，各个阶段的质量目标都要严格把关。对有一定经验的老员工，质量活动的考虑，像SRS阶段和设计阶段，这些阶段的质量目标可能要重点去关注，他们的编码能力已达到一定的水平，现在重点关注需求分析能力和设计能力。对于技术专家，他们在各方面的能力都比较高，在制定质量目标时，要考虑专家的质量本来就很高，文档和代码本身的质量就很高，这时制定质量目标时，就要考虑根据公司的基线是不是进行适当调整。对于新员工的情况，质量目标，问题发现率，代码检视发现的问题，就要适当的调高，新员工一般出问题的情况比较大，而老员工根据公司的基线就可以了。
l 项目进度与人力情况。在有限的人力和进度下，如何达到产品的质量。在质量策略中，需要明确下来的，就这些人力，市场进度也很紧迫，在后续的质量活动中如何取舍。该重视哪些活动，该裁剪哪些活动。在任何一个阶段都要投入人力去做的话，那在质量上的成本是很高的，那就没办法保证市场的紧迫进度。
l 分析项目面向的客户。比如说平台，它做的平台是针对公司所有产品的，它的产品的稳定程度，对很多产品的质量是有影响的，对于平台的质量就要求非常高。允许多少个问题，最后产品的稳定程度怎样，也包括需求的稳定程度也都是要考虑的。对于一般的产品，如果它面向重点局点或重点客户，或者面向一些普通的开局，根据不同情况进行考虑，对于重点局点或重点客户，质量方面要求更高。
l 制定质量目标时，需要考虑：1、客户需求（功能、性能、进度、认证……）；2、开发风险（技术、人员、产品地位、周边环境、开发模式、商务……）；3、售后策略（受限地区、客户层次、服务范围、替代策略……）
l 要分析专家投入，考察过程是否充分、有效。
Ø 体会：数据达到了，要看有没有真的达到，要分析专家的投入，分析检视的问题，看问题的划分标准是否正确，检视的效果好不好。看专家是否投入了我们计划中的工作量，如果专家只投入了1/2或1/3，就检视出来这么多问题，说明我们的质量目标是要超过上线的。要分析是否达到下线和是否超过上线。
l 分析缺陷原因和类型，用于指导以后的开发。达成了质量目标，也要进行分析。我们发现的错误主要是编码级的错误，分析错误主要分布在哪些类型上，对于编码人员是能力的提升。对后续的开发是很有指导意义的。
l 应用质量目标进行质量控制的步骤：
a) 目标清晰合理。根据历史数据、组织PCB（过程能力基线）、结合项目的实际情况（技术难度、开发进度、人员水平）制定出项目的合理质量目标。
b) 绘制控制图。利用实际度量值和预期目标形成控制图，可以清楚的看出项目在各个阶段的质量分布情况，需求关注那些超出上下线的阶段。
c) 查找异常点。分析控制图，查找出现异常情况的数据点。
d) 根源分析。一般采取鱼骨图，柏拉图（项目影响最大的几个分歧点）。
e) 制定控制措施。对问题原因进行分类整理，在限制条件下制定出可实施的有效措施。
2.7.3
l 分析过程的有效性。
Ø 体会：人力投入，找新员工检视与找专家检视，结果是不一样的。经验的积累在检视过程中发挥很好的作用。质量控制两个最基本的方法：开发阶段的检视和开发后的测试。开发阶段的检视效果是最好的。
l 考虑质量目标的合理性。
Ø 体会：比如对技术专家，定的质量目标比较高，发现的问题数相对来说比较少，对于这种情况，如果原因合理的话，可以提提例外报告，经QA同意，可结束该阶段。如果是其它的原因，那么就要重新进行改进，重新进行检视。
Ø 体会：如果是制定的目标不合理。如我们是增强项目，我们用错了质量目标，或者这个模块本身是比较稳定的，质量目标定得过高，达不到，就可以结束。
l 分析检视问题收敛性。
Ø 实践：我们在过程中，做了几轮检视，就是达不到我们的质量目标。分析发现检视的问题越来越少了，收敛了，可以考虑结束本阶段。
l 分析质量可控性。可控性指：质量目标没达到，如果在这个阶段可能出于进度或其它方面的考虑没办法弥补，在下一个阶段提出的弥补策略是否可行？如果不可行，则不能阶段结束。
l 召集相关的专家、部门人员一起来评审，共同决定是否通过。
2.7.4
l 对新员工的过程监控更细致点。
Ø 实践：要多增加监控点，这里监控点不是项目的结束阶段。根据不同的阶段，如编码阶段，三天就要监控一次，在写需求时，可能一周监控一次。考虑后期有没有风险发生，如果有的话，及时采取一些策略。
l 让新老员工形成互补。一对一的互补关系，或者新员工编码，老员工review，形成互补关系对团队来说是非常有好处的。
l 项目老员工发挥老员工的作用，包括项目管理和技术控制。
l 把老员工分类、共享、分组，按技术点分类，组成资源池，更高效地发挥老员工技能。
l 提高新员工技能来保证质量。
Ø 实践：首先了解新员工的特性，有没有工作经验，根据不同的人采取不同的策略。前期集中引导，告诉他我们项目要达到一个什么样的目标，我们公司要做哪些东西，我们项目要做部门里面哪些东西，从大到小，找到各自的位置。了解要做什么，针对做的东西，进行一个强化培训。
l 重视总结和提高。对于新员工，他们可能第一次进行这样的活动，要多总结，经过总结才有提高。
Ø 实践：每一个阶段进行了一些活动，有开发任务，有学习任务，每个阶段写学习心得和感受，然后大家交流。一种方式是写一个总结，以文档的方式，把它固化下来。另一种方式是进行交流，在周末，快下班了，利用1～2小时，请专家过来解答疑难地方。让新员工感觉有人帮助他，不要让她感觉孤立无援。
l 充分授权。
Ø 体会：告诉新员工怎么去做了，就放手让他去做，而不是总是害怕他做错，不让他去做，这样他会感觉到你不信任他，他就没兴趣了，没积极性了。充分授权告诉他应该怎么做，遇到问题，找谁来帮他解决。当然包括及时引导，和合理地监控。你授权了，你不管了，最后交付的东西肯定会出问题。
l 在新员工比较多的情况下，成立小组学习。
Ø 实践：新员工跟我们（PL）的交流可能有一定的障碍，新员工之间的交流没有障碍。成立学习小组，共同模块、关键模块的学习，流程管理，发挥新员工的想象和积极性。这样效率比较高，效果比较好。
l 加强培训指导，组织流程培训，提高质量意识。从技术上，从软件开发过程理解上，进行指导，让新员工了解项目开发流程，了解为什么这么做的原因（而不仅仅是告诉他必须这么做），提高新员工质量意识。很多新员工可能没有进行正规的软件开发流程。首先要进行流程和技能的培训，提高对质量的认识。
2.8.1
l 要对他们进行公司文化牵引；
l 在待遇方面先画饼，帮其分析个人发展前景；
l 细分职位，分担责任，给予个人责任感、成就感；
l 对于优秀的员工及时、准确地给予表彰；
l 让其多融入到集体，提升集体凝聚力；
l 生活上多关心；
l 分配思想导师，思想导师的工作到位；
l 加强培养，明确培养目标；
l 适当安排工作，使新员工感到受重视；
l 要结合新员工的心理特点，比如70年代、80年代的心理特点是有区别的，沟通、培训、安排工作要尊重和符合他们的心理特点；
l “跳一跳，够得着”，安排工作有适当的难度，有助于提高他们的信心。
以下是适用于骨干老员工和一般老员工的通用方法：
l 表扬要即时、正确，过时的表扬有时不但起不到效果，反而会有负面影响；
l 争取加薪；
l 利用其和公司的感情，与其多讲讲公司与他的故事；
l 了解生活困难，多与其进行心灵沟通；
l 采用“一对红”的方式让其带新员工，并进行公开表扬，抄送干部部；
l 公开进行每周一星的公告；
l 要注意变化操作方式，因为老的激励方式可能对于他们来说已经麻目了；
l 在日常的饭局时，可对其在洒后提出严格要求；
l 反（负）向激励；
l 老员工一般需要做一些创新工作，如果一段时间内不能安排，可说明过一段时间后考虑安排；
l 向老员工说明，各项工作要平衡，每项工作都很重要；
以下方法适用于骨干老员工：
l 了解想法，适当、合理的满足需求；
l 让其多带新人，承担更多责任，增强他的成就感；
l 让其多进行技术专题研究；
l 让其参加培训和培训他人；
l 让其做模块负责人；
l 让其参与奖惩；
l 培养接班人，如果有了接班人，他自己也有晋升的机会；
l 通过老专家与上层沟通，如让其在OPEN DAY跟上层领导沟通；
l 尽量安排一些重要的工作；
l 多授权，提高工作自主权；
以下方法适用于一般老员工：
l 肯定老员工的工作价值，讲清楚其价值所在；
l 对老员工提出一些希望；
l 深度沟通，给出职业方向索引（明确职业发展目标）；
l 像对新员工一样对其设置危机感；
l 了解老员工的矛盾所在，如工作无新意、价值得不到认可等，进行深入沟通、了解各种问题的根源，帮助找一些解决办法；
l 给予更多尊重；
l 引导其多提建议，增强团队归属感；
2.8.3
l 开工会、做LOGO、设立群组名（通过公共服务器，进行自我介绍），明确团队愿景；
l 进行足够沟通，熟悉成员的特点、特长、明确责任；
l 通过团队活动来增进成员之间的关系；
l 培养大家对团队自豪感、责任感、使命感；
l 利用产品名称，提高大家的归属感；
l 确立核心，发挥骨干员工的作用；
l 尽快建立项目成员的工作环境，包括办公平台中部门/项目编码的建立等；
l 项目经理快速动作，尽快完成项目计划等项目前期工作；
l 明确每个人的目标、任务，安排项目组内不同的角色；
l 尽量做到集中办公，集中吃饭等，而且要在座位上合理分配；
l 建立培训计划，开展培训工作，促进成长；
l 请高层领导讲话，进行动员；
l 研究工作难点；
l QA对项目提出要求；
l 参考国外一些软件项目形成统一标志的一些做法，可以给出项目独有的特点，比如定期举行活动、定期培训等。
2.8.4
l 明确责任，项目经理主动承担责任，责任不在大家。
l 行百里路半九十，以此激励大家。
l 大家共同分析延迟原因，找出改进点，明确后期的措施。
l 总结在困难中取得的成绩，说明领导的肯定与期望，最好请领导来讲话。
l 给项目组成员展望愿景，讲清市场形势；
l QA应藉此机会，引导后续的质量活动。
l 请大家吃饭，搞些郊游活动等来减轻压力、释放压力，缓解紧张神经，鼓舞士气、军心；
l 领导以身作则，带头加班；
l 项目完成后承诺休假、集体出去旅游等；
2.8.5
l 请开发代表发言，肯定成绩，说明项目到了生命周期结束时；
l 项目归档，根据项目特点可安排形成一些培训资料；
l 向员工推荐后续的项目，说明项目解散后续的工作安排；
l 给大家总结，点出每个人工作上的取得的成绩和进步；
l 搞一些活动，给大家庆功；
l 明确需要加班的原因以及任务＆目的：项目组遇到了哪些困难，才过来加班，不要让项目组成员认为是盲目加班；
l 让员工了解项目组的目标＆困难，最好让员工主动提出进行加班；
l 团队的绩效牵引，使员工感受到加班后完成任务的成就感；
l PL带头加班，鼓励士气，制定合理的里程碑；
l 加班的时候可以安排一些培训、检视等公共活动（这样做可以减少些抱怨）；
l PL在适当的时候对项目组成员进行一定的补偿，比如搞一些集体活动等；
l 给出加班的期限，让员工看到加班的尽头，不能让员工觉得天天加班，看不到希望；
l 引导员工提高日常工作效率；
l 给员工一定的机动性，不强制加班；
l 加班最好能让项目成员都来，一个是有助于讨论，一个是有助于提高项目的士气；
l 有些“牛人”能力很强，故意拖延进度，因为他们知道如果做完了，一定还会有更多的任务加过来，而且从现状来看，华为的加班不是短期行为，而是长期的一个政策，要注意如果项目经理承诺只一段时间加班，到时候兑现不了，会让员工认为是一种欺骗。
【场景演练实例】心服口服安排加班
PL：市场现在下来一个紧急需求，要求我们大家一个月内搞定。我们现在工作任务已经很饱满，大家看看除了加班外还能有什么好方法能顺利完成这项任务？如果没有，确实就需要安排加班了。
成员：那我们要加多长时间班？
PL：初步估算，该需求要30人天的工作量，我们组一共6个人，共要加班5天，初步设想，每周六加班，就是4天，平时再额外加一晚上大概2小时，这样就可以完成任务。
成员：现在我们已经加班很多了，有产品例行加班，几乎天天晚上都有加班。
PL：当前每周的加班主要是培训、学习。可以适当的将这些内容压缩或推迟。另外考虑到大家的身体，我们项目组每周一安排锻炼身体。周二、三、四晚上安排加班，这样就能充分完成我们的任务。如果我们能本月完成这项任务，对整个项目组是很重要的。
成员：我觉得只要我把任务完成了，加不加班应该是看员工自己的情况，如果我能完成任务，就用不着加班了
PL：我觉得是这样，我们这个项目是一个团队，大家都在这里，和大家不在这里的感觉不一样，我们还是需要提倡这种团队合作的意识。
PL：大家是不是能把这段时间熬过去，克服一下困难，任务完成后，我们可以申请团体奖项，同时，下个月可以安排大家轮休。
成员：轮休也是用我们自己的年休假吧？
PL：是年休假，不过年休假也不是说平时想休就休的吧，而且一般年休假最多请一天、两天的，如果我们这个项目顺利完成，就可以让大家多休几天年休假，比如连着休5天，可以好好放松一下。如果有什么困难，项目组可以帮着一起解决。
成员1：我每隔一周要去一次苏州（表示有困难，没时间）；
成员2：我家正在装修，下班后和周末需要有很多事情要处理（表示有困难，没时间）；
PL：大家还是尽量克服困难；
成员：要不这样，我每个周六请假，周日过来加班？
PL：那也可以，你的时间要自己把握好。
成员：能不能把集中讨论的放到平时，我平时多加班完成，周末就不来了。
PL：这样不行，一起加班有助于鼓励士气，还是大家都来吧；
成员：但是我觉得只要工作做完了，没必要周六一定要来。
PL：如果能平时把工作做完，周末不加班也可以，但是如果平时做不完，周末就一定要来加班，确保任务按时完成。另外，视情况需要，若需要大家都参与（如检视、调试等），则都需要来，以保证相互有效配合。
成员们：OK。
l 通过实际工作提升技能
Ø 让新员工多参与实际工作，如处理问题单或网上问题，通过实际工作来提升。
Ø 任务驱动，压力传递，提供他们成长的机会，敢于给新员工分配任务。对新员工的输出结果要严格评审。同时明确如果出了问题，责任人不是新员工，而是主管或导师，打消新员工的顾虑。
Ø 【体会】关于新员工培养，新员工不要让他过长时间的看资料，建议最多学2周，而且刚开始最好从测试入手，因为中测试工作中会遇到各类问题，可以加快他对问题的理解和学习。
Ø 参与代码走读。
l 组织培训
Ø 建立系统的培训体系；
Ø 集中组织培训。根据每个部门的特点，拟出每个部门培训的Checklist，培训区分专业课和公共课。
【实践】我们硬件部的方法：建立大学——培训班，将所有的新员工集中培训，共同学习硬件的一些基本知识，开发过程中一些基本规范，正确引导的方法论及公司的流程体系的学习。培训后的新员工再分到各个项目组。目的是要每一个员工在开发过程中规范化，统一化。当然我们的培训班也在不断的总结经验不断的完善。
Ø 面向不同的对象举办不同的培训，主要分社招、硕士、本科，因为基础不同；
Ø 【实践】在项目例会上腾出1小时给新员工培训当前的应该技术，并要求新员工到台前针对当前掌握的情况进行陈述，这样做可以加深他们的技术理解，且容易发现问题，会成长的更快；不但给新员工做培训，而且让每个接受培训的人到台前来讲，叫做陈述，如果他能把学的东西都在白板上写出来，就表示他已掌握了所学的；
Ø 【实践】8090测试这边新员工是老员工2倍。我们将新员工分成几个小组，每天有一个老员工带领进行讨论学习，当天要进行考试，当场打分，这样对新员工是一个促进、激励的作用。现在已经将表现突出的调出投入到老员工的队伍中来了。
Ø 新员工给老员工作培训。
【实践】我们一般的模式是老员工给新员工作培训，发现效果不是太理想。在新员工做培训胶片时，他本身就需要了解这些东西，自己通过逆向的方式加深自己的知识的理解，老员工在底下可以给新员工提意见，提问题，加强新员工的思考。
Ø 培训后会有一个培训反馈，大家可以匿名向老师反馈或提出各方面的意见，可以让培训的人知道自己有哪些方面做的好的，然后给出改进；
Ø 公司的MINI培训应该提前参加
【体会】新员工应尽早参加MINI培训。目前有要求新员工在转正前必须参加MINI培训及相关培训。因为项目很紧张，新员工一进来就参加项目，项目的周期一般是3~4个月，刚好新员工转正时，项目开始做Coding，跟相关的产品相关的平台去连调，与单板硬件连调，这个比单元测试以及其它任何一个阶段的工作量都要繁杂，工作量特别多，如果不让他参加培训，就影响他的转正，如果把他抽走，那么这个任务没人做。所以我们认为，项目开始的阶段，新员工投入的比较少，所以让他提前参加MINI培训比较好。当然，MINI培训放在后面参加也是可行的，如果有项目经验，培训的效果更好。
Ø 开展案例培训
【实践】新员工很多，产品开发过程中出现了很多问题，为了避免新员工继续犯这种错误，保证他们一次能把事情做好，我们每个月例行有一期案例培训。案例来自于这些问题，由骨干员工写出来（有时候也让新员工写），让新、老员工讲。刚开始效果并不好，为什么呢？比如有4篇不同性质的案例，老员工很容易懂，新员工却觉得很深奥，接受不了。所以后来我们一方面减少案例的深度，讲一些对实际的工作有帮助、与实际工作相关的案例，再后来边讲案例、边问他们问题（一方面是讲的人问，一方面是让听的人问），形成良好的互动，这样效果比较好。
Ø 邀请专家培训
l 考核
Ø 适当的举办考试，但要注意考试是双刃剑。
Ø 培训一定要跟踪和考核，老师随机抽查提问。
【实践】基础课程都是整个产品的历史、总体框架、网络上的应用。这些都是引起对新员工有兴趣的地方。对讲师的满意度进行调查。讲课时，好像都听懂了，下来一问，什么都不记得。要求老师最后十分钟随机抽问，要求后面有培训经理的角色，你今天听了这门课我第二天第三天去抽查你，并跟踪抽查结果。
l 资料积累
Ø 部门要注重培训资料的积累；
Ø 最好每个版本写一些FAQ，供新员工参考。
Ø 收集新员工的问题，形成指导书；
Ø 把培训成果合成一本新员工攻略，如，新员工需要装什么软件之类的。
Ø 提供CHECKLIST。
【体会】新员工做工作时不知道从什么地方入手，但CHECKLIST就像是路标一样（它会告诉你这一步做什么，下一步做什么），他只要看看满足了就打勾，这是最基础的技能，1～0.5个月就能上手（干活）。
l 要求新员工多总结、多汇报，促进成长
Ø 每周新员工写一次总结，总结这周的学习收获、心得，并提出遇到的问题，由导师负责解答。每周PL根据总结和导师的答复，做一下引导。
Ø 强调输出。新员工要经常进行交流，有参加XXX培训的心得，否则只知道蒙着头学习。
l 技术交流、鼓励提问
Ø 定期的团队技术讨论、交流。让新员工自己总结、讲解学习、工作的内容，其他人来提问，促进新员工的进步欲望。
Ø 项目组内建立互助气氛，并鼓励新员工多提问，比如：可以规定新员工每周必须提出多少问题等等。
Ø 鼓励新员工之间的交流，比如可以让几个新员工定期的自己相互讲课，其他新员工来听讲；
l 提供导师
Ø 体会：新员工转正后，要指定一个业务导师对他的工作和生活一个引导。新员工转正了，但对公司的文化和工作的问题还有很多，他们真正需要什么，我们PL有时关注不了那么多细节，可能会忽略一些内向的员工的需求，如果我们不能满足他们的需求，积累下来可能导致一些隐患。通过业务导师，采取持续激励手段。比如工作中，某一点表现比较好，通过业务导师向上反馈。
Ø 除了在技术上对新员工引导，同时在做事方法以及职业化方面也对他们进行培养＆引导。
Ø 建立 “老带新”的快速上岗，注意座位分配时能临近领域专家/老师；
Ø 【实践】思想导师作用充分发挥（手把手，以身作则）。每一位新员工都有思想导师，有些导师就直接安排一些事情让新员工做，关注比较少，新员工只能靠自己，这样的效果就不好。我们现在谈的是手把手指导，思想做什么工作，新员工就照着做，新员工工作的时候思想导师要关注、即时检查，有问题即时指出并手把手指导，这样新员工很容易上手，不仅掌握了知识而且掌握了技能。
Ø 老员工带新员工，给新员工订好计划，并跟踪计划的执行。
【案例】固网有个布道者，他会把对技术的理解、价值观、心得给新员工讲，这个效果非常好，他们有了自己的偶像，对技术的兴趣就起来了。
l PL多关注、多鼓励
Ø 对新员工要及时给予鼓励，重视责任心的培养。特别是对应届毕业生来说，还没有接触这个工作，还不清楚工作的重要性，PL要有渐进式的管理。
Ø 每周PL组织导师与新员工交流，可以利用周末、周例会、吃饭的时间，大家一起交流。
Ø 新员工多，红星激励法，通过邮件，让组员之间提出一些经验，让新员工评，然后颁发红星；
l 针对性培养
Ø 对新员工有针对性的培养，对新员工分类，指明他们的发展方向、目标。
Ø 对社招生，可以让他把经验共享出来，让他做培训其实也是一个激励。
Ø 培养计划要结合项目计划，合理安排工作任务。
l 强调新员工学习的主动性。
Ø 有时候思想导师非常忙，就只能靠新员工自己多学习、多问问题，把工作中遇到的问题记下来。（问：怎么样让新员工主动学习？答：反复向新员工强调这件事情）
Ø 与新员工多谈人生观，鼓励他上进，与他谈心，以身说法。比如：说自己在以前没人教，走了很多弯路，你们现在条件好多了，还有思想导师等。
l PL、开发代表等要以身作则
Ø 【反面案例】不光只是PL，包括我们的老员工、开发代表都要有一个模范作用，不同的项目会有很大的差距，在于各个阶段的学习及流程的遵守。有一个PL在周例会上批评一个新员工，“现在都什么时候了，你还把定位信息写这么详细干什么？问题单处理了没有？”，对于处理单的问题定位应该鼓励新员工把信息写详细，他反而不一样。这是一个整体的水平，3个月可能体现不出来，半年一年后就体现差距。
l 【案例】：如何处理新员工兴趣与工作不符？
问题描述：新员工能力很强，但他属于性格比较张扬，但他关注的与项目甚至部门不符，他的能力过剩，他可能用来发展很多他自己关心的方面。
处理方式如下：
1. PL在职责范围内进行调整。如果这个新员工所关心的有热情的东西是在我们组内能做到的，这种情况可以由PL来调整。如果这种情况做不到，就只能进行第二步了。
2. 与其它部门交换。看他到底有什么兴趣，如果他的能力很强，又有热情，那么对他想去的那个部门的领导来说也是欢迎的。可以和那个部门的领导协商之后，交换一个人过来。
3. PL可以深入了解他的根本的想法，想办法来转移他的兴趣，这是一个比较长期的工作。
l 老员工的技能也急待提高。
Ø 体会：产品线维护任务太重，同时员工本身思想不够活跃，外界又缺少激励、关注，很容易造成知识老化，知识层面闭塞。这里提出几点：多给老员工扩展技能的工作机会，激发热情；避免老员工做重复性的劳动；给老员工也要做培训规划；组织外围活动，提升技能，使之参加非本项目相关模块的设计；给老员工画一个更清晰的“饼”。
开发工作量大，但很多的工作流程、新技术没有时间学习？
l 培训要适应需求。与部门工作不强相关的，先不要培训，要避免盲从培训。
l 建立技能模型
Ø 对于一个PL来说，需要根据项目类型，以及项目领域特点，建立项目组的能力模型。完成项目组的任务，必须具备哪些条件，如何让每个新员工清楚地了解在项目中把工作做好需要的技能。新员工不断地涌入，如果有这个能力模型，如果有新人进来，他马上可以加入团队进行成长，成为团队的骨干成员。
l 从员工的兴趣和导向来激发员工的积极性，来提高工作效率，让员工自发的去提高自己的能力。
l 模范作用
Ø 实践：流程又多，技术没有时间学习，为了适应目前的工作情况，对于新流程，我们找几个容易接受的成员，起到一个模范作用，一个新流程的引进，他带头学习，大家评审并参与检视，发现有什么问题需要改进的，整个项目组就很清楚的了解这个怎么做了。
l 每日讨论
Ø 实践：如果没有时间做胶片，PL可以弄一块白板，大家聚在一起讲，可以由老员工给新员工讲，也可以新员工给老员工讲。可以把他理解的东西全部讲出来，看他有没有理解透。老员工可以在白板上直接讲解新的知识点。非常地简介而且有效。新员工比较忌讳培训相隔的时间比较长，建议每日讨论的形式，周期短，而且消化快。有不足的地方马上可以看到。
Ø 实践：每日讨论，对于新员工来说，参与讨论非常地好，往往比讲课还要好。给出一些案例，让新员工去点评，这个也是逼着他去学习。随机的抽取，培训要有效果。
l 考虑新员工学习能力的差异。新员工的技能水平存在差异，对于接受能力比较强的员工，很快可以接受，这样可以安排技术好的老员工进行引导，快速提升技能。对于那些接受能力差的，如果PL去专注他，可能花费很多时间，让刚转正的员工去做，他们也乐于去做这些事情。
l 安排机会让大家出去研讨，提供交流、学习的机会；
l 安排出差，出去之后他们的接触面会广些，这样能激发他们的学习需求等；
l 安排参加技术大会；
l 成员之间互相讲解，组织讨论，把各成员的研究成果集中起来；
l 计划该调整的就要调整，资源该申请就要申请；
l 上一级与产品一级进行沟通，请求一些支援，进行有效沟通。
l 在新员工的团队里面，计划必须考虑学习和攻关，我们要度量好，先做哪块后做哪块。我们不仅向下管理，我们也需要向上沟通，把实际困难和求助信息提上去，让领导知道我们尽力了，但有些事情需要协调。
l 【实践】各阶段前的学习。针对开发项目或维护项目的特殊做法，除了流程中要求的开工会以外，有的PL在Coding前，组织编程规范，以及产品的特殊的编程要求，以及久治箴言的培训，以及发生的一些死机案例。有的PL在Coding前，给大家出一道小小编程题，然后大家一起点评，一个是统一编程规范，一个是屏蔽低级错误。
有很多是我们不懂的新技术
l 一个项目团队，不要激发英雄主义，而要激发团队的力量，新技术我们可以分工分模块来交叉学习，发掘一些更好地新员工的能力。挖掘潜能。
l 向周边的资源进行求助。给我们一些引导和培训。
l 对项目而言，并不是所有的流程和新技术都有好处，项目组成员并不需要知道所有的流程，要明确哪些流程是需要的。
l 培训计划和课程的开发是一个很重要的问题，对于一个部门来说，需要新员工有个基本掌握的知识点，如果部门有基础培训，对项目来说会减轻很多负担。PL和老员工一起把共同的知识点整理出来，进行周期的培训。新员工要根据实际情况去参加课程，PL可以给出建议。进行周而复始的培训。
l 尽量减少项目组有不懂的新技术的可能。
Ø 固网产品线将技术骨干分类，人员分配到每一个技术中去跟踪，这样就不会出现什么新技术；
l 新员工喜欢新技术（对新技术比较敏感），老员工动力不是很足，我们就可以进行一对一配对，让新员工去钻研某些新技术，老员工可以进行检查，起把关的作用。
l 项目刚开始应有明确的分工，避免所有的人在一起解决相同的问题，对于技术难题，应组织技术骨干研究新技术，对新技术攻关，一般性问题可以让经验一般的员工解决；在攻关的过程中要多求助，不要局限于项目组内；
l 派人员去学习。
Ø 案例：业软的ISAP平台，全是未知的新技术。项目初，派一个新/老员工到中软的ISAP项目中一起学习、开发，这后将经验等带回来，做成胶片在内部进行培训，通过这种方式达到新技术的学习、和知识的增长。
l 请预研人员＆相关专家跟踪，定期组织汇报和交流。
【案例】：我们项目组是做分组语音的，我们以前接到过一个项目有三项新技术，其中有一项是XXX，我们使用了一个可集成的CPU，其中一些套片里有新技术，在公司也是第一次使用，实际上每个项目在启动时作过评估（认为是可行的），但实际项目组员工没接触到这些东西，所以我们在项目启动时做了一些有针对性的计划：
a、 首先我们会使用供应商提供DEMO板进行认证；
b、 结合自己的产品，我们用哪个系统进行ST（验证工作），然后结合到开发计划，当项目进行到联调阶段时遇到的问题就会少些。
案例：好记性不如烂笔头
新员工刚来，对通讯知识不懂很正常，刚开始我跟他说了一遍，过几天又遇到这样问题，我又跟他说了一遍，在新员工答辩时，我问他这是什么意思，他又不知道了，后来认识到，这是工作和学习的方式和方法的问题，我问他在大学里有没有做笔记，他说大学里老师讲，做笔记，考试时用得比较少。我当时告诉他，我刚来公司时，我的导师是一个博士，他讲了一个关键的问题，这句话可能是理解问题的关键，当时我不知道，但是我把它记下来。过了一两个月后我跟别人交流，发现这句话是理解这个问题的关键。我告诉他可以使用Word文档或笔记本记一下重点，然后你看到别人讨论这个问题时，你看看你以前是怎么理解的，理解到哪个层次，你当时可能只理解了一半，但也进步了。否则你一个月后遇到同样的问题，你还是从零开始学习。他按照这个做了一个星期之后，有很多零散的知识点，然后可以解决问题了。学习和工作的关键是一个方法的引导。
案例：了解真正的想法
PL与普通员工的沟通方面的投入比较大。尤其是和新员工的沟通。当导师发现问题时，要及时的与新员工进行沟通。每个新员工都有不同的生活背景，工作背景，以及发展想法。应届生可能心态比较好，容易接触新的做法，社招生有一定的工作经验，做事时喜欢采取原来的方式。比如说填写表单时，他以前没有接触过，他也不去问别人，按自己的想法填了，有时和要求有很大的差别。尽量跟新员工沟通交流，了解真正的想法。案例：有一位新员工原来来华为面试时并不是想做他现在分配的工作，因为他以前做底层或写驱动程序，他发现他做的和原来的没有任何关系，他觉得这和他原来想的不一样，华为招他时，也没说做这些。一开始他就有非常大的抵触情绪，我感觉这位员工的积极性非常差，给他分配的工作，做完了也就OK了，也不去深究。PL要耐心与员工沟通，了解员工真正的想法。
反面案例：要求减半
我分配一个员工解决问题，一周之后问题解决了，他兴高采烈地跑到我面前，“这个问题我搞定了”，我一看这个问题非常简单，怎么要一周呢，我就说了非常不应该说的话“这个问题还要一周？”到现在我对这句话还非常的反悔，这对一个新员工打击非常大，后来我也跟他沟通过，但多少还是有些遗留的影响。对于PL，不要把对自己的要求去要求一个新员工，把自己的要求减半，然后去要求一个新员工，这个比较合理，也有助于新员工成长，经常鼓励是非常重要的。
l 分析新增任务，对新增任务的需求规模、风险、工作量、资源进行合理评估。
l 分析新增任务涉及现有任务及相关人员，整理原有计划，可能产生的影响和风险，和上级确认上述问题，确定优先级。
l 分析任务时应与相关人员充分沟通，组织本项目组或相关人员评估。
l 向上司说出项目组目前存在的困难，提出建议，要求协调资源。
l 同上司沟通，要用数据说话，不要个人以为，主观臆断，如要以数据来说明自己的工作量确实饱满。
l 作出多套应急方案供领导参考或选择，而不是直接给领导出“难题”。
l 给出备选方案，比如是否可以裁剪某些阶段。
l 邀请CCB评审备选方案。
l 与已有的需求做一个排序，对新需求以及现有需求的紧迫性进行评估，调整需求，对于不太紧急的需求规划到下一版本；
l 是否能降低某些相对要求比较低的需求的质量要求来换取进度。
l 注重承诺。如果承诺能完成，就一定要完成。考虑极限的情况，如果真的是无论如何也无法完成，要向领导说明项目组的实际情况，并进行风险分析。在与领导进行沟通的时候要注意沟通的技巧，并且要有诚意＆诚信。
演练实例展示1：“讨价还价”
上司：小姚，我知道你们项目组最近工作比较忙，但现在有个新需求，要求三个月必须提供，若不能三个月内提供，我们这个单子肯定丢了，市场部已找了我很多次，我的压力非常大。你们组能否辛苦辛苦，接下这个任务。
PL：我们组现在有5个人，每人工作量都排得很饱满，象南非的任务啊，都很紧急，我这儿有份任务列表，您可以看看。您刚才说得这个需求，我估计了一下，大约需要3个人月, 目前我们组已经是经常加班，因此若要保证现有任务不变，这个新需求很难完成。当然，这个新需求的任务也不是不可以接，但您能否重新对我们的现有任务排个优先级，看哪个任务可以暂不开展，这样的话，我们才有可能腾出人力接新任务。
上司：我知道你们的难处，但你们手头现有的任务也很紧急，这些需求我们也都承诺了时间，因此现有需求不能砍，而新的需求也必须按时实现。
PL：按照上研的PCB，2.1K的规模，700LOC/人月的生产率，若要保质保量的完成这个新任务，我们估计需要3个人月，因此工作量还是很大的。若您让我们既要接下新任务，又必须完成现有任务的话，我们只有免掉一些开发过程，降低质量目标，但质量部对开发过程与质量目标有严格监控，您能否与质量部商量商量，让我们项目降低质量目标，换取进度。
上司：是这样的，质量目标不可以降低。但我认为，700LOC/人月的生产率好象有点低。
PL：可这是上研的基线数据。
上司：你们可以加班吗？
PL：但总不能让大家一个月一天也不休息吧。
上司：我知道你们现在加班已经很多了，但这个需求必须实现，否则将严格影响市场份额。
PL：实现这个需求是没有问题的，但若要保质保量，则必须要3个人月的工作量。我能承诺的是，若要保证质量的完成这个新需求，目前的任务就不可能保质保量的完成。
上司：我知道你们现在工作量很大，这样吧，我可以帮助你们协调一部份人力，但所有需求均不能砍，必须实现。
PL：目前距项目交付还有3个月的时间，请您帮我们协调一个人力。
上司：好，那我就帮你们协调一个人力。
PL：那应该就没问题了。
上司：这个需求非常重要，客户也非常关心，因此务必保证质量。
PL：我们是在必须满足质量目标的前提下，估计需要3个人月，因此一定没问题。
总结：1、项目经理对现有任务有清晰的计划。
2、项目经理对新任务的工作量有明确的估计。
3、项目经理提出了质量风险。
演练实例展示2：共同拍板
上司：市场方面传递了一个产品需求，市场压力比较紧，已经给客户承诺了，大概三个月把它开发完成，这部分对于产品市场还是非常重要的。
PL：首先需求的讨论和接纳，我都参加了，这个需求对我们的产品非常有用，我们产品拥有这个功能，将占领大部分市场。我们也讨论了这个需求实现的困难，也制定了几套方案。
一、这个需求可能需要三个月，可是我们项目已经到TR4了，我们建议可以做一个小版本，可以现在进行TR4。再开发下一个小版本，可是这个建议需要跟测试部、用服、市场协调，这可能需要您帮忙做这个工作。
二、我们分析了现在做的有些需求支持的业务也非常小，应用前景不是很好，能不能把这些需求暂时搁置下来，我们优先开发这个新增需求。
三、我们得知这个需求在其它产品线做过了，能不能和其它产品线协调，把他们的人叫过来一些，我们成立一个专项项目组来实现这个需求。
我们提出来这几个方案，如果能达成其中的一个方案，我们做起来是没有问题的。
上司：看能不能先从我们这个项目组考虑，挖掘挖掘潜力，比如周末加加班。
PL：这些没有问题，我们在制定计划时，已考虑到这一点。要完成这样一个需求，需要组织一个专项团队，需要时间、技术支持，包括相关部门的协调工作，如果这些都做好的话，这个需求是可以接纳的。现在需要CCB或者PDT或者IPMT作结论。如果这些需求满足不了，我们也会把这个风险往上提，到IPMT作决策，如果他们说做，我们就可以支持。
上司：那行，先把任务分析一下，包括风险，把备选方案拿出来，然后我们讨论一下，最后做个决策。
PL：那我们搞一个方案，我们内部PDT决定后，提交到IPMT去决策。
上司：OK。
总结：
上司：任务分配不是强行，这个任务本身是产品的一部分，也是我的压力。首先，当我对外承诺这个任务能不能完成时，需要先跟下面的人沟通，就是我们内部团队要达成共识，说可以完成，我才可以对外承诺，否则，就算我承诺了，也是没有效果的。这个沟通过程相当于是让我下面团队的相关专家对我的一个支撑。
PL：首先我是想接纳这个需求。一开始并没有说这个太难了，我们做不了，这样沟通效果就比较差。第二、整个这样一个过程，是一个需求决策，涉及到公司很多部门，包括市场、技术支援、测试；这些不是由我们PL来做的。我们能做的事情是分析影响、计划、进度、以及后续的策略，给出策略后，由PDT或更上层来做决策，所以我们要和开发代表达成共识，做这个计划，由开发代表来做决定。
2.10.2 又需要再给下属增加工作任务时如何沟通？
l 了解下属工作情况；
l 阐述任务背景，讲清任务性质，说明任务的主要意义，激发员工干劲，为什么有这个任务，为什么分配给他；
l 安排任务时，与员工达成共识；
l 表明任务挑战性，从机会来进行引导；
l 提供人力支持／外部资源支持；
l 倾听下属困难，尽可能给员工提供帮助；
l 说明员工作为任务责任人，是这方面的的业务专家，表扬并肯定员工的能力，表明他是最合适接收新任务者，并帮助调整工作计划；
l 和员工一起分析当前任务和其它任务关系；
l 进行任务分解，分解小了，难度也就小了；
l 任务按重要、紧急程度排序；
演练实例展示1：新任务的沟通
PL：听说你现在工作挺忙的，你现在感觉工作上怎么样？现在有一个新的任务。
下属：呀，其实我觉得工作现在确实挺难搞的，虽然说只有一个任务，但是这个任务目前有一个难点，有很多问题不了解，所以分析不清、挺难搞的。最近一直很忙，基本上没有什么时间。
PL：那你现在的难点多不多啊？
下属：其它的都还可以，但就是交换机分析方面不好开展，开展的时候遇到的问题比较多。以前的时候代码写的乱，文档也不全，所以比较难做。
PL：咱们现在这方面有很多的专家，完全可以找这方面的专家帮你解决。因为咱们当前人力上比较短缺，而你在这方面有很有经验，所以现在这个任务还是想交给你来做，你现在的难点我会找相关专家帮你解决。
下属：这些专家问他们时他们又会说忙啊、没空等等之类的话，现在如果我再问的话，具体的能找哪些专家呢？
PL：相关的专家在业务方面的有XXX、XXX等，其实我们这方面的专家还是挺多的。如果实在不行的话，我们会和上面的领导研究一下，到时候专门找一专家和你们协助，增加人力。我想这个问题只要难点解决了，你的任务完成应该没有问题，所以这个任务现在你应该可以做。
下属：行，那就先这样，我先和其他的人讨论一下，我先把手上的这个任务解决了再做那个新的任务可以吗？
PL：行，太好了。
总结/补充：
1、要鼓励员工的自信心。
2、对任务优先级进行排序，前提是对任务要很了解，或者应和相关的责任人沟通。
3、对下属描述新任务，要讲清楚为什么安排你做。
4、当员工手头任务已经很多，无法再安排时可将员工手头的工作让别的员工做，再安排其做现在的工作。
5、协调人员时要找对方的上司协调。
6、安排任务时，任务完成的验收标准要说明。
2.10.3
l 绩效目标最好是直线经理和部属员工共同制定；
l 工作目标要适合当前岗位，也可以制定一些具有挑战性的目标；
l 采用激励和引导的方式，工作量安排要使员工“跳起来能够得到”；
l 了解员工发展意愿；
l 阶段目标与项目目标相兼容；
l 提供可实现目标的途径；
l 指定PBC时，采用SMART原则；
l 与员工一起制定目标时，给出改进点；
l 对员工绩效目标分析重点和难点；
l 针对认证资格，制定绩效目标；
l 参考总目标，分析KPI和案例输出
l 量化、细化，参考上季度或部门指标制定
l 工作要有备份，有意识作为PBC任务明确
l 计划变动，PBC及时修改
2.11.1 ”的员工如何沟通？
l PL应选择适当的时机，提前通知员工准备好沟通，并安排好场所；
l 明确绩效导向和绩效依据；
l 基于PBC进行评估，指出员工不足的事实；
l 沟通时，指出改进点，不在员工之间横向比较；
l 安排能激励员工的任务；
l 给员工进行职业规划，结合部门发展规划；
l 三明治方法（肯定好的，改进点，说明工作期望）
l 倾听员工想法以及对项目组的建议，了解现在存在的困难，和员工一起制定下一个PBC；
l 明确考评的含义；不说考评为C，而说考评正常，注意用词；
l 首先有理有据，操作过程尽量透明，以数据、事实说话，而且平时就要有所积累、沟通，不要等到最后才说。对于因为考评比例导致的C，要对员工实话实说，沟通要以激励为主，并让其与优秀者比较找出其差距。对于另一种因为员工自身原因得到的C，要向员工说明C是公司对员工正常工作的评价，告诉员工据其自身能力来说还有上升空间，同时指出对员工下季度的期望。
l PL在说出考评结果前应更多地引导员工自己找不足。
l PL最后应对员工加大肯定，提出期望。
l PL和员工沟通考评时应多与团队做比较，和个人以前的绩效做比较，尽量不要与其他人做比较。
l PL可以让员工说说对团队的建议。
l 对于由于要平衡考评结果（照顾其他员工）而给了C的情况下，PL可以通过其他方式给予奖励。
l 根据每个人的实际情况，因人而异，有些人容易沟通，有些人不容易沟通，沟通方式有所不同；
l 引导员工正确的对待考评的心态，鼓励员工注重长远的成长＆利益，而不要对考评的结果斤斤计较；
l 考评的过程要公正，考评的标准要公开化。
问题讨论：
被考核人：我和某位同事差不多，他得什么？
主管（不要直接回答）：
a.可以先突出这位同事的亮点，且表明这个亮点对团队的KPI有绝对影响；
b.我的考评也和你差不多；
c.说明被考核人所从事的工作，占项目的比例不是很高，对项目组的贡献有限；
演练实例展示1：有理有据，以诚示人
PL：张三，我们现在就本季度的考评做个交流，你觉得上个季度的工作，你哪些方面做的好？哪些方面做得不好？
下属：我觉得在问题单处理方面，新员工指导方面，我做得都不错。
PL：上个季度你在问题单处理、新员工指导方面确实做得不错，但我们组5个人，你只解决了十分之一数量的问题单啊！
下属：不会吧，我觉得我解决的问题单挺多的。
PL：我这儿有我们项目组每个人解决的问题单数量的数据，你看看。
下属：是这样的，我主要在指导新员工花了大量的时间。
PL：我知道你在问题单处理、新员工指导方面都花了心思，还是不错的，你的考评是“正常”，你有什么想法？（这时，其实下属其实已经得到暗示，知道自己是C了）
下属：我觉得很奇怪，我问题单处理的不错，新员工指导的也好，为什么我的考评还是“C”!
PL：是这样的，我们考评除了考绩效，还要考你的进步，你是老员工了，经验很丰富，对你的要求当然也高一些。从绩效上来说，与新员工相比，你肯定要好，但你这个季度进步不大。我们考评是分层比较的。
下属：那我就不理解了，从项目组总体来说，我的绩效是排在前面的，但考评结果却是“C”，好的绩效得不到好的考评，那考评还有什么意义？
PL：我们项目组新员工较多，与新员工相比，你的绩效是好的，但与组内或组外相同技术资格的老员工相比，你的绩效并不排在前面。
下属：那我该如何努力，才能打“A”呢?
PL：你能这样想，说明你很有上进心。考评做到绝对公平很不容易，但从长远来说，还是能反映真实情况的。你上季度在解决问题单方面做得不错，但你若能将问题单解决过程中的经验、案例总结并共享出来，则更能帮助新员工成长，更快的担当起解决问题单的任务，而你自己也就有更多的时间去做方案设计等系统级更重要的工作，也更有利于你的进步，你的绩效也会更好。这样吧，我们来探讨一下下季度的PBC。
下属：那行吧。
总结：1、首先让员工自评；
2、领导平常就要收集数据，这样可以做到客观评价员工，让员工能信服。
3、对老员工要求不同，分层考评。
4、牵引做一个长远的评价。
5、若能给出一些明确的目标，会更好。
演练实例展示2： 直接了当，效果难保
PL：很遗憾的告诉你，你的考评为C。向你介绍一下本次考评情况，我是“C”，你也是“C”。
下属：我觉得我上个季度做的挺好，任务完成情况也挺好，而且我已经连着两个C了（怎么这个季度还给我打C）。
PL：一般员工间的差别都不大，做的都不错。所以考评为“C“不代表你工作不好，从我们考评的比例也能看出来。但是你的工作还是有一些缺陷的，遗留缺陷密度比较高。
下属：这的确是我的问题，以后会改正。
PL：好，既然你自己也承认有不足之处，那这次考评就这样。对了，你今天晚上吃饭了么？晚上我请你去吃饭吧（表示对员工的关心，切记要真诚）。
总结（这是一个沟通不是很成功的案例）：
（1）一定要记得肯定员工的成绩；
（2）不要把领导的考评结果＆员工的考评结果做比较，因为没有可比性；
（3）注重日常数据＆员工工作情况的积累；
（4）让员工先做一个自我评价；
（5）建议不要使用的方法：沟通的时候不要把员工之间横向比较；
（6）让员工了解考评是长远的，不要只看眼前的结果；
（7）可以给员工树立好的标竿“A”。
演练实例展示3： 绩效辅导，考评牵引
PL：杨涛，我们来就这个季度的考评沟通一下。你对你第二季度的工作表现能否做一个自评？
下属：我觉得我第二季度工作方面表现的还是挺好的。做了很多工作，平时加班也挺晚的，觉得还可以吧!
PL：你觉得有哪些不足的地方呢？
下属：不足的地方，暂时还没有看到。
PL：的确，在第二季度你做这个版本的开发，表现都很好，整个过程还有质量目标都是十分的优秀。但这次你这个项目是从7月份到8月份，8月底已经结束了。我记得我们在8月底的时候做过一次季度中间的绩效实现辅导。
下属：好像是。
PL：我们现在对绩效考评在平时和例会上对公司的绩效导向已经做过宣传了。我们考评分为两个纬度，一个是工作方面，另一个方面就是在团队建设方面。这个应该还有印象吧？
下属：对，记得。
PL：这个季度你在工作方面确实不错。我自己也记录了你的这方面的两三个优点，比如你主动加班，这也是一种华为文化，而且你在学习方面是比较积极，你的学习能力也比较强。但是，我在8月底给你做绩效辅导的时候和你提到过两件事，你还记得吗？
下属：能提醒一下吗？
PL：一个是案例方面的，另一个是招聘。
下属：对，对，我主要是工作太忙了，案例没有时间写，招聘也没法搞。我都工作这么长时间了，也不认识谁了。
PL：案例的重要性你应该已经知道了。在8月底的时候你的这个项目就已经结束了，在9月份的这个期间应该是转测试之后，在这段时间写案例的时间应该是有的吧？
下属：但是我觉得那些东西都很简单，没有必要写的。
PL： 没有必要写？但是我记得上个季度和你沟通时你说有几个比较好的思路没有时间写，这个季度你为什么不写呢？
下属：这个可能忘了。
PL：案例这种例行的事务我们每次在例会上都会跟踪的。我们组的XX他是做案例这方面的，每个人贡献多少思路他都是会跟踪的，我觉得这方面你是不应该忘的。另外对于招聘这方面我想说一下，西研所的发展方向我想你也是知道的。你们现在总是在抱怨西研所这边刷不了卡，深圳那边可以刷卡买东西。那如果我们现在一直都只有几十个人，形不成规模的话，至少连小卖部都不会有的。
下属：这个倒也是。
PL：所以说我们现在的招聘是为了我们西研所的壮大，只有我们西研所壮大了，才能有稳定。
下属：这个，下个季度我一定会朝这个方面改进的。
PL：现在我把这个季度的考评结果给你说一下：“你是C”。你看你是否能接受？
下属：可以勉强接受吧
PL：这个“C”我们平时在绩效导向上也介绍过，得“C”是正常的。只要你各项工作都完成了就达到了“C”的标准。
下属： 但是我看好象除了“C”，就是“B”和“A”。为什么我是最低的？
PL：因为大家都比较优秀，可以说还没有差到得“D”的地步。
下属：还有“D”吗？
PL：有。这个，公司有5%的人得“D”，所以说“C”是正常，这个季度打“C”，原因主要有两点：一是组织建设方面表现配合不积极，二是招聘方面。
下属：那就是说我下个季度将案例和招聘做好，就可以得“B”？
PL：以后在这个方面要注意一下。但是在下个季度做的时候要注意保持上个季度发展的良好势头，继续发展在项目组组织建设方面注意一下，下个季度的考评应该会有进步。
总结：1、让员工自评。
2、先肯定员工的优点，再指出不足。
3、在沟通时要注意场所的选择.
但结果只能给他打C,怎么办？
l 明确新员工一般没有不打C的；
l 项目经理有难度，晓之以理，动之以情；
l 说真话，给他定一个长远目标，说明其不要只看眼前利益，对员工要诚实、诚信；
l 态度和肢体语言很重要。
2.11.3
l 以事实为根据，以公平为原则，公平的评估，对事不对人；
l 要看时机，并进行正面引导，并用心倾听下层想法；
l 根据员工特点运用不同的方式来进行批评，如对于勇于承担责任的人，可以直接提出错误；有时也采取委婉方式；
l 分析原因，帮助下属改进；
l 指出错误时，不横向比较；
l 在项目组内，养成自我批评的氛围；
l 适当的鼓励；
l 及时总结，协助预防措施；
l 不算旧帐；
l 公开表扬，私下批评；
l 批评要及时；
l 避免员工重复犯错误；
l 按员工的积极性和能力进行分类（四象限），处理如下：
Ø （针对积极性高，能力高的员工）直接说出错误在哪。
Ø （针对积极性高，但技能差的员工）建议他看些资料或书，提高技能或考虑工种是否不能胜任。
Ø （针对能力高，但积极性差的员工）首先表扬好的地方，肯定成绩，再说出不足，然后画一个饼，给出希望，提高其积极性。
Ø （针对能力低和积极性差的员工）一方面可以分配他其它感兴趣的事，提高积极性，另一方面可以调整其做工作难度低的工作，或可根据问题的严重程度及是不是老犯同一个错误考虑是否需要淘汰。
2.12.1 新芯片的应用，无法预期的问题出现，如何识别、评估和控制风险？
l 预研要发挥作用，识别新技术/新芯片的影响、技术可行性、性能特点等，提供多个备选方案，前期先进行预研和评比，分析评估结果，加强前期验证；
l 可采取两套方案并行开发，规避风险，即以资源换风险；
l 做好规避措施的同时，要有替代方案，作为风险一旦发生时应急使用；
l 对采用的技术、方案，相关人员评议，可通过头脑风暴的方法；
l 请供应商参与；
l 加强风险管理，新器件不能乐观，即便是已经预研过也可能出现如可靠性方面的问题；
l 请工程设计等相关专家加强投入；
l 若必须使用工程样片，可以和客户沟通，说明业界现状（无成熟技术），沟通是否可以调整进度计划，并将风险提前告知客户，提高客户满意度；
l 进行人员培训，逐渐积累人员技能；
l 利用其他产品或项目的成功的经验、教训；
l 对交付件分析、评估。
【反面案例】TR2前分析不充分，导致项目开始后，不断有方案变更，对项目开发有较大的影响。对于有新技术引入的项目，建议：
Ø 提前做好方案的预研工作；
Ø 技术风险的优先级较高的任务，需重点关注；
Ø 要对需求的场景进行完善、清晰的分析
Ø 计划要细化，并留有一定的余量。
2.12.2
l 提前发现和识别，并制定相应的规避措施。
l 要求移植产品具有可测试性。对移植模块模拟测试和试用。
l 与移植模块的开发人员讨论清晰接口。
l 如果移植模块来自外包，要对其进行质量控制，介入其开发过程。
l 如果风险规避的要求超过了项目组的能力，及时向上汇报，请求支援。
l 风险一定要有有效的措施，如果请求支援后依然超出了团队的能力范围，而且我们有了有效的措施，尽管不能完全去防范风险的影响，但风险的影响一般可大大降低。
l 最后，如果风险发生了，我们还要勇敢地去承担风险的后果。
2.12.3
l 做好前期规划，统一协调进度；
l 固化相互接口；
l 专门组建负责统一协调的跨产品、跨部门的委员会；
l 标识任务相关性，标识关键路径并跟踪；
l 及时协调人力冲突的风险；
l 每个工作都有明确的责任人，负责协调资源完成任务；
l 需要制定和维护进度跟踪表，定期记录、跟踪；
l 相关责任人要定期汇报，主管要主动审核；
l 根据进度及时排定任务的优先级，并指定人员跟踪；
l 加强跟周边人员的沟通。
l 制定风险规避以及应急计划的具体可行措施；
l 全员参与，不同的风险指定不同的责任人，明确风险管理不只是PL一个人的事；
l 定期跟踪、更新（比如在周例会上讨论）；
l 加强风险规避的力度。
【案例】：合理明确责任人
FPGA开发中，利用到芯片厂商提供的IP CORE，在应用过程中，发现IP CORE存在BUG，项目组把该事件作为一风险跟踪，在风险跟踪前期，风险责任人和厂家FAE直接联系，效果不明显。后来，通过加强风险规避力度，上升风险级别，将风险责任人明确为PL、PM、开发代表，在开发代表的亲自参与下，每周跟踪风险规避进展，并最终规避该风险。
l 在合同条款中明确要求：
Ø 明确验收标准、技术标准，以及其他的质量要求；
Ø 明确双方的后续职责；
Ø 明确奖罚措施；
Ø 对合作方进行认证。
l 在执行过程中跟踪合作方的开发过程。
背景：新产品招聘十多个新员工，工作一年多，期间陆续有五名员工提出离职，对当前版本维护和后续开发产生很大影响。
l 人员备份
l 多关注思想动向，不能因为工作繁忙而忽视员工的激励。尽早发现问题，即便离职，也可以有较长的时间进行做好工作交接，做到工作的平稳交接。
l 平常注意活跃项目组气氛，项目经理和员工、老员工和新员工之间、所有员工之间形成容易沟通的气氛。
l 通过文档、过程记录等留下工作产品，降低人员离职的影响，也便于工作交接。
l 建立工作交接程序，通过交接流程，比如接手的员工需要通过陈述或者答辩的方式，来保证交接质量。
反面案例：风险提出后未跟踪，风险演变成问题。
描述：有一个项目组在做可视电话时，他用的技术是公司非常先进的技术，做的初期大家考虑这个很难，也把它当作一个风险提出，但没有列出一个计划进行跟踪，也没有指定相关责任人，当把单板做完验证功能后，后来发现有一个问题解决不了，这时产品已经面临发货阶段，导致后续的计划一拖再拖。如果当时做两套单板，一套拿出去解决，等功能相关问题被调通后，另一个的问题也被解决了。在我的项目组中，用的相关组件比较多，很多都依赖于其他组，有很多都是和我们同期开发的，我们的规避方法为：考虑一个版本计划，先开发一个接口联调版本，预先拿该版本跟相关组联调，规避接口风险。
开发代表经验交流
1、 严把项目入口关，对规格、项目任务书要组织严格评审和把关，不接受质量不过关的上级输入，开发在这部分要安排重点人员把关，可以协助前端明确需求但不要在开发过程中明确。这一点一定要顶住，把由于这个原因造成的整个版本的计划压力向上传递。
2、 项目经理要控制项目组改变项目范围
系统级的需求，开发代表很容易在分配到项目组之前控制；但是，来源于项目组内的需求，必须依靠项目经理，才能实现真正的控制；
案例：项目组内部没有划分出内部需求和问题的区别，项目经理判断也比较模糊，往往通过CMM问题单来启动小需求，开发代表也不容易识别。往往会导致：项目组的范围实际上在没有CR控制的情况下被扩大，而且由于很多小问题缺乏事前系统分析，往往在实现过程中才暴露出难度、人力投入上的矛盾，对进度和质量都有影响。
对项目经理的期望：
a.树立“开发组不能擅自改变项目范围”的意识；
b.任何变更，需要经过CCB的评审。
3、 TR2之前系统规格的制定，项目经理要积极参与
按照IPD－CMM的流程要求，TR2之前，责任主体在SE。但很多产品的实际情况是：SE及其核心组专家（例如系统组）不仅人手有限，而且在一些特性的细节熟悉程度上，不一定有项目组专家精通。因此，此阶段SE把规格细化工作分解到项目经理，由项目经理去组织完善是最合理也最实际的做法。事实也说明：如果项目组前期参与规格制定投入不多，在项目开发过程中发现规格问题（甚至可能是要推倒重来的大问题）的几率就越大。所以，在现有情况下，项目经理要加大TR2之前的投入。
4、 如何控制CR
（1）从源头控制CR的次数＆规模，在SOW阶段除了考虑功能特性，对其余特性也要充分考虑到；
（2）发挥CCB的作用；
（3）有效的版本规划。
1、 计划的制定一定要细致，不能和版本计划一样只有大概的活动计划。计划要项目组全体沟通制定出来，让每个人了解到每天应该做什么。
2、 项目计划中要合理分配资源，不能过度分配资源，并一定预留出应急的时间。
3、 有20%的倒推计划是不可避免的，但我们要了解是什么原因导致倒推计划。
4、 在制定计划时要考虑如何合理制定计划和分散计划、考虑风险及优化计划；
5、 在实施计划时还考虑计划执行、跟踪&调整、阶段总结。
6、 估计是项目计划的基础，估计要依据我们的实际能力基线进行，而不是上级说你用900行来估，就认了，这个与我们目前情况不符。
7、 项目计划是非常重要的，是项目的纲，一定要依据合理的估计进行项目计划。计划要有10％～20％左右的余量，一开始就制订的满负荷的计划，将导致项目每个阶段、每个活动都在赶，成员长期疲惫，情绪受影响，质量必然下降。项目计划要实时监控，可以利用项目监控库或者其他实时监控手段进行，要及时了解和通报项目进展，及时反映项目问题，对于重大情况需要计划调整的要及时沟通及时调整；要明确，一定大小的项目，计划压缩到了一定程度是不能再靠增加人力来解决的，对来自产品的靠增加资源来压缩进度或者执行一个活动的做法一定要慎重考虑，要同样说服产品，使产品明白：一个女人9个月生1个小孩，可是九个女人不可能在1个月内生出一个小孩。进度紧张时要制订可以操作的应变策略，如流程裁剪等，同时要每日跟踪进展，及时发现问题并调整。
8、 要正确认识计划管理，计划的用途有：
a) 计划作为一个全面的、分级分层的体系，用于预先综合/协调各种资源，安排各项工作活动。
i. 计划在制定期间，可以对工期、资源、成本进行优化；
ii. 计划在执行过程中，可以对工作任务进行监督、控制和调整，使项目能够按预计目标实现的同时，缩短工期、提高效率、节约劳力、降低消耗。
b) 除了预先安排/布置的作用外，计划还涉及工作目标（做什么，何时做），工作方法（由谁做、如何做）。因此，对组织和管理来说，计划可以统一团队的目标，让所有相关人员了解组织的工作目的和为达到目标必须做哪些工作，对计划执行，这可以方便的协调资源，加强互相合作，减少因协调等导致的内部消耗；
c) 对个人来说，可以通过计划了解团队对自己的要求，知道如何做才能对团队做出更有效的贡献，计划可以使个人工作明确，少走弯路，可以更积极主动的投入工作。
总而言之，计划是有效管理的开端；好的计划可以事半功倍；制作出一份优秀的工作计划，项目也就成功了一半。
9、 对计划的理解误区：
a) 计划赶不上变化，项目中经常面对那么多突发事件，很多事情是不是能够预料得到的，要计划还有什么用呢？
——计划是不可能消除变化的。不管我们制订计划时多么用心，计划制订得多么精确，变化总会发生，制定计划的目的之一是预测变化，并制定最有效的应变措施。计划的最终结果仅仅是计划管理的目的之一，而伴随制订计划中，对未来工作任务的逐步细化、对周围资源如何有效利用的考虑、对可能发生风险的分析及对规避措施的思考等过程本身则更有价值。
b) 项目进度要求很紧张，每月花几个小时来做计划、跟踪计划，简直是浪费时间。
——花几个小时制订计划，远比为了纠正偏差或多走弯路而多消耗掉的几天、几十天划算得多。计划迫使我们认真思考要干什么和怎么干，搞清这两个问题本身就非常有意义。弄清方向，弄懂方法，会使达到目标的消耗降至最小，这就是计划本身的价值。
c) “我很清楚的知道项目在接下来的时间里要做什么，何必要将它们写下来呢？”
——计划作为正式的、经过反复思考、推敲的东西，远比在头脑中模糊的假设准确得多。
d) 凡事讲计划，按步骤，灵活性何在？出现紧急突发事件后，如何应对？
——认为计划不灵活，或是一种约束，往往是因为计划在制定出来后就再也不刷新、不更正了。计划的跟踪、滚动、刷新与修改应该是一个始终贯穿计划过程的持续活动。有准确的计划在手，会对当前的工作任务、可调配资源等了如指掌，用其来应对突发事件则会更加自如。
e) 如果计划做得不准确（在现实情况下完全有可能），岂不是与没有计划一样吗？还不如不做计划。
——计划决定着未来工作如何开展，因此，应该花些功夫在计划的制订上，而不应该随心所欲，或草草了事。或许，因为经验等原因，计划之初可能存在不准确性，但如上所述，计划是一种持续的过程，可以对其进行修订。计划本身也是一种PDCA（Plan-Do-Check-Action）循环，随着经验的丰富，计划的准确性将会不断提高。
10、 开发代表制定计划期间，项目经理需要协助开发代表进行"兵棋推演"，把各个环节模拟走一下。
11、 计划准确与否，其实很大部分是建立在历史数据基础之上的；但是事实上，度量的客观性、真实性及可信度都不高，原因是：度量数据从未集中反馈过，所以数据经常会填错或记不清，导致度量数据不准。
12、 项目经理是保证度量数据准确的基础，不仅思想上要重视（要消除例行公事的态度），而且应该纳入绩效考评参考依据。项目组的“财务报表”都不准，那么产品的“财务报表”还准吗？
a) 很多人认为度量很重要，但就是做不好，原因是：
i. 存在一个误区，认为度量工作很繁琐，需要投入大量人力；
ii. 没有尝到甜头，没有清楚的认识自己的开发能力；
iii. 由于以前的历史数据不准，对后期项目造成了很大的影响，所以对度量存在错误的认识。
b) 建议：
i. 还是强制或纳入考核体系；（投入多少了，完成多少工作量）
ii. 先保证有，再清晰化。
13、 关于效率
我们现在讲零偏差，零Bug，同时我们也要注重高效。我们在把工作做好的同时，我们要创造轻松、愉快的环境，那我们怎样把事情做得高效。X/Y理论，我们讲Y理论，相信大家是努力的，相信大家很辛苦，大家目标一致。尊重别人是一种美德，相信别人也是一种美德。对于问题单，我们有没有心平气和地讨论解决方案。如果我们没有诚信，很多事情就不能解决。2/8 原则，每一个角度都希望把这个事情做的100分，完美有时候需要付出代价，如果一个版本有200个问题，一般来说20％的问题是重点，我们要集中精力解决这40个问题，那我们的质量就上去了。我们现在人力紧急，要抓住关键问题，先解决核心问题。GSM也好，CDMA也好，关键问题还是几个老问题，如信号飘忽，信号衰减，信号不一致。我们没有解决这些关键问题，导致遗留到现在，我们的品牌也上不去，质量也上不去。结合产品实际质量去做事情，不要老关注分数，问题不能解决，就是不能发布。不管什么时候，我们都要围绕质量核心，对我们的影响，对客户的影响，基于这个前提，才有意义。
1、 风险管理是公司的薄弱，各部门可能都有，但是都是很原始的，没有真正纳入项目管理过程中。项目经理需要培养风险管理的意识；
2、 项目经理的风险识别和控制活动要例行化。项目组内部风险包括：项目开发过程中的技术风险、部门配合风险、人力风险、质量风险等，项目经理是首先能识别和觉察的人，应建立本项目组风险控制表格，在每周例会上进行风险处理监控。需要上升到产品级别的风险，需要及时知会到开发代表，制订产品的风险响应计划。经验也表明：开发代表看起来似乎没有风险的一项开发活动，只要发动了项目组，总会提前识别出一些风险来。
3、 风险计划一定要落到实处，要SMART化，要定期Review风险计划，对可能发生的风险提前规避，促使项目不受风险影响，按计划进行。
4、 汇报风险和问题
a) 对于项目的问题要及时汇报
b) 请求上级协调资源（爱哭的孩子有奶吃）
5、 充分利用QA的力量
a) 裁剪生命周期，重点开展投入产出高的活动
b) 反馈项目问题，请求解决人力和进度问题（并不是所有的项目就一定很紧）
1、 构筑项目组的质量文化
a) 明确项目组的质量目标：过程符合度、遗留问题缺陷密度，勇于挑战目标；
b) 在项目组开展有效回溯：明确回溯目标＆制度，对事不对人，好的回溯予以表扬；、明确回溯范围：每个ST/AT/Release问题都在项目组内开展回溯；
c) 明确服务意识，创建服务氛围：对客户、对周边项目组、对项目组内部。
2、 如何做到缺陷预防？
a) 版本EDA分析
b) 质量回溯－－回溯的目的是为了改进，目前做得还不够
c) 案例学习－－分析/学习的目的是为了制定预防措施
3、 如何落实预防措施？
a) 问题单审计－－审计的目的是为了监督措施的落实情况
4、 如果提高质量意识
a) 质量红黑榜（质量角）－－表扬和批评的目的是为了创建质量氛围
b) 黑脸文化－－质量黑脸，测试黑脸
5、 如何看待测试问题单
我们在工作中有很多冲突，也有很多焦点。不管测试人员怎么提，不管是不是致命问题，解决就完了，不要在问题的级别上争执。测试人员有测试的考核，开发人员有开发的考核，如果总是提示性问题，他们的绩效在哪？我们可以换位思考一下。测试人员要站在客户的角度来考虑，我们研发人员不要总去想测试人员怎么提问题，我们要关注在问题的解决上。
有时要思考一下，这个问题不解决会怎样，会对客户的影响有多大。在质量方面是不是影响很大。希望大家围绕质量、效率、成本、客户满意度。从这几个方面考虑，开发人员、测试人员、质量人员，分歧就会小一些。
开发、测试在职责上存在一定的矛盾，可能是有冲突的，大家要充分理解，所以首先要做好自己的岗位职责，开发把开发工作做好，测试把测试工作做好，不要层层传递，什么问题都往上抛。从整个公司策略和战略上讲，我们推行IPD，就是要提倡团结协作，不仅是流程，还要从管理上，为了保证项目，每个人都要做好自己的职责。IPD的好处是基于产品开发，能解决不同岗位之间的矛盾，为了使团队最大效率化，目标可视化，从整个公司的团队策略去推行开发方法，前提是每个岗位把自己的工作做好。
6、 把事做正确——不要轻易做演示版本
我们现在的开发版本，问题最多就是方案，动不动方案优化一下。然后是编码问题。我们产品以前有个误区，为了应付市场，我们先做一个测试功能，有很多缺失，如出错没有报警等。我们不要轻易做测试功能，至少方案上要做到TR3，或者概要设计，如果因为人不够，我们编码可以一部分不编码，这部分也不参加测试。你看我们有哪几个版本放到外面去了受控，市场不管商用还是试用还是演示版本，在人不是特别紧缺的情况下，我们不要轻易做一个演示版本，我们的版本出去，面对的是全球，谁来告诉客户这个功能不能用？我们在做方案和设计时，不要存在侥幸心理，就是要做商用，要规范地开发。我们要一次性交付好。我们在流程规范上，做事的心态上，有很多的差距，潜意识上又很多这样那样的问题，我们要做就做好，要做就做商用的功能。
实践中，检视活动，是所有质量保证活动中最简单，也是最不容易做好的一件事情。检视活动本身就相当于一个微型项目，也应该有其计划、实施、收尾等过程。实际中很多项目经理往往忽略了这些过程，甚至视为不得不完成的“副业”来进行。
但如果制定了明确的检视目标和落实到人的计划，也还不够，因为很多检视内容枯燥无味，也特别冗长，光依靠检视专家“革命靠自觉”也是保证不了效果的。因此，项目经理作为基层管理者，在改善检视方法、提高检视效率上要多做文章。
Review这个法宝一定要利用好。要制订一个详细的Review计划，明确Review内容、人员、时间等等。专家的有效投入是最主要的，组外专家一定要推动上级主管来解决落实，组内专家在项目例会上落实，对于落实后没有投入的人员一定要推动质量部去处理。Review事后要定量的总结。 项目进展很紧时，可以考虑集中Review的方式进行。另外，待评审的文档要保证基本质量，每个评审要至少保证2～3人的有效Review投入。
比较好的经验有：
a) 将“长篇大作”化整为零，分多步检视完，就是说把100页的文件分解为N个文件；
b) 在检视文档中故意“埋地雷”，在需要检视者加强检视的地方不妨故意搞点小错误，谁要是挖出了“地雷”给予小奖励（案例：在第一次试行这个活动时，自己认为不太可能发现的“地雷”，竟然全被检视者挖出来了）；
c) 对检视专家建立“检视积分制”；
d) 对检视专家缺乏熟手的情况，不妨先强制进行集中检视，再下去分散检视的方式；
e) 评审流程的贯彻落在实处，让员工都认识到review执行的有效与否是项目遗留缺陷多少的关键；
f) 制定易于监控的计划：典型项目的阶段持续时间只有半个月～1个月，最好按周做计划，每周更新，这样可以使计划可行、计划的变动小；
g) 对评审效果进行绩效统计；
h) 重视评审检视，经常采取周末集中检视的形式，上午分开预审，下午集中检视；
i) 光网络有正式的检视实验室，有多台电脑，大家先各自在电脑上看，有问题提出讨论直接修改；
j) 检视计划做到3/4级计划中。对复杂单板会提前开介绍会，便于相关专家了解。正式评审前需先进行内部检视，内部检视是开发完成一个模块就检视一个模块。对专家发现问题数会进行汇总统计并发给所有人。
k) 若评审未达成质量目标，会重新评审；
l) 投板前还要做一次内部检视，非常重要；
m) 对新器件，评审专家不可能去看详细的器件资料，一方面是开发人员自己必须通读每个管脚应用，另外可请厂家协助进行模块级检视，效果很好。
1、 “羞答答的玫瑰，静悄悄的开”，是项目经理的大忌。项目经理不求表达能力要如何强，但一定要敢于去表达。遇到事情或问题，要敢于沟通。因为和项目经理接口的有开发代表、测试部、兄弟产品、兄弟项目组、本项目组成员、产品其他人员等等。遇到事情或问题，我们其实不怕争吵，但最怕不敢或不愿去吵，因为这样会耽误事情；事情吵一吵，可能就清楚了。项目经理要多找机会开会，多找机会当众发言和争论，还要经常让项目组成员跳出来发言。所以提倡大家越吵越清楚。
2、 项目管理的主要工作就在于沟通协调。和上层沟通时，可采用迂回策略，如通过测试代表或其他代表去协调。压力也要传递到周边。
3、 管理者进行有效的沟通，包括与上级领导、相关部门及人员、项目成员；沟通的手段包括电话、会话、报告、函件等等，这样可以调动所有力量有效地推动项目问题解决；要利用好例会、开工、阶段会议明确要求，解决问题。
4、 双向交流才能算沟通，另外沟通时候要学会倾听。
5、 沟通表达能力－向上
a) 你说的话代表谁？
代表了你所在的子领域的最高意见，需要为发言的正确性和有效性负责。
你充分征求了子领域各专家的意见了吗？
比如说Team有10个人，有3个人的技术很强，PL的意见才是项目的意见，你要把你这个子领域内各个专家的意见征集起来。如果上级看到你的承诺一而再的实现不了时，他会怀疑你发言的正确性和有效性，下次他会问你“你确认吗？”“有证据吗？”，这说明了你说话的诚信下降了。我们自己的言行和输出代表组织的言行和输出。如果这一点做不到，那你只能是一个孤独的英雄，孤独的英雄在我们公司从来没有好的下场。你所代表的就是你所在子领域的最高意见。
b) 说给谁听？
你在向上级或相关人员汇报、交流工作，需要清晰明确地表达内容。“你说的话我听得懂吗？”“你知道我关心什么吗？”当你做到开发代表或更往上时，你经常发现你说的话别人听不懂。
我现在最大的苦恼：不是说弟兄们哪个不听话或牛人太多，而是在解决网上问题时，怎样能让领导听得懂？
你知道我关心什么吗？有一次进度延迟了，开发的一个很重要的角色寄邮件给我，一个Page第二个Page之后，我看了一下，不知道他在说什么？然后我给他回了邮件说，这个问题你想说什么？你想告诉我什么？原因是什么？你不要说这个堆栈怎么回事？这个模块怎么回事？我所关心的是事情现在的情况是什么？事情的真实情况是什么？后果是什么？原因是什么？我看了邮件，我要知道：发生了一件什么事情，给我们带来了多大损失，我们下一步应该怎么做，谁能搞定这个事情，他搞不定我该怎么办。
假设N年之后，开发代表都是职业经理人，根本听不懂你这个变量怎么回事？你的表达就摆脱了对人的依赖。
c) 你想说什么？
交流的内容要简明扼要，重点突出，便于相关人迅速抓住问题的本质。你说的这些话想干什么？
做什么事情都要非常清楚，你想干什么？在我们寻求帮助时，不管是上层的帮助还是周边部门的帮助，一定要很清楚的表达出来。你想要谁听到这个事情，你想说什么？
我们需要表达的是：第一现状是什么？第二是什么原因造成的？第三后果是什么？
6、 沟通表达能力－向下
a) 你说的话代表谁？
代表了你所在的子领域的最高意见，需要为发言的正确性和有效性负责。你确认代表了部门的意见了吗？
我有一次跟部门的员工沟通，跟他谈了一个多小时，他说：以前从来没有人这样跟他谈过心，以前别人跟他说的都是套话。后来他不断地改进。希望跟员工沟通，能坦诚地把意见表达出来，套话没什么意思，不能促进灵魂深处。我们该怎么发展，为什么会出现这个问题，你认为我们会有什么问题。我觉得PL学的东西要杂，跟很多人能很快的找到共同的话题，因为每个人的想法，每个人的知识领域都有区别。知识面宽一点，沟通起来比较有效。
如果说话不正确，乱发言，迟早会为此付出代价的，员工也会因此产生怀疑。员工不是怕别人指出来不足之处，而是怕说“你这次做的挺好，但由于什么原因……”，这样员工会心灰意冷，感觉一方面不跟他说真话，一方面还在骗他。
b) 你说给谁听？
你在下级指导工作，需要清晰明确地表达内容。你说的话太抽象了，能不能具体点，最好有点背景信息？
我们在布置任务的时候，你一定要ensure，跟上层交流一下，不要怕麻烦。当有疑虑的时候，一定要跟上层沟通清楚。
c) 你想说什么？
交流的内容要简明扼要，重点突出，便于相关人迅速抓住问题的本质。你说的这些话想让我干什么？
作为PL，你说的话代表部门意见。管理资源毕竟有限。你要把东西非常真实地露出来，中间的人会出现冲突。如果不能把痛苦说得很清晰，可能会付出一些代价。
1、 全面认识什么是团队
a) 团队有明确的目标；
b) 所有团队成员对团队目标有共同的认识；
c) 在团队里，每个成员都有明确的职责和角色分工；
d) 团队成员相互协作、相互支持、相互信任、相互鼓励、相互尊重；
e) 每个成员都清楚团队的状态与计划；
f) 每个成员都清楚自己在团队中的作用；
g) 每个成员在团队中都得到了发展。
2、 如何取得一致的团队目标
a) 在项目开工会上与所有团队成员就团队目标进行充分的交流、讨论，直至达成一致的理解；
b) 团队目标必须分解成每个团队成员的个人工作目标，并且通过交流确保每个团队成员都对自己的个人工作目标有清晰、正确的认识；
c) 无论是团队目标还是团队成员的个人工作目标都必须是符合SMART原则；
d) 应定期在项目例会上与团队成员重新Review团队目标，保证目标与实际执行的一致性，必要时应制定相应的纠正措施；
e) 当团队目标发生变化时应第一时间知会每一个团队成员并重新确认达成一致理解。
3、 如何管理团队
a) 项目经理要学会管理你的员工：他们要什么？你能给予他们什么？他们为什么要服从你的管理？像管理你的“存款”一样管理你的员工，获取双赢的增值，教会他们如何做事情。
b) 项目经理要学会“管理”你的领导，管理的目的是更好的完成工作任务。如何管呢？让他知道你在做什么；让他知道你为什么这么做；让他知道你有哪些问题；让他知道你计划做什么。
c) 项目经理更要学会管理自己：你作为主管要承担更多的是责任；只有团队成功了，团队中的成员成功了，你才是成功的；你应该是表率，你是团队中最优秀的；号召项目组成员“向我看齐”。
d) 项目经理要有效的管理项目成员。项目经理的职责要使项目成员组织起来发挥1＋1>2的效果。我觉得对人的管理要刚柔并进。第一，要明确各种制度包括项目组自己制定的土政策，要向下传递压力，成员都有头悬刀的压力感；第二，要活跃团队气氛，使成员团结向上，包括组织气氛建设，有效的激励等等。要做好这两点，可以利用支撑部门的力量推动，包括通报表扬和批评、处罚、关键事件、考评、红黑记录、奖券、经费等等。项目成员之间要做好人力资源的备份和培训，例如技能备份、放权管理等等；任务安排要和员工沟通好，符合SMART原则，确保员工能操作，可完成；例行任务要流程化，模板化；如做成CheckList、模板等，对已经流程化、模板化的例行任务要授权出去，例行跟踪，保证时间重点关注重点、突发事务，及时解决。
e) 要树立项目经理的领导威信，一是通过上级任命和利益考评相关性下压，二是通过项目经理自己以身作则的榜样力量；
f) 项目经理对项目不能粗犷管理，而要善于利用各种数据实行定量管理。只举一个例子：项目成员投入的量化管理；
g) 项目经理要学习、掌握并善于利用各种项目管理手法进行项目管理和控制，要理顺项目内部及往上的问题反馈渠道。不要以为项目经理就只是协调一下资源、做做度量、召集一下会议这么简单。
h) 树立有团队是幸福的观念，要设立团队共同的愿景，当你爱你的团队和成员时，你就会更用心的去培养他们，从而提升整个团队的生产力/竞争力；
i) 要做到带人带心，在适时的亲近下属，及时与下属沟通；
j) 要在团队中把做的好和差的区分开好，形成一种导向，让大家都朝着做得好的方面努力；
k) 待人宽厚，要善于学会自嘲、自我批评，如绩效沟通会，平时大家把数据收集起来，并做成胶片，在会上（大概2个小时左右）进行展示，对表现突出的要表彰，有数据说明，比较容易让人信服。
l) 要信任下属、用人所长。
m) 注重团队交流与沟通及创造高层次的团队氛围；
n) 有团队的成功才有个体成功，英雄主义是不行的；
o) 分配任务后，要进行适时监控，这样可以保证团队成员不偏离原始计划，充分理解计划，按进度完成任务；
p) 有些问题，如果项目经理承诺不了，可以向上求助；
q) 管理本来就是出于不信任的，因为不信任，所以才需要管理，但是我们必须先信任别人，才能做到放心把事交给别人做，也就是说信任要日常化，管理要制度化；
r) 根据产品未来1-2年的的特性规划，分析人力需求，主动向研究部提出人力需求。条件允许的情况下，可以根据特性规划，提前做好技术储备。
s) 新员工多，做好培训，最好能亲自讲，你是业务最熟悉的人。可以将项目组的知识分为知识点；每个人掌握的情况在一个表中记录。
t) 管理是 “管事理人”，不是”管人理事“。
u) 将Team Building按照项目管理的一部分来操作，将Team Building议题作为项目组一个例行议题，形式不一定光是吃饭。
v) 是否经常同项目组成员一起共进工作餐。
w) 最好集中办公，如果项目成员太分散，需要提出来；
x) 不要开漫谈式没有结论的会议，这种会议将影响团队气氛。并注意会议结论要跟踪，一定形成闭环。
y) 一般来讲，不要采用投票的方式来裁决。
z) 要善于利用项目以外的资源进行帮助，包括各技术管理组组长、开发部部长、质量部等。通过这些渠道推动某些工作的开展和问题的解决往往快速而有效。
aa) 自己敢于为下属承担责任，不要忘了自己始终是第一责任人；项目得到肯定时候，不要忘了下属。“下属做不好，是主管的错，下属做得不错，是他的功劳；下属做得不好不坏，大家的运气；”
bb) 项目经理是团队的组织者，是团队行动的最大影响者，所以项目经理要严于律已，业务知识和技能要过硬；
cc) 项目经理要实事求是，客观处理事务，不要固执已见；
dd) 项目经理在业务和管理两方面要合理投入，要掌握平衡；
ee) 适度竞争：论功行赏，奖惩分明。项目经理可以在各个方面建立奖惩制度。比如：在Review方面建立积分制度，对积分高的员工在组内通报表扬，对积分低的则要沟通，提出改进建议。
1、 激励时，要做到正确、及时、分明；
2、 项目经理虽然不能通过直接的手段（奖金、加薪等）给出项目组成员激励，但可以给予适当的激励与支持性的工作氛围，为项目组成员设立愿景，帮助其自我实现。同时也可以在各种荣誉方面多给予推荐。
3、 项目经理要多关心员工，比如健康、情绪、压力、家庭、经济等。特别对于新员工。
4、 对于上进心不强的员工如果激励呢？我们一方面要允许“B”岗位的人存在，另一方面要关注一下“B”岗的人，因为他们可能只是没机会表现。
5、 不要让项目组经常上研究部或者产品部的黑榜或者批评栏中，对项目组士气有影响。创造能表扬项目组或者成员的机会。
6、 项目经理的权力最推荐使用奖励与专家权力
7、 项目经理对于项目组成员要显式的表扬，隐式的批评；不要吝啬你的表扬，不要吝啬表扬的范围，尽可能的扩大影响范围。
8、 奖惩方面：不要吝啬奖励，赞美下属的原则：及时性和公开性；只奖励为数很少的团队成员如本月最佳团队成员等，会破坏团队凝聚力，要扩大奖励的范围。当然也不要奖励错了，对于那些因为自己原因导致进度延迟，版本质量存在重大问题来加班加点的，不要公开奖励，另外不要违反流程制度来激励。
1、 跟QA提前或及时交流，灵活运用流程，提前定义过程，相信流程但不迷信流程。
2、 要善于利用前人的经验教训。以前项目的经验教训是宝贵的财富，利用好以前项目的总结等。
3、 深刻认识我们为什么没有严格执行流程矛盾心情？及如何化解对流程的矛盾心情？
a) 进度紧张就会有抛弃流程的欲望；
应对之道：平衡，启动前与QA协商合适的项目流程；
b) 流程带来长期利益，常常遭到短期利益冲击；
应对之道：人之常情，需要培养战略眼光；
c) 开发人员对流程的诉苦也会干扰PL执行流程的决心；
应对之道：考验领导能力和执行能力的时候，犹豫将导致失败；
d) 对过程控制能否带来好的结果比较怀疑；
应对之道：原因是怀疑流程流于形式，没有效果，从而形成恶性循环；解决方案就是我们可以在项目组内明确项目流程及其意义，避免流于形式的执行，让流程真正的服务于项目开发中。
e) QA经常干扰PL的正常工作，心理上与QA比较对立；
应对之道：要抛开偏见，顾全大局。现在流程变化很快，不断新增，PL对一些流程又不是很懂，所以项目经理应该好好“使用”QA，因为他们都是流程方面最好的顾问。
f) 对单枪匹马开发的迷恋；
应对之道：对产品的复杂性，规模应用对质量的要求一定要有充分认识；
4、 如何较好的实施流程？——循序渐进，抓住重点，坚决执行，落实流程
a) 循序渐进、抓住重点
——不必务求完美，根据项目组实际情况，制定可实施的合理项目流程；对风险较高的部分作为重点；如：需求跟踪、代码检视等等。
b) 坚决执行、落实流程
——在项目组内明确项目流程及其意义，避免流于形式的执行，让流程真正的服务于项目开发中。
c) 可行的一些建议：
i. QA是最好的流程顾问；
ii. 让项目组成员承担某些项目管理活动；
1、 项目经理是项目责任主体，要为整个项目的质量负责；项目经理作为项目的主管，带领项目成员完成项目，项目是整个项目团队的孩子，而不是上级主管的、不是QA的。
2、 项目经理更多的需要作管理、协调、沟通，而不是技术；项目技术活动的管理要充分利用技术负责人进行控制。（也有观点认为项目经理技术方面要过硬）
3、 正确对待“杂事”：各种报告、审计、会议等等。把这些工作做好了，项目组能得到更多周边的鼓励，有利于项目的斗志。使“杂事”变好事；
4、 今日事、今日毕，现时事、现时毕；
5、 悲观＆乐观：项目组都乐观的时候，要冷静；项目组都悲观的时候，要有效激发项目斗志；
6、 要做到民主与集中相结合；
7、 不要“忘事”，自己忘记的小事可能就是别人的大事。有事情随时记录、提醒。
8、 要善于与团队成员及周边沟通；
9、 了解员工，要使得合适的人做恰当的事；
10、 无论是对人还是对事都要树立责任感，要更好输出绩效，身先士卒；
11、 要提升个人的业务能力，起到中流砥柱的作用；
12、 要有感染力和影响力，项目经理的一言一行都会影响到整个团队的士气，项目经理要做到在困难面前镇定自若；
13、 项目经理要注意通过某些途径提高团队的凝聚力，如通过举办活动等；
14、 要帮新、老员工制定工作愿景；
15、 重视时间管理，别让琐事牵着鼻子走，时间管理的高效秘决就是：授权；
16、 要培养自己的坚韧性，坚强刚毅，迎难而上，积极乐观，能屈能伸；
17、 培养自己的责任心，热爱本职，追求更好；
18、 追求快乐的领导。真正的领导不是服从和一致，而是注重细节，慎用威严，积极的去想办法带动影响感染团队。
19、 真诚对待他人。待人以真，示人以诚。只有真诚地对待他人，才能和员工相处的更融洽，让团队更有凝聚力，共同进步。
20、 时刻反省，工作的同时提升个人能力，给自己制定一个梢高的目标，促使自己不断提升。孔子说过：“三人行，必有我师焉。择其善者而从之，其不善者而改之”。 经验和教训都可以给人以启迪。相信大家通过多层面研讨学习，“如切如磋、如琢如磨”，会有所体悟，有所收获。
21、 凡事要以身作则，严以律己，但非万能帝。项目经理是团队的带头人，只有自己作好，才能发动集体，但我们不是圣人，遇到困难要懂得寻求上级协助，学会沟通。
1、 项目经理的要素维度
28个人参加讨论：
|
| 沟通与表达能力 | 职业化精神 | 创造力 | 竞争精神 | 知识与技能 |
| 成为PL的因素 | 27 | 23 | 0 | 5 | 28 |
| 成功的PL具备的3要素 | 28 | 28 | 12 | 12 | 14 |
根据现场统计来看，对我们PL来说非常重要的是：沟通与表达能力、职业化精神。
知识和技能是靠大家积累和沉淀的。这个不是PL的共同的属性，只是一个私有的属性，是取决于你这个人。但这是使大家成为一个PL的因素。
竞争精神和创造力。还是希望大家多去关注创造力，否则只是一个执行的机器。QA说的一定是对的吗？能不能帮QA改进流程？我们需要不断地思考。
2、如何理解职业化
a) 理解岗位职责，不错位，相互补位；
b) 管理无止境、不断的修炼。多思考（思考10分钟和一天是有差别的），敏感，多悟；
c) 情景管理，敢管，善管；
d) 有些管理没有绝对的标准；
e) 关注无人管的人和事；
f) 关注问题之后的问题（QBQ，类似RCA）；
g) 提高执行力、培养信心；
h) 职业化不是一天练成的；
1．基本条件：
现在要求项目经理必须通过公司项目经理认证；具备一年以上华为开发经验，具备相关产品背景；有完整的开发经历；熟悉研发流程、规范。
2．品德、素质：
·信守华为核心价值观：团结奋斗、敬业精神、责任感、使命感；
·诚信：坚持实事求是的行为准则，愿意将意图、观点、事实开诚布公地与他人进行交流；
·自我批判精神：工作中勇于自我反省，善于从不足、错误中汲取经验教训。
·领导能力：有能力并愿意做一组人或一群人的领导。
·主动性：提前预测风险及其发生的可能性，并有计划地采取行动提高绩效、避免问题的发生。
·关注质量和准确性：质量是研发人员的脸面。在工作中时刻关注质量，提前做好质量计划、质量预防措施，并有计划地采取行动实施质量改进。阶段性地对工作或信息进行审视和监控，确保准确。
3．知识和技能：
·技术领域的领头人。
·管理能力：具备沟通能力，在众人面前和一对一的谈话中清楚、明确地表达自己的意见，并善于倾听；制定计划及管理，能合理估计项目所需工期、资源、和成本及风险；制定有效的计划监控管理措施和风险规避措施。熟练掌握Project等IT项目管理工具。
·流程：掌握、运用IPD相关的业务流程的能力；将流程与业务技能结合的能力。
做一个项目经理不容易，做个出色的项目经理更难，只有我们了解这些要求，衡量自己的符合度，反省自己的不足，朝着这个目标不断进步。
问：项目已经进展了一半了，客户的需求发生了重要变更，怎么办？
答：需求总是在变化的，这时候你的主管应该帮你做一些事情，做好版本规划，减少需求的变更及其影响。你自己则要提供给主管做决策的依据，同时在计划中一定要有应急的时间。
问：需求电子流的规范承诺日期和网上的问题单是谁负责？
答：是SE承诺，但时间和责任人是开发代表承诺的，经PDT评审。但是版本承诺在RDPDT，两者再沟通。
问：市场需求太多，任务直接到项目组，直接给开发部，由项目组SE直接过滤，这种情况如何解决？
答：让市场决策。需求是由市场判断，SE分析，开发人员实现的。
问：针对版本火车，导致大量版本并行，RNC是如何控制的？
答：从人力角度分析，每半年的R版本控制在200KLOC以下，这样，人力是足够的。另外，一定要用新版本替代老版本，减少老版本维护工作量，把主要精力集中在新版本上，充分保证新版本的稳定性，从而实现老版本的替换。
问：根据组织的数据，我做了两份计划，一份偏紧一份偏松，领导选择了偏紧的，在此基础上再砍掉两周，说要有挑战性。这种做法是好还是不好？制定的偏紧的计划，实际上是需要增加资源。我担心的是，如果制定了计划，出现偏差，员工对制定计划的严肃性表示怀疑。
答：对于项目来说，没有最好的，只有最合适的。领导可能根据项目特点和市场需求，选择一个更合适的计划。另外50个人做项目，如果做得好，等于100个人，如果PL管理得不好，就相当于10人。
问：如何做好计划的合理性？
答：如果一个计划只给出时间点对于老员工可能是合适的，但对于新员工是没有用的。如果新员工非常多，计划就要更细，最好作为新员工的日工作计划。
问：如果客户要求的时间点项目组肯定做不完，怎么办？
答：（1）首先20%的项目做一个倒推的计划是不可避免的，但我们可以了解用户到底要什么，用户对于你最不满意的地方是什么？然后我们可以先争取提供用户最想要的。（2）你的上级主管应该屏蔽一些对于项目的不利影响，你应该通过具体的数据和事实告诉主管为什么无法完成。任何时候都应该保持诚信，帮助主管做出合理的分析。
问：项目编码阶段只有一个星期，如何细化计划？
答：（1）可以让员工自己来做计划，每天汇报进度。（2）项目经理只花20%的时间用于管理是远不够的，要多做管理和沟通的工作。同时要允许员工适当地犯错误，帮助员工成长起来。
问：项目经理是执行层面的，在执行规格和交付点上不清楚，当时间紧，往往就牺牲了质量方面。对于倒推时间点方式，应怎样沟通、达到平衡？
答：要将存在的问题“喊”出来，大家找到解决的方法。对需求要进行分析分类，有些可能可以延迟到下各版本，另外，PL可参与前期规划，充分了解。
问：经验介绍中提到项目计划要预留10～20％的裕量，但因为本来就人力不足，要预留裕量根本做不到。
答：的确难以做到，但要争取，强势的PL会好一些。另一方面，可以和MARKETING沟通，分版本分节奏开发。有个PL，管理30多人，对每个人的任务做了个列表，如多少人在做补丁，多少人在做新版本，若有突发任务，则明确要求必须增加人力。目前RDPDT也有人力计划，对MARKETING的新需求，会根据人力情况安排，需求也是有一定回旋余地的。另外，也可以利用周边资源。
问：有的同事不愿意填写工作日志，如何解决？
答：可以把日志当做计划用，每天早上将一天的工作在日志中做个安排，到晚上再刷新，记录实际时长；
问：一项任务分配下去后，怎样保证按计划执行，除了检查点以外，还有什么高招？
答：每周、每月例会监控或经常问起、催促；
问：自己不能控制自己的计划，老有突发重要任务，如何平衡与计划任务的关系？
答：1）记录第一个月、第二个月的突发任务，给开发代表看，作为参考（经验数据），给下次计划提供参考；2）计划制定时留有余量。
问：要赶进度，要加班，开发版本还延期，怎么办？
答：要进行人力资源分析或记录好加班数据，为以后输出准确的度量结果做准备，保证以后不发生类似的版本延期问题。
问：以前有外包或离职人员走了，人力忽然释放了或来了几个新员工，这样交付质量、进度就受到了影响，怎么办？
答：是有影响，我们的任务是怎么把影响降到最小，把执行开发过程、任务做到位，必须做的做到位，参与一些项工作，有困难或不能解决的及时向上反馈。
问：在项目组中，老员工少，新员工多，培养员工的工作还来不及做，哪还有精力和人力做项目？
答：（1）根据实际情况制定项目计划，向上级反映情况，并请求帮助；（2）请别的项目组帮忙做一些核心工作，或者临时借用一些专家攻克技术难点。（3）对项目需求进行考虑，争取拒绝一些对项目造成严重风险的项目。
问：项目经理如何保证REVIEW效果?
答：我们项目经理还要承担一部分管理的事情，我们需要精细化管理，比如评审会议，1、选择评审专家，一定要选合适的人，哪些人参与这个会议哪些人不能参与这个会议，参与评审的专家数量要适当。2、有时候没有经过预审，就开始评审，在评审中很多都不熟悉。现在很多评审都存在这样的问题，上午发评审会议通知，晚上就开评审会议。没有给专家预审时间。3、Review的过程，很多东西都是自己写自己在评审会议上读，5个人花了两个小时，最后改了几个错别字，几个规范问题。4、有没有修正问题。我们PL要有精细化管理，要发现哪些人适合于编码，适合于做设计，适合于解决问题，我们需要跟项目组成员交朋友。
问：检视专家参与度不够，如何解决？
答：1）提前提醒；2）说明检视内容的利害关系；3）请吃饭。
问：在快发布时，有一个致命的问题，测试部不能重现的问题，暂时没办法解决，这种情况怎么办？
答：首先要分析是不是致命问题，如果是致命问题，则不能发布，若非要发，由产品线总监签字走紧急版本发布流程。产品线要控制版本的紧急发布比率。
问：编码阶段时，发现分配需求的稳定度很高，但对于SRS的稳定度比较低，我们发现跟SRS的写作人有关系，同时TR2的设计规格太粗，由谁来对我们TR2的质量负责？
答：由SE负责。要与SE进行互动，PL可以提前参与，SE也应再往后支持一下。
问：对于已经定死了交付日期，但版本质量差的情况，应如何处理？
答：要进行针对性分析，看看质量薄弱环节在哪里，并改进，另外要与前方人员沟通，若必须使用，则只能进行小局点尝试，要控制应用范围。
问：RDPDT在接受倒排计划的同事，是否接受降低质量？
答：首先，应尽量避免倒排计划，一般版本计划有一定弹性，要合理制定计划。若确实非常紧急，是突击版本，则不能按正式版本使用，只能小范围应用，对正式版本，不能妥协质量。另外，目前产品质量分A/B/C级，在产品前期就应确定策略。
问：如何判断版本收敛了，测试可以退出？
答：（1）当一个版本不增加新需求，再测试2轮+1轮回归测试，测试就可以退出了；（2）通过分析日均发现问题数，可定性判断测试是否可以退出；（3）对特性进行A、B、C、D评估，根据A+B的比例判断版本是否收敛，该项主要是依据测试人员的主观判断，没有利用具体工具。
问：项目组成员缺乏主动性，计划是4天的任务，项目组成员3天就完成了，但仍然到第4天交付的质量也不是最优的，如何与其进行沟通？
答：你首先要想一想你有没有把你的期望告诉他？对于他所做工作的质量要求要量化，分配任务前要提前与他沟通。另外要教给新员工好的工作方法。
问：如何与绩效为C的员工如何沟通？
答：学习一下韦尔奇的人力曲线，多跟他们进行面对面的沟通，沟通时一定要真诚，做得好的表扬，做得不好的要指出来，两个表现差不多的，就要看长期表现。
问：如何做好新员工培养？
答：（1）组织部门的新员工定期进行汇报，让新员工轮流讲解、互相提问（类似于我们的新员工学习小组）；（2）创造学习环境，加大外部压力；（3）作为PL应经常与新员工交流谈心，激发其内在动力。
问：新员工不敢问问题有何高招？
答：可以站在他的旁边，逼其问问题；
问：怎样做到奖惩分明？
答：奖励多些，惩罚少些，以鼓励为主。采用质量回溯的方法。
奖励的方法：
a) 每周记录员工的好的方面、差的方面，季度考评及时提供给功能部门做为参考。
b) 可在工作日志中提出表扬。
c) 表扬时范围越广越好，批评时范围越小越好。
d) 由于新员工的思想承受能力弱，因此新员工在批评的同时要及时做好思想工作。
问：部门活动除了吃饭，还有其它的可以提高新员工快速融入团队的方式吗？
答：可以组织一些网络游戏对战等；
问：如何提升团队士气？我刚接了一个项目，项目组大部分都是新人，6月份提交测试以后，问题数特别多，最多的时候达到了300个，在其中的2-3个月问题100-200个/月，问题数就是下不去，这时大家就感觉没有什么成就感，士气就不行了，大家看不到问题单收敛的趋势。在这种情况下如何提升团队士气？
答：在这种情况下，确实压力比较大。但作为PL自己要承担更大的压力，有两种方式：a、压力来了直接传递，b、压力来了，慢慢传导。这个时候对PL个人承受/素质要求高，另一个对沟通能力要求也比较高。市场有时候会有点不讲道理，这种情况下要去多沟通，让市场代表了解项目组的真实情况，让他了解真实情况以后，可以问他有没有什么办法？有些事情不能由项目经理来做，可能是开发代表或产品经理，他们有必要的时候可以与客户诚心沟通，多数客户还是讲道理的。只要你不是跟他讨价还价，只要你是真心想把产品做好，跟他把需求过滤一下，公司也在也在狠抓，为什么我们大家都这么忙，研发开开要加班，就是因为需求没控制住。以后市场要做需求承诺电子流，跟项目成员多沟通，与大家一起干，大家就比较认同你，然后再谈下一步。
问：如何鼓舞团队士气（尤其针对外包人员）
答：（1）让他了解产品的愿景。
（2）对他做的任务作出评价（影响力度比较弱，因为不是华为公司的，评价对于他们来说没有直接的利益影响，比如说加薪什么的，关于这点可以与外包公司沟通并协调）。
（3）加强自身技术水平，达到一定的技术影响力，提高个人魅力，平常注意搞好私人关系。
（4）多做一些组织气氛建设的活动。
问：项目组的绩效是有差别的，有好的也有坏的。那考评时，如何考评？好的项目组和坏的项目组，好的项目组中得B的比例是不是要高一些？
答：可以介绍一下我自己的做法。每个季度有一个PBC，半年给PL做一个PBC，不同项目组可能有几个维度，比如关键事件，解决产品非常严重的问题，问题解决率，还有小组的任务完成度。另外还有35％的关键事件，当然带有一些主观性，也有一些客观评价，包括问题解决率，规范度，NC解决率。主要是开发代表给PL评分。好的项目组中得B的要高一些。现在考评是分层分级。
问：如何评价PBC？
答：如果PBC每季度才刷新的话，有点慢，实际情况都变了好几轮了、项目也有延迟了；用PBC也可以，但必须在这个基础上，制定一个月度计划——每月刷新项目组的计划，每周刷新个人计划。
问：1个开发人员，一个维护人员，如何合理评价？
答：一般都是向维护倾斜，大家喜欢做开发，不愿意做维护，对个人的更大些，维护优先级比开发高，向突出事迹的人身上倾斜，开发和维护差异很大，不好放到一个层面。
问：在人员比较稳定的情况下，部门员工的考评在1年多以后都保持一定状态，感觉绩效考评没有什么效果，这种情况你怎么考虑？
答：是会有这种情况，包括今年、明年新员工大量进来以后也会出现这种情况。所以说一定要分层，但是这个分层不能太快，不能一步就分完了，3-4个季度调一次，例如可以把2B1C的划一个圈，为什么是2B1C呢？他们会在后面的季度里打A，仍然会影响他们任职资格的评定，因为我们的任职评定需要2B2C以上才有资格；另外一种层次划一个圈，划成2个圈再对他们进行考评，这是一个持续的过程，3-4个季度调动一次，刚好和任职资格的时间稳合上，分完后正好有一个任职资格的沟通沟通，这个时候沟通他们比较容易接受和理解。任职资格跟公司对他的评价是很有关系的，他可能一直拿B，为什么打B，因为考评的范围就是这样设的，你跟讲道理，他就很容易理解。
问：碰到小团队怎么办呢？
答：小团队确实有些问题，容易变成大锅饭。这个时候更多的时候是你要以身作则，你要去带他们。在沟通上、评审、考评各方面，多用一些激励手段（包括荣誉奖等），要根据表现给绩效，如果你不公正，他们就不会服你。
问：项目组的某些成员有几个月时间在为其他项目组工作，这种情况下如何考核?
答：可以把考核临时转到其他项目组，可以问问开发代表的意见，或者看你是第一责任人还是那个项目组是第一责任人。
问：量化考核的实际做法有哪些？
答：KPI（产品线分给产品，产品分给开发代表，开发代表分给项目经理），你也需要进行分解，分给正面的员工，把素材讲给他们听，能做到量化的点提出来，如缺陷密度是怎么样？SD出了什么问题，用内部管理制度的方法量化起来。
问：假设你的项目组80％的人资历比你老，如何管理？
答：A.要注意态度问题；B.私交要好一点；C.你很有水平，每个人的职责分清楚，把工作安排好，该制定计划就制定计划（如果不做计划，就向上级反馈），制定了计划就要好好执行，有能力就做PL,没能力就做技术骨干；D.该做什么就做什么，以结果来认胜负。
问：项目结束后，如何安排项目组成员？
答：首先分析哪些人适合做维护，哪些适合做开发，然后下去沟通，了解他们的需求，一般都能解决问题。
问：来了一个新员工，是北方人，离上海、北京近，他表示他来这工作也是为了学习，但2年后就会走，这种情况如何给他安排工作？
答：A.重用他，如果他是人才；B.如果有人选，就表示他任何时候走都无所谓；C.也可进行沟通，了解其需求，也许时间久了可能改变其想法。
问：PL几个组成的一块做团队里，有些事不能都自己做，要分下去，但是例行的，没有挑战性的，他们就不想做，怎么处理？总有人配合的不好，挑战性的工作如何分，是给技能好的人还是中庸一点？
答：顺其自然，中庸之道，到时候再调整，先沟通，从长远来看，总有合适的方法解决。
问：产品多，市场压力大，要加班加点如何处理？
答：有目标了，该加班就加班，还是沟通的问题，要注重版本分布，做好规划。
问：新员工喜欢发邮件，网络化比较严重，容易耽误事情，如何解决？
答：提醒其重要的事情一定要保证有回应；
问：团队、技能，一些员工做JAVA，进来也做JAVA，做的得心应事，绩效也好，但团队重心转型后，他的绩效受到了影响，这种影响该如何处理？
答：从几个角度去考虑a、站高一点，不要把他看成项目组的人，要为他的将来考虑；b、与他沟通，把他转到其他产品线，把这个专家给其他产品，这样可以从这个产品线划1-2个新员工名额；c、新员工经过1-2年积累，流动大的话，好处：知识面会宽一些；坏处：整体打通技术通知，让其长期做一项技术；
问：我们项目组有十几人，都是我一个人在管，想再分一下，分给底下的人管，但没有任命，请问这种情况如何处理？
答：有没有任命没有关系，你可以选择资历老的人或技术专家担当“副手”，只要在内部进行过沟通，内部达到一致就OK。之后可以侧面打听一下大家对“副手”是不是认可，看他可不可以承担责任或具备相关技能等。
问：在制定计划时，由于项目时间很紧，为了保证质量和进度，所以将周六都算进去了，当时与项目组成员沟通过，但他们在action时存在压力，可能心里有些想法，这种情况下如何保证他们有效实施计划？
答：要事先与他们沟通清楚为什么加这个班，从项目的角度、项目的需要讲这个事情，告诉他们如果不加班对产品有什么影响。
问：技术强的人认为他们在工作时间内就能完成所承担的工作，周六不需要来加班。
答：可能是技术专家/骨干没有贡献精神，如果有这种想法就要与他们加强沟通，要告诉他们这不是某一个人往前赶，而是一个团队统一向前走。
问：在项目组内有些人8小时能完成某工作，但有的人可能需要9小时才能完成，但项目又却实很紧张，有人提前忙完了就学习一些技术知识，但开发代表却认为他们没有工作，在偷懒。
答：可以安排这类人参加一些技术认证，让开发代表看到他们取得的成绩，了解他们在干什么。可能是项目经理与开发代表沟通不够，我们对员工要看绩效。a、如果偶尔发生，通过沟通可以解决；b、如果是长期的，要加强计划；c、可以通过Openday与专家沟通如何解决些事。
问：项目经理需要具备大度、自律、智慧等个人品质，而且要充当表率等，这对PL要求是不是太高了？能不能通过流程或方法管理项目组？如我们项目组有人很固执，有时我影响不了他，他反而影响了我。
答：PL一定要职业化，碰到这种情况就要学会沟通技巧，沟通有专门的课程，所以说好东西是要多学的。
问：跨项目组之间的人员分配，有时间冲突时如何处理？
答：在工作量、时间、进度上提前做好沟通，提前做好计划。
问：项目组中技术较强的人在一起时产生的技术上的矛盾该如何解决？
答：
面对：一同讨论分析利弊，一起达成一致
求同存异：把达成一致的事情先做了，再讨论不同的观点
强制：在意见相差不太大的情况下，不要使用强制
撤退：别人怎么说就怎么做
或采取以下方法：
a) 加强技术学习，提高自己的业务水平，培养自己在技术上的影响力。
b) 在项目划分和每个模块安排人员时候注意强弱搭配，避免各模块的力量不均。
c) 了解项目运行过程中的细节，在冲突发生时候，能够正确引导项目成员解决，使自己的管理在项目组中得到认可。
问：实际所得达不到期望标准：有些人想学习新知识，但在所分配的任务得不到想要的，于是对工作没那么热情了。
答：（1）了解其难处，与其进行沟通，将项目组的各项业务模块对其进行分析，坦诚以对，让其知道项目经理安排人员的难处；（2）在项目划分时候，争取一个技术比较强的模块（能够吸引项目组成员），满足一些技术兴趣特别强的成员，让这些人兼任其它模块，完成整个项目的需求。（3）多组织内部学习，特别是学习其它项目的知识。
问：有些人能力有限，却不甘做边缘工作。
答：（1）项目一开始就明确并委婉的拒绝，例如：请他/她说明对于整个项目他/她有什么思路，如果说不出，他/她自己会了解自己的不足。（2）在安排一些边缘工作的同时，请他/她参与一些核心工作，让其得到锻炼
问：人员紧张，如何备份？
答：可以进行交叉评审、交叉测试等，让大家了解各块的内容。
问：有些人技能较差，进步较慢，但工作认真努力。
答：（1）对于此人的工作能力要扬长避短，帮助他换一种工作任务。
（2） 若项目中无法换工作任务，而他自身意识到自己的不足，可以安排他打下手。（3）对于不上进的要劝退。
问：面对项目成员工时欠缺压力，项目经理如何操作？
答：（1）团队的节奏是由团队领导控制的，根据计划，进行适当调节，要有张有弛，节奏紧的 时候适当放松一些，节奏松的时候，调整计划，把项目的状态调整起来；（2）工时用于判断整个部门的紧张程度是合适的，而针对具体员工是不合适的；（3）避免周六加班。
问：你前面讲到要让项目组成员“向我看齐”，但项目经理主要时间用于管理，在技术上投入不多，如何保证项目组成员“向我看齐”？
答：（1）项目经理的技术是不能丢的，可以因为时间的原因无法亲自做需求分析、设计，但一部分核心的分析和设计要参加Review，并给出更高层次的指导。
（2）项目经理要帮大家解决问题，即使无法亲自解决，也要提供他一个途径去解决。
（3）项目经理自己应该把自己摆在项目组绩效为A的地位上，各方面做得优秀，项目组成员才能向你学习。
（4）项目经理要把受到的挫折变为自己的经验，提高自己的管理。
问：项目经理是否应该做雷锋？
答：其它部门需要配合时，若自己也很忙，则要从整体角度考虑优先级，若自己的优先级更高，则可以推掉其它项目任务。
问：开发代表平时都做些什么工作？
答：1、版本规划。2、市场需求分析和确认。3、与外部沟通和外部的接口工作。
问：开发代表的上级主管和直接主管是谁？
答：是产品经理和更高一层的大开发代表以及功能部门主管。
问：开发代表接触不到代码的心理是什么？
答：要有一个角色转变的意识，意识到位了，做事情会容易些，要快速转换角色，与周边做好紧密的合作、沟通。
问：具体PL做工作时，有些做的实，有些虚，虚的不产生大绩效，虚与实如何把握？
答：不要做“甩手掌柜”和“老黄牛”，两种都是要批判的，开发有周期，如TR2-TR3，TR3-TR4，TR4A以后开发项工作就会减少，维护就会增加，有时是高峰期，有时是闲点，要对任务进行区分，哪些重要又紧急？如一个工作表，哪些事情分下去自己要列一个表，对任务分配有帮助，不忙时安排一些学习，学习案例等，进行审视也是一种学习。同时自己也要多学一些时间管理、任务管理的知识。
问：新员工招进来以后培养时间一般是2-3个月，到独立工作要6-12个月，我对其花了很多心思，可后来他去了别的项目组，所以我个人就有点想法，要如何平衡这种心态呢？
答：1）向大庆学习（大庆当时很牛），他们就把最牛的人输出去，这些人出去后一般还是在石油行业或相关行业，可以提高大庆的影响力，以及一些潜在的好处；2）如果牛人不出去，下面的人如何成长；a、我培养这个人是花了很多心思，但培养人就是我工作的一部分，我做好了培养工作也就是做好了工作，自己也应该觉得很高兴；b、这些人出去后，如果你真心为他们的成长交流、负责过，当你的某项目工作与他们相关时，就会得到他们很大的帮助。
问：但是它对我的绩效有影响？我培养了新员工没得到上级好的评价，怎么办？主管没有正确评价我的工作。
答：我培养新员工可能没有得到你很好的评价，这时我怎么办？难道以后新员工的培养工作就不做了呢？不行，我们还是应该以一种积极的心态对待这个事情，我们还是应该继续认真做好培养工作，有时可以与主管沟通一下，让他看到这块的工作，包括你让新员工组织的一些培训和交流，有些邮件都可以了给主管。我个人觉得只要你一直好好的做，总有你的成绩会得到领导的肯定的——金子总会发光。如果主管确实看不见，就想办法让他看见。这个新员工不可能一直在一个项目组，他总有一天会去别的项目组，如果你在公司时间比较长，你就可以发现身边的人陆陆续续都不在了，大家都分到不同的部门了，这是一个很正常的情况；从另外一个角度来讲，这些人都是你带的，如果你真心为他们的成长交流、负责过，他们出去以后如果与他们打交道时，你的工作会很好开展。
职业发展
问：当个人规划与产品定位的发展有矛盾时，如何协调？
答：1）首先做好本职工作，才能有个人的发展；2）看有没有人接班，只有有人接班时，才可能调整。
问：如何引导开发人员对资料开发的重视？
答：首先分析不重视的原因：1）一开始就不重视，2）资料组人员在地理分配上不在一起，造成了一些生疏；3）客户不重视（国内是到现场解决，可国外就不一样了），然后引导开发代表从交付件入手，从准时交付资料出发，面对海外客户。
问：项目做完了，但不被认可的时候怎么处理？
答：（1）项目组进行分析，确认是项目组没有做好，还是项目立项或者是别的外界因素导致，将分析结果对产品或者领导汇报并知会所有项目成员，如果项目真的做的太差，项目组要做自我检讨（这种情况很少），如果是其他因素导致，要向领导说明情况，并请其到项目组进行安抚。
（2）妥善解决项目组后期维护问题，要立即给项目成员安排工作，新组织新项目组（寻找新项目做）。
问：遇到领导不理解为什么项目需要的时间长，效率低时该怎么办？
答：（1）收集以前和现在做的项目的记录，向领导列出已有的进步。
（2）列出事实并说明原因。
（3）接项目时应事先说明实际情况，打好招呼。
（4）自己实在无法说服领导时，可以找身边的同事或者领导的领导等帮忙说服。
感谢所有在研讨会中共享经验、案例的项目经理！
感谢所有参与研讨会经验交流和互动的开发代表/优秀项目经理！
感谢亲临研讨会进行致辞的各级领导！
感谢所有参与研讨会引导、组织、策划的同事！
感谢所有支持、关注研讨会工作的人们！
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
