项目绩效考核体系执行简述
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，如需转载请自行联系原作者