WEB 开发中需求流程的狂想

AMD-K6

已经排版好的文档请参看： http://www.gracecode.com/article ... %E7%8B%82%E6%83%B3/

Gracecode.com 原创文档，请您务必保留此段信息。


前言
相对于传统的软件开发模式，WEB 开发是一种及其快速的软件开发模式。经历了将近一段时间的 WEB 开发，我的开发思路比以前更加的透彻。但是期间暴露出了很多的问题，特别是在软件功能的前期分析、需求模式的提出、开发流程的规范化等方面有着传统软件开发未暴露出的更多问题。由于软件需求在软件开发中起着非常重要的作用，在这里对于 WEB 开发模式中软件需求的相关问题提出来和大家探讨一下（可能语气过于激进甚至可以说是 BT ，请各位读者自行辨别）。

迂回、还是痛苦的迂回！
“Hi，手气不错~是的，用户调查那块我决定还是做成用户必选的吧。虽然目前已经可以使用，但是如果每个用户都不填写我们的用户调查，那么我们几乎无法获得用户到底再想什么了。”

“好的，但是~我说的是万一，如果做成必选的话，那么用户会不会觉得厌烦呢。技术上不是问题，但是考虑到用户习惯，并不是每个用户都喜欢这样的调查的。他们只想看一下我们的网站有什么内容而已……”

“可以的，如果有用户提出来这样操作太烦琐的话，我们再改回来就是。”

“好吧、好吧~ 但愿如此，我也希望这个是我开发完成以后的最后一次功能性调整了。”

是的，相信上面的谈话每个做软件开发的人都碰到过。但是我们缺在强大的用户需求面前显得是如此的渺小：我们能左右服务器的运行状态，但是却无法得知我们正在 coding 的代码最终的功能是什么。而需求的提供方也不知道，到底用户需要怎样使用我们的网站才能感到非常的满意。

而最终状况就是，作为我们 WEB 开发者一边不停的在开发新的系统功能、而一边却要修改目前已经完成的功能。 是的，这是一件非常恐怖的事情。

但是这样的事情确实是发生了。

而需求的提出方此时也对用户的种种“不合理”的需求感到非常的混乱：到底是放弃我们的市场统计数据让用户“充分自由” 地浏览我们的网站，还是填满整整 N 页的市场统计数据好让自己的总结报告让自己的上司感到一丝安慰？

是的，其实无论作为开发者的我们、还是作为需求提供方，我们都在痛苦的迂回中徘徊。

出路在哪里？
难道一直让这种痛苦的状况延续到我们的年度总结？!相信无论是哪方，都不愿意将这样的状态给延续下去。

OK,让我们偷个懒带上耳机仔细想想我们目前的问题在哪里。相信解决了这个问题你的上司也会偷偷的笑的。

首先，作为需求的提出方，我们需要想想为什么我们总是那么频繁的提出需求性的更改；而令一方面我们又在苦苦的等待原本未完成的需求却迟迟的没有实现？然后，作为我们开发者的角度想想，为什么我们频频的更改已经完成的功能，却苦于无法应付接下来我们需要去做的下一步的功能开发。

其实出现这样的问题一个非常常见的问题就是我们忽视了用户使用角度上的体验。所谓的用户体验，并不仅仅指的是页面的美观，按钮有多漂亮，图片有多震撼视觉；最要紧的是我们的用户在操作使用我们的网站的时候有没有感到盲目。正如上面对话中所说的：不是每个用户都喜欢用户调查的。但是用户为什么那么讨厌那“该死的”的用户调查？那是因为用户在操作网站实现自己的“目的”的时候却突然跳出一个“该死的”用户调查（是的、是的，我已经说过两遍那个“该死的”了）。

而需求方却对此耿耿于怀：如果用户都不回答那些该死的用户调查，那么我们就无法提供给我们的上司这次的统计数字了！

是的，是的（噢，我都被双方都搞得头晕了），让我们这些做程序的说服你们为什么需要这样做把，请允许我们使用流程图来解释一下需求修改前和修改后的流程：



对比两张图，我们可以很清楚的认识到：如果用户不填写那“该死的”调查报告的话，那么他可能永远都无法实现其使用该功能的根本目的。于是用户就急躁不安，“为什么在我办正经事的时候打断我，你不知道这样对我来说有多么不礼貌吗？”。

好吧，好吧。我们需要更“优雅”的方式解决我们三方的问题。我们程序员再次带上耳机寻思出路，三曲听罢、灵光乍现，迅速画出了下面的流程图：


似乎这样看起来就能解决问题了，将用户调查放在用户实现“目的”以后。但是这样需求方就有很多的怨言了：如果用户不填写那些对于我们来说非常重要的调查报告呢？“OK、OK 是的，但是如果您认为您能相信用户急着完成其目的的时候胡乱填写的数据吗？而目前这样的安排也可以让用户在完成了其目的以后的确有点事情可以做做，不至于那么无聊拨您的电话查询您的生日。” [p]是的，我们完全有理由相信这样的流程产生的调查报告是相对真实的。因为此时用户已经完成了他最紧迫的功能需求，而且正“闲着” 没有事情可以做。

以上是针对一个具体的功能需求提出的解决方案。虽然是一个具体的需求更改的例子，但是从中可以看到很多典型的问题。请让我按照这三张不同的路程图分别阐述。

第一张图我们可以理解成完全为用户体验考虑的结果，是的如果真的这样的话需求方的人得晒太阳去了：他们完全得不到用户调查数据。而此时用户完成其“目的”期望值很高，因为在完成“目的”的过程中没有碰到任何的阻碍。

第二张图简直可以说是用户是需求方的噩梦！需求方或许可以在短期内获得巨大数量的用户调查统计数字，但是这些数字并不是非常准确的：有些用户可能为了继续完成其“目的”而将调查报告乱填一气，而更多的用户则选择放弃。所以这样造成的结果就是用户调查数据可能在短期内居高，然后迅速下降。而用户“目的”的成功完成的期望则是越来越低。

第三张可能是相对前两张最符合双方口味的流程了。用户也完成了他们在我们网站的功能目的，而需求方也能相对准确的得到用户的统计数字：即使相对第二种方法得到的统计数字从量的方面上要小很多。

现在可能有些人会轻轻敲自己的脑袋了，“为什么我们一开始就不选择第三张呢？”是的，如果能真的一开始就这样的认识到，那么就没有前面这样的对话了。这样作为我们系统的开发人员也能节省许多不必要的“功能应酬”。而做到这样的完美的需求分析有很多的因素，但是最重要的三点原则我们应该谨记：

永远都要以用户为中心，然后再分析需求。
对于一个功能需求我们需要再三的考虑。
如果对于第一点不是非常的明确，请您参考第一点。
可靠的流程
那么我们已经知道一个明确的需求是如此的重要了，但是具体需要怎么做呢？

“以用户为中心”
一个好的需求永远是将用户体验放在首位的。正如上面的对话一样，需求方要求不断的更改需求的功能也是因为能让更多的用户访问我们的网站，带来更多的流量。但是正如很多事情一样，出发点是好的、但是如果实现方面出现了偏差，那么再好的计划都是事倍功半的。

传统的需求分析和需求提出流程可谓是“黑箱操作”的结果：一群需求方未经过用户的讨论就“想当然的”提出这个网站应该做成什么样子，然后将自己的想法告诉我们开发人员。然后开发人员根据需求方提出的想法，“想当然”的就将需要的功能实现了出来。因为需求方和程序员的处理事情的角度始终是不一样的（但是当然的，开发人员是不管所谓的市场报告是多么的重要，而需求方也不管你的代码是多么的优美），于是问题就在开发人员实现了功能需求以后逐渐的暴露了出来。

回顾我们整体的开发流程，可以分成三个角色：用户、系统分析方（需求提出方）、还有我们开发人员。而上面的流程看起来是多么的糟糕：用户完全没有发言权，他们甚至不知道有一个新的功能是为他们准备的；需求的提出方完全没有考虑到用户和开发人员的想法，他们兼了用户的职责，“自作多情”地认为用户是这么想的；开发人员也没有任何的发言权，他们完全沦落成了代码工厂。三方的效率都非常的低，而且非常容易的出现问题。

我们需要配合
“三个臭皮匠，顶个诸葛亮”，这句名言可谓多么正确的概括了我们接下来需要改进的流程。用户永远都不会关心需求方的网站统计数字、需求方永远不会关心网站的功能具体是怎么实现的、而开发人员也永远不会很在意最终用户的牢骚：这事情和我们真的没有关系，即使我们有时候也在想这个问题。

噢，三国鼎立的时代就这样产生了，我们还是化干戈为玉帛的好。那么我掉了那么久的胃口，真正是需要怎么做呢？好吧，好吧，我承认了，我也找不到一个彻底的解决方法（如果想扔鸡蛋的话，请您煮熟了再扔），但是目前为止按照我个人的理解有一个我认为目前比较“合适”的流程，请看流程图：


噢，是的。我觉得应该这样子才对。90% 的用户都不会主动向网站管理者提供他们的牢骚:“真是让人扫兴，这个该死的流程犹如填写入党申请书一样的麻烦，你们能不能将其简化一下？”、“嗨，你们的页面让我看着眼花，感觉就像我家的猫将猫食吃得满地都是一样……”、“网站如果有 RSS 订阅该多好”……是的，是的，获得原始用户需求的唯一办法就是亲自询问我们的最终使用者的感受，而不是在页面的底部扔一个我们的服务器邮箱了事。于是就这样，我们的可爱的需求方又有事情可以做了：除了应付我们的共同的上司以外，还得应付那些难缠的网站使用者了。

但是相信花这点时间是值得的，想想我们做这个网站的根本目的吧。然后需求方将用户提出的原始需求汇总，整理出文档来。请允许我将这份文档称作 DOC VERSION 0.5。“0.5 不会吧，那么低的版本号，我们可是花了很长的时间整理出来的……”。是的，是的，也许你认为这样不公平，但是请允许我说完可以吗（隐约间我看见又有几个生鸡蛋在飞了）。

结合原始的用户需求文档和需求方的需求文档，可爱的需求方这个时候可以去敲开发着的办公室大门了。不、不、不，你想你完全理解错误了，事情远没有结束。需求方并不是找他们直接开发功能去的，而是找开发人员讨论需求的可行性。并要求开发人员从技术的角度上整理出此功能项目的操作流程，并让开发人员提出自己的意见。这里文档版本号就姑且定为 VERSION 0.9 吧 -- -- 因为的确是加了一点“料”了。努力吧，其实距离真正的着手开发的日子已经不远了！

是的，你看到了。我们的需求人员在这里起到了粘合剂的作用：他们首先黏合用户，得到真正的用户在想什么，然后结合上自己的功能需求，和开发人员共同讨论需求的实现价值和可行性。然后他们从用户和开发人员这两座天平上寻找一个平衡点：类似于黄金分割点，看起来非常的美妙，不是么？

在开发人员提出了自己的想法和规划出了基本的流程图以后，他们就有一个大致的开发方向了（好吧、好吧、其实我们一贯都是这样做的）。但是这样确定的好处就是直接提出了自己的想法，避免了盲目的 coding。是的，对于开发人员来说也非常的美妙。

文档的重要性
这里我得说一下文档的重要性。这里的需求分析和提出的每一个步骤都应该紧随着包含了一篇相应的文档。这样的好处就是无论在需求开发过程中，有任何的人员调动都不至于重新的来过 -- -- 是的，原来的那位离开的朋友留下了一笔丰富的“遗产”：文档（对于我们开发人员来说，看流程图远比看生涩的代码要好）。另外的更重要一点就是当然文档可以看作是某种程度上的契约，如果需要更改任何的功能需求都需要更改文档。这样我们的需求更改过程就有了一个依靠，而不是盲目的浪费电话费和口水去做我们开发人员的思想工作了。

相比你也才得到后期的维护和需求功能方案的更改的步骤了。是的，必须以文档为标准！更新和更改每一个功能需求都需要修改相应的文档，并通知你的上司：让上司知道你有事情要做总是一件非常好的事情。

大体的需求流程方面这就完全扔到了我们的开发人员去实现了。剩下的需求提供方可以继续的收集用户的原始需求了，然后计划下一波对开发人员的骚扰了。是的，在这里对开发人员致以最崇高的敬意。

be continue……

结尾
是的，是的，我的话远远还没有说完，事情也远远没有做完。而目前我的确感到打字非常累了：上班打这些字的确是需要一些勇气的。如果大家有很多的好意见和建议的话，欢迎您前来骚扰。本人的邮箱是 i[dot]feelinglucky[at]gmail[dot]com （此段信息也兼做征 GF 之用）。最后谢谢大家能花时间看我的那么多废话。

yanglei1979

我所总结出来的开发经验是这样的:在和需求方沟通的时候就用程序来沟通,等沟通完,程序也做完了,然后再优化,总结和写开发文档,这样是比较快速而又合理的开发方式.

先写开发文档,以前也做过,感觉不太适合开发WEB程序.不知道大家是怎么认为的

biinn

我们的做法是：对于每一个功能修改，先写文档，文档要通过全team的review，至少team的architect要review过。然后coding，在code check in到main branch 之前，代码要经过全team的review，然后补充文档。

在整个过程中，coding只占25%的工作量。其他的是50%文档，25%测试。文档要包括完整的test cases。

当有人问我关于我做的模块的问题时，我就email给他一个clearcase的链接，看文档去吧。

jame298

我感觉前期的准备和文档输出非常重要,再熟悉一套框架的应用,一个良好的团队...完美了