一页纸项目流程管理-20130516

今天在编写项目的测试报告时，列举所有的模块，然后在列举模块下的功能。需要对项目进行简介、模块进行说明，功能进行描述。
在整体查看功能图，发现串联问题不大，知道整体的流程应该如何流转，下一个节点应该如何操作也很清楚。但是早描述每个功能里包含哪些提交功能、关联控制时，发现了问题。
当系统越复杂问题也就暴露的更多。项目做完了，回过头来看，原来以前有好多地方、好多设计、好多控制点可以取消，存在有好多争议的地方。在使用时有争议的功能，一定在设计、开发、测试之间的争议很大。回头总结很重要，更重要的是应用在项目的过程中，如果只是项目结束后做了总结，而在执行过程中，不做更正，那么总结也就流于形式了，没有什么意思了。
一些编写功能说明，一边我就联想系统之间的控制点，突然发现，我们缺少的是一个大的业务流转图，要很细，应该包含几点：
1、整体流程的流转：系统的整体流转
   举例：绩效考核系统，包含三大节点，合同制定->考核->激励，系统围绕三个节点来设计，先合同制定完成，然后根据绩效合同来进行员工的考核，考核完成后，考核结果用于激励模块的应用。每个节点的结束输出作为下个节点的开始输入。
2、系统大流程节点下的小流程：细化到小流程的状态即控制点
   举例：合同制定有个小流程，需要绩效专员来制定，领导来审批。
3、大流程和小流程融合到一张图里，以大流程为主线，各个节点的流转中，把小流程合并进去。

在实际的项目开发中，各种大流程和小流程的流程图很多很多，PM会绘制很多的流程图来保障系统的正常流转，保证没有设计上的死角，完成客户的业务需求。PM对系统的流转很清楚。最大的问题在于，开发和测试人员不清，开发领到任务去开发时，只是知道小点，根据当时设计文档上的控制点1，2，3来完成了，但是1，2，3控制点在系统中如何测试呢，不知所以然。所以相对应的Bug就来了。返工就多了，工时就浪费了。

更重要的是，开发人员没有了整体把控观念，开发人员不能很快的发现设计的缺陷，不能起到旁观者清的角色，去提醒PM，这样做很复杂，那样做更简单高效。NO。

目前比较流程一页纸项目管理，同时也更适合于移动设备的观看，拖拖拉拉就可以看全了，而且一目了然。所以，我命名为一页纸项目流程管理。

所以，下个项目中，要实施一页纸流程管理，来验证一下能否在项目的开发过程中，起到良好的效果。