(此文章同时发表在本人微信公众号“dotNET每日精华文章”,欢迎右边二维码来关注。)
题记:今天的内容是我的一个简单总结,希望让没有任何经验的入门产品经理对产品设计和需求分析有一个大致的了解。当然由于是我自己的心得体会,所以未必是正确和最有效的。
如何设计一个产品,并对其进行需求分析,实际上有很多著作供我们学习和参考。从学院派的《软件需求》,到创业派的《启示录:打造用户喜爱的产品》,还有鸡汤派的《人人都是产品经理》,都值得我们一读。诚然通过阅读经典书籍确实可以让我们逐步入门需求分析和产品设计,比如我就是16年前备考MCSD的时候,通过一本《Analyzing Requirements and Defining Solution Architecture(英文原版)》入门需求分析的。但是在这里我期望总结一个简单步骤和使用的一些方法工具,来让从未做过这方面工作的朋友也可以快速了解并开始上手这方面的工作。
具体内容如下:
- 用一句话说出产品的愿景(Vision)。我要为谁(Who)提供什么(What)产品,可以为他带来什么价值(Value)。愿景是产品设计和需求分析最重要的事情,决定了一个产品的成败。这一步也同时要对使用者进行剖面分析,又称用户角色分析。形式和工具没有什么固定的,一般而言就用顺手的文档工具写出文字即可。
- 根据愿景确定产品的范围(Scope)。即要回答产品要做什么不做什么,通俗而言一般就是产品特性列表。范围在产品的不同发展阶段有可能有所不同。但是要注意:什么都做或者适用所有人的产品,要么不存在,就算存在也是一文不值。Less is More。同样,用Word写一个文字或者附加少量图示的文档即可。
- 根据范围确定的特性,从使用者的角度构想使用场景和业务流程。场景描述的是使用者会如何使用每个具体特性,而业务流程就是使用的过程。场景描述可以用文字叙述,而业务流程用Visio等工具画出流程图。
- 根据业务流程,得到UML用例。用例即系统和外部用户交互的情况。对于初学者而言,UML用例比较陌生也难以完成这方面的工作。所以从这里开始,可能就需要开发工程师协助来完成。编写用例的目的是把纯粹从用户视角的业务流程解析为计算机视角的活动。只要是绘图工具都可以绘制用例图,当然比较专业一点软件会比较顺手,Visio也可完成。另外,此步骤如果比较困难也可省略。
- 根据特性和用例,来创建用户故事。用户故事就是用一个固定格式的话语“作为什么用户,打算做什么,以便得到什么好处”,来详细描述需求点。用户故事简单而言就是对特性进行细化。可以创建史诗级用户故事,然后逐步细分,细分到容易评估工作量的粒度。用户故事理论的最佳参考资料是《用户故事与敏捷方法》。
- 编写UI原型。在进行场景描述和业务流程设计的时候,就可以开始用一些原型工具,比如Mockups或者PowerPoint来绘制UI原型图。原型图尤其可以补充用户故事用文字无法表达的内容。
由于这是一个入门介绍,所以上述步骤其实很多细节都没有深入,也没有考虑非功能性需求的分析步骤。同时,本文重点是讲解需求分析过程,所以也省略了同设计、开发相关的一些步骤。
最后再次强调,这并非最佳实践,仅仅是给初学者的一点入门总结分享。