17 | 需求分析到底要分析什么？怎么分析？

Apr 4, 2019

17 | 需求分析到底要分析什么？怎么分析？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

17 | 需求分析到底要分析什么？怎么分析？

2019-04-04 宝玉来自北京

《软件工程之美》

课程介绍



讲述：宝玉

时长17:03大小15.58M



你好，我是宝玉，我今天想与你分享的主题是“需求分析”。
通过前面的学习，我们知道在瀑布模型中，第二个阶段就是需求分析阶段，同时需求分析的结果也决定了后续的系统设计、开发、测试等阶段能否顺利如期进行。即使是用敏捷开发，同样也少不了对需求的分析整理。
可以说需求就是整个产品的源头，所以需求分析的结果往往决定了产品的成败。如果没有正确把握客户需求，可能就会一步错，步步错！
就像我在《特别放送 | 从软件工程的角度解读任正非的新年公开信》提到的秋千的案例：
客户想要一个给三个孩子玩的秋千；产品经理以为就是一个板子加两绳子就行；架构师发现除非把树截开，否则秋千没法荡起来的；程序员以为用绳子和板子连一起就完事了；而真正满足客户需求的，也就只要在绳子上挂个轮胎而已！
所以在本篇文章中，我将带你去了解：需求分析到底要分析什么？以及我们怎么样才能做好需求分析，抓住用户的真实需求，做出来客户想要的软件产品，避免失败或浪费。
什么是需求？我们日常在项目中，经常会听到“需求”这个词，比如说：
项目经理对产品经理说：用户给我们提了一个需求，想要一个给三个孩子玩的秋千，你分析一下；
产品经理对架构师说：我们现在有一个需求，在树上拴两绳子，再吊一块板子，你做一下设计。
很明显，这两个需求的意思不一样，前面这个需求是用户需求，后面这个需求是产品需求。
用户需求是由用户提出来的，期望满足自身一定需要的要求，例如用户说：“想要一个给三个孩子玩的秋千。”这种原始的用户需求通常是不能直接做成产品的，需要对其进行分析提炼，最终形成产品需求。
产品需求就是在分析提炼用户真实需求后，提出的符合产品定位的解决方案。就像上面“在树上栓两绳子，再吊一块板子”，就是产品经理针对用户需求提出的解决方案。
需求分析是要分析什么？其实对用户需求的分析，不是一个动作，而是一个过程。需求分析，就是对用户需求进行提炼分析，最终形成产品需求的过程。
而针对每个用户需求的需求分析过程，需要经过三个步骤。
第一步：挖掘真实需求
大部分用户提的需求，都不见得是其真实的需求，需要透过现象看本质，去挖掘其背后真实的需求。就像福特汽车创始人亨利福特说过的：
如果我最初是问消费者他们想要什么，他们应该是会告诉我，“要一辆更快的马车！”
这里“要一辆更快的马车”就是一个典型的用户需求，但这并非是用户的真实需求，用户的真实需求，需要通过分析才能得到。
要分析用户的真实需求，可以从三个角度入手。
目标用户：用户不同，诉求也不一样；
使用场景：使用场景不一样，解决方案也会有所不同；
想要解决的问题：用户背后想要解决的问题是什么。
我们假设目标用户是普通乘客，使用场景是日常出行，那么用户想要解决的问题其实并不简单是“要一辆更快的马车”，想要更快的马车只是用户自己能想到的解决方案，而他想解决的问题是“更快更舒适的出行方式”。
而现实项目中，大多数人需求分析的不正确，就是因为没有挖掘出用户的真实需求。
我们再看之前的秋千项目，目标用户是三个孩子，使用场景是一起户外玩耍，想解决的问题其实是能有一起玩的娱乐设施。
第二步：提出解决方案
我们知道了目标用户，其使用场景和想要解决的问题，就可以结合产品定位，提出相应的解决方案。
比如针对想要“更快更舒适的出行方式”日常出行的乘客，我们就可以提出汽车的解决方案，而不一定要局限于马车，汽车能更好的满足用户需求。
针对三个孩子想有一个在户外一起玩的娱乐设施这个需求，我们可以提供一个轮胎式的秋千，就可以很好的满足他们的需求，我们甚至可以建一个小型游乐园。
第三步：筛选和验证方案
在提出方案后，我们需要对方案进行筛选，比如对于秋千项目，建小型游乐园的方案虽然能满足需求，但是成本太高，需要排除掉。
在选好方案后，还需要对方案进行验证，以确保方案能解决用户需求。
在传统瀑布模型中，选定方案后，会写成产品设计文档，走相应的评审流程，评审完成后再进行设计、开发和测试，测试完成后会让客户再进行验收。而敏捷开发，在整个开发过程中，每个迭代或者关键的里程碑，也一样需要客户进行验收。
通过以上三步，就可以对用户需求进行提炼分析，最终形成产品需求。
所以在需求分析过程中，分析的就是一个个用户的需求，找出背后的真实诉求，再有针对性的提出解决方案。
对于解决方案，要进行筛选和验证，有些不可行的用户需求不会变成产品需求，可行的用户需求会按照优先级进入实施阶段，最终变成产品。
怎样做需求分析？前面我介绍了对单个用户需求的分析，主要经过三个步骤：
第一步：挖掘真实需求；
第二步：提出解决方案；
第三步：筛选和验证方案。
而软件项目的用户需求，从来就不是单一的，而是一系列需求，所以对于软件项目的需求分析，还需要增加收集整理的步骤。整个过程是迭代进行的，如下所示：
收集需求：对用户需求进行收集整理；
分析需求：对需求进行分析，挖掘用户真实需求；
需求评估：筛选过滤掉不可行的需求；
需求设计：针对用户需求提出解决方案，设计成产品方案；
验证需求：验证方案是否可行。
我在美国 DePaul 大学读书的时候，曾在学校兼职，当时接到一个项目，要为计算机学院的网络教学系统做一个网页版的播放器。
我们知道现在的课堂里面，老师上课的时候，会用电脑放 PPT 或者课件，同时还要在黑板（也有的是白板）上写写画画辅助说明。
DePaul 大学的网络教学系统，就是在老师上课的时候，用摄像头把老师讲课的整个过程都录制成视频，同时也会用特殊的软件，把当时电脑屏幕上显示的内容，和白板上写的内容，都录制下来。
这样选网络课程的同学可以通过网络直接观看，既不会漏了老师讲的内容，也不会错过老师在电脑上放的和白板上书写的内容。播放器要做的就是要播放录制的教学视频、电脑屏幕和白板。
我将以这个项目为例，讲讲如何做需求分析。
1. 收集需求
这个项目的原始需求是老师给我的，只是告诉我要做这样一个播放器，让学生能看教学内容。而这个需求还不够，我还需要继续收集用户需求。
收集用户需求有很多方法，这里列举部分：
头脑风暴：就是大家一起开会头脑风暴讨论；
用户调研：通过调查问卷或者访谈，通过问用户一些问题收集反馈；
竞品分析：通过分析其他同类产品的功能获得需求；
快速原型：通过原型来收集反馈，收集确认需求。
拿播放器的项目来说，头脑风暴没有足够的项目成员，也没有同类产品可以做竞品分析，做原型的话，成本有点高，所以用户调研就是最适合的收集需求的方法。它不仅简单，而且能收集到真实的用户反馈。于是我通过微信群、邮件、用户访谈从老师、领导和学生那分别收集了一些反馈。
老师们没有什么有效反馈，因为他们基本不需要用到这个软件，领导们有个需求就是希望能播放字幕，而很多学生希望能有 2 倍速快进功能。
2. 分析需求
收集了需求，就要分析用户的真实需求，这是最难的部分，也是最体现产品经理需求分析水平的地方。
用户需求背后的真实需求有三个层次：
表层需求：用户对解决问题的期望，例如马车更快；
深层需求：用户的深层次动机，诉求产生的原因，例如乘客对出行速度的要求；
底层需求：人性本能的需求，例如对安全感对舒适的追求。
要分析好用户需求背后的真实需求，就是要结合“目标用户”和“使用场景”，按照上面三个层次去思考。
我们拿刚才播放器为例，目标用户是学生，使用场景是学校机房或者家里，希望解决以下问题。
字幕的问题：
表层需求：显示字幕；
深层需求：语言不好，跟不上老师节奏；
底层需求：聋哑学生无法听到声音，只能通过字幕学习。
快进的问题：
表层需求：能快进播放；
深层需求：可以节约学习的时间，提高效率；
底层需求：取得好的学习成绩
经过这么一分析，基本上就对于用户的真实需求心里有数了。
3. 需求评估
需求收集分析完了后，还需要进一步评估，以决定做还是不做，优先级如何，先做哪些再做哪些。
需求评估考虑的因素有：
可行性：技术能否实现；
成本：人力成本、时间成本；
商业风险和收益：有没有商业上的风险，收益是否合理；
紧急性与重要性：是不是用户迫切的需求。
如果确定可行，还需要评估其优先级。评估优先级一个简单的方案就是用“紧急重要四象限”的方法来区分：
复杂一点的有 KANO 模型，如下图所示。
红色曲线，是用户认为必须要有的功能；
绿色曲线，就是用户明确提出的需求；
黄色曲线，属于兴奋型需求，就是用户自己没想到，超出预期的功能。
回到我们播放器的例子：
红色曲线（必须要有的功能）：能播放视频、播放电脑屏幕，播放白板；
绿色曲线（用户明确提出的功能）：字幕、2 倍速快进；
黄色曲线（超出预期功能）：10 秒快进、10 秒快退、在时间轴上记录笔记。
4. 需求设计
在分析和评估完需求后，还需要提出解决方案，也就是对需求进行设计，做出来有效的产品设计方案。最终的产品设计，会落实到人机交互上面，用户可以通过软件界面交互。
现在产品设计方面，各个平台都有一套比较成熟的界面标准控件，大部分产品设计都可以基于标准界面控件，组合成满足需求的用户界面，在满足功能的前提尽可能做得易用和美观。
在需求设计的时候，可以用草图、原型设计工具、界面设计工具进行设计。
在需求设计阶段，可以参考其他成熟的产品。比如我在设计播放器时，也是通过借鉴其他软件的设计来完成的，比如说向 Youtube 借鉴了视频播放器的设计，向 Skype 的电话会议系统借鉴了其播放区域切换的交互，最终完成了产品设计。
5. 验证需求
在需求设计好后，还需要进行验证，看解决方案是否能满足用户的需求。
对需求的验证方式其实是贯穿整个软件项目生命周期的，在需求分析阶段，会反复验证确认设计好的需求是否满足用户的真实需求，例如各种设计评审。
在产品开发完成后，也需要有需求的验收，以确保开发出来的软件产品是客户想要的，满足客户需求的。
现在很多互联网产品，还有一种基于数据的验证需求方式，也就是 A/B 测试。
设计好一个功能上线后，并不直接让所有用户使用，而是先给一小部分用户使用，然后分析数据，看使用这个功能的用户群和不使用这个功能的用户群，在营收、访问量、活跃度等关键数据上是更好还是更坏。如果好，就加大比例，如果数据不好，可能就会调整甚至取消这个功能。
我在设计播放器的时候，首先用 PPT 做了一个简单的草图，拿去给老师确认，收集一些反馈后，写了一个 PC 版的软件原型，拿给一部分同学试用。在收集反馈后，做了一些修改和调整，最终确认了产品的设计。
在需求分析完成后，就可以基于需求分析形成的文档，进行设计和开发了。（DePaul 大学的网络教学系统产品演示）
总结今天带你一起学习了软件工程中一个非常重要的知识点：需求分析。
需求分析，就是一个将用户需求变成产品需求的过程。要做好用户需求的分析，需要找出来隐藏在用户需求背后的真实需求，还要针对用户的真实需求提出解决方案，最终验证方案是不是能满足好用户需求。
需求是整个产品的源头，很多软件项目失败的原因就在于没有做好需求分析，软件中很多浪费也来源于需求没想清楚导致的返工。做好需求分析对于软件项目来说非常的重要。
要做好软件项目的需求分析，需要做好需求的收集整理工作，然后对收集好的需求进行科学的分析，评估是不是可行以及划分优先级，对可行的需求项进行设计，最后还要验证设计出来的结果是不是满足需求。
希望你通过这节课的学习，能科学地运用好需求分析的知识，对项目的需求分析把好关，保证最终产品能满足用户需求，超出用户预期。
课后思考你工作中有没有遇到因为需求分析没做好导致项目失败的案例？你了解 AB 测试吗，有在项目中用过 AB 测试吗？极客时间的课程为什么要支持音频？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 11

提建议

16 | 怎样才能写好项目文档？

18 | 原型设计：如何用最小的代价完成产品特性？

 写留言

精选留言(25)

Charles
2019-04-04
思考1（需求分析没做好失败案例）：客户做了好多年澳洲海鲜批发生意，发现很多C端用户只有在少数大酒店才能吃到真正比较好品质的澳洲海鲜，所以想做个面向熟悉城市的地方性商城，自己搭建仓促、物流、售后等，让用户在家里就可以吃到好的澳洲海鲜产品，最终由于线上运营成本方面考虑，只做了线下的类似生鲜门店和餐厅的结合体，线上部分做了一半就没有进行下去。跟着老师的文章思路，现在看来当时只做到挖掘了客户而非用户的真实需求，接着就直接提出解决方案和技术可行性发现没问题，没有在成本方面和客户探讨是否能支撑到位想做的事情。思考2（AB测试）：了解AB测试，但是目前的项目中更多的是人工方式去分析新功能是否可行，比如做了某个功能，入口隐藏掉，但是网址可以访问，提供给部分用户网址让用户使用新功能，收集反馈，也算吧？😀 思考3：极客时间课程音频功能满足几个用户需求点：1. 上下班路上或开车等场景下不方便看文字，先听一遍音频，到了方便看文字的场景再过一遍音频里有时候消化不了的内容，利用不同的场景结合提高学习效率和效果 2.一边听音频一边看对应的文字，对于那些看书困难户，体验很好没有心理负担
展开
作者回复: 挖掘客户真实需求这事，属于典型的知易行难，做好确实不容易。 AB测试如果配合数据分析，会效果更好。用户反馈可能会说谎，数据不会：）赞，分析很到位👍
12
bearlu
2019-04-04
今天这篇文章信息量很大。我想问问，我是否总结成一个思维导图，方便形成模式？
作者回复: 👏如果你能总结成思维导图那再好不过了，无论对你自己，还是分享出来对其他人，都很有帮助
7
hua168
2019-04-06
老师，需要分析不是产品经理的事吗，我们开发不用需求分析的吧？不是产品经理把需求文档交给开发，开发有什么不懂再和产品经理沟通吗？是不是大家理解一致，开发知道产品经理这个需求的作用、解决什么问题，然后大家理解的是不是一致就好了？需求分析好像与开发关系不大呀？
作者回复: 这是个好问题。理论上来说，需求分析是产品经理的事，但不意味着程序员不需要懂。具体我在下一篇《19 | 作为程序员，你应该有产品意识》有详细解释，为什么开发也应该懂一些需求分析的知识。
5
易林林
2019-04-04
目前还没遇到因需求分析没做好而失败的项目，只是遇到过因需求分析没有做好而完成得非常艰难的项目，不断变更，不断调整，不断加班...，有点绝望中死不足惜的那种味道。需求分析在项目中的重要性不言而喻，不过大部分软件项目对它的重视基本上都来源于“没有需求就不能开工”，更像是一种仪式，并且还要求仪式做到尽善尽美，否则延期的锅就是需求分析的人来背。真正实施项目的人不会在乎需求是否合理，是否某些方面值得改进，即使在乎也只是在心里嘀咕两句就算了，谁也不愿意惹事。项目做完是我的责任，项目做错是你的责任。我觉得这里比较重要的一点是：需求跟踪，有了跟踪就有了不断改进和完善的空间，有了将项目不断拉回预定轨道的可能，只要在需求跟踪过程中控制好变更的时机和频率，无论对产品需求还是对具体的项目实施人员都是非常有利的，项目的成功率也会大大增加。
展开
作者回复: 没需求当然不能开工，需求是项目的源头。没想清楚就开工，然后边做边改也是软件项目一大特色。不过没有想清楚的需求，第一版最好快猛糙快速原型式开发，另外聚焦核心需求，否则后期变更太痛苦。
5
六维
2019-04-07
突然接到一个通知，需要和第三方的人员开会，当时也不知道需求是什么，参加会议后，听明白对方需要的，和上级领导确认他的目标后，发现两者，各自有各自的目的，是对立的。反馈后，上级领导还是坚持要做。结果对接上线后，完全没有使用过。这种情况也不止一两次了，感觉很是无奈，总是做一些无用功，却又没办法改变现状。
作者回复: 大家目标不一致很正常的，合作，就是要寻找共同的目标，找到折中的解决方案。举个相似的例子：我们程序有些功能是通过Http Header的值来控制开启的，某个功能默认是不开启的。前几天我们测试的同事希望开发能打开这个功能，不需要设置Http Header。开发的同事就不愿意了，因为改了后可能还会影响其他组使用，另外过些天他们测完，估计还得改回去。所以我问了一下测试，原来他们的测试工具不支持设置http header。也就是他如果能通过其他方式测试也是OK的，并不需要修改默认行为，于是建议开发增加支持通过url参数开启功能的方式，对测试来说达到目的，对开发来说改动也不大，也不影响其他组和后续的维护。这个例子不一定和你的情况一样，只是作为一个参考，这样下次你也可以尝试思考一下有没有折中的方案。
4
AntLoin
2019-04-04
经常出现用户自己都不知道自己想要什么，而是希望先有个东西，然后他们再在这基础上来提出自己想要的。做成音频个人观点： 1、本身这个群体每天看着电脑等都很疲劳了。 2、看文稿时，如果有微信、QQ等消息时，人会不自觉的去看看，一看可能一会就搞其他去了，注意力就不在了。 3、听的同时给予了更多的思考空间，然后再结合文稿就更能巩固其中的知识点。
展开
作者回复: 是的，很多时候用户并不知道自己想要什么，你得先给他看到一个东西，然后他再会想到更多的需求。但是如果被用户牵着鼻子走成本就太高了，所以要分析需求，要做原型设计低成本的确认需求。分析的挺好，音频就是契合用户的各种特殊使用场景的需求。
3
Change
2019-10-17
1. 收集需求 * 头脑风暴 * 用户调研 * 竞品分析 * 快速原型 2. 分析需求 * 表层需求：用户对解决问题的期望 * 深层需求：用户的深层动机，诉求产生的原因 * 底层需求：人性本能的需求 3. 需求评估 * 可行性：技术能否实现 * 成本：人工成本、时间成本 * 商业风险和收益：有没有商业的风险，收益是否合理 * 紧急性与重要性：是不是用户迫切的需求 * 评估其优先级：紧急重要四象限 4. 需求设计 5. 验证需求
展开
3
小老鼠
2019-09-12
1、汽车不是比跑得更快的马车成本更高，与游乐场与秋千区别是什么？ 2、上课时老师说需求是作什么，设计是怎么做？您说的是用户需求是作什么，产品需求是怎么做。好像有矛盾。 3、如何分析隐性需求？ 4、需求分析做不做这个产品与可行性分析好像有共同处？ 5、立项什么时候做，做什么？ 6、产品工程师与需求分析师工作内容有什么区别？
展开
作者回复: 1. 成本是相对的，需要在成本和满足需求之间寻找平衡。这就好比手机从几百到上万都有，能满足不同层次需求。游乐场和秋千的差别主要也在于成本的差异。 2. 产品需求也叫产品设计，应该不矛盾 3. 分析隐性需求可参考文中“挖掘真实需求” 4. 可行性研究的基础也是要先了解清楚用户的需求，在根据需求去寻找可能解决方案以及可行性 5. 立项一般是在对需求了解，并做完可行性研究觉得可行之后再立项 6. 似乎没有产品工程师，只有产品设计师。需求分析师一般是去了解业务，了解用户的需求是什么，把专业的需求翻译的让产品设计能理解；产品设计师基于理解的需求设计出来相应的解决方案。举例来说，建筑行业软件的需求分析师需要懂建筑行业的专业知识，能明白建筑行业的专业术语，同时也要懂一些产品设计和软件开发，他们要把建筑行业的专业需求提取成软件中可行的需求，描述成产品设计师、软件工程师能理解的语言。
3
一路向北
2019-04-07
经常犯的错误是，对客户的需求理解不够底层，导致在项目做了一段时间之后，根本不是客户想要的产品。这也是文章里说的，需要表层分析，深层分析，底层分析。没有这个递进式的分析，即使能够做出符合用户的产品，也是有很大的运气成份。极客的产品有音频，主要是分析了用户的需求，很多时候用户不想对着电脑屏幕或者手机学习的情况，听音频也有一种互动的效果，和上课的学习比较贴近。
作者回复: 👍很好的反思。极客时间的音频，确实是使用场景确定的，有时候不是不想，而是不能对着电脑屏幕，比如在路上、在开车。
2
花灰
2019-09-08
宝玉老师，需求分析师在进行提出解决方案阶段的时候，需要拉上产品经理或者程序员和测试工程师一起制定么？解决方案和产品经理xiede产品文档最大的不同是什么呢？
作者回复: 提出解决方案阶段，产品经理、程序员和测试一起参与是非常必要的，这样可以协助提出技术上的可行性分析、估算工作量，避免提出一些不切实际或者成本过高的需求。解决方案写的文档是从客户的需求角度，提出要解决什么问题，比如客户说想要一个交通工具帮助通行。产品经理写的文档是从设计的角度，提出如何解决问题，比如说设计一个马车。程序员则是对方案进行具体实施，比如建造马车。
1
一铖
2019-05-16
宝玉老师，这个课程有ppt或其他整理成册的文字材料吗？
作者回复: 抱歉，暂时没有其他形式的文字材料
1
宝宝太喜欢极客时间了
2019-04-28
老师，需求分析的过程对应于UML，收集需求是否对应于业务用例模型，分析需求对应于概念用例模型及系统用例模型，设计需求就是进行原型设计呢？
作者回复: 不建议你把需求分析和UML放一起理解，UML是一种用来做设计时的手段，是偏向对已经设计好的产品需求进行建模分析的。收集需求通常是指的用户原始需求，产品经理需要进一步分析处理才能变成最终的产品需求。用例模型一般是针对已经设计好的产品需求，对用例进行建模。原型设计只是对产品设计的一种有效手段，但也不是唯一的手段，比如有的程序员，自己在脑子里就能构建出产品的模型，然后代码实现，都不需要借助原型。
1
Jay.Soul
2019-04-28
做软件外包，前期需求分析的时候虽然每个功能点都能分析到，但是后期给客户测试的时候，总是会提很多小问题小功能的修改，就导致项目成本增加。不知道老师有没有好的解决方案。
作者回复: 建议参考我后面需求变更那一章的策略，比如可以提升客户变更的成本，或者降低响应变更的成本。另外可以把客户提前确认，在半成品的时候确认时提出的小修改相对容易加进去，正式发布了问题也会少一点。
1
果然如此
2019-04-12
我认为需求分析的其中两个环节需求评估和方案验证好像是有关联的，因为只有看能不能提出合理的方案才能知道需求是否合理，老师对这这两个环节区别怎么理解的？
作者回复: 你说的对，这两个环节是有关联的，所以我在文章的图片是用的环形表示，因为整个过程是迭代进行的，评估后提出方案验证，验证后修改再评估。
1
果然如此
2019-04-11
音频的好处除了地铁、开车，还有是能快速过一遍文章，然后再仔细读每个段落。这篇让我醍醐灌顶，看了好几遍！另外，我也把看过的章节总结到云笔记里。
作者回复: 👍是的，音频主要还是结合用户使用场景的。总结是很好的学习习惯
1
hua168
2019-04-11
老师问一个题外问题： 1. 在国内英文差怎办？很多国外前进的文章看起来比较吃力，老记不住英文单词，出现过几十次就能记住了。网上有很多说通过读文章学英文四级，不知道靠谱不？英文四级够用了吧？ 2. 去国外需要考雅思/托福吗？
作者回复: 1. 多练练就好了，刚开始肯定吃力，多看看就越来越熟了。 2. 如果不是上学不需要。但是英语不好确实限制很多，比如不便于工作上的交流。
1
天天快乐
2019-04-04
音频更方便程序员们在上下班途中，比如地铁中收听。闭上眼睛，收听极客时间的音频课程，一方面打发无聊的时间，休息一下疲劳的双眼；另一方面，学习新的知识，充实自己。
作者回复: 👍是的，其实主要和文章中的知识点“使用场景”相关的。
1
rubyniu
2019-04-04
支持音频对于看书就困的人来说，是很有好处的。😂
作者回复: 你可以尝试从用户场景角度再考虑一下：）
1
远逝的栀子花
2022-09-01 来自陕西
作为研发最近经历了很头疼的需求分析: 1. 整个项目管理混乱，项目经理没有时间管理，需要自己去确认需求 2.与架构师反反复复进行需求对齐，一次次确定需求范围，不断分析需求中的风险点 3.需求要求的功能非常多，开发时间短，人力有限，三角形原理质量是没法保证的，与产品经理以及客户讨论多次，最终识别到客户的核心需求，非核心需求全部砍掉放到明年的项目规划中 4.不断识别需求中的依赖风险，提前将依赖风险提出进行评审，上升解决风险
展开
ifelse
2022-06-25
需求分析，就是一个将用户需求变成产品需求的过程。要做好用户需求的分析，需要找出来隐藏在用户需求背后的真实需求，还要针对用户的真实需求提出解决方案，最终验证方案是不是能满足好用户需求。--记下来

