接手新项目,落地产品前要先能「想清楚」,才能「做明白」

0 评论 6300 浏览 9 收藏 17 分钟

编辑导语:产品经理接手一个新项目之后,做好业务梳理和方案规划非常重要,这有利于更快地推进工作;并且在产品落地前,需要通过不断的检测,实施线下巡检标准化等等;本文作者分享了关于复盘项目的经历以及实践经验,我们一起来看一下。

从入行产品到现在的 2 年时间里,自己做过了不少项目,比如现在的:线下巡检标准化、员工行为管理系统等等。

但一直没有体系化的复盘这些经历,为了能让这些实践成为自己的经验,接下来决定对它们做个总结。

下面,先从线下巡检标准化这个项目开始,希望我的思考能带给你一些启发。

一、什么是线下巡检标准化

公司服务的客户,业务上会通过线下巡检的方式,管理旗下门店的日常运营情况;而我们是将这种业务模式产品化,帮助对方更有效率的开展工作。

这类服务模式的 SaaS 产品,属于支持客户业务开展的一种手段,帮助这一类存在相同痛点问题的客户,为公司创造商业价值。

二、为什么要做线下巡检标准化?

这是我入行产品做的第 1 个大项目,从参与到主导,虽然当时做得懵懵懂懂,但通过事后复盘,发现很多信息都藏在了日常沟通中。

后来我发现,无论是做产品规划,还是落地项目,遵循自上而下的思考模式,能帮助我们「更有效地厘清做事的思路,避免事后返工浪费公司资源」,以我这次做的项目为例去分析:

1. 公司定位

公司提供的是视频监控运营服务,通过接入客户门店内的摄像头,对监控画面进行切片、过滤等处理方式,关注客户指定的员工行为,定期告知客户。

PS:不同行业的客户,接入摄像头的线下单位的叫法会有不同,比如餐饮、零售行业等叫做门店;消防、工地等叫做站点;学校叫做校区或幼儿园;考虑公司服务的客户,大部分是餐饮行业,所以下面统一叫做「门店」。

1)客户有哪些?

连锁品牌这类 B 端客户,以及政府、企业级的客户。

2)要解决客户的什么问题?

第 1 类客户:连锁品牌这类 B 端客户(餐饮为主)

随着客户门店数量的增多,为了提高管理效率和透明度,客户会制定员工行为巡视标准,规范管理门店,比如:员工着装是否规范、后厨是否有人吸烟、仓库是否有老鼠等。

客户购买我们的服务,希望能在营业日抓拍员工行为,获取门店日常工作开展规范情况,并辅助他们奖惩、整改门店。

第 2 类客户:政府、企业级的客户(餐饮和工地项目为主)

根据政府监管要求,为了避免安全事故的发生和隐患,客户会通过场地的摄像头进行监管。

以工地的业务场景为例,客户购买我们的硬件盒子和算法服务,比如:未戴安全帽、渣土车密闭等,摄像头会基于算法实时抓取特定行为;再配置专门负责监管违规的员工,处理告警反馈的违规情况。

3)解决思路

为了解决客户的这些问题,基于客户的特性,我们提供了两类服务:

  • 自运营:将产品(全部权限的后台 + App)交付给客户,由对方自行安排运营人员管理门店,以及自行推送员工行为的报告。
  • 代运营:将产品(部分权限的后台 + App)提供给客户,由我们提供运营服务,客户只需接收员工行为的报告推送,再确定后续的业务处理流程,看是否需要奖惩或整改。

这两者最大的区别,在于员工行为是由我们的运营人员抓取推送给客户(代运营),还是由客户自己的员工抓取推送(自运营)。

至于这么做的原因,是因为大部分客户的门店数量少,配置人员管理的成本高。

因此,对于连锁品牌的 B 端客户,大多是以代运营为主,少数门店多、信息化程度高的客户,会选择自运营。

而对于政府、企业级客户来说,都是以自运营的硬件设备 + 软件产品的方式提供服务。

2. 产品定位

基于公司定位,推导产品定位。

1)用户群体有哪些?

  • 外部客户:自运营和代运营模式下的客户,以及服务代理商。
  • 内部客户:代运营模式下的公司运营人员。

2)提供了哪些产品,产品的定位分别是什么?

  • 线下巡检产品:为客户提供门店的线下巡检管理工具,提供不同业务下的规范管理、任务制定等相关的运营支撑能力。
  • 线上巡视产品:为客户提供门店的线上巡视管理工具,通过人工运营服务,提供灵活的员工行为抓取,以及报告审核与推送等相关的运营支撑能力。
  • 算法盒子产品:逐步支撑工地和后厨环境下的监测管理流程,为政府、项目承包方等大型客户提供场景化告警的能力,提升处理违规的响应速度,降低事故发生的风险。

3)用产品做什么?

整理上面的信息,得到下图:

以我的项目为来说,通过客户类型、服务模式、用户群体可以发现,线下巡检产品其实属于线上巡视产品在业务上的延伸。

要知道,公司的核心产品之一是线上巡视产品,基于销售回访发现客户的续费率很低,通过调研发现客户觉得违规行为推送服务,「只能发现问题,缺少解决问题」的手段。

PS:员工行为分正面,比如按时上下班、闲暇时间练习剪发(美容美发行业),和负面,比如后厨吸烟、收餐不及时(餐饮行业);大多数客户实行多罚少奖的业务模式,因此员工行为推送大多为违规行为推送。

于是,产品团队通过调研发现,客户会定期派人线下巡检门店,发现违规问题会要求门店负责人改掉,但目前的业务模式会存在以下问题:

  • 管理层:拿到领导制定的巡检标准和规范,由于门店数量多、分布广,无法合理分配巡检资源,比如规多的门店多抽查几次、扣分频率高的项多关注等。
  • 执行层:由于要求多、人员变动不了解业务、检查位置不同等问题,因此容易执行错、漏,不仅巡检效率低,还会因巡检问题导致门店负责人被罚钱。

因此,因为公司为了补足「解决问题」这个能力,再加上目标客户业务上存在的问题,我们决定通过产品提供一套标准化的解决方案。

三、线下巡检标准化的设计思路?

在理完「为什么做」之后,接下来才是思考「产品该怎么做」,同样是按照自上而下的思维模式。

1. 产品的预期和目标

基于产品定位,推导在理想状态下,我们需要提供什么能力,解决客户在哪些具体场景下的哪些问题?

1)具体场景有哪些?

调研标杆客户的线下巡检后,梳理业务流程提炼后:巡检跟踪 → 违规整改 → 数据犯规 → 门店奖惩。

  • 巡检跟踪:制定巡检标准和规范,指派给对应角色完成线下巡检。
  • 巡检反馈:门店负责人收到巡检结果,对巡检结果做整改或申诉,再由巡检员审核结果。
  • 数据反馈:展示统计结果,为客户提供门店巡检的决策依据。
  • 门店奖惩:基于巡检结果,客户可对员工进行奖惩。

2)基于这些场景,我们应该提供什么样的产品能力?

① 巡检跟踪:支持多业务场景下的派发任务

录入模板:根据多个标杆客户提供的巡检模板,梳理归纳之后如下图:

任务下派:根据客户实际派发任务的场景,比如:

  • 普通任务:正常派发单个任务;
  • 重复性下派的任务,提供「周期性任务」自动下派的解决方式;
  • 抽查巡检的模式,提供「抽检任务」的检查方式;
  • 任务执行:支持在 App 上完成巡检;
  • 巡检结果查看:针对客户领导层、管理层、执行层 3 种细分的用户群体,支持在 PC 和 App 上查看巡检结果。
  • 巡检结果导出:为了客户留档、二次数据分析等场景,需要支持客户定期导出巡检结果数据。
  • 巡检结果通知:为了便于及时的整改和申诉,需要在门店巡检任务提交后,通知门店相关人。

② 巡检反馈

巡检项的整改 / 申诉与审核:属于在巡检业务上的延伸,具体来说:

  • 巡检结果无误:门店负责人需要承认结果,并整改违规;
  • 巡检结果存疑:门店负责人可以提出申诉,反馈给巡检员审核;
  • 创建事件:支持对巡检结果存在质疑的人发起整改、整改后提交审核、以及发起申诉的业务场景。

③ 数据反馈

巡检结果统计:根据业务需要,在后台系统中展示统计数据,比如:任务完成情况、得分情况、违规情况等。

④ 门店奖惩

员工行为奖惩:根据线上巡视,和线下巡检的结果,为客户奖惩员工提供理论支持。

2. 产品的现状和能力

基于 01 产品的预期和目标,在希望解决的客户问题的具体场景中,我们已经覆盖了哪些能力?

接手这个项目时,产品流程并不符合业务流程,同时产品逻辑上也有缺失,因此需要重新规划和设计整套系统。

3. 产品欠缺的能力

根据产品的预期和目标和产品的现状和能力,推导产品目前还需要的能力,如下图所示:

4. 产品的规划和优先级

基于产品欠缺的能力,明确接下来该怎么做。

当时线下巡检产品属于业务探索期,从产品规划上分为 3 个阶段:

  • 优先调整产品逻辑,使产品逻辑能够符合真实的业务流程;
  • 补充业务流程下的基础功能,支持多业务场景上的使用;
  • 跟线上巡视产品结合,深入到目标客户的关键业务流程中;

根据产品发展方向,推导认为要做的事情,以及事情间的优先级,如下图所示:

以上,就是我复盘这次项目带来的经验总结,其实都是在围绕:要做什么?为什么要做?这两个点去论证。

在想清楚这些之后,后面再落地产品逻辑时就是顺理成章的事情。

四、线下巡检标准化的产品逻辑?

在明确设计思路之后,剩下的就是将逻辑产品化,这里以阶段1:优先调整产品逻辑为例,可以分为以下 3 个阶段:

1. 巡检前:录入信息,下派任务

1)品牌列表

当客户购买线下巡检产品后,由我们负责在系统中新增对应的品牌。

2)架构设置

由客户自己录入自己品牌的层级架构,即品牌 → 区域(N个) → 门店的树状层级关系。

3)用户列表

客户按已建好的架构,在不同的层级下关联人员,比如:区域关联的人,通常为区域负责人或督导;门店关联的人,通常为门店负责人、店员。

4)模板列表

客户客按设计思路中模板类型,录入巡检的模板,同时支持两个层级的分类。

5)任务列表

客户针对不同的业务场景,可选择是否使用模板,以要执行的门店为单位派发任务。

2. 巡检中:员工执行,上传结果

1)App接收和执行任务

到了任务开始时间,客户的员工会在App上看到任务,按照模板执行后提交。

3. 巡检后:展示和通知结果

1)App查看和通知结果

单条门店结果提交后,与门店关联的人就能收到反馈通知。

五、写在最后

现在回想起来,这个项目本身的逻辑并不难,但因为自己第 1 次逐步接触完整的项目,再加上自己的经验有限,所以还是做了很多“错误”的决策。

从这次实践中,我总结出了几条经验:

1)自上而下的思考产品为什么做?要做什么?(思路参照文章的二和三)

否则直接上手,会让我们陷入做事,但看不清效益的无用功之中。

2)B 端产品服务于业务,想不明白、做不完整是因为缺失了某些业务信息。

因此,找最懂业务的人去确认自己的理解是否准确、是否缺失,接下来再去落地产品。

#专栏作家#

空,公众号:小木盒产品记,人人都是产品经理专栏作家。一名在迷茫道路上,成长前进的B端SaaS产品人。希望能通过不断思考、不断复盘,让自己成为一个思考有深度,表达有条理的产品人。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!