产品分析 ∣ 一位博士后教我如何做软件需求分析

今天公司的高级顾问刘博士与产品经理们进行座谈，以提问回答的形式以点带面来解答、探讨大家在平时工作中碰到的一些问题，主要是针对软件方面。过程中，我向刘博提出两个问题。

一、如何更好地做好需求落地？

背景：来公司这1年多时间里，负责做了大大小小五、六十个项目的需求分析，大多都是各业务大区提过来的项目需求，在这过程中面对不同项目的需求，不断地锻炼需求转化能力，关于如何更好地让需求落地看能不能从牛人身上学习到更好的方法论。

回答：产品经理在日常的工作中，既要面对客户也要对接研发人员，在这中间充当着桥梁的作用，将业务需求与开发需求给连接起来，不同级别层次的产品经理，区别就在于“修”好这座桥的质量和效率如何。在拿到原始需求时，要有能力去甄别筛选它们，可以采用结构化方式对需求进行梳理，然后排好他们的优先级别，这样在心中对接下来要做什么事情有个比较好的认识。经过第一阶段的梳理，大概清楚要做什么事情后，接下来是将业务需求转化为系统功能的阶段，可以采用用例图（UML）的方式，将什么东西要做什么事情和如何去做给表达出来，一层层的剖析下去直至达到需求细化的程度。让开发人员知道怎么去研发。举个例子：（他拿起手中的iphone）现在我要对按下音量下键的这个需求去做分析，怎么做呢？首先我会识别出按下音量下键这个需求的合理性和必要性做个识别，清楚我为什么要去按音量下键这种场景？然后，将它转化为在系统中进行表现。在按下后，我会对软件的哪些模块进行数据的交互以及如何与用户进行交互?这就是产品经理对接开发的时候要去做的事情，同时也是让需求如何去做落地流程？

结论：其实，过去的2年工作中，我一直都是在重复着刘博士回答的这个需求落地的过程。然后我跟他说明了这个情况后，问有没有更好的需求分析方法。比较尴尬的是，他直接回答说没有，软件的需求转化过程基本都是以这种方式进行，本质上没有太大的差异。

二、在评审过程中，如何衡量抉择最终的方案？

背景：在日常进行需求评审的过程中，由于不同人员看待同样的问题方法会不一样，在评审过程中偶尔会出现开了N久的会议没有最终拍板的方案，作为产品经理面对这种情况，要如何去衡量最终的方案？

回答：随机应变。无论怎么去讨论，其本质不能变的就是要满足用户需求。再有的是出现这种情况，几种实现的方式都已经可以满足用户需求，但实现的方式不一样。针对这点，产品经理要通过博弈的方式，识破出各种方案的破绽，来引导大家形成统一的共识，做出最终方案地敲定。

结论：上面的问题其实更像是程序员与产品经理的日常撕逼。产品经理作为用户的代表，要多为用户争取更大的利益，在衡量抉择最终方案过程，多模拟应用场景来摆明依据。要是实在不行，只能这么说：方案就这么定，后果我来承担。担当的越多，责任越大，这应该也是一位成熟的产品经理在团队内的表现。

其他同事提出的问题：在您日常接触那么多产经经理过程中，觉得哪一点素质对产品经理是最重要的？刘博士答道：持续学习。社会瞬息万变，逆水行舟，不进则退。产品经理在做好分内的事情完，要再花时间去了解行业内的发展趋势，不断地学习其他优秀产品好的地方，吸其精华，弃其糟粕，不断地完善自己，与时代共成长。

刘博士建议，在产品团队中要建立起知识库，内部定期做技能、经验相关的分享。库是死的，通过分享的方式，可以让里面的知识活起来，形成产品圈特有的氛围和默契，让团队成员能够共同学习共同成长。

作者：David