| 摘要：
说教性质的需求分析理论，各位看了也白看，所以咱们就来一个真实个案——“订餐系统”体验一下。“订餐系统”貌似简单，但陷阱重重，各种需求分析的经典场景将会一一重现，各位做好准备接受这个挑战没有？本文文字超过1万1千字，而且有n多图片和思考题，请准备好盒饭边吃边看吧……
大纲：
1.某IT公司员工的吃饭问题
2.需求分析的大道理
3.背景-需要-需求规格
4.没完没了的“新需求”
5.领导“突发奇想”
6.榨干人脑汁的需求分析
7.变被动为主动
视频课程：
如果觉得看文章麻烦，可看本文对应的视频课程：http://www.cnblogs.com/umlonline/archive/2011/07/20/2111430.html
正文：
1. 某IT公司员工的吃饭问题
咱们出来干活的，天天需要吃午饭，所谓“午饭吃不好，工作干不好”。某IT公司深知这个道理，为了让大家方便吃午饭，由公司统一订餐，并且费用全包。
这样的做法，大家当然开心了，不过行政部的同事就要辛苦一点，每天要“服侍”大家吃饭，我们看看怎样个做法：
文员每天都要向餐厅索取最新菜单，然后拿着菜单找每个人确认今天吃什么。
大家都确认后，文员以电话或者传真的方式，向餐厅订餐。
餐厅送来午饭，文员通知大家，然后大家来取餐。
这样的做法维持了一段时间，但是问题逐渐就来了。
员工A抱怨：我明明点了酸菜鱼，干嘛给我送来红烧鱼。
员工B抱怨：我刚才去开会了，没有点餐，怎么就这样把我的餐给漏了？
员工C抱怨：我对中午饭要求不高，每天吃麻辣牛肉就可以了，不需要天天来问我吃啥，打断我的工作。
......
大家都开始来责怪文员了。
文员受了一肚子的委屈，她解释如下：
有些人写的字不太清楚，有时会搞错；
公司这么多人，有人上厕所有人去开会，我哪能保证每次都不漏人。
我按员工C说法做了，没有再问他了，但有一天取餐的时候，他说上火，不吃麻辣牛肉，要我换！都定了，怎么换啊？保险起见，我以后天天都问他了。
呜呜......
公司领导觉得问题责任不在于文员，而是这样的订餐方式太落后了，导致诸多问题！好歹是一个IT公司嘛，订餐也需要信息化！于是领导萌生了要做一个订餐系统的想法。
于是咱们的好戏就开始了......
2. 需求分析的大道理
你非常光荣地接受了这个任务，领导任命你为订餐系统的项目经理，你会如何展开需求分析工作呢？
可能你会这样想：那还不容易，这么简单的系统，直接编码就行了，还写什么需求！
伙计，不要冲动，看到这里请你先停止阅读，找张纸和笔，用你自以为合适的方式列出这个系统的需求。
请写完后才继续往下看噢！
不听话了？没写完就往下看？
咱们先说说需求分析的一些大道理：
首先我们需要明确项目的背景，我们要回答这些问题：也就是为什么会有这个项目？客户为什么想做这样的一个项目？如果没有这个项目会怎样？
了解背景的基础上，我们需要进一步了解以下内容：
1)本项目解决了客户的什么问题？
2)本项目涉及到什么人、什么单位？
3)本项目的目标是什么？
4)本项目的范围是怎样的？
5)本项目的成功标准是什么？
以上这些内容，我们称之为客户的“需要”。
接下来，就可以定详细的需求规格说明书了，一般我们会对功能性需求和非功能性需求都列出详细的要求，我们这里把这些要求定义为“需求规格”。
图1 背景、需要、需求规格
对于功能性需求，我们往往会描述成用例图。
图2 用例图
对于非功能性需求，往往会对系统稳定性、性能、兼容性等提出要求。
什么是背景？背景这东西比较笼统，简单地说就是这个项目的来由，我们需要用说故事的方式讲清楚项目的背景。
什么是需要？
需要就是客户真正想要的东东，是高层次的需求，我们可以把需要解决的问题、关键涉众、项目的目标、范围、项目成功标准等全部统称为需要。
什么是需求规格？
需求规格是很细级别的但又没有细到详细设计程度的需求了，描述出系统与用户是如何交互的，系统要满足怎样的一些非功能要求。
需求分析过程，无非就是由背景到需要到需求规格的过程，这个过程是螺旋前进的。需求分析中最难解决的问题往往就是搞不清需求之根源，把握不清背景和需要，往往就会被繁琐的需求规格所困住，被客户牵着鼻子走。理论是完美的，现实是残酷的，我们现实的需求分析工作，往往会出现这些问题：
背景啊背景，我该如何写你呢？
我们公司的需求规格说明书中，第一章节就是“背景”，但往往大部分项目写出来的背景写了等于没写。有些写了诸如此类的内容：某年某月某日与某某公司签订了某某合同，成立了改项目组，项目人员有谁谁谁，客户联络人是谁谁谁。有些项目更懒，直接复制前期需求文档的背景，以致项目已经做到第三期了，第三期的背景仍然是抄第一期的。不知道如何分析背景，背景不知道写啥，这是项目的普遍现象。
目标在哪里？
对于“项目的目标”，项目组普遍的问题有：
1.根本不知道“目标”这回事。
2.目标写出来了，但被扣上“大而虚”的帽子。
3.没有用目标来指导下一步工作，后面遇到具体问题时，没有用目标来思考。
4.目标写出来就不变了，没有持续去思考是否需要调整。
需求规格优先
很多需求分析人员喜欢将系统要做的事情，以用例或者功能点的方式记录下来，但往往没有记录为什么需要这样一个用例或者是功能点，没有去思考这个用例或者功能点背后隐藏的客户需要是什么。更甚者进入具体的界面设计，在需求文档中写清楚界面上放什么按钮什么菜单等，一开始就将需求“僵化”，这样会让后面的工作陷入“万劫不复”之地。
本小结开始的时候，要求你先写下本系统的需求，再继续往下看。不知道你写的需求中是否有背景、需要这些内容呢？你写的需求是不是几乎全部是“需求规格”呢？
下面，我们将来挑战“订餐系统”的背景、需求和需求规格。
图3 某需求规格说明书目录
3. 背景-需要-需求规格
请按顺序回答以下问题：
1.本项目的背景是怎样的？
2.本项目能解决什么问题？
3.本项目的关键涉众有哪些？（说明：涉众是指系统会影响到的人、角色、单位等，或者说什么人、角色、单位会影响到本系统。）
4.本系统要达到怎样的目标？
5.本系统的范围是怎样的？
6.本系统应该具备怎样的功能？
7.本项目成功标准是怎样的？
在往下阅读之前，请先独立思考，写出以上问题的答案。
1.本项目的背景是怎样的？
参考答案：员工中午饭要吃好是很重要的事情，但手工订餐存在一些问题，领导试图通过订餐系统来改善。
答案点评：
1)本系统的用户是“员工”，而客户是“领导”。（说明：用户是指使用系统的人员，而客户是可以拍板付钱给公司的那个人，是项目组的米饭班主。）
2)领导的目的不是为了做这个系统，而是希望通过这个系统解决问题。
3)领导应该不太可能投入大的投资来解决这个问题，例如：不太可能将员工的午饭标准提高到每人每餐50元，也不太可能为这个项目投入100万的经费。
背景应该怎样描述？
背景应描述出系统的用户和客户是谁、项目的来源，并且可以由此推断客户可能的投资预算，本项目对于客户的重要程度等。
2.本项目能解决什么问题？
参考答案：
1)手工订餐本身工作效率低，有时会影响员工的正常工作。
2)手工订餐容易出错，导致员工吃不到饭或者是吃不到自己想吃的饭。
答案点评：：
1)问题描述得很具体，并且问题产生的根源似乎都是因为“手工订餐”导致的。
2)手工订餐并不会让大家吃不到饭，只是有时会出一些小问题。
3)手工订餐的最大优势就是灵活，不好的地方就是容易出错，这个订餐系统如何才能保持手工订餐的“灵活”优势呢？
问题应该怎样描述？
需要清楚明确地描述清楚项目解决的问题，同时要分析好当前的工作方法的优点。系统除了要解决当前的问题，还应该保持原来工作方法的优点。很多系统解决了问题，但丢失了原来工作方法的优势，往往是得不偿失。
3.本项目的关键涉众有哪些？
参考答案：员工、前台、领导、财务、餐厅。
答案点评：
1)全面考虑了各种涉众。
2)员工是使用本系统的主体，他们最关键的需求应该是能方便准确地订餐。
3)前台通过本系统来统计订餐、和餐厅沟通、下订单等，前台可能是本系统使用功能最多、操作最复杂的角色。
4)领导有时也会通过本系统来订餐，但对本系统的主要要求就是大家要用得舒服。
5)财务可能需要根据本系统的订餐记录和餐厅结帐。
6)餐厅需要提供菜单给前台，餐厅可能以传真或电话的方式获知我们的订餐，不同的方式将会影响本系统的某些功能。
如果找出关键涉众？
1)应广度优先地尽量多地列出可能的涉众。
2)列出每种涉众在本系统的关键需求。
3)每一种涉众都应该清楚说明本系统是如何影响她的，以及她是如何影响本系统的。
4.本系统要达到怎样的目标？
参考答案：达到“吃饭易”的效果，保证员工不会因为吃饭问题影响正常工作。
答案点评：
1)目标描述应简单容易记忆，以便项目组随时记住。
2)本项目的目标并不是让员工吃饭吃得开心，也不是用来保证员工正常工作（光靠这个系统，是不能保证员工正常工作的），而是希望通过本系统来消除手工订餐的问题。
应该如何描述目标？
应该用简单、明确、恰如其分的语言来描述。简单、明确是方便项目组记忆，以便在工作中随时可以用目标检验工作。恰如其分则要求目标描述不要夸大系统的作用，也不要缩小系统的作用。很多项目描述目标的时候，往往会夸大系统的作用，如提高工作效率、提高生产力等，这些目标往往不是单纯靠系统就可以做得到的，更多是靠企业的管理，系统只是起到配合和支持的作用。
5.本系统的范围是怎样的？
参考答案：
1)这是一个订餐系统，只考虑与订餐相关的功能。
2)这是一个单独的系统，不考虑与其它系统集成或交互。
3)使用本系统的是**的全体员工，不考虑分公司的员工。
答案点评：
从功能、与其它系统的关系、用户三方面描述了本系统的范围。
应该如何描述范围？
范围往往客户并不会直接给出的，我们需要从项目解决的问题、目标等入手，从功能、与其它系统的关系、用户等来思考系统的范围。
由前面的资料，我们可以知道，客户应该不会投入很多钱，客户目标只是希望解决手工订餐带来的麻烦，所以我们定范围时，应该尽量让系统简单，能满足目标便可。本系统其实可以做得很复杂的，订餐这事情其实与请假外出相关的，订餐也会与财务结帐有关系，如果将系统边界扩大，很可能将问题复杂化。
6.本系统应该具备怎样的功能？
参考答案：
图4 用例图
对于“订餐”这个用例，我们还可以进一步细化用户与系统的交互：
用户指示订餐
系统给出菜单
用户选择菜单并确认选择
系统保存用户的选择，提示订餐成功。
答案点评：
1)用例图全面地描述了系统用户与用例，条理清晰、一目了然。
2)对于每一个用例，还可以进一步描述用户与系统是如何交互的，为下一步工作做好准备。
3)除了描述功能，还需要考虑系统的非功能需求，如性能要求、安全性要求等。
应该如何描述功能？
1)要根据前面的问题导出系统应具备的功能以及非功能需求。
2)用例图是描述功能性需求的好工具，但不要拘泥于只用用例图。
3)对于非功能性需求，客户往往没有具体想法，需要我们从客户的需要出发，定出具体的非功能性需求。
7.本项目成功标准是怎样的？
参考答案：用简单的方式达到目标的要求，达致双赢。
答案点评：
1)“简单”意味着成本低，符合双方利益。
2)达到目标要求是真正的客户所需。
如何考虑项目的成功标准？
我们做一个项目，成功标准并不是为了赚钱，更加不是不惜一切谋取最大利益，双赢才是最重要的原则！对于客户来说，首要目标就是要满足他的需要，然后就是合理的预算，对于软件公司来说，首要目标就是为客户提供高性价比的解决方案，赚取合理利润。要达致双赢，客户的成熟度是很重要的，但更重要的是软件公司的成熟度，项目组需要以专家、顾问这样的高度来解决项目中的问题，引导双方达至双赢。以上7个问题，问题1是背景相关的问题，问题2、3、4、5是需要相关的问题，问题6是需求规格相关的问题，而问题7是我们需要认真考虑的问题，考虑清楚项目的成功标准才能更好地指导项目后续工作，提高项目成功概率。
4. 没完没了的“新需求”
由于你的彻底而深入的需求分析工作，订餐系统进展非常顺利，很快就上线运行了！但问题也就来了，客户陆陆续续提出了以下问题：
1)要经过好几个页面才能进入订餐页面，不太方便，希望能在首页直接进入订餐页面。
2)一次只能定一天的餐，不太方便，希望一次能定多天的。
3)我有时选了一个菜，前台却说这个菜没有了！
4)能不能提供多家餐馆选择？
5)订餐标准才8元，现在物价都涨了，能不能提高一下标准？
6)能不能直接连到餐馆的网页上去看菜式？
7)能不能做口味分析和营养分析？
系统能用起来，问题肯定多多，没问题反而说明没有人用这个系统，所以有问题是好事，但问题多了又会让人很烦躁，改来改去没完没了啊，项目的成本也会持续上升。
你准备如何招架呢？在继续阅读之前，请你逐一分析上述问题并提出解决方案，要写下来奥！
下面我们来逐一分析上述问题。
1)要经过好几个页面才能进入订餐页面，不太方便，希望能在首页直接进入订餐页面。
2)一次只能定一天的餐，不太方便，希望一次能定多天的。
我们首先要思考，这两个要求背后的需要是什么呢？这两个问题都是在实际使用订餐系统中产生的，用户提出这样的要求无非是希望系统更加好用更加方便，订餐系统无非是要方便大家订餐、减少订餐时间，故这两个要求应该予以满足。
系统上线后，用户往往会提出很具体的修改要求，这些要求往往是易用性方面的问题，如：界面布局、操作方式、文字表达、排序条件等细节问题，这些问题不解决的话会降低用户体验，此类问题一般应尽量解决。
前期对项目的需要把握得比较好的话，软件基本上是能符合用户的需要的，哪怕用户提出了一些易用性方面的要求，一般也是很容易修改的。不过谁也不能保证对需要的理解没有偏差，有可能系统上线后才发现理解错了客户的真正需要，这时修改系统的话一般来说工作量会比较大，但原则上应该给予修改，双赢是项目的目标，客户关键需要没有满足，项目不能算成功。
3)我有时选了一个菜，前台却说这个菜没有了！
会什么会有选了菜但没有这个菜的问题呢？是软件的bug吗？
原来餐厅的菜单会定期更换，前台会及时更新订餐系统的菜单，但问题是餐厅修改菜单并不是很准时，而且修改后又不一定能及时通知前台，导致有时会出现员工按照老菜单订餐，但实际上餐厅已经修改了菜单的情况。
第二个问题是午餐标准的问题，明显不是系统的问题，但用户还是提出来了，他们难道不知道不是系统的问题吗？为什么还要对我们提出来？是不是希望我们向公司领导反应问题？
软件有些问题，并不是软件本身的问题，而是管理的问题。要用好一套系统，必须配套相应的管理办法，很多管理的问题软件是不能解决的。第一个问题，要改善的话则需要加强对餐厅的管理，让他们及时送上更新后的菜单；而对于第二个问题，则需要公司检讨订餐标准是否合适了。
项目组遇到客户提出这类问题时，不要因为不是软件问题就事不关己，应主动分析问题并提供适当的解决方案，很多问题只需要在管理上稍微改善一下，问题就可以立马解决。
4)能不能提供多家餐馆选择？
为什么用户希望选择多家餐厅呢？有人喜欢吃辣菜，有人喜欢吃粤菜，有人想吃粥粉面，就算是同一个人也会今天喜欢这个明天喜欢那个，如果能有多家餐厅可供选择，则更能满足大家的口味了。大家能吃到自己喜欢的午餐，更有利于大家做好工作，从这点看似乎这个要求是满足需要的，我们应该予以满足。
要实现这点，软件自然要费点周折去修改，但问题远远没有这样简单，管理上会变得麻烦很多：前台需要从多家餐馆获取菜单，要管理多家餐馆；财务要对多家餐馆进行结帐；更麻烦的是，有些餐馆要订餐数量多才会送餐，如果哪天某餐馆点的餐不够多，还需要选择了这个餐馆的员工重新订餐。这样复杂的管理，软件应该如何来适应呢？
看来如果寄望通过修改软件来满足这个要求，就会陷入一个“无底洞”，似乎无论怎样做都难以满足要求。实际项目中，经常会遇到这类问题，这时一定要认真地分析：
深入思考修改要求背后的需要是什么。
如果要满足该要求，在软件和管理办法上需要做什么改变，代价有多大。
如果不满足这个要求，影响会很大吗？
中午饭是工作餐，主要目标是方便快捷，员工哪怕吃不到最想吃的，也可以选择吃第二、第三想吃的，中午餐的预算也不可能很大，没有必要将午餐搞得很复杂很丰富，故这个要求可以不满足。
如果我们再动动脑筋，还是有简单易行的办法来解决这个问题的：员工可选择在公司统一订餐，也可以选择自己解决，无论哪种方式都享受公司的午餐补贴，如果在公司统一订餐，则只能选择一家餐厅。这样员工如果图方便，又觉得统一订餐的那个餐厅合适，就可以选择使用订餐系统来订餐；如果觉得想吃点别的，甚至是自己带饭，那就自己解决呗，反正午餐补贴是照样享受的。
6)能不能直接连到餐馆的网页上去看菜式？
为什么有这样新奇的要求呢？订餐标准才8元，这样的餐厅会有网页吗？
有时候用户会突发奇想，提出一些新奇怪异的要求，这时候要思考他的动机是啥了。由于客观条件限制，或者技术上做不到的，要予以拒绝。
为什么会有人想去看餐馆的网页呢？有可能是某些员工想了解一下餐馆的信息，好方便他和家人平时去撮一顿，如果是这样的原因，那只需要告诉他一些餐厅的网址就可以了。
7)能不能做口味分析和营养分析？
口味分析的意思就是希望系统能根据平时你的订餐情况，自动推荐你下次点什么菜。营养分析则是根据你订餐偏好，分析你的餐饮是否合理。这两个功能实在是太高级了，如果真的要做，那么系统需要增加数据挖掘的功能，这可是高技术含量的噢！
那到底要不要满足这个要求？这个要求其实已经超出了本系统的需要了，可以认为是对之前需要的升华，目前就算不满足也不会影响客户当前的使用，但如果要实现的话会导致项目成本上涨，对于这样的情况，可建议客户考虑项目的“二期”。
系统上线了，客户给你的挑战就会陆续而来，上述几个问题是实际工作中常见的几类问题：
对于符合需要的易用性方面的要求，应尽量满足。
有些问题可通过改善管理办法来解决。
有些问题需要同时在软件和管理办法上做工作来改善。
客户一时冲动的要求，可另辟蹊径解决。
客观条件做不到的、技术上做不到的，应予以拒绝。
超出范围的要求，可引导客户做第二期。
5. 领导“突发奇想”
你好容易满足了大家提出来的各类要求，这回到领导“突发奇想”了！
事情是这样的，领导发现尽管有了订餐系统，但有时候某些员工因为请假或者外出工作，不能及时在网住上订餐，中午回到公司时没有饭吃。领导就萌生一个想法，不在公司的员工能通过手机短讯来订餐就好了！
于是领导对你下达了要求，让你带领订餐系统项目组完成这个新功能。
请你先思考这些问题：
1)领导这个要求的需要是什么？
2)如果要做这个功能，人机是应该如何交互？
3)要实现这个功能，要增加什么设备？软件要怎样修改？
你开始挥汗如雨地干起来了，这个要求可不简单啊！
1)要购买发短信的设备，要研究这些设备的开发接口。
2)手机屏幕这么小，而且只能通过短信来交互，如何选菜单、定餐、取消订餐等细节都需要想清楚。
手机订餐功能终于做出来了，但这个系统还时灵时不灵，问题是出在软件、硬件，还是中国移动都搞不清楚，领导大发雷霆，这样的小事情，怎么搞成这样？！
后来有人提出来，不在公司的员工，打电话回公司告诉前台吃什么，不久搞定了？
顿时全世界一片哇然，你一屁股栽倒到地上！
领导要解决的问题其实只是要方便不在公司的员工能及时订餐，而领导提出来的通过手机来订餐是领导自己提出来的一个解决方案而已。我们的客户往往就会直接将他们想像中的解决方案提出来，从而让你忽略掉他的真正意图，当按照客户的解决方案去做的时候，往往不能命中真正的需要，费时费力又不讨好。当提出具体修改要求的人是领导级人物时，项目组更加是手足无措，唯领导命令是从。
作为项目组，任务时候都必须比客户更加清醒，不要埋怨客户的变来变去，绝大部分客户是理性和聪明的，只是我们不够厉害，不能分析出客户真正之需要。客户其实不是出钱让你按照他的要求去做，而是让你处于他的角度，提出高性价比的解决方案，满足他的真正需要。
6. 榨干人脑汁的需求分析
需求分析最核心的问题就是搞清楚客户到底想要什么！客户通常只会有朦胧的大概的想法，他们提出来的需求，往往只是表面的、不全面的，甚至是匪夷所思、互相矛盾的，我们需要透视它的本质。如果我们能说出客户内心深处真正想要的，而客户又不能直接表达出来的东西，我们才能真正做到“为客户带来价值”！
有很多方法能帮助我们搞清楚客户真正之需要，如问卷调查、访谈、用例图、用户故事等，还有前文介绍的“需求分析大道理”，事实上这些都不是提高需求分析能力的根本方法。需求分析的大道理、方法论这些最多让你开阔了研究，但基本上难以帮助你解决项目中需求分析的实际问题。上文的订餐系统，看上去简单，但也足够让你抓狂！没有深厚的功底，是难以做好需求分析工作的。
要具备怎样的技能才能成为需求分析高手呢？
图5 需求分析高手
需求分析能力的提高，依靠长期的积累，长期的实践！以下是一些建议：
1)不要以为学过了一些需求分析知识，就以为自己很厉害，也不要用这些大道理来指导项目组工作，不仅对项目组毫无实际帮助，还会帮倒忙。
2)不要一毕业就直接投身需求分析的工作，最好还是从编码开始，另外也可以考虑做测试、实施。
3)要不断地积累业务知识、技术知识。
4)学习面向对象分析、面向对象设计，并在实际工作中运用，面向对象分析与设计的方法，会从本质上提高你发现问题、分析问题、提炼问题、解决问题的能力。从这点上说，从开发开始是最好的选择。
5)把握一切能提高你表达能力与理解能力的机会，和别人沟通要及时表达出你对别人说话的理解，平时多写文章、博客之类的，提高你的书面表达能力。
6)为什么强调要有丰富的管理和被管理的经验呢？订餐系统中其实我们看到很多跟管理相关的问题，很多问题是需要管理办法去解决的，缺乏管理和被管理的经验，就会难以理解客户的问题，更加是无从从管理上提出具体的解决办法。
需求分析是榨干人脑汁的活，超具挑战性的工作！要站在比客户更高的角度把握住客户的需要，然后将客户的这些需求转化为软件可实现的需求规格，与此同时还需要为客户提供与软件相匹配的管理意见。你做好准备迎接这样的挑战了吗？
7. 变被动为主动
大部分情况下，需求分析的工作总是比较被动的，总会有点被客户牵着鼻子走的感觉，为什么会这样呢？看看下图：
这个图表示了随着项目的开展，客户与项目组对本项目的需要的认知程度是怎样变化的，横轴是时间，竖轴是对需要的认知程度。这个图说明了这些问题：
1)项目最开始时，客户对需要认知程度比较高，而项目组只是有朦胧的认识。
2)随项目的开展，客户和项目组都逐步提高了认识。
3)整个项目开展过程中，客户对需要的理解程度总是比项目组要高。
以上该图反应了绝大部分项目的情况，这样的项目客户对需要的理解永远领先于项目组，这样项目就不可避免地会陷入被动的境地。项目组做出来的东西往往不是客户真正想要的，要反复多次，但做出来后，客户又会继续有新的要求，周而复始，没完没了，客户和项目组都相互不满对方的表现，最终项目很可能是“双输”。
如果是下面这个图呢？
在项目初期，客户对需要的理解程度是比项目组要高的，但项目组的学习能力比较强，对需要的理解很快就超越了客户，并且在后面持续领先于客户。
按照这样的曲线，项目成功的机会是很高的，只要项目组对需要的理解领先于客户，就能化被动为主动，最终达到双赢！
很多公司会接手很多新项目，这些项目之前是没有什么积累的，保证这类项目成功的关键，就是要提高项目组的整体水平，人的水平是决定因素，不要指望什么用过程大框框能改善项目情况，更加不要指望那些半桶水的QA来监督项目组。
下面这个图呢？
什么情况下会是这样？
产品化的项目！
产品化的项目才是公司持续盈利之道，所有公司都需要积累自己的业务与技术知识，将项目产品化。但凡产品化的项目，项目组对需要的理解要比客户深刻很多的，客户会很崇拜你、认可你，在项目开展过程中，项目组要不断地去提高客户的业务水平，同时学习项目中特有的产品中没有的东西，将这些新内容提炼到产品中来，为下一个项目服务。
变被动为主动的奥妙就在此！提高需求分析能力没有捷径，努力提高水平吧！
8. 最后的疯狂
订餐系统的故事还没有结束，过了一段时间，大家的抱怨陆续又来了！
来自员工的抱怨：
有些员工觉得A餐厅好吃，有些又觉得B餐厅好吃。
有些喜欢吃辣，有些喜欢吃汤粉汤面之类的。
有些一会喜欢这个，一会喜欢那个。
很多员工强烈要求支持多家餐厅！
有些员工想自己带饭回来吃，但公司不会给予午餐补助。
前台的抱怨：
员工有时向她抱怨餐厅送餐慢，她也没办法，已经催了n次，换了几家餐厅了。
不太同意要支持多家餐厅，她的管理工作会麻烦很多，而且有些餐厅订餐少的话不会送餐的。
多家餐厅时，需要维护多家餐厅的菜单，而且每家餐厅的菜单更新时间不一样。
财务的抱怨：
不太同意支持多家餐厅，因为财务需要每家餐厅都提供发票，而不是每家餐厅都能提供发票的，除非我们愿意出更多的钱。
开发人员的抱怨：
不是吧，这班人这么难服侍，还有需求变更啊…
支持定多天的餐和支持多家餐厅其实是有矛盾的，而且也很难实现！
领导的抱怨：
这么简单的订餐系统，怎么搞得这么复杂！
我的这么美好的想法，居然惹下这么大的麻烦
|
