2015年某问题项目的解决措施

解决方案

一级任务	二级任务	要求	对应领导的期望	交付物	预期控制的风险
1.完成产品的功能审计	——	梳理出目前确定的产品各个功能模块需求、设计、编码、测试哪些做完，哪些没有做完。即使做完的模块还有哪些问题。		《产品成熟度表》 作用：明确产品开发工作的目标，为下一步工作制定计划提供依据。	1.项目目标缺失，团队工作没有重点。 2.产品状态对项目组内外不透明，造成打乱仗。 3.争取获得最终能够获得产品成功的资源。
2.编制项目的产品集成计划	a)按照业务的逻辑顺序， 排出客户最优先需要完成的功能，确定迭代的项目范围。	和AAA梳理出业务开发的先后 顺序，切分系统功能。	产品和项目范围的“切分”。	《产品集成计划》 作用：时间花在客户最关切的功能实现上，项目过程重新受控。	齐头并进赶进度，开发工作各自为政，产品零零散散，不可交付，客户压力增大 。
	b)以一至两周为小迭代的周期，规划产品集成的顺序和版本。	在两周范围内，规划好开发完成哪些功能，以什么样的开发质量要求交付给测试，形成稳定的产品版本。			缩小产品的范围使项目管理环境简单化，暴露使得项目团队生产率低下的问题，及时处理，给团队减压。
	c）确定产品集成过程中的产品编码和测试的版本管理。	1.将和BBBB达成一致的代码版本管理方案文档化，制定分支命名规则，启用产品命名规范。 2.开发和测试过程稳定化，使过程受控。 3.配置管理的方案必须落地到项目组。		《代码版本配置管理计划》	1.开发过程中没有可用版本进行交付。 2.测试的版本不停改动，没有稳定版本。 3.解决中间产品多版本的问题。
	d）重新排定项目的进度计划	1.确定每个代码版本的预期完成时间，版本完成后如何与客户进行沟通和交流。 2.要有一个月内进一步的人员工作任务安排。		《迭代二项目进度计划》	解决项目各个人员不知道如何 协作，工期不明确的问题。
	e）形成集成测试的初步测试方案	1.熟悉每个开发版本的业务功能，确定测试的重点。 2.制定出测试分工的工作清单，比如开发人员能够自测什么，出现最多的bug是什么，做好预防；QA和质量部的人员能够帮助做哪些简单测试。 3.制定不同版本产品的发布条件	充分调动项目组人员和组外人员参与测试，减少测试人员个人工作压力。	1.XX项目特殊的《集成测试用例》； 2.常规测试工作的用例，形成一个清单并的推广，纳入公司的财富库； 3.不同版本的集成测试发布标准； 4.BUG预防清单；	1.测试人力不足，做好资源利用最大化的工作计划。 2.防止测试人员过度测试，影响项目的进度。
3.配置管理方案的落实	a)组织项目组人员培训	1.对配置管理方案认可，没有没听懂的人员。		培训确认单	对配置方案不熟悉，无法执行
	b)测试环境的搭建。	1.保证建立起EOS的测试产品部署环境，软件硬件和网络安装到位。 2.弄清产品部署的规则和方法。		可用的测试系统	测试与开发环境不分离，测试被 开发牵着鼻子走，测试没有效果和尽头。
	c)集成计划的版本开发监控	1.保证代码分支的建立和代码及时修改，确保分支正常发布。		代码版本的分支	配置管理方案缺乏实践的检验和监督。
	d）测试版本的获取检查	1.保证代码从分支中获取		从分支获取的构建部署包	避免测试人员直接从主干上获取 代码，引起版本混乱。

 

客户需求开发优先级排序

（以十分制打分为原则,综合得分高开发顺序优先）
	技术实现难易	客户价值	客户进度要求	业务逻辑 先后顺序	KPI项	比例	模块开发 顺序得分
模块1	7	8	7	10	技术实现难易	25%	7.8
模块2	5	4	6	8	客户价值	20%	5.75
模块3	8	8	4	3	客户的进度要求	35%	5.6
模块4	4	6	3	5	业务逻辑顺序	20%	4.25
模块5	3	7	6	4	比例合计	100%	5.05
模块6	4	6	3	5			4.25
模块7	4	5	2	7			4.1
模块8	6	7	8	4			6.5
模块9	4	3	2	7			3.7
	人工打分	人工打分	人工打分	人工打分

软件版本计划

问题项目管理工作

周一		周二		周三		周四		周五
会议 10分钟	新项目任务计划通报	代码检查 30分钟	工作流模块化改进	代码检查 30分钟	统一数据库命名规范（10条）	代码检查 30分钟	统一工作流调用方式	代码检查 30分钟
	周评审会议结果通报		技术复用评估		统一注释规范（10条）
	问题反馈		统一UI界面管理（10条）		统一编码规范（10条）
16:30 检查日工作情况	取样工作成果并记录	16:30 检查日工作情况	取样工作成果并记录	16:30 检查日工作情况	取样工作成果并记录	16:00 检查日工作情况	取样工作成果并记录	项目汇报 30分钟	进度、风险、控制措施
	收集工作问题并记录		收集工作问题并记录		收集工作问题并记录		收集工作问题并记录
	检查风险并通报		检查风险并通报		检查风险并通报		检查风险并通报
17:00	可用代码提交SVN	17:00	可用代码提交SVN	17:00	可用代码提交SVN	17:00	一周工作总结	17:00	可用代码提交SVN

 

SVN使用规范计分表

序号	分数项	分值	次数	单项合计	计分方式	执行标准
1	按时保质，提交项目文档到正确的目录	3	0	0	直接加分	每个项目每星期抽查，项目结束后加分
2	使用自动化代码下载、编译、部署方式实现集成构建	5	0	0	直接加分	每个项目每星期抽查，项目结束后加分
3	能够有效使用分支，且分支有实际意义	3	0	0	直接加分	每个项目每星期抽查，项目结束后加分
4	日志填写完整且清楚明白	2	0	0	直接加分	每个项目每星期抽查，项目结束后加分
5	代码产品做迭代计划分出产品版本	2	0	0	直接加分	项目计划中检查
6	使用文件冲突解决方式处理文件版本	3	0	0	直接加分	每个项目每星期抽查，项目结束后加分
7	项目成员在本地进行代码产品测试	3	0	0	直接加分	每个项目每星期抽查，项目结束后加分
8	代码始终在trunk和branches中开发	5	0	0	直接加分	每个项目每星期抽查，项目结束后加分
9	无日志注释，建立没有实际意义的branch和tag	-1	0	0	分值X次数	每个项目每星期抽查，发现后扣分
10	日志中填写跟提交内容无关的信息	-1	0	0	分值X次数	每个项目每星期抽查，发现后扣分
11	没有按照目录命名规范进行命名	-1	0	0	分值X次数	经1次提醒后拒绝改正，执行扣分
12	提交不稳定的代码到tag下面	-1	0	0	分值X次数	每个项目每星期抽查，发现后扣分
13	直接通过服务器硬盘上提交代码文件，绕开SVN管理，覆盖他人代码	-1	0	0	分值X次数	经1次提醒后拒绝改正，执行扣分
14	提交无法编译通过的代码到SVN	-1	0	0	分值X次数	经1次提醒后拒绝改正，执行扣分
15	上传超过10M以上与参与项目无关的文件到SVN	-1	0	0	分值X次数	每个项目每星期抽查，发现后扣分
16	无任何理由，代码3个工作日内不提交SVN	-2	0	0	分值X次数	以每次发现后的3日重新计算次数
17	提交病毒程序到SVN	-5	0	0	直接扣分	每个项目每星期抽查，发现后扣分
			总分：	0