- 最后登录
- 2012-7-23
- 注册时间
- 2012-7-20
- 威望
- 0
- 金钱
- 26
- 贡献
- 8
- 阅读权限
- 10
- 积分
- 34
- 日志
- 0
- 记录
- 0
- 帖子
- 6
- 主题
- 6
- 精华
- 0
- 好友
- 0
该用户从未签到  - 注册时间
- 2012-7-20
- 最后登录
- 2012-7-23
- 积分
- 34
- 精华
- 0
- 主题
- 6
- 帖子
- 6
|
本文版权属 cszixun所有
转载请注明: 中人网论坛- cszixun-( 链接地址:http://community.chinahrd.net/forum.php?mod=viewthread&tid=652146)
3 r3 D/ E% V4 |; T5 x0 g2 j1 {0 G( }$ c) j
一、需求调研
$ f# d) Q8 U0 G" M8 R! K8 d* G7 x
需求调研非常的重要，如果你想活下去，最终我们还是要想方设法满足用户的要求。用户是个外界因素，我们是无法控制的，那么我们只有尽可能改进需求分析的方法来尽量减少不必要的麻烦。那么我觉得日本人做法倒是可以借鉴，在有条件的情况下派专人去现场，随时记录关键性的需求，即使不能去现场也尽可能的获取尽可能多大信息，不要指望开发后去获取什么有价值的东西。那么是否应该做个原型给客户看看?我是觉得这不大合适，因为如果项目周期短的话，等你做好原型，黄花菜都凉了。但我觉得等到需求做到差不多的时候可以做用户界面，所谓用户界面就是用户接口，是和用户打交道的地方，所谓一图解千言，有了界面用户会清楚自己所买的东西在未来会是个什么样的东西，再者开发几个有说明性都界面倒是不会暂用很多时间。等到需求确定下来后就要整理成文档了，这个是很重要的一步，是做设计时候的重要凭证和依据，这个文档就是用户规格说明书，所谓规格就是有规范的格式和内容。; A. t7 k* t/ r1 L/ @- V
u6 ?1 |$ m4 J5 _ 二、需求评审
8 n, f5 w3 C# v, M6 ~) ?2 e" f, h2 i, t& L7 j
已经有了较正规的文档了，那么下一步就是召集所有开发人员开会，最好有客户代表参加，尽管我是很厌烦开会，但该开的会还是要开到，因为之前我遇到这种情况，开发人员根据设计文档写代码，可是他并不知道自己在开发什么，站在自己的角度想一下，如果自己都不确定自己做的东西，即使有再完备的设计，也会对开发毫无兴趣，只会让自己觉得自己是个代码机器。所以所有人员参加需求评审是让大家知道自己在做一件有意义的事情，自己正在满足社会的需要，自己在为和谐社会做贡献，即使你从没那么想过，那你敢保证的你的潜意识没那么想过吗?人是要有社会满足感的吧。另外开会前一定要准备关键有价值的议题，据观察需求评审会最容易扯到不着边的话题，所以主持人要控制话题，会议控制在2-3个钟头，最好做成幸运52的形式，所有人员一定要互动起来，否则就变成了个人演讲。需求也做了，会也开了，那么要求客户签字吧。/ h m+ D5 m I1 j" v2 G2 f: R1 p0 G
( a$ G& q0 r7 H# K
三、需求管理6 }4 a7 j8 k) k# c
1 V0 P& ]/ W e5 L: ?
需求管理是在开发开始之后进行的，这也是另所有人头疼的一件事，之前做完一个项目后，客户经常打电话找我们。后来转念一想，难道这种情况真的不能避免吗?至少是可以大幅度的缓解的吧。这就是我们需求管理中的变更管理没做好，改了哪些地方自己都忘记了，最后是跟着感觉走，拆东墙补西墙。在这里我建议要建立需求跟踪矩阵表，有了这个表我们至少可以对要修改的地方有了依据，迫使我们去调查到底是改什么地方，怎么改，最后改成了什么样。可能你会说客户需要大幅度修改原有计划，很难跟踪到具体某一项需求，那么我觉得这是由于前期的需求开发没有做好，在后期客户进行实质性的修改的几率是很小的，比如客户要求我们做个OA系统，最后总不会要我们改成个门户网站吧。
0 v$ \ X: \- Z. d 更多关于项目管理的方法在长松咨询网。 |
|
窥视卡
雷达卡
发表于 2012-7-23 16:33:33
转播
淘帖
分享
收藏
支持
反对
@朋友
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
学习
支持