查看原文
其他

你的需求是怎么描述的?

2017-06-29 老刘 码农翻身
1  领导口述型


张大胖一边心猿意马地Coding, 一边听着领导在电话里“卑躬屈膝”,”奴颜媚骨”地讨好客户 : “好的,李总,我明白你的要求了!  下周一上线? 嗯.... 没问题 , 我们开发人员的素质绝对一流,请您一定放心!“


打完电话, 领导转头就对大胖说: “紧急任务,下周一上线,审批流程中第二步和第三步需要合并, 另外李总需要真实笔迹, 想在App端支持手写功能。”


“手写功能我没做过啊” 张大胖说


“还不赶紧学!”


“服务器端还得存储手写审批的图片呢!”


“快把小李叫过来, 你们俩坐一起,攻关一下”


费了九牛二虎之力, 张大胖把审批流程中的第二步和第三步合并了, 可是领导回过头来就是一句:“李总又说了, 还是两个步骤分开好一些, 我们rollback 吧。 手写功能怎么样了, 什么? 还没开始? 抓紧啊!”

2 稀里糊涂型


“走,大胖,今天跟我去参加一个需求交流会,王总亲自和我们交流。”


张大胖挺不乐意去的, 这个王总是个国企信息部门的领导,懂一点点计算机技术,自以为是。


你不懂计算机或者精通计算机都行,就怕这样懂一点点的半吊子,总是喜欢想象一下,再发挥一下,认为软件很简单: “不就是读取后台的数据库嘛? 有什么难的? 我也学过,别想蒙我! ”


更要命的是,需求澄清的时候,王总从来都是高谈阔论,一个会议他自己都能说2个小时,只说愿景和战略,夹杂着自己对计算机的理解, 很少能见他倒出来一点需求的干货。


可悲的是作为乙方,大胖还得附和着,频频点头表示认可, 努力领会领导意图。


张大胖只好在会后问王总手下的人, 这些人知道细节,但是却没有决定权: “这是我个人的想法啊,不一定对, 你去问问王总去”


张大胖不敢去, 因为一去就被骂: “你们是怎么搞的, 我在会上不是说过这个问题了吗,还没听懂?   这样吧, 下周再开个需求会议!”


下周的需求会议依然照旧。 三个月过去了,需求还是朦朦胧胧的一片。


王总说: “你们先开发一个版本,让我们看看!”


第一个版本出来了, 被很批了一顿。


第二个版本出来了, 继续批。


底层的数据库表被改来改去,开发被折磨得一点脾气都没有了。


神奇的是, 这个项目某一天竟然成功的交付了, 王总凭借这个项目还获得了集团的奖励!


当然这个项目是没人用的。

3事无巨细型


张大胖的公司接了一个日本的项目, 看看人家发过来的需求, 哇塞,100多页,这Use Case写得多么详细啊 !  每一步什么人做什么事情清清楚楚、明明白白、真真切切。


类图,顺序图一个都不能少,那叫一个漂亮。


还有这界面画得简直和成品一模一样啊,啧啧, 这像素, 简直是拿着放大镜画出来的。


这伪代码,写得真是详细,稍加翻译就可以变成程序了, 真是只差一个码农了!


听说他们为了整出这套文档就花了整整一年的功夫, 张大胖在翻译伪代码的时候老是想: 花了这么长时间整需求, 他们怎么不直接把软件给写出来呢? 还有,万一这需求错了该怎么办啊?


4 口述+界面原型


大胖, 我们到会议室去开个会,讨论下这个版本的新需求


开发,测试, 美工 济济一堂, 经理把这个版本的需求概要地说了一遍,然后就打开小梁设计好的界面原型讲了起来。


界面原型是个好东西, 非常直观, 一看就知道到底要做成什么样子, 页面之间的跳转关系也一目了然。


张大胖一边听,一边心里琢磨着这个数据库表该怎么设计, 表该怎么改,怎么做数据迁移,界面的流程该怎么跳转, 后台需要提供什么样的服务...


大家叽叽喳喳的讨论了一个下午,终于安静了。


看到大家的理解基本一致了, 经理开始做最后的总结陈述:

"怎么样? 还有问题吗?  没有问题的话小梁按今天讨论的把界面修改一下, 大家估算一下自己的工作量,下班之间报到我这里。"


张大胖心想,估算也没啥用, 反正上线日期都确定了。


需求知识进入了各自的脑海, 而没有进入文档。


5 客户参与型


这个项目有点意思, 采用了敏捷软件开发的思想。


张大胖欣喜地看到, 精通业务的客户代表竟然入驻了项目组,和大家一起吃饭,一起上下班。


刚开始的时候, 需求以用户故事的方式描述了出来,简单得不能再简单了,就是从用户的角度来描述用户渴望得到的功能 ,格式如下: 作为一个<角色>, 我想要<活动>, 以便于<商业价值>  , 但是大家都看不习惯。 后来干脆不要求具体是什么形式了, 只要把需求的业务价值体现出来, 简单明了就可以。


客户能深度参与到开发中真是太爽了, 有了问题随时提出,很快就得到解答。  


对于界面应该是什么样子, 张大胖经常和客户一起在白板前写写画画, 很快就达成了一致。 有时候还需要美工出马, 做出Web界面或者App界面让开发使用。


项目采用迭代的方式,每两周交付一个版本, 客户代表会帮助做验收测试,保证项目不会偏离方向。


由于有客户的参与, 项目极大地减少了沟通的成本,减少了浪费, 客户代表能告诉你哪些需求最重要,优先级最高,一定要先做,哪些可以往后放,最后有些需求真的被砍掉了。


在这种氛围下工作,大家的心情都很舒畅, 最后项目上线虽说晚了两周, 但是客户非常满意, 他们得到了他们想要的系统。


后记:以上这五种情况是我的亲身体验或者是朋友的经历, 需求的描述多种多样, 不同的项目类型、管理风格会导致天壤之别,大家的项目是怎么描述需求的? 欢迎留言!


你看到的只是冰山一角, 更多精彩文章,请移步《码农翻身文章精华


有心得想和大家分享? 欢迎投稿 ! 我的联系方式:微信:liuxinlehan  QQ: 3340792577


码农翻身

用故事讲述技术本质

微信号:coderising


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存