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

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

一、项目背景

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

二、V1.0.0版本

1. 项目启动

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

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

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

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

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

会后我将所有的反馈进行了整理，并进行以下分类：第一版本需解决问题、后续版本待排期需求、暂不由系统解决问题。将问题分类和解答之后，和相关业务方进行单独的沟通，得到明确的答复，我们开始优化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协议。