如何进行有效需求分析一

　　需求分析让人头秃，笔者针对这个问题展开了通俗易懂的阐释，希望给大家以帮助。
　　你有没有因为需求分析四个字，而感到头发日渐稀少？你有多少个失眠的夜，是在思考领导说的把系统优化一下这句简单的话？你又有多少次面对客户无休止的需求变更，而想要拔刀相向的冲动？
　　这一切的背后，到底是人性的扭曲，还是道德的沦丧？
　　朋友，你的福音到了，欢迎来到大型情感类专题：如何进行有效需求分析？
　　左脑喜欢逻辑，右脑喜欢故事；最好的陈述一定是起于故事，终于逻辑。
　　今天的内容，就让我们从一则生活中的故事开始吧。
　　生活故事
　　有一天夜里，资深需求工程师老余刚忙完一个重要的项目，带着放松的心情进入了梦乡。
　　这时他年仅3岁的小孩夜里醒来，吵着要吃饼干。孩子的妈妈首先被吵醒，带着情绪训斥了小孩：半夜三更吃什么饼干，好好睡觉！
　　没想到小孩不依不饶，继续哭闹着。不久老余被吵醒了，他安静地走到客厅，找了一小会儿，果然没找到饼干。
　　他随手拿了两块吐司面包走进卧室，脸上掠过一丝自信的微笑。小子，没有饼干了，吃点面包填肚子吧！老余边说边把吐司塞到小孩手中。
　　果然，小孩接过面包后就不再哭闹了，吃完一片就乖巧地躺下。不一会儿，老余家又归了平静。
　　分析
　　从故事中我们可以看到：
　　小孩子提了一个需求，即要吃饼干。
　　而妈妈考虑的是，家里没有饼干了，并且是半夜，想要实现这个需求的话，肯定还要起床下楼，并且找到24小时营业的便利店。这个实现成本太高了，于是断然拒绝。
　　而爸爸则透过现象看本质，小孩子半夜要吃饼干，这并不一定真的是想吃饼干，极有可能是饿了。这样的需求，可以通过其他更易实现的方式更好地解决。于是，随手的两块吐司面包，就让这个家庭又重归了平静。
　　典型的三类人群
　　孩子客户
　　那你也许会问，为什么小孩子不能够直接说我饿了，而是一定要吃饼干呢？
　　因为，这就是典型的客户思维方式。
　　我们先给出这样一个结论：在方案级的探讨，客户是感性的；而在问题级的探讨，客户是理性的。
　　你是否有过这样的经历：
　　客户说，xxx功能我们想要，你给我们加一下吧。
　　这样看似非常明确的需求，但往往很容易发生颠覆性的需求变更，到最后客户自己明确说明的这个功能，自己又把它给亲手砍掉。原因可能很简单，也许就是三个字：不好用。
　　这种经历，能给我们带来什么样的启发呢？
　　这句话很关键：客户是问题专家，而非解决方案专家，他提出的方案未必能够完美解决他遇到的问题。
　　小孩子提出想吃饼干，这是一个方案级需求，这极有可能是因为小孩子脑海中突然回忆起了饼干的味道，并且小孩子才3岁，客户的感性思维，在这里体现的淋漓尽致；而小孩子饿了，这是问题级需求，这才是需求的本质。
　　我们可以看到，以吃饼干这样的方案来解决饿了这样的问题，显然是不合适的。
　　我们再来说客户的理性一面，当你跟客户沟通这样的话题：在当前工作中，有哪些方面你会觉得有困难呢？
　　这个时候，你会发现，客户表达出来的内容，就像滔滔江水、连绵不绝，如黄河泛滥、一发不可收拾，并且还会加上各种事例来佐证他的观点。如果可以，他可能更希望拿个U盘，把他遇到的这些困难直接传到你脑子里。
　　而这些内容，往往都是理性的，都是客观存在的事实。当然，这也是我们需求分析的突破口，我们后面也会提及。
　　妈妈程序员
　　典型的技术思维，关注的是方案级需求，即吃饼干这个方案能否实现。
　　我们脱离这个故事，在我们的实际工作中，究竟什么是技术思维呢？
　　关注点：实现方式、技术架构、技术价值、开发成本。
　　定义：从功能和工程实现出发，在满足产品需求的同时，寻找可复用技术架构和低开发成本。
　　爸爸产品经理
　　典型的产品思维，关注的是问题级需求，即小孩子遇到的本质问题是饿了。
　　同样，我们看一下在实际工作中，产品思维是怎样的定义？
　　关注点：用户价值、使用场景、商业价值、业务闭环。
　　定义：从用户价值出发，在满足商业战略和业务目标的同时，寻找产品路径满足用户需求。
　　需求打开的正确方式
　　通过开篇生活中的故事，我们可以体会到，要做好软件需求工作，业务驱动需求思想是核心。而作为产品经理或者是需求分析师，我们不是简单的需求传递者，我们是问题解决者的角色。
　　那么，在与客户进行沟通时，需求打开的正确方式是怎样的呢？
　　澄清问题了解背景建议并确定解决方案
　　1。澄清问题
　　想要解决谁的，什么问题？
　　用户现在遇到这个问题会采用什么样的解决方案？
　　这个问题中有需要进一步细化和明确的概念吗？
　　2。了解背景
　　该需求谁使用？什么时候使用？具体怎么做？
　　有需要澄清的业务术语吗？它们的格式是什么？
　　不做谁生气？多久生气一次？多久用一次？
　　3。建议并确定解决方案
　　要解决这个问题有哪些可行的解决方案？
　　这些方案的实现成本分别有多大？
　　你觉得哪种最合适？
　　该解决方案对用户而言有什么优缺点？
　　有其他需要挖掘的需求吗？
　　需求全景图
　　写到这里，不由地想起之前面试的经历。
　　面试官问我，一个产品研发完整流程分为几个阶段，每个阶段的占比是多少。
　　我当时做了这样的回答：一个完整的产品研发流程中各部分的占比，大概50做需求，30做开发，20做测试。
　　然后，面试官紧接着问我，既然需求分析占比这么高，那说一下需求分析的方法论吧。
　　我突然发现自己对于这方面方法论的研究几乎空白，只知道最终的产物，是利用Xmind列一个功能清单，但至于这个功能清单是如何得出来的，我当时的认知是具体问题具体分析。
　　当我看到《有效需求分析》这本书中，提出了需求全景图的概念时，真犹如哥伦布发现了新大陆一般，不禁惊喜万分。需求全景图，包含了诸多内容，但自己感触最深的还是功能主线这一项，毕竟我们每天都在与功能打交道。
　　回到我面试的那个问题，最终的功能清单是如何得出来的呢？
　　最好的思考角度，就是厘清系统中的所有功能是因何而存在的，这也正是我们前面所说的，需求分析的突破口。
　　功能主线的梳理，无外乎以下三个角度：
　　1。业务支持
　　固化优化业务流程，因此业务流程是核心；
　　业务延伸到新的通道（诸如手机端），这从本质上来说也是一种流程的重构，核心还是业务流程；
　　将个人能力转化为组织能力，这种能力存在于具体的业务场景中，因此专家场景是核心（后续的文章会详细论述）。
　　2。管理支持
　　事前风险避免，通过增加管理流程；
　　事中风险控制，通过规则和审批；
　　事后总结优化，通过数据分析。
　　前两种通常会在业务支持分析中统一处理，第三种则应该独立进行分析。
　　3。维护支持
　　系统投入使用之后，还需要对其进行维护，最典型的包括初始化、配置、排错等，而这些运营维护场景也都需要有相应的功能来支持。
　　当然，功能是我们的最终落脚点，但需求分析不单单是功能，这里先把需求全景图展现给大家吧：
　　结语
　　需求不是一场简单的头脑风暴，也并非高深的诸如马斯洛需求层次理论，更不是领导交代的任务、运营提供的方案或是客户要求添加的功能，需求是一项系统的工程，更是一门生活的艺术。
　　我们经常在电视中看到，古代的那些位高权重的大臣，几乎每一个都是需求分析高手，没事就在那犯嘀咕：皇上今天说的这句话是什么意思呢？
　　由此可见，需求分析不仅仅是软件领域的方法论，更是存在于我们生活的方方面面，让我们一起探索需求全景图的奥秘吧！
　　注：我们探讨的需求分析，是基于B端产品。当然，C端的小伙伴也是可以参考的。