系统|重构 10 年历史的 B 端产品,我的一些经验体会( 三 )


调研后:前期对调研人员有了具体安排,那调研后也就需要有对应输出。
在此阶段我们主要输出的文档为:主要流程图,异常流程图,用户访谈记录。
系统|重构 10 年历史的 B 端产品,我的一些经验体会
文章插图
流程图例
4.2 如何进行需求梳理
因用户组老师工作繁忙,不可能把每个需求以及旧系统对应的功能一一描述给产品经理。所以,我们采取的工作方式是,根据上述产出的某用户组主要流程图和异常流程图,再把该用户组使用频率高的页面和流程图中的节点一一匹配。
这样就可以知道目前该用户组为实现自己的主要目标的过程中,在系统上有哪些操作。
还需要明确一点,需求调研是一个反复的过程,不可能每个用户组只调研一次即可。我们调研的整体思路还是采用先整体后细节的逻辑。
先整体:第一次调研了解用户组的主体流程和异常流程,再与旧系统页面做对应;后细节:后几次调研才开始了解页面上的其他场景和细节。
4.3 如何进行需求分析
对于使用了旧系统近10年的用户而言,他们对自己想要什么、不想要什么已经非常明确,而我们产品经理只需要能理解用户的核心需求并作出优化设计就可以了。
但即使是这样,我们还是会把用户的需求用”用户故事”的逻辑来理解。即,用户故事=用户+故事=人+事+故:谁要使用这个(角色),要完成什么活动(活动),为什么要这么做,这样做带来的价值是什么(价值)。
我们不是需求的搬运工,我们在刻意了解需求意义,进行需求分析之后,才开始进行产品设计。
5. 分配需求梳理工作组里的产品经理有 7 位,完全前几步,接下来就是分配具体的任务了。
我们决定以用户组的维度来进行分配任务,但这也并不是随意去分配,在分配的时候还要考虑各方因素。
前期在对用户组调研的时候,已经大概了解了对应的难易程度。于是再根据现有产品经理工作年限以及兴趣的情况,进行分配任务。
比如一个产品经理,可以分配2个困难模块,3个较简单模块;比如刚来且工作经验不足的产品经理可以先分配些简单的模块去熟悉,然后逐步开始进入深层次的协作;还有对于难度较大的模块,可以让多人共同协作。
如此一来,整体团队的工作任务就已经分配得当,大家就领好自己的任务专注执行即可。
6. 整体监控当产品模块都分配下去后,还需要计划需求梳理时间,即每个模块梳理的时间截点;
还要定期询问各位产品经理的工作情况,是否按时进行,是否遇到问题,是否需要协助等。
经常跟进进度,监控整体进度,也让整个团队的目标都在按照计划的日期如期开展。
我们只有先有条理的规划,然后一步一步执行,这样才能顺利完成任务。
三、我的感悟跨进互联网做产品经理的那一刻,我便暗暗下定决心,要成为一名优秀的产品经理。
转眼 3 年多了过去了,我在这期间看了不少产品经理的书籍,也系统地学了不少产品知识。
如果问我产品经理最重要的能力是什么?我会毫不犹豫的说,解决问题的能力。
1. 解决问题,需要系统思考在我看来,任何一个职业都是在不断发现问题和解决问题,产品经理亦是如此。
但即使是同样一个问题,换作不同的人处理,事情的完成效果也会不一样。总有些人更快些,效率高些,处理的更恰当些。
那这种能力如何去培养呢?
其实最关键的一点就是需要平时积极思考,不断的去总结和复盘。
【 系统|重构 10 年历史的 B 端产品,我的一些经验体会】