[讨论] 什么是敏捷之道
 |
dandan_5956
2010-08-11
最近在做内部业务支撑系统，感觉效率太低了，用户提出一个需要，到用户能用到这个功能，要经历多少个步骤？要经多少个人？来看看吧
业务部门丽丽觉得自己整理Excel很痛苦，告诉开发部门需要做一个系统来整理Excel，开发部门需求人员开始跟丽丽接触，将丽丽的想法转换成需求，需求人员整理成用户需求文档，半个星期过去了，项目经理拿到用户需求文档，仔细看了，发现很多地方不合理，跟需求人员交流，需求人员又跟业务部门丽丽交流，你来我往，最后确定了需求，又一个星期过去了，项目经理开始画界面原型，通过界面原型和需求文档同组内的开发人员交流，最后编写出了静态页面，一个星期过去了，接着，开会，业务部门丽丽，需求人员，开发人员都在，丽丽看了静态页面的展示，觉得能行，就OK啦，接下来就开始编程实现，花了2个星期，交给测试组测试，改改BUG，又花了一个星期，最后，交给维护组部署上线，终于可以和用户见面了，用户一用，XX的Excel的YY字段本来是要填多个，诸如此类的问题，总结新的需求，重复上述的步骤。 是用户很难伺候，想法很多，其实不是，而是开发人员难以获取到用户想法，用户想法传递都是通过文档，中间经历这些人，难免有信息失真，再说用户很多时候只有一个概念，想让他们一开始就明确需求，天方夜谭，只有当程序做出来，用户一用，用户才能明了他们的想法，发现程序操作和他们想法有出入，这都很正常。 问题关键在于：开发人员同用户之间的交流不顺畅，信息传递，中间有太多不必要的环节。从用户有了想法，到开发人员了解用户的想法，中间有需求人员，项目经理，大都通过该死的文档来传递信息，再看，系统开发完毕，到用户使用，中间有测试人员，维护人员，稍微改个什么东西，又要测试来测试，又要维护来部署。为何不让开发团队和用户直接交流，需求人员整理需求文档就有用吗，测试组测出的BUG就那么严重，部署还要维护来做，开发不会做，版本号就那么重要，这就是规范，自己折腾自己。 开发，部署，用户用，用户用得不爽，改，再部署，用户再用，其实就这么简单。 |
 |
shen5277
2010-08-11
调研的时候调研人员和客户的意思难免会有误差，还有一种就是客户改需求，不过相对第二种来说，第一种还真够恶心的
|
 |
liangzhian0620
2010-08-13
这个问题其实就是一个怎么获取用户真实需求，就比如你在一家餐厅里吃饭时，口渴了想喝水，就让服务给你一杯冰水，可是等了半天服务员都没有把冰送来，又把服务员叫过来问他为什么还没有把冰水送了，服务员说：先生对不起我们的冰决用完了，现在正在做冰块，可能再过10几分钟就好了，这时你心里就会不很舒服。
其实这个例子中你向服务员要一杯冰水，就是你向服务员提出的需求，但你真实的需求是口渴，想要一怀水解渴，并不是非要一怀冰水，矿泉水也可以。而服务员也没有明白你的真实需求，也没有更进一步的去了解你的需求，所以导致了让你等了很长时间都没有解决口渴这个问题。 所以我觉得调研人员就好比这个服务员，怎么去了解用户的真的需求是非常重要。 |
|
dandan_5956
2010-08-13
开发团队和用户交流是否顺畅对于需求获取至关重要
|
 |
系统程序
2010-08-14
liangzhian0620 写道 这个问题其实就是一个怎么获取用户真实需求，就比如你在一家餐厅里吃饭时，口渴了想喝水，就让服务给你一杯冰水，可是等了半天服务员都没有把冰送来，又把服务员叫过来问他为什么还没有把冰水送了，服务员说：先生对不起我们的冰决用完了，现在正在做冰块，可能再过10几分钟就好了，这时你心里就会不很舒服。
其实这个例子中你向服务员要一杯冰水，就是你向服务员提出的需求，但你真实的需求是口渴，想要一怀水解渴，并不是非要一怀冰水，矿泉水也可以。而服务员也没有明白你的真实需求，也没有更进一步的去了解你的需求，所以导致了让你等了很长时间都没有解决口渴这个问题。 所以我觉得调研人员就好比这个服务员，怎么去了解用户的真的需求是非常重要。 我的看法是软件行业和传统服务行业还是有较大差异的，例如这个服务员正确的做法是在发现没有冰的时候应该去问客户是等冰块还是换其它的，但是在软件行业，我的意见是要了解客户的目的，而不是让客户提出解决的方法，客户说Excel表的时候，需求分析人员应当去了解他关心的是哪心数据，而不是表格本身，能够处理好那些数据就行了，而不在于是Excel还是别的什么报表工具 |
