项目绩效考核体系执行简述
1.沟通先行，定义沟通规则；
或许每个人都有很多事情要做、都比较忙，但排上计划的事情就要尽量按计划执行；
如果对计划安排有争议，请在计划制定前讨论，准确评估和告知风险，商定计划安排；
(1).与研发沟通规则
1).确定对功能模块需求理解准确、正确，需求反交底，要点罗列；【必须执行】
2).确定对功能模块实现逻辑清晰，想明白再去做，设计草稿、流程图草稿；【选择执行】
3).确定功能模块拆解清晰，尽可能用时评估准确，预留缓存时间；【选择执行】
4).确定功能模块的代码，经过自测、测试场景数，测试场景草稿；【选择执行】
5).每天提交自测通过的、完整的代码到TFS，并协商解决代码签入冲突问题；【必须执行】
6).每天更新研发任务状态，每周五(或每周二、四)发布，更新任务状态提交测试验证；【必须执行】
7).每周三(或每周一、三、五)查看Bug平台，4点半提交的问题，当天清理掉；【必须执行】
8).每天碰到技术问题、需求不理解、需要配合沟通的问题，及时反馈团队，在群组讨论；【必须执行】
9).每天技术问题处理思路确定问题、定位问题、解决问题、验证问题、提交测试，【必须执行】
其中定位问题、解决问题花费时间超过2个小时，选择进行下一项；如必须解决，请求技术支持；
(2).与测试沟通规则
1).确定对功能模块需求理解准确、正确，需求反交底，要点罗列；【必须执行】
2).测试用例场景覆盖充分，对于多场景覆盖，可以使用简易草稿测试用例；【必须执行】
3).每天更新测试任务，每周一(或每周一、三、五测试)，更新测试状态；【必须执行】
4).定期做测试小结，审查提交功能一次通过率，问题反复修改率，定期出测试报告；【必须执行】
(3).与项目经理沟通规则
1).每天跟进研发进度、每天跟进测试进度、定期做功能的阶段性验收测试；
2).客户问题的收集整理、跟进验证，必要事项的推进执行；
3).项目的整体状况，需求、开发、测试、UAT、试运行、验收；
4).项目的问题和干扰；
5).项目的发展和改进；
(4).与客户沟通规则
1).启动阶段：明确主要交付物，验收交付物；
明确需求变更流程、问题升级流程；
环境搭建的主要负责人权责，并提前做好相关环境准备；
2).需求阶段：以文档、表格、简易图、原型，与客户邮件确认；
帮客户梳理业务，站在用户角度，多多思考业务流程；
3).UAT阶段：通知相关用户尽情的提问题，过了UAT阶段就没机会了；
告知客户尽可能用生产环境的数据来测试，相关配置规则可与生产配置一致；
登记客户的问题，筛选排优先级(重要层度、紧急层度)，按计划、节奏性交付；
4).试运行阶段：确保运行状态的效率，保持很快的响应速度，确保客户试运行通畅；
小问题，当天解决；大问题，2天内解决；
2.TFS源代码管理，版本管理，项目管理(任务项建立、进度计划、需求管理等)；
或是其他项目管理系统，进行可视化管理，进行数据登记管理，日常登记，定期进行分析总结，形成报表和报告。
3.项目进度评估
承诺客户问题，不把握的问题一定先内部沟通；
如果开发需要1天，要给客户说需要2-3天，留一个缓冲；
已经承诺客户的时间，我们内部完成时间要提前1-2天。
功能越复杂预留时间和提前时间更多些
4.启动会要明确内外部需求变更流程、问题提交流程
(1).问题提交流程
客户提交问题->分析客户问题(1.原因；2.做什么；3.效果)->现有项目可不可以满足？->可不可以推掉不做？->
可不可以延迟处理？->必须处理->问题评审->是否必要做？(原因？)
->功能Bug->研发评估用时(设计、开发、测试、文档)+缓冲时间->客户讨论是否接受？->
->功能需求->研发评估用时(设计、开发、测试、文档)+缓冲时间->客户讨论是否接受？->
客户接受成本(进度、预算)->我们按计划进行调整
5.项目经理每天整理更新问题列表和待办事项列表
反思团队项目中做的好和不好的，以及以后的改进措施；
反思公司决策做的好的和不好的，如果可以影响，提出你的见解；
反思客户的关系，客户的痛点和关注的焦点，站在客户角度思考，尽可能帮客户解决困扰和难题；
6.研发工作场景模拟
情景1：研发小王同学，按照指定的项目开发计划，提交XX模块的功能，并通知测试小宋同学，让其帮忙测试下。
小宋同学，在测试的时候，发现XX模块的AA处，处理的数据不对，告诉小王同学。小王同学说，这个没有错，老大就是要求这么做的。
把研发老大叫来，说了这个情况，小宋同学说，这里不能这样处理，会影响YY模块的SS的数据，这样是有问题。
老大想了下，确实有点问题，确实不能这样处理，小王同学回去改一下，就这样我们苦逼的小王同学回去改Bug了。
可能这个场景，在大家的公司很普遍也很正常，但你会发现很多问题。来看看同样的问题，好的处理方法： 研发部门有研发计划，每个研发工程师有研发任务安排，大家都严格按照计划执行和做适当的调整； 测试部门有测试计划，每个测试工程师有测试任务安排，大家都严格按照计划执行和做适当的调整。
小王的节奏： 安排研发计划，在指定日期(2015-05-25)开始功能(模块A)的开发，完成单元测试，在指定的时间(2015-05-30)提交功能(模块A)，无需知会测试工程师进行测试，测试计划会有相关的安排，到指定的时间去测试相关功能。 提交完功能A，按计划进行，开始功能B开发。同时于(2015-06-03)登录Bug管理平台查看并修复模块A的Bug，对于Bug有歧义的地方，集中整理下与小宋同学沟通。
小宋的节奏： 按照测试计划，在指定日期(2015-05-30)开始功能(模块A)的测试，在指定日期完成一轮测试(2015-06-02)。
情景2：研发小王提交了功能A，通知小宋测试，小宋同学每测出一个Bug，就告诉小王同学，小王同学立即修改。
研发同学，期待自己不被打扰的进行软件开发工作，无论是Bug或是其他沟通事项的处理，都需要集中去处理，不能思路不断的被打断，那很痛苦且产生Bug较多。 测试同学，期待自己不被打扰的进行软件测试工作，无论来多少测试任务，也要一个个按计划去测试，客户反馈的问题，也是集中起来一起验证，除非紧急的问题。 其实，每个人工作都是一样的，都想着同性质的东西，集中一起处理，可以把精力集中在每个该处理的事情上。
7.敏捷项目管理应用
(1).软件项目敏捷应用概述：
1.迭代计划(需求拆解和风险评估)；
2.每日站会(昨天、今天、问题)；
3.每日构建(自动化编译、自动化测试)；
4.每周发布(或每日发布)；
5.每周回顾(本周交付、下周交付、整体交付)；
6.看板(整个项目维度、拉式管理)；
7.ShowCase展示(展示成效和激励、保持快节奏)；
8.Project+禅道+TFS；
9.沟通管理：面谈、电话、QQ、邮件(日报、周报)；
(2).软件项目敏捷应用具体：
1.迭代计划制定
提前一周安排出下一个迭代的计划，需要跟客户、开发经理、产品经理、测试经理，做好沟通的协调，优先考虑客户的功能交付；
进行相关需求的拆解，项目经理到模块，开发经理到功能点，评估用时和技术风险，确保一个迭代交付一个或多个有价值的功能；
把制定好的迭代计划，发送相关干系人，并约定相关人在规定的时间节点进入实施，整个迭代计划预留缓冲时间，确保在迭代结束时，按时按质按量交付。
2.每日站会执行
团队轮值主持，每个人告知大家昨天做了什么、今天要做什么、碰到的问题，简洁清晰，站会组织时间不易过长；
开发人员反馈进度、反馈技术问题、团队了解彼此的模块进度和相关接口，测试人员反馈测试进度、测试问题、了解提交功能安排测试等。
每天站立会，了解团队的计划执行情况，及时发现其中的风险和问题，及时做调整。尽早暴露、尽早处理、提高反馈速度、沟通透明化。
如：申请资源、协调资源、给予支持、沟通协调、澄清表明、技术风险等。
3.每日构建执行
借助TFS进行源代码管理，开发人员单元测试、集成测试、每日构建、自动化测试。
确保每天提交质量好的代码，每天工作都能完成，每天都能按时提交交付功能，每天提交一个版本。
减少很多功能集中提交的积压，减少集中测试的压力，减少Bug堆积的压力，减少整体功能交付的进度压力；
4.每周发布执行
每周五中午前，研发提交可测试版本，提交开发包测试部测试，并提交功能交付列表；测试部提交测试完善的产品版本，提交产品部署包，供外部客户使用。
减少很多功能集中提交的积压，减少集中测试的压力，减少Bug堆积的压力，减少整体功能交付的进度压力；
5.每周回顾执行
每周五组织迭代回顾，所有讨论基于数字和报表；
本周完成多少功能，是否与周计划匹配，有什么问题，该如何调整，改进措施，监督和度量；
查看整体交付计划，安排下周交付功能列表，及时调整，是否加人，是否加班，是否加强测试等等；
思考项目改进、团队改进、学习提高、团建活动等等
6.看板执行
从需求功能点->开发->测试->发布，便签纸移动展示，TFS面板展示，燃尽图展示，让团队了解整个项目的状况，每个人都有项目的整体意识。
提高团队的参与感、提高团队凝聚力、提高团队对项目的整体把控、提高团队沟通与协调、提高团队透明化、每个人都是主人公为团队改进献计献策；
7.ShowCase执行
ShowCase多放在迭代回顾或是周回顾的时候组织，多用数据和报表展示，业务成绩展示，团队成长展示，迭代成效展示；
主要展示团队的成绩，大家的努力成效，更好的表扬和激励，给予肯定和认可。小迭代团队组织，大迭代可以邀请领导参与，更多的形成正向激励。
本文转自SanMaoSpace博客园博客，原文链接：http://www.cnblogs.com/SanMaoSpace/p/5399867.html，如需转载请自行联系原作者
