20150922——第一个项目总结

60 阅读 0 评论 40 点赞

我是靠谱客的博主沉静电话，最近开发中收集的这篇文章主要介绍20150922——第一个项目总结，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

这里记录下我职业生涯中第一个项目吧，历时4个月，经历可以说是一波三折。4月初入职，月底接到这个项目，5月初讨论需求、做设计，5月中旬开始开发，六月下旬方案被老板否定，然后重新设计和开发，到8月初才上线10%的流量，经过大半个月的数据观察，8月下旬开放全流量。涉及到一些私密的问题，我就把故事改编了下，主要是讲我在项目中遇到的一些挫折和我的一些不足之处吧。

项目背景大致是，公司新建了一个仓库。算算公司也有不少的仓库了，而这些仓库覆盖的发货国家、采用的发货方式及运费费率都是不同的。对于新建仓库，目前有两个问题：一是对于该仓库发货的商品，目前前端只能支持按照老仓库发货去计算和收取运费；二是考虑到运费成本，线上只有整个订单的商品满足从新仓库发货的条件时，才会使用该仓库进行发货，导致新仓库的出库量一直不大。所以做这个需求的目的，就是在保证转化率和销售额的前提下，提高新仓库的利用率。

然后，我就经历了以下的困难时期：

（1）设计阶段一

一开始，我就向导师咨询了新仓库相关的历史背景，发现这个需求有一个地方让我觉得很难拿捏。目前线上之所以仍然按老仓库发货的费率去计算和收取新仓库发货包裹的运费，是因为新仓库发货的费用相对更高，半年前上线过新仓库的运费费率计算需求，直接导致了订单转化率降低，最终以代码回滚作为结束。因此，对于我接到的新需求，不做的话，运费持续亏损，新仓库订单量无法增长，无法实现公司的战略规划；做的话，又可能导致转化率下降。思虑再三，决定将选择权交给用户。当订单满足整单新仓库配货时，强制用新仓库发货并收取新仓库发货的运费；当订单既满足老仓库整单发货，又满足老仓库和新仓库分包发货时，让用户自行选择，并默认勾选便宜的发货方式；至于只有一种发货方式的情况，则无须纠结了。

（2）开发阶段一

我来公司的时候，正好赶上了公司的离职高峰期。前端的开发，离职的离职，休假的休假，最后找了1个新来的程序员接手了前端页面的工作。但是由于她对公司业务一无所知，这个功能的逻辑又比较复杂，本来计算两周开发+测试的需求，整整做了一个半月。在这一个半月了，不仅仅是开发天天加班到深夜，PM和测试也是时不时要熬夜对功能。当然，除了开发的原因，我在这一阶段也犯了两个错误：

1）没有跟开发详细解释业务逻辑。这个需求在第一阶段就报出了很多bug，跟程序员对业务逻辑的理解不深有很大的关系。当时就只是通过写文档，用一些业务逻辑图和“if-else”判断语句来跟开发沟通，但是没考虑到这段代码在其他地方也会有影响。这直接导致了后面一些页面交互的混乱，比如开发不知道提交订单页有哪些元素，又或者有很多类似于勾选“rewards”后页面无法记住之前选好的收货地址和运输方式这样的bug。

2）没有把自己当做用户，从前到后完整地思考整个功能的使用过程。在功能设计和需求宣讲的时候，我把所有的注意力都放在了提交订单页，完全不知道前后页面之间的关系。所以当开发告诉我自测通过时，我只是简单试着下了个订单，就发现place order页无法跳转到支付页面。之后，开发又花了两周的时间去处理页面之间跳转的问题，虽然大多数时间是用于处理修改代码时产生的各种bug。

所以，我吸取了教训，在之后的产品方案设计中，会首先把自己当成一个用户，结合现有功能，想象使用的整个流程，细致到页面各个元素之间的关系，每个按钮点击后有哪几种可能，每个选项被选后页面会做出哪些改变（包括UI和数据变化），等等。然后把这一流程整理成文档，在需求宣讲时详略得当地过一遍。这样一来，当开发对业务一无所知时，也不会导致写出的功能和预期差距很大。

（3）测试阶段

由于功能逻辑比较复杂，我在开发提测前对测试专门进行了需求宣讲，提到了这个功能上线后，线上各个购物阶段，页面和数据库操作的一些变化，并写了一些用例。但是整个测试过程也是曲曲折折，进度很慢。有几点是我做得不够的：

第一点，我当时认为测试方法是测试人员才应该去考虑的问题，所以后来导致了测试人员迟迟不知道如何开始。

第二点，没有高度重视测试用例评审这件事；没有考虑到测试对公司业务、代码逻辑不熟悉的情况，导致测试用例覆盖不完全，同时报了很多无效的bug。

第三点，当项目深陷bug无法自拔时，没有及时组织每日的进度确认，把控测试的流程和进度。每一轮测试都应该有准确的时间安排，不能让测试人员因为与bug周旋而延误了测试进度。

（4）设计阶段二

在需求即将上线时，方案被老板否定了，重新设计开发。所以，重大项目，一定要让领导确认方案，血淋淋的教训啊！

（5）上线前后

电商网站的改版总是特别谨慎，每个可能影响到转化率的地方，都需要做AB测试，跟钱挂钩的功能就更是如此了。小流量上线后，除了观察代码稳定性外，还需要详细分析点击率、转化率、客单价等数据变化，才能决定这个需求是否可以全流量。

在这个需求里，我收集了A、B组用户的转化率、客单价，新仓库订单数量增长量，运费收支等相关的数据，分析项目收益。但是后来想来，对于用户可以选择发货仓库的情况，应该统计各个仓库被选择的概率，这样才好对默认选项进行优化，保障转化率。另外，还可以跟踪物流满意度、物流费用的数据，去对各个仓库提供的服务进行比较。

疏忽、遗漏的地方还有很多，简单做一记录，时时翻阅，给自己提个醒。产品经理是个细活儿，不管有没有权利规划公司的战略方向，细节是不可忽视的。希望自己以后思维能更严谨，少挖坑、少踩坑。