项目复盘:0-2项目的深度剖析

1 评论 4003 浏览 12 收藏 13 分钟

编辑导语:作为产品经理,在工作中往往要面对多方的问题,通过一个又一个的项目积累经验。本文作者对自己做过的一个项目进行了总结,通过复盘减少重复性犯错的可能,总结经验,才能更快成长,成为一名优秀的产品经理。

我曾负责过多个项目,一直以来都没有对做过的项目进行复盘分析,本文我挑一个同时带有B端和C端特点的0-2项目进行复盘,回顾过往的经验和遇到的问题。

一、项目背景

我公司所处行业为跨境电商,在准备做该项目时,公司刚刚上线了采购系统,采购部门的工作已经完全实现系统化。上级领导决定,开发一个“供应商门户系统”,对接内部采购系统,用于供应商端的接单、发货。产品经理负责人是我,业务部门也派出一个同事与我对接,他作为关键相关方。

二、V1.0.0版本

1. 项目启动

我之前并没有接触过采购相关的业务流程,业务同事首先给我讲解公司现有采购流程。

我们确认了公司现有的情况,采购内部已经实现了系统化作业,所有的下单、对账工作都可以在采购系统完成。但是对外的沟通工作,需要通过微信、QQ等社交软件进行,下单需要通过excel表格、截图进行传递给供应商,效率教低,出错率高。

若订单跟进过程中有员工离职,很难追溯沟通记录和订单进程,对于订单按时交货有较大影响。我们根据现有情况明确了第一版本系统要做的核心功能是接单、发货。接下来我们开始研究同行业和相关SaaS公司的系统,分析了他们的核心流程和功能点,结合我们公司现有的情况,制作了第一张框架图。

经过一个月的调研设计,我们完成了原型V1.0.0,与相关部门的负责人进行了第一遍的评审。不出所料,第一遍评审过程中,不同部门提出了他们的意见:

  1. 仓库部:这个系统设计在接单发货过程中,为什么没有考虑仓库的收货难度?我们希望供应商发货必须有箱唛和装箱清单,否则我们拒收。
  2. 财务部:既然已经可以在系统实现接单发货了,我们也希望可以进行对账请款,由供应商自行查看账单,减少沟通。
  3. 采购部:供应商不配合怎么办?我们有什么方法能够强制供应商使用?

会后我将所有的反馈进行了整理,并进行以下分类:第一版本需解决问题、后续版本待排期需求、暂不由系统解决问题。将问题分类和解答之后,和相关业务方进行单独的沟通,得到明确的答复,我们开始优化V1.0.0的设计稿。

一周后我们开始了第二轮的评审,需求更加明确了,得到的肯定变多了,也仍然有一些反馈意见,会后我们按照第一次的方法处理了反馈意见。又过一周我们开始了第三轮的评审,本次评审顺利过关,各个业务方都得到了想要的答案。

我们的项目真的可以进行开发了吗?我们对评审通过的方案打了一个问号,本项目有点特殊,特殊的点在于我们是B端产品,业务需求提出人是公司内部员工,但是系统使用方是“供应商”,在需求设计评审阶段,使用者没有参与,我们意识到了问题的严重性。

我们把这个问题与上面领导进行了沟通,争取与供应商当面交流的机会。我们前后约了5个不同区域不同行业的供应商,与他们交流之后得到了有效的建议,我把这些建议纳入到需求设计中,并进行了再次的评审。

至此,从接到任务到第一版本需求设计完成已经过了两个月了,需求评审通过之后,我们召开了项目的开工会议,项目正式进入开发阶段。

2. 项目开发

项目进入开发阶段,组织上对这个项目较为重视,投入的开发资源比较充足,所以开发进程很快。

但是在开发接近尾声的时候还是出了问题,由于项目组人员过多,又是两个地理区域的人员同时参与,前面各自开发单独模块很顺利,在联调过程中,多个技术没有事先沟通好对接方式,调试各种失败。项目经理决定,调配项目人员到同一区域,当面沟通,确认技术细节,项目才顺利进入到提测阶段。

3. 项目上线

经过了漫长了开发、联调、测试,项目终于要上线了。

上线前的时光也并不顺利,我们之前的项目都是内部B端系统,缺乏C端系统的经验,上线前没有申请公共服务邮箱和网站域名,一系列问题接踵而至,作为产品没有理由推卸责任,这是我经验不足导致的问题。

立马联系运维,与公司领导协商方案,最终邮箱申请为163邮箱(这个为后续埋下了坑),网站使用官网域名建立二级域名,所有问题解决之后,项目总算上线了。

4. 上线使用

上线的那一刻我们是喜悦了,但是之后我们是痛苦的,按照之前的规划,我们邀请了10位供应商参与试用,账号开启了,邮件发了,但是并没有人用,我们傻眼了。

我们去找供应商沟通,为什么不使用我们的系统呢?我们得到的答案是,使用系统对他们来说并不会有实际的效益,而且还要按照系统流程来走,很不方便,他们现在使用聊天软件沟通挺好的,没有太多限制。

我们在前期设计时,做了大量的调研,规范了业务的流程,满足公司的使用场景,也考虑到了供应商的使用医院,调研时,他们表示愿意使用系统,但是结果大家并不愿意配合,我深刻的理解了一句语:不要听他怎么说,而要看他怎么做。

难道我们只是做出了一个自嗨的系统吗?难道真的没人用了吗?不,我们不甘心,与上面领导开会沟通,为了促进供应商的使用,我们从下面几个方向各个部门并行推进系统的使用:

  1. 供应商门户系统开发“产品推荐”的功能,只要供应商愿意使用,我们就给他们入口,推荐他们的产品给我们,增加合作点;
  2. 仓库优先处理通过供应商门户发货的订单;
  3. 财务可以优先支付通过供应商门户处理的订单;
  4. 公司上层领导与供应商沟通,加强合作。

大致有了方向之后,我们开始了第二个小版本的需求规划。

三、V1.1.0版本

本版本的核心目标是推进供应商的使用,开发新品推荐的功能。我与产品开发部的同事沟通流程之后,就进行了设计开发,总体开发上线时间为3周。上线之后,给供应商开通了相关模块,供应商表现出了一定的使用意愿,开始慢慢接受了。

在逐步开发用户量100个,并稳定使用1个月时,系统经过小版本的迭代,优化功能基本完善,我们准备开放用户量到1000个。

第二批用户开放1000个左右,开通账号发送邮件邀请供应商使用,在邮件发送到180个时候,邮箱被限制了,163邮箱检测我们邮件发送过多,判定为推广邮件,邮箱被限制了…坑还是踩到了。

我们尝试更换阿里邮箱、126邮箱,都会在某个数据量上被限制。无奈之下临时切换了方案,使用短信发送,短信的缺点在于无法设定格式,放置图片,只能做到通知作用。

在大量账号开通的通知送达之后,还是切换回了邮箱,同时优化邮件的格式,加入更多的参数,使用多个模板,减少邮件相同的比例,避免触发邮箱的风控机制,并且准备使用自有的邮箱服务器。

供应商门户系统开始进入正式的使用阶段,0-1项目搭建完毕。

四、V2.0.0版本

第一阶段公司内部现有供应商已经被激活,我们第二阶段要开始尝试引入新的供应商,“供应商入驻”功能开始进行规划。一个月时间供应商入驻完美上线,前后流程已经打通。

两周后问题出现了,供应商入驻的入口是供应商门户网站,但由于入口太深,外部供应商根本找不到入驻页面,无法联系到我们。网站推广成了问题,我们开会沟通,得到了以下方案和可行性:

  1. 百度推广:成本太大,供应商门户系统商业价值不大,没有全面推广的必要性;
  2. 改造公司官网,搭载供应商入驻入口:实现方式快,改造成本低,官网有一定知名度,该方案为首要方案;
  3. 使用公众号推广,成本低,但是实现周期长,作为迭代版本方案。

搭载官网入口的方案上线之后,第一个月陆陆续续有100家供应商进行了申请,效果不错,得到了供应商管理部门和上级的认可。在V2.1.0版本,公众号上线之后,配合官网使用,效果不错。

接下来我们陆续开发了公众号接单、开放API接口、签署合同、视频版帮助中心、下载发货标签等等的功能,供应商门户系统虽然没有为公司带来直接的收益,但是也在减少人工、提高效率,缩短交期方面做了突出的贡献。

五、结语

一个系统从0-1搭建不容易,把一个产品从1带到2,更是一个挑战,在中间会遇到各种各样的问题,我没有退缩,一直在寻找更高的突破。

产品经理作为产品第一责任人,负责的不仅仅是方案的输出,还要负责系统的使用和不断的优化,在我的产品观中,产品没有完结,它拥有无限的生命力和价值,我们要做的就是让产品生命周期不断延续,发挥无尽的价值。

望与君共勉,欢迎评论骚扰~

 

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

题图来自Unsplash,基于CC0协议。

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