澳门葡京官网,第一手的商务信息

当前位置 : B2B

浅析:从0到1如何搭建B2B端产品?

来源:人人都是产品经理

作者:

2017-04-17 14:26:06

导读:使用B端产品的用户,希望通过这款产品可以将自己内部管理混乱的流程标准化,最最重要的就是可以提高人效。

了解项目,熟悉业务流程及背景

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

首先最重要的是了解这个产品属于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,我认为两种非常紧急且重要:

阻塞性bug

影响业务的bug

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

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

产品上线

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

产品上线意味着两件事:

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

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

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

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

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

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

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


微信扫一扫
关注EC官微
澳门葡京娱乐场官网版权所有,转载请说明出处