本文主要是介绍需求的冰川，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在面对客户、面对用户或是面对五花八门的产品时，我有时会忍不住问自己，到底什么是需求分析？这概念好像哪哪儿都有、无人不知无人不晓，又好像深不见底难以摸个透彻。那我们在谈论需求分析的时候，都在讨论些什么？
要谈论需求分析，先要说说需求本身这个概念。在我们的语境中，需求往往包含了两层意思：
- 用户需求：从用户自身角度出发产生的“自以为的”需求
- 产品需求：由综合提炼用户的真实需求而产生的符合组织和产品定位的解决方案
这样一来，重点显而易见：真实需求和解决方案。如何挖掘需求、如何确认需求和解决方案我们已经有了很多成熟的方法论。但真实的需求又是什么？如何知道我们拿到的就是所谓“真实的“需求？要想摆脱需求罗生门，无限接近用户真正的需求，让产品从能用到好用，恐怕第一大忌就是“想当然”。
“想当然”，很大程度上等于我们经常在讲的making assumptions。做合理的assumption并积极地验证假设从来不会造成问题；可怕的是没有意识到assumption的存在还自我感觉良好，这大概就是我们中文里“想当然”所包含的意思了。
拿到我们的项目交付语境中，“想当然”是什么？是懒做甚至不做用户调研关起门来做需求；是自以为了解用户也了解客户没经过验证就敲定了需求；是偏听偏信客户爸爸的话说什么就做什么。
用户研究与验证
了解用户/客户是个庞大的课题，当用户体验被不断强调，可能没有人会跳出来否认用户研究和验证的价值。但反观我们的实践，很多时候业务分析师在需求层面上对用户研究和验证的重视还远远不够。
造成这种缺失的一大原因在于角色的割裂。有人理所当然地认为用户研究与验证是设计师的事，毕竟他们的头衔才是“用户体验设计师”。在产品同质化严重的今天，“体验”二字包含的不单是界面好不好看，操作顺不顺畅，更是背后的业务逻辑和痛点把握。如果强行将需求分析和用户调研分割开来，我们所做的需求分析很可能是浮在真相表面的“假需求”，所谓用户体验更是无从谈起。
业务分析师常常被形容为产品和交付之间的桥梁，产品经理把握产品走向，聚焦产品成长；业务分析师则往返于产品经理和程序员之间，专注如何迅速有效地让产品落地。于是，有人理所当然地把用户研究与验证的锅扣在产品经理头上，认为他们作为产品的最终负责人，应该由他们去做用户反馈的收集，再传递给业务分析师。
首先，我们应该承认产品的需求和运营是无法独立存在的，如果业务分析师和产品经理是纯粹的上传下达关系，分析师既不接触用户也不关注反馈，他甚至连“好”的定义都模棱两可，如何能分析好需求又怎么做好一个产品？其次，虽然产品经理们对自己的行业和领域有很深的了解，但对产品的规划设计和交付却很难面面俱到。他们不是不愿意做好用户研究与验证，而是不一定具备这种能力；即使做好了，也很难知道如何准确地把合适的信息传递给业务分析师和交付团队。
我们不止一次地强调“复合型人才”对产品构建和组织转型的重要性，在需求分析领域，用户研究和验证或许是呈给业务分析师的第一份考卷。
“了解用户”无法一劳永逸
在没有直接接触过用户、也没有参与过产品前期设计活动的时候，我曾经想当然地认为“了解用户”是售前团队、产品探索和规划设计团队的事情；我作为交付阶段的业务分析师，只要跟着项目计划保证交付就好了。后来有机会接触了更多项目更前期的阶段，开始认识到事实也许并非如此，但也并没有付诸实际行动。原因再简单不过：项目交付已经焦头烂额，花“额外的”精力去做用户研究和验证只能带来眼见的工作量负载而非立竿见影的成效，更别说有招致需求膨胀的可能，不如作罢。
在产品探索和规划设计阶段，由于时间紧、任务重，我们的用户研究与验证往往侧重在产品概念层面，确保产品方向性的正确。因此，即使在产品快速启动时产出了完整的需求列表和设计，也不意味着他们统统是ready to go的状态；更不意味着在交付的第二期、第三期，可以照搬当时的产出作为产品目标。“了解用户”无法一劳永逸，反之，它应该是持续的：在产品进入稳定的交付阶段后，业务分析师应该继续积极了解用户，不断验证并挖掘需求；用户和环境都在改变，该重新组织产品规划设计工作坊的时候，不能搪塞了事。
我目前所在的团队正在做一个听起来挺无聊的需求：给产品中的某功能换名字。我们的产品旨在帮助企业员工提高心理健康水平，在必要时进行干涉并提供援助。这个产品已经上线两个月，收到了不错的用户/客户反馈，但是从GA收集到的数据来看，发现我们当初产品设计阶段收到正面反馈的一个功能使用率并不理想。团队经过用户研究发现，从某种程度上看，是这个功能的名字出了问题。因为用户大多常常处在焦虑状态，这个叫“Goal”的小功能让人觉得压力山大，commitment很重以至于overwhelming，结果干脆不用；我们将在下次发布中，把“goal”换成“pathway”，让人觉得这是压力生活下的一条绿幽小径而非任务/目标。
Stay hungry, stay foolish
用户研究和验证的方法千千万，我不在这里一一列举。Stay hungry, stay foolish这句用烂了的话，恐怕是我能找到的最契合“BA怎么做用户研究和验证”的原则。面对客户的需求，多问一个为什么；面对用户的答案，多想一个为什么；能最大程度地避免“想当然”，或许就能最大程度地做好“用户研究和验证”
我们常常形容需求是冰川，露出海面的只是冰川一角。写到这里，我忽然想起去年夏天我在某客户的合作工厂做用户测试，工人们因为厂房过于炎热光着膀子也不带安全帽，我趁他们休息间隙想要和他们聊一聊，我走过去蹲在抽烟的人们旁边想要加入他们，但几乎于此同时，大家都站起来离开了。想要融化冰川，或许不只是挖掘那么简单。
更多精彩洞见，请关注微信公众号：思特沃克
这篇关于需求的冰川的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
