从0到1搭建B端产品,我的总结与体会

人人都是产品经理2018-06-14 12:32:39

本文重点描述产品从需求收集到上线过程中注意事项,如何避免踩坑类似的经验总结,以下内容以B端产品为例,献给同样是小白的你。

—— BEGIN ——


本人作为一枚初入产品领域的小白,在加入公司后,有幸参与了一个从 0 到 1 的项目(B 端工单系统,涉及微信 H5 及 PC 管理后台),短短几个月时间,对如何做产品有了一点自己的想法以及理解。


了解项目

熟悉业务流程及背景


当你接手了一个项目时,先不要去着急了解这个产品的功能,它的用户体验好不好。


首先最重要的是了解这个产品属于 B 端产品还是 C 端产品,它的受众人群是广大 C 端用户还是合作公司?因为二者的本质还是有比较大的差别。


使用 B 端产品的用户,希望通过这款产品可以将自己内部管理混乱的流程标准化,最最重要的就是可以提高人效。为了提高人效也许不会那么注重用户体验,更不会有一些很炫酷的交互,正如张小龙大神所说的:用完即走。因为作为 B 端产品不需要对用户增加什么粘性。


其次需要熟悉为什么要有这个产品,打造这个产品的初衷是什么?为了解决当时的什么问题?有和没有这个产品对实际业务有什么影响?提高人效是否可以量化(如:没这个产品办一件事需要1小时,有了这个产品后,办相同的事只需要 1 分钟)?整个产品的未来规划是什么?


尤其是 B 端产品,要紧跟公司的战略发展,必须熟悉了解公司当前的战略发展是什么,最重要的战略合作伙伴有哪些,这个产品在公司战略发展中起到什么样的地位。


相信对这个产品有了以上的了解后,在日后的产品需求优先级的判断,及产品设计中会更游刃有余。


需求收集


通过对以上内容对产品的历史及未来有了一定的了解后,接下来就要进入整个产品的初始阶段:收集需求。既然是一款紧随公司战略发展的 B 端产品,那么高优需求一定是来自业务部门以及相关战略合作公司。


首先收集最高优紧急的需求,也就是与当前公司战略发展最密切相关的,根据关键需求梳理 MVP 主流程,同时产出流程图。然后确认该流程图中所涉及的角色有哪些,每个角色应该有哪些最基本的功能,才能使整个流程不阻塞,走的通。


有些 B 端产品不仅涉及到公司内部的多个部门,还涉及到公司战略发展的合作伙伴,这时你就会发现每个部门或合作公司,都会对这个产品都会提一些自己的需求。


这时最重要的两个问题出现了:


1. 需求提交流程规范化


当有很多部门或合作公司同时对你所负责的产品提需求时,作为 PM ,我们是需求的收集方,同时也是需求的过滤方,更是善于梳理流程的专业户。


可以让每个部门选出一个负责收集该产品需求的负责人,每个部门人员的需求统一提交至需求负责人处;同时,每个部门的需求负责人,再选出一个总的需求负责人,由总的需求负责人收集所有部门负责人的需求,同时过滤掉一些提交重复的需求,最后以正式的形式(邮件)交至 PM 手中。


接到需求后,PM 线下和各部门需求提交人积极沟通,了解需求背后的逻辑,需求产生的原因,自己再过滤一些伪需求。


2. 需求优先级判断要明确


当非常多的需求到 PM 手中后,不可能所有需求都在一个版本做完,就算 PM 产品设计能做得完,但是也得问问天天加班加点的程序员哥哥愿不愿意啊~


所以,要制定重要的需求优先级排序,明确下一个版本要达成什么目标,需要什么功能,在不影响大版本发版的情况下,可以对哪些小的功能进行优化。


明确了需求优先级后,便可以进入到下一个环节— 产品设计。


通过以上行为收集了需求,并且明确了需求的优先级,对下一个版本的迭代目标有了更深的理解之外后,再补充一下需求收集中。尤其是迭代目标需要注意的几个重点,避免踩坑:


  • 无论任何需求传递到 PM 手中,都要与提这个需求的人直接沟通,而不是层层传递,拒绝接收二手需求(如:运营中心市场部门员工A提交需求至本部门需求负责人 B 手中,B 再将需求汇总传递至运营中心总需求负责人 C 手中,C 将需求传递至 PM,PM 需要对需求进行核实了解,应直接找到 A,而不是 B 或 C)

  • 当 PM 收集了很多需求后,自然要结合公司发展战略,总结出下一个版本需迭代的高优需求。既然是公司战略层面的问题,自然少不了开会。每次开会,会议的决策人最好在场,避免以后将本次会上的所达成的结论推翻。需求高优不高优,有时就是老板一句话的事儿。并且在会议结束后,要将会议纪要同步所有相关人员,做到信息一致。


产品设计


Axure 是 PM 吃饭的家伙,你可以不会 PS,不会编程,但是 Axure 你必须得会。


我非常享受画产品原型的时候,因为这个时候,才是 PM 真正发挥创造力的时候。此阶段最重要的两个产物,是产品原型和 PRD 文档,产品原型决定了你的产品长什么样,而 PRD 文档决定了你的产品规则逻辑。


作为产品小白,刚开始画产品原型的时候,面对一大片空白区域,真的不知如何下手,这一点我深有体会。此时不妨去看看别的产品是怎么做的,竞品也好,还是当今最流行的产品也罢,真的会帮助你少踩不少坑,最好多看几款产品,取其精华去其糟粕。


作为一款 B 端产品,要本着提高人效的心态去完成这款产品,似乎不需要多么炫酷的交互。因为这个产品的用户是上来工作的,不会因为你一个超炫的视觉效果而爱上这个产品,从而多加加班。


但是最基本的交互是必须要的,如什么时候用浮层,什么时候用弹窗,什么时候打开一个新页面,筛选是用下拉还是点击,完成一件事的操作流程是否足够简洁等等。


界面样式,只是这个产品的表现形式,应该对任何一个细小的功能有更多的联想。例如一个工单列表页,涉及到很多信息:工单提交人、工单实施人、提交工单时间、工单状态、工单完成时间、工单所在地、工单名称等等等等。


这里就涉及到信息展示的问题,要联想到谁会用到这个页面?可能是管理者要登录后台看自己公司的工单信息,那么他希望看到什么?可能要看看自己哪个员工又签单了,什么时候签的单,工单的进展如何了,并且看到这些信息之后有什么样的操作?可能要对已完成的工单操作一下服务成功,或者把某一个进展不顺利的单重新分配给自己其他员工,他希望的达到怎样的效果?


所以要对如此多的信息进行筛选,列出操作此功能的人最关心的信息,将其不关心的信息弱化,或者在工单详情页去展示,并且配上可能出现的场景操作。


在产品设计中,一定要注意产品设计的细节,任何细节都不可想当然。因为研发会根据你所有的需求描述去实现产品,可能会因为一个小细节的变动,牵一发而多全身,有时只是 PM 的一句话,但是却是研发工作的一整天。


PRD 文档的书写要细心,尽量要多考虑产品的边界值,如:设置密码,密码的长度控制在多少位,是否需要特殊符号,大小写是否有区分,对输入不规范的报错形式是怎样,文案怎么写能让用户知道自己输错了等等。


一些技术难题,可以抛给研发去处理,但是对于产品需求,一定要自己去构思完成。


产品开发


终于到了将自己的构思实现出来的重要一步,交付研发。其中自然少不了评(si)(bi),我们现阶段的产品评审流程为:组内评审—设计评审—和业务部门评审—研发评审—项目启动。


如果想着研发哥哥会按照自己的产品原型和需求文档,任劳任怨的实现出来,那你就大错特错了。


正式启动研发后,还会发现之前评审没有发现的种种问题。项目正式启动研发后,有以下几点总结:


  • 每天最好以站会的形式和大家同步彼此的工作进展,因为有些研发会有多项目并行的情况,如果有影响上线时间的情况出现,那么也好做出调整,而不是后知后觉。

  • 需求和研发成本如何取舍,根据当前项目紧迫程度做好评估。如某一个需求,研发成本比较高,那此时需判断此需求是否影响主流程,是否属于 MVP 功能,如果会影响主流程,非做不可,但是做了会影响上线时间,那么就要及时协调研发资源,如果又没有多余的研发资源可供协调,那么就要考虑变更需求或听取研发的其他建议了。如果不是影响主流程的需求,那么就要根据当前项目紧迫程度做好评估,是否可以将此需求延迟至下一个版本。

  • 如有延期上线风险,合理调动研发资源。

  • 尽量考虑周全所能遇到的场景,以便研发设计技术框架。

  • 我所用到的项目管理工具是 jira,会在每一次的项目启动后建立相关的用户故事和任务,任务分配给各自负责的研发就好,用户故事可以存放原型和 PRD 文档。


测试环节


辛苦的程序猿哥哥通过加班加点的写代码,终于通过了联调,将自己的代码部署到了测试环境,那么就该测试和 PM 上场了。


测试评审尽量叫上相关研发人员,可以作为产品实现是否正确的二次确认。并且评审要细致,将各个功能的不同操作所导致的结果考虑情况全面,归根结底还是 PRD 文档要书写全面,因为测试同学会根据 PRD 文档来写测试 case。没错,一切都是产品的锅。


每一次新版本的迭代,不仅要测试新增加的功能是否有 bug,还是测试产品的主流程是否受到本次迭代的影响。


关于 bug,我认为两种非常紧急且重要:


  1. 阻塞性 bug

  2. 影响业务的 bug


阻塞性的 bug 自然不用多说,例如你用微信聊天,信息发不出去;用携程买机票,没法儿出票。


而影响业务的 bug 是指:用携程买机票,本来机票 1000 块,但是用户 1 块就买到了,这个 bug 不属于阻塞性,但是却影响重大。


产品上线


我们产品上线的流程为:研发提交上线申请 — 测试回复测试通过并且展示 bug 处理情况—产品验证是否通过—产品上线—产品发 release 邮件周知老板们及项目成员。


产品上线意味着两件事:


  1. 可以进入到下一个版本迭代的工作当中了。

  2. 对本次上线的产品功能负责。


在此主要整理一下产品上线后的注意事项:


  • 尤其是一款 B 端产品,一定要在产品上线前几天,对公司内部用到该产品的所有部门进行相关培训,并且编写产品功能使用手册及时同步大家。

  • 线上回归测试,收集 bug,严重 bug 紧急修复;影响不大的 bug 可以考虑到下一个版本迭代修复。

  • 收集用户的使用反馈,对体验不好的功能进行优化。

  • 数据监测,最好通过线上数据,可以给业务部门一些指导性的建议。


我每天都会自己写日报,记录项目的的进展,以及某些会议达成的重要结论。并且也会记录自己在工作中认为重要的产品体会,每天没事儿看一看,相信看的多了会有更深的领悟。


—— END ——


本文由 @不过我喜欢 原创发布

未经许可,禁止转载


点击“阅读原文”下载APP