posts - 177,comments - 176,trackbacks - 0

      最近在做平台型的产品工作,相对于垂直类产品的小而美特点不同,平台型产品更加注重生态建设,根据公司自身特色,依托现有平台资源,瞄准服务对象,从而推出一整套的解决方案。同时,相对于以前做运营商产品规划不同,互联网产品规划侧重竞品分析,业务讨论,主动规划。没有人告诉你需求是什么,BOSS定方向,产品经理基于大方向开展一系列调研、分析、头脑风暴、评审、汇报工作,最终在规定的时间产出业务和产品需求。

       结合实际工作中的一些经历和体会,分5个部分谈谈对产品需求分析思路的理解,和各位交流学习,同时附上指导自己开展需求分析工作的一些方法论。

     1、使用场景调研

       调研竞品的使用场景、产品使用流程

       备注:关注竞品有什么、此阶段不要被自身产品现状束缚。

       输出:产品调研报告

              1.梳理产品的会员体系

              2.梳理产品的账户体系

              3.梳理出产品使用过程中的涉及功能

              4.梳理不同用户的产品使用权限区分

              5.梳理产品提供的服务的生命周期管理

              6.梳理产品的支付/计费/结算体系

 

    2、渐进明细定位

       根据公司的业务方向和业务目标定义平台该承担什么职责、不该承担什么职责

       备注:高层给的是大方向,到产品定位落地是一个渐进明细的过程,需要结合公司业务目标、组织机构、业务范围、假设及依赖,产品团队多轮讨论才会逐渐明晰。

       输出:产品上下文场景图

              1.通过调研设计产品的总体使用流程,只抽象到产品的二级模块。

              2.以用户为视角绘制用户使用产品时自身产品和外部产品之间的业务交互、自身产品内部组件之间的业务交互。

    备注:该阶段可以先抽象出产品的内部组件,回答产品是做什么的?为什么要和周边产品这样划分?为什么要抽象出这些内部组件?
   

    3、明确产品逻辑

       明确平台的使用对象是谁、使用产品的流程是怎样的

       备注:根据使用对象设计产品权限、产品使用流程

       输出:产品流程图

              1.根据产品上下文场景图,将产品场景进一步细分。

              2.根据每一个细分场景,以用户为视角绘制用户使用产品时自身产品和外部产品之间的业务交互。

    备注:该阶段回答产品有哪些使用场景?这些场景都经过哪些平台?平台间的交互顺序是怎样的?为什么是这样的交互顺序?

 

    4、抽象平台组件

       依据产品上下文场景图,结合架构原则,细化管理组件。

       依据产品上下文场景图,结合架构原则,细化执行组件。

    1.对外提供的接口

      设计哪些接口该提供、哪些接口不该提供。

      设计哪些接口字段该提供、哪些字段不该提供。

      备注:

        字段的提供与否需结合平台定位、业务流程合理性、数据延时问题、技术实现代价综合考虑。

        根据业务场景设计区分查询接口、推送接口等

          2.依赖外部的接口

      设计哪些接口该提供、哪些接口不该提供。

      设计哪些接口字段该提供、哪些字段不该提供。

      备注:

        字段的提供与否需结合平台定位、业务流程合理性、数据延时问题、技术实现代价综合考虑。

        根据业务场景设计区分查询接口、推送接口等

        输出:产品功能结构图

       根据抽象出来的组件组合成产品的功能结构图,区分管理组件和执行组件。

       备注:功能结构图只描述自身产品有哪些功能模块,可以增加有交互的外部产品。

 

    5、梳理依赖关系

        1.内部组件间的关系

    根据功能结构图,以用户为视角,结合细分场景,梳理组件之间的业务关系。

        2.与外部组件的关系

    根据功能结构图,以用户为视角,结合细分场景,梳理与外部组件之间的业务关系。

       输出:泳道图、时序图

    泳道图用于描述用户在使用产品时,产品组件与外部组件之间的交互顺序和交互结果。

    时序图可以作为泳道图的补充,描述组件之间同步/异步交互时的交互顺序和交互结果。

 

    6、指导自己开展需求分析的一些方法论

        1.发现真正的问题

              1、解释:解释利益相关者说所的内容,揭示本质。

              2、分离:从所提的解决方案中分离出问题本质,无论技术如何实现,本质总是存在的。 

              3、抽象:对于任何技术,都必须从技术中抽象出来,看到它背后的本质目的。不要问技术能为你做什么,而要问技术在做什么。

              4、端到端:查看端到端的过程,忽略当前工作在部门间的划分。

              最重要的工具:头脑、眼睛和耳朵。

 
      2.寻找最佳解决方案

             1.影响解决方案的因素

                  组织机构和项目目标、限制条件、创新、包含的功能、非功能需求、用户体验、技术可行性、开发成本、差异化

             2.开发解决方案的方法

                  1)确定产品范围,业务用例中那些部分要自动化。

                  2)考虑用户,研究群体如何行为和思考。

                  3)设计用户体验,专注于用户对产品的感觉而非功能(业务分析师在这里的任务是提出建议,为业务辩护,设计由体验设计师完成)。  

      4)创新   

                      1.方便,达到产品使用起来方便,节省用户时间,让生活更方便。        

                      2.联系,让产品与顾客或用户的联系更紧密。                

                      3.信息,让产品提供所有需要的信息,让顾客执行事务更容易。

                      4.感觉,让用户用产品时感觉安全、有竞争力、产品体验快、用户服务响应快。

                      5.接口草图,快速打造解决方案,快速汲取意见、快速修改。

                      6.分析业务事件的真正起源(通常在组织机构之外),将产品边界扩展到相邻系统的思维深处。

                      7.相邻系统和外部技术,将产品边界扩展到相邻系统之前,考虑它的本质和技术,可能会决定你设计的产品。

                      8.权衡成本、收益和风险

                      9.用文档记录设计决定(产品为什么是这样)

                      10.使用产品用例场景,解决需求规格说明书的枯燥乏味不可读的问题。

               备注:

                   1.没有公式化的方法能得到最佳解决方案,你要考虑许多因素,最佳设计就是这些因素的最佳折中。

                   2.在这个阶段的思考和努力,可能意味着生命周期更长、更满意的产品,多年内需要教少的维护修改,提供更好的客户满意度,为拥有者交付更大的价值。

posted on 2015-06-07 21:38 cheng 阅读(3065) 评论(1)  编辑  收藏 所属分类: 互联网产品

FeedBack:
# re: 再谈需求分析
2015-06-29 12:17 | 好介绍
这个需求分析分享的介绍值得一读再读,很有启发性!  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: