折磨程序员的五类需求描述
1.领导口述型
张大胖一边心猿意马地Coding， 一边听着领导在电话里“卑躬屈膝”，”奴颜媚骨”地讨好客户 ： “好的，李总，我明白你的要求了！ 下周一上线？ 嗯…. 没问题 ， 我们开发人员的素质绝对一流，请您一定放心！“
打完电话， 领导转头就对大胖说： “紧急任务，下周一上线，审批流程中第二步和第三步需要合并， 另外李总需要真实笔迹， 想在App端支持手写功能。”
“手写功能我没做过啊” 张大胖说
“还不赶紧学！”
“服务器端还得存储手写审批的图片呢！”
“快把小李叫过来， 你们俩坐一起，攻关一下”
费了九牛二虎之力， 张大胖把审批流程中的第二步和第三步合并了， 可是领导回过头来就是一句：“李总又说了， 还是两个步骤分开好一些， 我们rollback 吧。 手写功能怎么样了， 什么？ 还没开始？ 抓紧啊！”
2.稀里糊涂型
“走，大胖，今天跟我去参加一个需求交流会，王总亲自和我们交流。”
张大胖挺不乐意去的， 这个王总是个国企信息部门的领导，懂一点点计算机技术，自以为是。
你不懂计算机或者精通计算机都行，就怕这样懂一点点的半吊子，总是喜欢想象一下，再发挥一下，认为软件很简单： “不就是读取后台的数据库嘛？ 有什么难的？ 我也学过，别想蒙我！ ”
更要命的是，需求澄清的时候，王总从来都是高谈阔论，一个会议他自己都能说2个小时，只说愿景和战略，夹杂着自己对计算机的理解， 很少能见他倒出来一点需求的干货。
可悲的是作为乙方，大胖还得附和着，频频点头表示认可， 努力领会领导意图。
张大胖只好在会后问王总手下的人， 这些人知道细节，但是却没有决定权： “这是我个人的想法啊，不一定对， 你去问问王总去”
张大胖不敢去， 因为一去就被骂： “你们是怎么搞的， 我在会上不是说过这个问题了吗，还没听懂？ 这样吧， 下周再开个需求会议！”
下周的需求会议依然照旧。 三个月过去了，需求还是朦朦胧胧的一片。
王总说： “你们先开发一个版本，让我们看看！”
第一个版本出来了， 被很批了一顿。
第二个版本出来了， 继续批。
底层的数据库表被改来改去，开发被折磨得一点脾气都没有了。
神奇的是， 这个项目某一天竟然成功的交付了， 王总凭借这个项目还获得了集团的奖励！
当然这个项目是没人用的。
3.事无巨细型
张大胖的公司接了一个日本的项目， 看看人家发过来的需求， 哇塞，100多页，这Use Case写得多么详细啊 ！ 每一步什么人做什么事情清清楚楚、明明白白、真真切切。
类图，顺序图一个都不能少，那叫一个漂亮。
还有这界面画得简直和成品一模一样啊，啧啧， 这像素， 简直是拿着放大镜画出来的。
这伪代码，写得真是详细，稍加翻译就可以变成程序了， 真是只差一个码农了！
听说他们为了整出这套文档就花了整整一年的功夫， 张大胖在翻译伪代码的时候老是想： 花了这么长时间整需求， 他们怎么不直接把软件给写出来呢？ 还有，万一这需求错了该怎么办啊？
4.口述+界面原型
“大胖， 我们到会议室去开个会，讨论下这个版本的新需求”
开发，测试， 美工 济济一堂， 经理把这个版本的需求概要地说了一遍，然后就打开小梁设计好的界面原型讲了起来。
界面原型是个好东西， 非常直观， 一看就知道到底要做成什么样子， 页面之间的跳转关系也一目了然。
张大胖一边听，一边心里琢磨着这个数据库表该怎么设计， 表该怎么改，怎么做数据迁移，界面的流程该怎么跳转， 后台需要提供什么样的服务…
大家叽叽喳喳的讨论了一个下午，终于安静了。
看到大家的理解基本一致了， 经理开始做最后的总结陈述：
“怎么样？ 还有问题吗？ 没有问题的话小梁按今天讨论的把界面修改一下， 大家估算一下自己的工作量，下班之间报到我这里。”
张大胖心想，估算也没啥用， 反正上线日期都确定了。
需求知识进入了各自的脑海， 而没有进入文档。
5.客户参与型
这个项目有点意思， 采用了敏捷软件开发的思想。
张大胖欣喜地看到， 精通业务的客户代表竟然入驻了项目组，和大家一起吃饭，一起上下班。
刚开始的时候， 需求以用户故事的方式描述了出来，简单得不能再简单了，就是从用户的角度来描述用户渴望得到的功能 ，格式如下： 作为一个<角色>, 我想要<活动>, 以便于<商业价值> ， 但是大家都看不习惯。 后来干脆不要求具体是什么形式了， 只要把需求的业务价值体现出来， 简单明了就可以。
客户能深度参与到开发中真是太爽了， 有了问题随时提出，很快就得到解答。
对于界面应该是什么样子， 张大胖经常和客户一起在白板前写写画画， 很快就达成了一致。 有时候还需要美工出马， 做出Web界面或者App界面让开发使用。
项目采用迭代的方式，每两周交付一个版本， 客户代表会帮助做验收测试，保证项目不会偏离方向。
由于有客户的参与， 项目极大地减少了沟通的成本，减少了浪费， 客户代表能告诉你哪些需求最重要，优先级最高，一定要先做，哪些可以往后放，最后有些需求真的被砍掉了。
在这种氛围下工作，大家的心情都很舒畅， 最后项目上线虽说晚了两周， 但是客户非常满意， 他们得到了他们想要的系统。
后记：以上这五种情况是我的亲身体验或者是朋友的经历， 需求的描述多种多样， 不同的项目类型、管理风格会导致天壤之别，大家的项目是怎么描述需求的？ 欢迎留言！
你也许感兴趣的：
- 【外评】80% 的开发人员不开心
- 【外评】如何判断自己已成为高级程序员
- 【外评】如何成为最优秀的程序员
- 【外评】程序员大神每天什么都是时候工作？
- 【译文】在 Meta 工作 12 年：回顾我参与的所有项目
- 【译文】每个开发人员都需要问自己的一个问题
- 【译文】程序员工作很累，但 70% 的程序员在周末休息时以写代码为乐
- 【译文】我是一个糟糕的程序员
- 在技术圈逢凶化吉，靠的居然不是技术？Altman 晒出17条年终总结，人际关系占首位
- 【译文】加密货币交易平台FTX审判，第四天：欺诈在代码中
你对本文的反应是：