欢迎进入微简园地
开放的舞台
[微简法]当前用户2017/3/16 9:50:10

微简甲方原则

信息化飞速发展的今天,大多数单位都经常有软件定制开发项目。项目过程中,通常由信息中心负责,相关业务部门配合需求,专业的软件公司负责开发。然而,因为信息中心人员不懂业务,业务人员不懂开发,负责开发的软件公司通常也不懂业务,所以整个项目中碰到的问题非常多。以下是经常碰到的问题:

1. 项目做完之后才发现不是自己要的。

2. 到最后验收前才能试用系统,发现的问题没时间修改,只能放到二期。

3. 项目时间过半了,什么也看不到,也不知道做的怎么样了,心里空落落的。

4. 进度无法控制,只能看PPT进度汇报,具体也不知道怎么样。

5. 文档、PPT写的很好,最终做出来却不是那么回事。

6. 业务人员听不懂开发人员在说什么,开发人员也听不懂业务人员在说什么。

7. 业务人员提需求的时候很笼统,开发人员做出来总不是一回事。

8. 很多多余的功能,业务人员抱怨操作麻烦。

9. 很多隐含的需求没有想到,最后验收的时候才发现。

10. 总是在后期不断的修改需求、增加功能。很多时候也不是很清楚系统到底要做些什么。

11. 项目风险高,政治风险也高。领导的期望很高,但无具体要求。

12. 出了问题后,相互推卸责任,扯皮的事非常痛苦。

这些问题怎么解决呢?有没有简单、容易操作、有确实有效的方法呢?我们推出了一套极其简单的模式,可以很轻松的解决这些问题。

原理很简单,就是从项目开始就先做界面,前期需求以界面为主进行沟通,需求阶段就完成绝大部分界面。想象一下,业务人员本来也不是很清楚自己要什么,提需求的时候也很笼统,而看到界面之后,业务人员的兴趣马上就来了,就可以积极主动的提出更具体、更准确的需求细节,操作方面也可以从一开始就修改的很舒服。开会的时候,大家看着界面来讨论问题,也就非常具体,非常形象,不会再有沟通上的歧义。

前期项目进度不好控制,用这个方法就很容易了。计划有几个业务模块,每个模块有哪些界面,哪些做了,哪些没做,一看界面就清清楚楚。那部分需求理清楚了,那部分还没有做,一目了然。把界面原型作为需求阶段的考量,可以非常具体的知道项目的进展。

这样,甲方人员就可以从头到尾清清楚楚、明明白白的知道系统是什么样,是不是自己要的。也就可以完全避免“做完后才发现不是自己要的”的问题。有问题也可以在项目早期发现并及时纠正。

基于这个原理,微简提出了“微简开发方法”,同时还提出了“微简甲方原则”,前者是给软件公司用的,后者是给甲方用的。作为甲方,可以全部或部分的应用“微简甲方原则”来管理项目、约束乙方。它是第一套专门为甲方制定的开发管理准则,目的是保证甲方从头到尾清清楚楚的控制好项目。

以下是“微简甲方原则”的具体内容:

1、从头到尾我们都要看到系统的界面,以界面为主进行沟通。

2、需求开始我们就通过界面模拟来体验、试用,并及时提出修改意见。

3、我们尽量努力做到需求不变。

4、系统要简单、实用,不要搞的太复杂。

5、增加工作量的功能我们不要,够用就行了。

6、不要只用PPT来应付我们,我们要有实际意义的结果。 

7、很多时候我们也不是很清楚要做什么,需要你们引导我们。