作者：徐锋
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
有效需求分析试读：
前言
笔者的《软件需求最佳实践》一书自2008年面市以来，受到了很多读者的喜爱，并且有幸成为很多企业、组织进行需求分析和管理团队的参考书籍，也让笔者暗下决心，一定要继续努力研究、打磨，给大家奉上更接地气的新版本。
但没想到这个承诺却一直没有兑现，当《软件需求最佳实践》脱销之后，出版社为了满足读者的需求，又出版了一批典藏版。更没想到的是，连典藏版本都脱销了，新版本仍然“青黄不接”。
是不是笔者忘记了这件事呢？当然不是，这九年来，我无时无刻不在思考、打磨，您手上拿的这本薄薄的小书，实际上经历过3次推倒重来（当时笔者直接把书稿整个目录删除，一个字一个字地从头码起），还有无数次的重构与修订，希望这些努力能够让您阅读得更加轻松、有益。本书特点
这是一本不以方法论为核心的书。笔者经常说：“我们不是在画活动图，而是在做流程分析；不是在画类图，而是在厘清数据关系；不是在画用例图，而是在识别场景……”如果我们过于以方法论为核心，那么会很容易忘记初心。因此本书是围绕着“我们要做什么，应该如何思考？”为主线展开的。
这是一本努力摆脱左脑思维的书。左脑喜欢逻辑，右脑喜欢故事；最好的陈述一定是起于故事，终于逻辑。因此本书不想过多地讲道理，而是寄期望于一个个故事、案例，让大家从中感悟到需求分析的有效思维，并且使用一系列的“任务指引卡”模型帮助大家快速记忆。
这是一本努力追求清晰简明的书。在移动互联网时代，人们的时间变得更加碎片化，大家更习惯碎片化阅读，因此笔者极力给本书减负，首先是让开本变小，然后是篇幅变少。
这是一本源于实践并高于实践的书。相信所有需求实践者都能从书中看到自己工作的缩影，很多实例均采集于一线实践，相信大家会从中有所收获、反思。
这是一本致力成为开箱即用的书。18个按需求组合的关键任务，针对每个任务的一步步指导，以及每个任务输出的“软件需求规格书”片段模板，让大家更容易在实践中应用。本书讲什么
如果说《软件需求最佳实践》想给大家的是一个过程框架，那么本书想给大家的则更像一组锦囊；过程框架重在方法论的应用，锦囊妙计则重在完成任务。
相比前者，本书只聚焦于需求分析环节。本书分为四个部分，由19个章节组成，如下表所示。
在本书的写作过程中，力求语言浅显、文字生动，通过大量的实际工作案例和生活隐喻故事使读者更易于理解原理、学会应用；相信即使是非技术背景的读者也能够轻松地读懂大部分内容，并从中受益。
另外需要说明的是，本书是针对政府、企业等组织应用系统的，诸如电子政务系统、办公自动化、ERP、资金管控系统等。对于从事公众类应用、互联网应用、消费电子研发的产品经理，建议阅读本书的姊妹篇《产品七诫》。封面照片
本书的封面取材于笔者在西藏大昭寺门口拍的一张照片，当时顺着一排排微弱的烛光向深处看去，一道幽兰的阳光深深地打动了我。当时我在想，这不就是需求分析工作的一个写照吗？心中充满希望之烛火，才是通向本质需求之途。只要用心，必然会闯出困惑之黑暗，寻找到真正的光明。致谢
本书的顺利出版，首先应该感谢多年以来的合作伙伴李冰女士（策划编辑），感谢您和您的团队为本书付出的辛勤劳动；其次也感谢自己的家人、朋友多年来的支持与理解。
本书出版之际，正值笔者从事需求咨询培训工作10周年，在此感谢这些年的所有客户，你们在咨询及培训课程中反馈的意见、观点、建议都使得本书更加精彩。
• 保险行业：中国平安、中国人寿、中国人保、太平洋保险、太平保险、合众人寿、华汇人寿、前海人寿、生命人寿、幸福人寿、泰康人寿、珠江人寿、友邦保险、民生保险、阳光保险等。
• 银行行业：中国工商银行、中国建设银行、中国光大银行、中国兴业银行、中国民生银行、山东农信社等。
• 证券行业：中金所、深交所、广发证券、国信证券、招商证券等。
• 通信行业：中国移动、中国电信、中兴通讯、华为、烽火通信、广州电信研究院、新大陆、星网锐捷、福诺科技、网通集成等。
• 政府机构：国家税务局、最高检察院、国家专利局、中国证券登记结算中心、深圳人力与社会保障局、电信十所、公安部一所、山东电业局等。
• 甲方组织：大亚湾核电站、中国国航、中国中车、中国船舶、航空结算中心、广州航信、富士康、北森测评、建发集团、深圳鹏海运、丰田金融、通号集团、麦田地产等。
• 行业软件／集成公司：惠普、恒生电子、用友软件、金蝶软件、航天信息、华宇软件、远光软件、四维图新、广联达、东软、税友、软通动力、华东凯亚、从兴电子、天方达、新意软件、万维软件、翰纳维科技、上海欣能、康拓普、博涵前锋、易程科技、信诚通、石化盈科、艾因泰克、信源信息、和利时、易程科技、中油龙慧、中油瑞飞、首信科技、亿力吉奥、英华达、图讯科技、昊美科技、海鑫科金、中兴力维、日电信息、中体信息、中邮科技、天安怡和、京天威、全专科技、亿讯信息、合道信息、雁联等。
• 产品需求咨询／培训服务客户：腾讯、百度、阿里巴巴、搜狐、网龙、唯品会、vivo、OPPO、金立、魅族、传音、创维、天奕达、迈瑞、星网视易、星网升腾等。Part 1引导篇0 软件需求全景图
在信息技术深入应用的今天，政府、企业等各类组织都依赖于信息系统来开展自己的业务。针对这些组织应用类软件系统的需求分析工作，核心在于“业务分析”。而要想厘清此类软件系统的需求，必须要抛开具体的技术实现，站在用户的视角审视用户想要解决的问题、想要达成的业务目的。0.1 业务驱动的需求思想
要做好软件需求工作，业务驱动需求思想是核心。传统的需求分析是站在技术视角展开的，关注的是“方案级需求”；而业务驱动的需求思想则是站在用户视角展开的，关注的是“问题级需求”。0.1.1 方案非需求
生活悟道场有一天夜里，资深需求分析师老余刚忙完一个重要的项目，带着放松的心情进入了梦乡。这时他年仅3岁的小孩夜里醒来，吵着要吃饼干。孩子的妈妈首先被吵醒，带着情绪地训斥了小孩：“半夜三更吃什么饼干，好好睡觉！”没想到小孩不依不饶，继续哭闹着，不久老余也被吵醒了……他安静地起身到了客厅，找了一小会儿，果然没找到饼干！他随手拿了两块吐司面包走进卧室，脸上掠过一丝自信的微笑。
“小子，没有饼干了，吃点面包填填肚子吧！”老余边说边把吐司塞到小孩手中。果然，小孩接过面包后就不再哭闹了，吃完一片就乖巧地躺下。不一会儿，老余家又回归了平静。
在这个例子中，小孩提出“要吃饼干”，这实际上是一个方案级需求。由于家里没有饼干，因此妈妈认为孩子提出了一个不合理的需求，于是想办法让小孩放弃这个需求。
而老余则快速意识到了这个方案级需求背后真实的问题级需求是“饿了”，因此找到了可行的解决方案——吃面包，小孩的需求也得到了满足。0.1.2 变更／优化型需求分析任务执行指引
在软件需求分析实践中，用户提出变更、优化型需求也通常都是直接提出“方案级需求”，因此我们需要还原出“问题级需求”，其分析过程如图0-1所示。图0-1 变更／优化型需求分析任务执行指引
1．失败的变更需求分析
案例分析小王是一名实战经验还很少的需求分析师，在一次酒店管理系统的建设项目中，听到酒店前台人员提出的一条需求：请在酒店入住界面中增加一个酒店平面图，在图中实时地显示出房型、房态和价格信息。
“这个变更你们给我们多少开发时间？有预算不？”这一段时间被变更折腾得不行的小王马上问道。前台人员瞪了他一眼，撇撇嘴说道：“就加这一点点东西，就别老提时间、钱了行不？多伤感情呀！”<旁白：很多经验不足的需求人员在听到需求变更时，总是第一时间想到成本！虽然成本很重要，但必须先澄清问题、思考业务价值才是良好的习惯！>小王被前台人员一句话顶得无言以对，只好接着澄清需求：“那这个平面图是一层一张，还是把所有楼层都整合在一张大图中呀？”前台人员一脸疑惑地反问：“我们酒店有这么多层，都整合在一张大图中能用吗？”小王接着问：“那实时是几秒呢？1秒、2秒还是0.5秒呢？”前台人员不假思索地说：“越快越好吧！”小王听到这里满脸愕然，思考了一下继续问道：“那房态有几种呢？是用颜色还是直接使用文字来体现呢？房型呢？价格又要如何显示呢……”前台人员在犹豫中给出了一些反馈。小王边听边在纸上画了一些原型图，初步获得了一些确认，他心想希望前台人员以后别改变主意。“对了，在这个平面图上还要关联哪些功能呢？”小王突然想到了一个新问题。
“关联什么功能？现在暂时还没想到，如果以后想到再告诉你吧！”前台人员十分肯定地回应道。小王听到这里，只能愣愣地望了望对方。
从需求分析师小王和客户的交流中，大家发现问题了吗？是的，小王所有问题都集中在“解决方案层面”，期望客户细化“如何实现”，但用户要么没想法，要么不确定，这样的沟通必然会带来巨大的隐患。
案例分析（续1）小王和前台人员交流后，就整理了一份文字描述，将这个需求转给了开发。结果开发人员小李看到之后，第一反应就告诉他：“你不知道在B/S架构上实现平面图的工作量很大吗？为什么不劝用户放弃这样的需求？”小王再次一脸愕然，只好动用感情牌：“我相信这样的需求对于你这种高水平程序员来说不是什么难事，而且我已经答应用户了，你这次就帮我一个忙，改天我请你撮一顿！”小李听完后诡异地一笑，很自信地说：“好吧，你还好碰到我，碰到别人谁都不帮你干！”几天之后，小王拿到小李给他的结果当场傻了眼，这哪是图呀！分别就是用HTML中的表格搭出了一个示意图，简陋、难看！可是第二天就是和客户约好的交货期，他只好硬着头皮带着这个“丑媳妇”去“见公婆”了。前台人员看到这样的解决方案顿时也傻了眼，不过他却很有技巧地提出了不满：“您觉得这是图吗？可以放大、缩小、平移吗？这些字这么小，怎么能够看得清呢？”小王只好悻然地带着新的反馈去找开发人员小李：“不好意思哦，客户说还要放大、缩小、平移……”小李听后脸上马上挂满了乌云，但一瞬间又变成了“多云转晴”，神秘地说：“好吧，交给哥们吧！”两天后，小王看到小李传过来的新解决方案，更加无语了！小李只是把原来的HTML表格示意图放在一个帧里，然后加上了放大、缩小两个按钮！单击“放大”按钮，字体放大一号；单击“缩小”按钮，字体缩小一号；整个HTML表格也就随之缩放。他马上找小李提出了自己的质疑……小李撇撇嘴说道：“虽然丑了点，但也解决问题了不是？不是说看不清吗？现在放大就可以看清了呀！至于平移，直接拉滚动条不就可以了吗？”小王迫于时间的压力，只好带着“整容失败”的新解决方案去见客户了。前台人员看了一眼，直接二话不说打电话给其领导：“领导，您看他们新上线的入住功能……那个平面图……您看做成什么样了！他们就是这样应付我们的吗？”客户领导震怒了，马上一通电话打给了小王所属研发中心的大领导！从此，这条需求就升级成了一个极高优先级的需求……
从事态的发展中我们可以看到，如果基于一个目的不清晰、实现方案相当明确的需求进行开发，一旦开发成本比较大，就极易出现执行变形，严重的时候甚至还会使客户关系恶化……
案例分析（续2）小王的项目团队开始开会研究这个需求，最后大家一致认为只有使用SVG（B/S架构下的一种矢量图解决方案）是最合适的，可惜团队中没有人会。最后领导决定派一个资深的开发人员研究学习一下。最后，这个资深开发人员花了2周的时间学习、2周的时间开发调试，在一个资深美工的协助下打造出一个很完美的平面图，效果很棒，大家一致认为客户应该会相当满意。可惜这个看似完美的平面图功能，也只是让客户开心了两天。两天后，客户就反馈说这个功能不好用！当大家问他为什么觉得不好用时，结果得到的反馈居然是：看运气，运气好时还不错，运气背时太难用了！刚好公司PMO举行了一次跨项目交流例会，这个项目组就把这个案例分享出来，结论是“需求真是一个令人头痛的问题”，一直以来对古怪需求特别有兴趣的我马上主动说：“交给我吧，我看看如何解决！”
当我们“完美”地满足了客户提出的“方案级需求”时，最终未必会得到完美的反馈。因为客户是问题专家，而非解决方案专家，他提出的方案未必能够完美地解决他遇到的问题。
2．澄清问题
案例分析（续3）我找到了最初提出这个需求的前台人员，问他：“您为什么会觉得有时好用，有时不好用呢……”我话还没说完，他就马上打断我说道：“你知道我想要用这个平面图干么吗？”我会意地笑了，顺着他的话问道：“我这次来就是想了解您想通过这个平面图解决什么问题，以便给您构思一个更加有效的解决方案。”他接过话题，缓缓地说：“因为有时客人过来入住，会要两间甚至多间相邻的客房，这时我经常遇到困难。你知道的，房间号相邻通常不意味着房间相邻。”［澄清谁的、什么问题］
“嗯，那现在您遇到这样的问题是如何解决的呢？”我顺着他的思路继续发问。“之前我遇到这样的客人，首先会找哪些楼层有足够的客人所需房型的空房间；知道哪些楼层有之后，再判断它们是不是挨着的……”他不紧不慢地说道。［澄清现状，也就是现在是如何解决的］
“嗯，由于不好判断，因此您就想这时有个平面图可以直观地找出挨着的房间来！但有时有多个楼层都有足够的空房间，因此您将纠结从哪层看起的问题……”我知道自己找到了问题所在！他微微一笑，说道：“的确是这样，有一次发现3、5、7、8、9、15、18、20、30楼都有空房间，结果我从30楼开始找，一直看到3楼才找到合适的！唉，早知道从3楼开始找就好了……”
“那您认为什么是‘挨着’呢？”我突然问了一个有点怪异的问题。果然，他一脸困惑地看着我：“‘挨着’就是‘挨着’嘛，还有什么叫‘挨着’……”我淡淡一笑，说道：“我当然知道两个房间紧挨着是紧挨着，但对面的房间能满足客人需求吗？斜对面呢？如果斜对面也能，那么中间隔一间能不能呢？”
“这还真是一个有趣的问题”，他马上给予了我肯定的回应。我们花了几分钟的时间进行分析，最后得到了一个严谨的共识：两间房间门步行距离在2米内完全满足、5米内可以推荐，毕竟客人就是希望方便同行者交流、联络。［对模糊概念进行澄清］
这段对话是否能够让你对“问题级”需求建立更清晰的理解呢？是否也让你看到了更清晰的需求了呢？在这里我们澄清了问题、了解了当前遇到该问题的临时解决方案（现状），并对模糊概念达成了共识。当然，为了给出更准确的解决方案，我们还需要对相关背景做更进一步的了解。
3．了解背景
案例分析（续4）
“那么您当时提出做一个平面图，主要还是自己用吧？应该是在办理入住的时候使用吧？”我虽然已经有了十成把握，但还是习惯性地和他进行了一次确认。但得到他的确认之后，我继续问：“那您可以简单地说一下办理入住的过程吗？”他耐心地解释道：“首先根据客人的需要找出合适的房间，然后记录客人信息，最后开出钥匙卡，整个过程挺简单的！”［这一步是在澄清业务场景，谁、什么时候、怎么做的；了解了办理入住的过程之后，如果最后仍然使用平面图解决方案，我们很容易得出在平面图上选中房间后直接跳转到客人信息录入界面，因为关联功能源于用户的使用场景。］由于之前小王在需求沟通过程中已经明确了“房态”、“房型”、“价格”几个业务术语的概念，因此我就跳过了这一步。［明确业务术语的定义，是做好数据需求的基础。］
“在您的印象中，要几间挨着的房间的客人多不多呢？每天都有吗？”我希望了解这个需求的使用频率。前台人员很快就回答了这个问题：“不算多，1天2~3次的样子吧！”听到这样的回答，我心中明确了一个概念，这个需求未实现生气的只是酒店前台，一天大概生气2~3次的样子。
“你们酒店是连锁的吗？其他前台人员也有类似的困扰吗……”我继续对一些业务环境作些了解，以便明确相关的非功能需求。［非功能需求源于业务环境。］
对话到这个阶段，我相信大家都已经很清晰地理解了这个需求，接下来我们就可以建议并确定解决方案了，你还觉得应该开发平面图吗？
4．建议并确定解决方案
案例分析（续5）通过前面的沟通，我认为这是一个基层操作者（前台人员）非常用的功能，未实现时也就是添加了一些工作不便，因此我认为应该采用更加简单的解决方案。
“您平时工作这么忙碌，遇到客人要求几间挨着的房间时，还要自己一层一层地看平面图去找，更加麻烦；我觉得直接让系统来帮您挑出来更方便一些，您觉得呢？”我开始引导客户接受更加简单的方案。前台人员马上接过话题说道：“那敢情好！具体怎么做呢？”我拿出笔在纸张上边画原型边解释道：“在原来的查询空闲房间的界面上，增加间数、是否挨着的选项，当你指定间数并要求挨着时，系统会查询出满足条件的房间，并说明是2米内，还是5米内，你觉得如何……”前台人员听懂了我提出的解决方案之后，爽快地说：“太好了，就这样办！这样省事多了……”
正如对话中所示，我们在建议解决方案时应该站在用户的立场，说明这种方案的优点，毕竟需求分析师是“问题解决者”，而不是简单的需求传递者。
5．关于需求挖掘
在需求沟通时，我们需要挖掘一下客户的潜在需求吗？有人赞成，认为这里不挖掘，客户迟早也会提出来，后面开发更麻烦；有人反对，认为很容易产生需求蔓延，而且客户经常是“所听即所要”。
针对这样的两难问题，我个人的经验是：“只挖掘问题，不挖掘方案”。因为在问题级的探讨，客户是理性的；而在方案级的探讨，客户是感性的。
案例分析（续6）当他接受了我所建议的解决方案之后，我考虑还是应该做一些需求挖掘，以避免未来需求不断以“挤牙膏”的形式提出。首先我在心中概括了一下这个需求的问题类型，显然是“客人提出了特殊的入住请求”，因此我问他：“另外，请您回忆一下，除了要挨着的房间之外，还遇到过其他特殊的入住请求吗？”他微微仰起头回忆了一下，回答了我的问题：“嗯，你这么一说，还有一种比较常见的，客人交代要一间不太吵的房间。”我点了点头，顺着他的话问道：“那如果你给了一间比较吵的房间，会有什么后果吗？”
“遇到不太挑剔的客人也无所谓，但有些客人会马上要求换房，如果没有空房可换，还会马上投诉。”他脸上流露出一丝无奈。“……”
在这段对话中，我又得到了一个新的问题：“找到一间不吵的房间”，业务频率和“几间挨着的房间”类似，但如果没解决对业务影响更大。但在我的沟通中，并没有明显提升用户的预期，我可以让开发人员在设计时考虑到未来这种需求的实现。0.1.3 变更／优化型需求分析任务产物
1．变更／优化型需求分析模板
针对变更／优化型需求分析，有些公司在实践中也采用了厚重的需求规格模板，导致了大量无效信息。我建议使用一个简单的模板，如表0-1所示。表0-1 变更／优化型需求分析模板续表
与前一小节中讲解的分析过程相对应，该模板中主要包括原始需求、问题澄清、业务环境描述、业务场景描述、业务术语说明、解决方案概述6个部分。（1）原始需求：说明需求是谁提出的（提出人，必填）、他属于哪个部门（客户信息，建议填）、原话是什么（原始描述，必填）；如果有需要，还可以对其进行编号（编号）。（2）问题澄清：这个原始需求背后的问题级需求是什么（要解决的问题，必填）、现在如何应对该问题（现状，选填）、问题描述中有需要澄清的定义吗（概念澄清，选填），以及还有相关的其他需求吗（相似问题场景挖掘，选填）。（3）业务环境描述：该需求未实现对谁产生直接影响（不做谁生气，建议填），这种影响的频率如何（多久生气一次，建议填），有哪些对非功能要求产生影响的因素（其他非功能需求，选填）。（4）业务场景描述：当需求人员或开发人员不理解该问题发生在什么样的业务场景中时，可以选填本部分。它主要包括：该需求发生在哪个业务场景中（场景名称），这个场景是怎么样的（建议采用子任务、任务变体的形式整理）。（5）业务术语说明：如果需求人员或开发人员对该需求中相关的业务术语有理解歧义，那么建议选填本部分。也就是列出易有理解歧义的术语名称，以及术语意义、构成等说明信息。（6）解决方案概述：必填，针对该问题可以有哪几种解决方案，各有什么优缺点，推荐哪种？为什么？
2．变更／优化型需求分析示例
针对前一小节的案例分析结果，我们可以整理出如表0-2所示的任务输出，大家在具体的实践中可以参考。表0-2 变更／优化型需求分析示例续表0.2 组织应用类软件系统需求全景图
对于变更／优化型需求，我们需要澄清问题（Why）、了解背景（场景——功能，术语——数据，环境——质量）；这样的逻辑对于一个项目、产品的需求也是类似的。
从宏观角度来看，组织应用类软件系统需求可以分为价值需求（目标场景、干系人关注点、干系人阻力点）、详细需求（对应前面的背景，也分为3个线索）两大部分，如图0-2所示。价值需求主线包括目标场景，干系人关注点、阻力点两个角度；而详细需求则由行为需求（也称功能需求）、数据需求、非功能需求三条主线组成。在本章后续小节中将对这几条主线的分析要点进行概述。图0-2 组织应用类软件系统需求全景图0.3 价值需求主线
什么是价值需求？简单来说，就是从黑盒子视角回答“整个软件系统为客户解决了什么问题、创造了什么机会”，“对于系统而言，最关键的干系人有哪些”，“各个重要干系人对系统的关注点是什么？有哪些担心（阻力点）”三个本质性问题。
价值需求是组织应用类软件系统需求的灵魂和方向，但在笔者所接触的很多此类需求分析实践中，这部分做得相对薄弱。这将使得项目范围更容易蔓延，客户从中获得的利益与价值不容易呈现，从而导致客户满意度难以有效提升。
在目标分析方面，经常会看到很多放之四海而皆准的、定性的描述，如“打造一套先进的信息化系统，有效地推进管理的提升……”这样的目标自然无法作为“成功标准”来指导系统的开发与实施工作，甚至会出现“我们走得太远，以至于忘记为何而出发”的尴尬境地。
如果说在很多需求分析实践中，目标分析方面只是做得不到位，那么在干系人识别与分析方面则经常是干脆直接省略，在《需求规格说明书》中根本找不到。而这方面的缺失会导致忽略他们的关注点，陷入他们的阻力点，从而在开发过程中不断受到影响。
如图0-3所示，价值需求分析关键在于执行好目标分析、干系人识别、干系人分析三个任务。这些任务将分别产出：多份《问题卡片》，场景化地定义项目目标；一张《干系人列表》，列出所有关键干系人；多份《干系人档案》，针对每个关键干系人整理相应的关注点和阻力点。图0-3 价值需求主线的“任务－产物”示意图
本书的第1~3章将详细说明价值需求主线中目标分析、干系人识别、干系人分析三个关键任务的具体方法、技巧和产物。0.4 详细需求
价值需求是方向，是成功的标准。那么什么是详细需求呢？简单来说，就是从灰盒子视角完成三个主题的分析：“为了给客户提供业务、管理、维护支持，需要提供哪些功能？”“系统所涉及的问题域中有哪些数据，之间是何关系？”“所处的业务环境会带来哪些约束和质量要求？”
这三个主题实际上就是详细需求中的功能需求、数据需求、非功能需求三条主线。要想清晰地梳理出详细需求，可以先沿着这三条主线厘清脉络、识别出最小粒度的需求单元，然后为识别出的需求单元填充具体的细节描述。0.4.1 子问题域分解
由于很多系统涉及的问题域有多个，如果直接对整个系统进行功能、数据、非功能主线的梳理，会很困难。如果存在这种困难，我们就应该先从业务的角度，按系统涉及的不同子问题域进行分解，以便逐一分析。正所谓“分解的目的在于控制复杂度”。
如图0-4所示，显然最关键任务就是子问题域分解，它将产出一个《系统分解模型》，该模型可以根据实际需要选用层次图、构件图、数据流图等图表呈现分解结果。简单来说，该任务就是从灰盒子视角回答一个问题：“系统涉及哪些子问题域，它们之间有什么关系？”图0-4 子问题域分解的“任务—产物”示意图
正所谓“哪里有分解，哪里就有接口”，当完成子问题域分解后，还需要执行业务接口分析这一任务，定义各子问题域间的业务接口，说明这些接口的用途、谁实现、谁使用等细节。0.4.2 功能主线
有人说，组织应用类软件系统就是带一定业务逻辑的增删、改查功能；也有人说，做需求就是先搭菜单结构。这些都是典型的白盒子视角，是从开发视角来说的技术驱动需求理念。这一视角，会让用户对需求分析过程敬而远之，写出的需求文档也将令其望而生畏。
有人说，我们应该先找业务用例，再找系统用例，从用户的角度来“发现”。这虽然是一种“黑盒＋灰盒”的视角，但大量实践者苦于难以有效地完成思维角度的切换；另外，这种较小粒度的抽象方法，容易在需求分析过程中陷入树木而忽略森林。
有人说，我们应该让现场客户用“作为×××，希望系统实现……以便……”的句型说出他的需求。这也是一种完美的黑盒视角，但我们真的能够把“讲清需求”的责任转移到用户身上吗？这种转移真的有利于需求分析吗？
实际上我们还有更好的思考角度和做法，那就是厘清系统中的所有功能是因何而存在的。如果我们站在更宏观的角度上来看，实际上最核心的无外乎以下几个方面：（1）通过系统固化、优化业务流程，提升流程执行效率、节约成本、降低风险等。（2）通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等通道上。（3）通过系统将个人知识、能力转化为组织知识、能力。（4）通过系统实现数据的信息化，辅助管理、决策。
很显然，前3种实际上可以归结为一类，用于业务支持；而第4种则是另外一类，用于管理支持；此外，软件系统不是一次性的，而是不断演变与优化的，因此还需要提供用于维护支持的功能。也就是说，功能主线的梳理可以从业务支持、管理支持、维护支持三个角度展开。
1．业务支持
业务支持最典型的是三类：首先是固化、优化业务流程，因此业务流程是核心；其次是业务延伸到新的通道（诸如手机端），这从本质来说也是一种流程的重构，核心还是业务流程；最后是将个人能力转化为组织能力，而这种能力存在于具体的业务场景中，因此“专家场景”是核心。
要梳理出业务支持所需要的功能，简单来说，就是从灰盒子视角回答四个问题：“根据目标和干系人关注点，系统涉及哪些业务流程？”“这些业务流程是如何定义的，需要优化吗？”“系统对流程中所有业务场景都要支持吗？还是只支持一部分？”“有哪些业务场景的工作经验需要模型化？”
如图0-5所示，梳理业务支持需求关键是四个任务：（1）业务流程识别，为各子问题域生成一个《业务流程列表》，列出系统涉及的业务流程；（2）对各业务流程进行分析与优化，绘制一组《流程图模型》；（3）业务功能识别，识别各流程中系统需支持的业务功能模型；（4）业务功能分析，描述各业务功能的具体需求。
对于第三个任务“业务功能识别”有一种延伸，当涉及专家系统需求时，需要抽象出“专家场景”，也就是要通过系统模型化，以便新员工能够“复制”执行该任务的经验。
看到这里，或许有人会有所顾虑，在这个面向对象分析的时代，为什么还会以“业务流程”作为分析的入手点呢？而不是应该从“人”这个角度吗？因为系统要支持的是业务，而在业务领域中通常是先制定业务流程，再明确岗位及岗位职责的；只有清晰地梳理出流程，才能更好地分析需求。图0-5 业务支持需求分析的“任务—产物”示意图
2．管理支持
软件系统对管理的支持，主要可以体现在三个方面：（1）事前风险避免，通过增加管理流程；（2）事中风险控制，通过“规则”和“审批”；（3）事后总结优化，通过“数据分析”。前两种通常会在业务支持分析中统一处理；第三种则应该独立进行分析。
要梳理清管理支持所需的功能，简单来说，就是从灰盒子视角回答三个问题：“管理层用户希望通过系统来实现哪些管理、控制需求？”“希望通过系统做哪些辅助决策？”“要实现这些管理、控制、决策支持，需要哪些信息？用什么方法获得它们？”
如图0-6所示，第一个关键任务就是管控点识别与分析。首先从管理者的视角识别出他们的管控点，也就是管理场景，得到《管控点列表》；然后对每个管控点进行实现分析，得出所需的业务报表、BI需求、数据仓库、数据挖掘需求。而辅助的关键任务就是业务报表分析，对前一个关键任务识别出的业务报表项，从数据项、计算方法、展现格式、统计口径等方面进行具体描述。图0-6 管理支持需求分析的“任务—产物”示意图
对于这个部分的需求分析，在很多需求实践中都是从技术角度进行的，无论是开发团队还是客户，都认为应该列出所需的报表格式，但由于用户很难在需求阶段清晰地提出业务报表需求，因此经常出现分析不透、变化迅速的问题。
而对于BI需求、数据仓库、数据挖掘方面，更是常常脱离用户，不断地试错。归结到底，是缺乏从管理场景角度的思考。
3．维护支持
系统投入使用之后，还需要对其进行维护，最典型的包括初始化、配置、排错等，而这些运营维护场景也需要有相应的功能来支持。
要厘清维护需求，简单来说，就是从灰盒子视角回答两个问题：“有谁会需要对系统进行维护？”“他们需要执行哪些维护任务？”
也就是说，执行维护需求分析这一任务时，首先识别未来的维护用户，可能是客户自己的维护团队，也可能是开发团队自己。然后根据不同的维护用户列举出未来维护、运营相关的场景，整理成一张《维护场景列表》，如图0-7所示。图0-7 维护支持需求分析的“任务—产物”示意图
在这部分分析时，建议不要从功能实现的角度来列举功能，而是从维护场景的角度分析，如不是“日志”功能，而是“排错”场景。
另外，由于这部分的内容通常是可以重复使用的，所以一次的整理结果，能够在多个同类系统中重复使用。0.4.3 数据主线
大家都知道，在一个组织中有四个最核心的“流”：工作流、信息流、资金流、物流。而在一个组织应用类软件系统中，资金流和物流是不会真实出现的，而是以信息流的形式呈现。前面提到的功能主线中，是从“工作流”线索分析的。而数据主线，重点就在于厘清组织中的“信息流”。
对于数据主线的需求分析而言，简单来说，就是从灰盒子的角度回答三个问题：“系统相关的问题域中有哪些业务数据？”“它们之间是什么样的关系？”“每个业务数据的具体构成是怎么样的？”
如图0-8所示，数据主线的关键任务有两个：一个是“领域建模”，也就是用领域类图的形式刻画出问题域中所有业务数据实体之间的关系；另一个是对每个业务数据实体进行“业务数据分析”，详细定义数据构成与推演过程。图0-8 数据需求主线的“任务—产物”示意图0.4.4 非功能主线
由于系统部署、应用的环境不同，会带来不同的约束、不同的质量要求；而如果没有有效的分析，也会使得系统无法满足实际应用的需要。
对于非功能主线的需求分析而言，简单来说，就是从灰盒子的角度回答一个问题：“系统相关的外部环境会带来什么样的约束和质量要求”。
这部分的需求分析，在很多实践中存在很大的缺陷，最典型的情况有三种：（1）定性描述，直接写“高可靠、高易用、高灵活……”之类的要求，而实际上并没有传递出任何有效的信息。（2）盲目定量，拍脑袋写出量化指标，写出一些客户、需求人员、开发人员都无法清晰理解的似是而非的量化要求。（3）诸如“所有查询都在7秒内响应”之类的全局性描述，这种描述难免以偏概全，缺乏实际有效的落地性。
对于非功能需求而言，是不是要做到面面俱到地进行分析呢？这是一个值得思考的问题。实际上我们可以根据系统的特点，决定非功能需求的分析深度。也就是通过质量树梳理的任务，找出最为重要的质量类型，并以一张《关键质量树》列表呈现。
对于非功能需求的分析工作，最核心的是逆向思维，从威胁入手。基于《关键质量树》中的每种质量类型，识别出业务环境中可能产生的破坏力大、出现概率高的威胁场景，使用《目标—场景—决策表》描述出来。
也就是说，非功能主线需求分析的核心任务就是质量树梳理、质量场景分析两项，如图0-9所示。通过这两项任务，把握关键的质量类型，用场景传达具体需求。图0-9 非功能需求主线的“任务—产物”示意图0.4.5 补充性内容
通过价值需求、详细需求（包括功能、数据、非功能三条主线）的梳理，识别并描述业务功能、业务报表、业务数据、质量场景、业务接口五类最小需求单元，基本覆盖了需求分析的所有内容。此外，还有两方面内容，一是约束，二是规则，有时需要单独进行更加详细的分析，如图0-10所示。图0-10 补充分析的“任务－产物”示意图
当系统中有大量的约束时，需要强化约束分析。当系统是一个强规则，规则量大、规则很复杂时，就可以考虑单独作为一个主题来分析，否则可以在流程分析、业务功能分析、领域建模时附带对规则进行分析即可。0.5 信息系统需求分析任务小结
为了帮助大家形成整体的感觉，在此把前面提到的一些在组织应用类软件系统需求分析中需要回答的关键问题，以及18项需求分析关键任务汇总在一张图中，如图0-11所示。
在实际的需求分析实践中，应该根据实际的产品、项目特点，明确出关键的需求主线，以对其进行合理的剪裁。图0-11 组织应用类软件系统需求分析18项关键任务Part 2价值需求篇1 目标／愿景分析
项目目标也可以称为愿景，是组织应用类软件系统项目、产品的灵魂，是对于出资人（或发起人、属主）而言价值的体现。但在很多需求实践中，目标、愿景描述常常是空洞无物、混沌不清的，写出一些放之四海皆准的定性描述，失去了指向性。1.1 任务执行指引
目标／愿景分析任务指引，如图1-1所示。图1-1 目标／愿景分析任务指引1.2 知识准备
要执行好目标分析任务，首先需要深入理解三个关键知识点，即需求=预期–现状；目标就是问题和机会；目标的三种描述方式。1.2.1 需求＝预期－现状
生活悟道场你们平时有请过父母到装修高档、菜价较高的酒店“打打牙祭”、尽尽孝心的经历吗？在这种时候，你感觉自己的父母开心吗？是不是经常有“适得其反”的效果呢？当服务生端上一道大菜时，父母们总爱问价格，听到菜价后常常带着咋舌称贵的表情说：“如果我们自己在市场买，这些钱可以……”当你略感失落的时候，有没有思考过背后的原因呢？由于我们父母这一代，大多都经历过60年代大饥荒，而且成长于经济相对欠发达的历史阶段，因此在饮食方面的“预期”相对较低。而当今社会物质文明快速发展，饮食方面的“现状”条件优越。因此处于预期等于现状，甚至低于现状，哪还会有需求呢？那么如何应对呢？不妨同时请上你父母的几个好友，这时在餐桌上可能就会收获完全不同的效果。每上一道大菜时，他们的好友问完价格纷纷议论称贵时，你父母很可能会淡淡地说其实也还好，但内心喜悦之情油然而生。
从上面的故事中，我们可以悟出需求的真谛：需求，实际上就是用户的预期和现状之间的差距。如果没有差距，也就不会出现需求。而在任何一个时间点上，他们的预期和现状存在三种可能，如图1-2所示。图1-2 预期与现状带来的三种心理状态（1）预期高于现状：也就是用户不满于现状，希望自己的业务、管理能够开展得更好，甚至有明确的改进预期。这种情况下，用户通常会比较积极地配合需求调研，只要调研方法得当，就能够很好地识别出目标。（2）预期等于现状：我们也经常接触到一些用户觉得现状已经不错，基本能够符合自己的预期。这种情况下，他们通常对变化表现不积极，基本上很难用直接的调研方法来获取需求。（3）预期低于现状：有时部分用户甚至觉得现状已经很好，常说“想当年我们多么混乱，现在这么好”。这种情况下，他们甚至会抗拒变化，对需求的调研表现出消极的态度。
当遇到后两种情况时，就需要我们通过对现状的深入了解，提出用户可能为之心动的“新预期”，从而让他进入“预期高于现状”的状态，如图1-3所示。图1-3 提出新预期1.2.2 目标就是问题和机会
生活悟道场笔者一直都是一个纸质书的狂热爱好者，身边也有几位“同道中人”，都认为不可能因为电子书放弃纸质书，因为电子书没有“书香气”，因此E-ink屏并不打动我们。但后来我却“叛变”了，购买了Kindle，并且付费购买许多和纸质书价格相近甚至相同的正版电子书。因此，身边的这群“同道中人”纷纷表示了不解，我思考了一下，只讲了几句简单的话，就让他们也“叛变”了纸质书。我说了什么呢？其实就是两个场景：（1）你们每次想购买书时，最痛的是什么？（2）每次出差，在飞机上拿出准备好的书籍时，最常发现什么问题呢？对于喜欢买书的我们来说，书架早已被榨干，购买新书时总是发愁放哪里，或者放弃哪些旧书，着实是一种痛苦的抉择。而常常出差的我们，经常在飞机上发现“想看的书没带，带的书又不想看”的窘境。出差前体能充沛，希望利用差旅闲暇时提升自己，带的书往往比较专业。真在飞机上累得不行时，已无暇阅读。我讲完这两个场景之后，这帮“同道中人”很快产生了共鸣，也开始了自己的“电子书”生涯。
在这段故事里，我就是“给用户一个新解决方案，使其获得新预期，从而产生需求”，也就是“机会”。
如果客户对现状满意，就需要我们提出新预期来让他产生需求，这就是“机会场景”，即用户无意识需求。寻找机会场景的关键在于从用户角度思考，而不是从系统中找优点。具体思路我们将在1.3节详细介绍。
如果客户预期高于现状，那么他就会意识到这种“问题”，或称为意识得到的需求，通常可以通过访谈获得。
不管是“问题场景”还是“机会场景”，目标分析主要针对的是项目发起人、出资人、项目属主。（1）项目发起人：也就是项目的提出者，通常会对预期与现状有清晰的了解；同时也对问题的解决或机会的创造最为重视。（2）出资人：也就是为项目提供预算的人或部门；他们通常对项目的成本／效益更为关注。当项目发起人不具备预算审批权力时，就会寻找出资人的支持。（3）属主：也就是负责推动项目实施的责任人或部门。当项目发起人／出资人认为自己直接推动项目会有阻力时，就会寻求一个属主来推动。
简单来说，目标分析之前需要寻找到项目发起人、出资人、项目属主（有时是同一个人扮演多个角色）心中预期和现状的差距；或者是有意识的问题，或者是无意识的机会。1.2.3 目标的三种描述方式
案例分析某大企业人力资源部提出要开发一个高管日程管理系统，实现公司高层领导日程共享，以全面提升沟通效率。但因该公司的相关规定，提出项目需要做效益分析。人力资源部觉得不好描述，就将这一任务交给研发团队来完成。研发团队也感觉到一筹莫展，不知如何入手。我给了一个简单的建议，既然难以量化就干脆从“问题场景”入手，了解下之前有没有因为日程共享不及时，产生会议邀约不及时，从而带来业务损失的事情，并分析一下这些事情带来的损失。然后在目标描述时讲个故事：（1）问题。列举出这些真实的会议邀约不及时的故事。（2）影响谁／后果。分析这些不及时的会议邀约带来的后果、业务损失。（3）解决方案要点。罗列出系统的开发要点。最后用一句话概述系统的价值：通过高管日程共享，避免会议邀约不及时而产生的业务损失。
在这个小案例中，我们看到了三种典型的目标描述方法：定性描述、定量描述、场景化描述。（1）定性描述：也就是从总体属性、趋势、宏观的角度来说，如“全面提升客户服务质量”、“全面提高沟通效率”。这种方法的描述只是指出了一个模糊的方向，无法有效地界定系统的范围。（2）定量描述：也就是从微观的角度来说，会使用具体的、精确的数据描述。最典型的就是SMART原则：具体的（Specific）、可衡量的（Measurable）、可实现的（Attainable）、有相关性的（Relevant）、有时限性的（Time–based）。
例如，“通过系统的业务受理时限自动提醒等功能（Attainable），在系统正式投入使用后的3个月内（Time-based），将客户因业务办理超时而引发的投诉（Specific）从每月100笔以上降低到5笔以内（Measurable），从而提升客户服务质量（Relevant）”。（3）场景化描述：也就是用故事场景来描述用户的期望。例如，“大幅减少甚至避免客户因业务办理超时而引发的投诉，以提升客户服务质量”。注意这里只是列出场景化描述的标题部分，其实还应该具体写出当前的现状、它所引发的影响，以及系统可以采用的策略。更详细的方法参见1.4节“任务产物”。
定性描述通常是空洞无物、无法验证的，因此应该避免采用。定量描述最精确，易于验证，只要有可能都应该做到这种程度，但有时会难以达到。而这时可以采用折中的方案，即场景化描述，它真实、易于理解、可以验证，同时感染力强，是一种值得推广的做法。1.3 任务执行要点
目标分析这一关键任务，可以分成如图1-1所示的四个步骤执行。（1）访谈“问题”：通过对关键干系人的访谈，识别预期与现状的差距。（2）研讨“机会”：通过与领域专家、技术专家、用户代表的交流，寻找潜在机会。（3）定义问题／机会：描述问题、机会，以及它影响谁、产生什么结果。（4）分析问题并确定解决方案：深入分析问题，然后确定策略级的解决方案。
其中，访谈“问题”、研讨“机会”两个步骤可以根据实际的项目需要选择只执行一步，或者两个步骤都执行。下面我们就针对每个步骤的执行要点做进一步阐述。1.3.1 访谈“问题”
通过与项目发起人、出资人、项目属主的访谈，了解他们对项目的预期和现状之间的差距，就可以定义出系统要解决的“问题”。
在执行这一步骤时，通常会遇到两种情况：一种是外因触发的项目，通常问题不太清晰；另一种是内部提出的项目，通常已经有了基本的思路。
针对不同的情况，在目标分析时应该采用不同的策略来收集用户想要解决的“问题”，如图1-4所示。图1-4 访谈“问题”的典型策略
1．外因触发
有些时候，项目发起人会因为受到外部因素触动而提出一个项目，这时通常只有一个宏观的方向，但具体要解决的问题不够清晰，从而给目标分析带来困难。
对于这种情况，我们应该先识别项目的触因，然后根据触因选择相应的对策。最常见的触因有三种：参观考察、竞争对手动向、热点及新技术趋势。（1）触因：参观考察；策略：分享收获。
案例分析笔者有个朋友刚升任某企业CIO，有一次请我喝茶，说他们老板给了他一个任务：“明年我们计划投资一笔钱，打造一套为企业量身定做的、达到国内领先水平的信息系统，你做个计划吧。”这位朋友追问老板：“那目标是什么呢？”老板面带疑惑地回答：“我刚才不是和你说了吗？”面对这个相对空洞的目标，他希望听听我的建议。我告诉他这种项目典型就是外因触发的项目，让他从参观考察、竞争对手动向、热点及新技术趋势中试着选选触因。
“对！我们老板前一段时间带着公司的几个高管出去考察了几家公司，很可能就是这个因素触发的！”这位CIO朋友回答。我笑了笑，问他们老板是不是在国内考察了一圈。他问我怎么知道的，我说：“你们老板不是说国内领先吗？”然后我建议他和老板下次围绕这次考察的收获展开沟通。果然，当他问老板：“上次您带队出去考察，这么好的学习机会当时都没能赶上，您能和我们分享收获吗？”老板就开始“倒豆子”了，而且用了“×××能够做到怎么怎么样，我们呢？”的经典句式。
“×××能够做到怎么怎么样”，就是新的预期；“我们呢”，就是现状。由于老板在参观考察时看到了新预期，因此需求被提出了。后来我和这位CIO朋友交流时，我说老板的说法实际上是一种抽象、提炼。“量身定做”，说的是要结合企业实际情况灵活变通；“达到国内领先水平”，就是指在哪些方面做到。
从上面的案例中，我们可以发现参观考察创造了一种“离开现状”，看到“新预期”的情境。在这种情境下经常会看到自己的不足，找到一些令自己心动的“机会点”。但是却很容易被高度抽象成为定性的描述，从而出现了沟通的问题。因此我们应该还原用户观察的内容，使问题场景化，以便理解他的目标。这也就是“分享收获”的访谈策略。（2）触因：竞争对手动向；策略：竞品分析。
案例分析多年前，笔者负责一个ERP项目实施时，和对方的老板做了一些沟通。当问到总体的预期和要求时，老板回答：“不是都说不做ERP是等死，做ERP是找死吗？我们来找死了，你看看应该怎么做？”对于这样的客户，直接展开访谈是很难获得有效的需求信息的。因此，我们基于客户所在的行业，根据不同规模、发展不同阶段、不同核心商业模式分类，再对每种类型的企业能够通过ERP改进的关键业务问题、业务机会进行场景化描述。当时客户老板看到这样一个《竞品分析报告》，激动地说：“这简直就是一本可以改进的报告呀！”同时也很快地明确了自己的企业可以从ERP中获益的要点。
如果说参观考察是主动走出去发现差距，那么竞争对手新动向则是竞争带来的相对差距，通常是被动差距。当竞争对手新动向带来一定威胁和挑战时，就会催生系统升级、建设的需求。但在这种情况下，用户通常更加没有清晰、完整的思路。
针对这种触因的目标分析，大家或许从上面的案例中找到了策略。是的，关键在于我们帮助客户完成“竞品分析”。这对需求分析人员的技能要求会更高一些，需要从宏观视角进行总结和抽象，才能更好地实施。（3）触因：热点及新技术趋势；策略：分享理解。
案例分析有一次，有位朋友问我大数据需求分析如何进行。考虑到他所在企业的特点，我感到十分疑惑，因此反问他为什么最近对这个话题感兴趣。结果他告诉我：“我们老板要求我们要充分利用大数据技术，全面提高企业管理水平。”我总觉得其中暗藏玄机。我让他找机会问问老板对大数据技术的理解，后来这位朋友打电话给我，苦笑着说：“我们老板说应用大数据技术，连哪里会发生疫情都可以预测，而我们连销售数据都经常统计失真。”通过这样的答案，你猜到老板的真实需求了吗？
参观考察是看到的需求，竞争对手动向是威胁、挑战带来的需求，那么新技术、新热点则是趋势带来的需求。如何有效利用各种新技术提升竞争力，也是各类组织当前的重要课题。
但对于新技术的价值、用途的理解却也是参差不齐的，因此会带来一些与该案例类似的、似是而非的需求。
因此当遇到热点及新技术趋势带来的项目时，在目标分析之前重点在于“分享理解”的策略。只有真正理解了项目发起人对新技术的看法、理解，才能够揭开后面的真实需求。
2．内部提出
如果项目源起于内部的发起人，那么通常发起人会有相对成熟的思考，换句话说，已经认识到了预期与现状的差距。针对这种情况，可以通过有效的访谈，来识别“问题场景”。
案例分析在一次企业信息化开发项目中，客户的一位大领导来到了我们驻场开发的会议室里，强调：“在这次项目中，我们还需要全面提升客户服务质量。”现场的几位小伙子面对这个宏观、空洞的要求，没有做出任何反应，似乎在当他没说过。但我总觉得他话里有话，因此问道：“领导，您一般会通过什么方法来了解和评估客户服务质量呢？”领导回答道：“这有很多可选的方法啊，第一，可以通过了解和分析客户的投诉；第二，可以走到客户身边倾听他们的声音；第三，管理层自己体验全流程去发现问题。当然，我们还可以通过身边其他人的反馈来了解。”
“那您最近是看到哪些令您担忧的投诉，还是最近走到了客户身边倾听到什么建议，还是有什么人和您反馈了这方面的信息呢？”我问道。
“哎，其实这方面的问题不少！就在昨天，我老婆还抱怨到我们公司办了个业务饱受挫折……”领导回答道。
“那您认为是什么原因导致的呢？”我继续问，领导详细地分享了他认为的原因。
“那您希望在这方面系统给予什么样的支持呢？”我希望能够在解决方案上进一步探讨……这位领导果然没能很具体地描述，因此我就给了一些相应的建议。
就像这个案例一样，客户即使看到了问题，但通常仍然无法具体地阐述，造成了沟通的困难。而要提高访谈质量，获得有效的信息，重点在于提高自身的提问技巧。
在这个案例中，我们使用的是“表象原因决策提问法”来挖掘出用户的真实需求信息。整个过程通过“还原表象、分享原因、共商决策”三个提问步骤来实现访谈的深度。
另外，如果我们需要问一些具有多元线索的大问题，还需要使用“分而治之提问法”（可以按职能、产品服务、工作主题进行分解，如图1-4所示）来有效地引导用户梳理自己的需求。这些具体的提问技巧的详细介绍，请阅读本书的姊妹篇《有效需求获取》。1.3.2 研讨“机会”
当用户的预期等于现状，甚至低于现状时，我们就需要发现“机会场景”。机会场景的发掘可以通过新业务、新技术和新人群三个角度进行，具体的策略如图1-5所示。图1-5 研讨“机会”的典型策略
1．新业务
案例分析美国的Apple公司在产品方面凭借iPod、iPhone、iPad等一系列杀手级硬件，iTunes、App Store等创新性内容服务平台迅速占领市场、取得成功的同时，也在销售模式上创新地应用了“高端体验店＋分销”的模式。中国的小米在精准地推出了1999元、799元、699元、599元的高性价比的小米、红米手机的同时，也在营销模式上创造了新的篇章。而淘宝、京东成功地利用互联网、移动互联网开辟了新的商业时代。这一切都给苏宁、国美等传统卖场提出了新的挑战！在这种历史背景下，传统产业面临了“变则通，不变则不通”的巨大挑战，也必然会在业务模式上做出各种转型。这种转型同时也会带来很多创新产品、项目的机会。例如，苏宁将门店逐渐转型为体验店，引导用户在店里通过网络下单，这必将带来系统的整体重构等。而淘宝、京东、微店等电商渠道使众多商家改变了经营模式，他们会需要好评管理、针对曝款优化的库存管理系统等。
从上面的点滴中，大家或许已经发现了“新业务”会带来新产
试读结束[说明：试读内容隐藏了图片]