工作小结-好搭产品死亡笔记

最近一阵没有写工作小结。并不是不想写，其实是发生了一些没有想到的事情。

总而言之产品挂掉了。

在我们这个团队，产品每日都想的是怎么往后推进，从来没有想过之前的行为为什么有问题。而对于我们开发来讲，基本上也都是上行下效，重心总是在技术上，而不会对产品产生质疑。关于失败的总结一直都是避而不谈，开会的话语中永远都是美好的未来。其实这也是失败的一个因素。

我希望以我全程参与的开发者的身份，来对产品的死亡做一个总结。

3月，开始

3月的我加入了好搭，当时项目还没有改名为好搭盒子，app的版本停留在1.9.3，当时做的是导购的模式，通过淘宝客，租赁衣服进来生成模型，然后通过提供服务给用户，通过淘宝客来获取佣金。
由于老模式竞争很大，需要比较多的投入才能达到比较好的传播的目的，另外在用户上面，其实在当时的传播模式在当时是很有吸引力的，但是当时的效果做的并不是很好。再加上天使轮融资成功，需要抓紧从好买衣脱离，所以仿照了国外Stitch Fix上市的盒子模式，期望能通过虚拟形象加上盒子模式，给虚拟形象带来一个有效的传播。

4月，2.0版本上线

由于以前从好买衣转来的后台，和上头吵翻了，因此上头决定新招一个后台，但是只招了一个后台。重构当时给了2周，但是到三月末还是没有好，后来又给了两周，一个月整后端接口好了。在4月中旬我们开启了app的大规模改版计划。

起初是加上盒子，盒子模式需要增加加盒、地址、押金、付款、订单等模块，后续又加上了会员系统，另外在商品的展示阶段，刚开始使用的是单品+合集的模式，商品结合的是medel+单品展示的。改版很大，对于我来讲就是不日不夜的加了两周班。

改版上线前遗留几个比较严重的问题，一个是盒子模式的本地保存和服务端保存冲突模式，服务端保存会导致加盒的模式很卡顿，加盒的过程需要验证服务器库存+操作本地盒子增加删减+push新的盒子到服务器+拉新的盒子到本地更新本地的衣服状态+本地存储新的盒子到sp。由于盒子的操作是一个很高频的模式，但是操作盒子带来的网络操作以及本地操作，当时验证需要大约400ms，而一次增加就会带来400ms的卡顿感，其实对用户来讲是十分不友好的。

由于着急上线，盒子的模式就被直接忽略而直接在4月30号上线了。

从现在的角度来看，当时如果能多用2天的时间，将整个盒子的模式改变一下，应该就不会有2.0版本评分从4.3掉到3.0的问题了。市场对2.0版本最大的评价就是卡。

5月,正式由好搭虚拟试衣变更为好搭盒子

5月的产品计划是增加了芝麻信用免押金、加入了人工客服、增加了引导页面，同时对于订单模块进行了较大规模的优化。

这个版本是正式更名为好搭盒子，同时也进行了一定规模的投放。由于客户量增加导致暴露出了一个问题，就是由于信用免押金用户开始通过免押金进行订盒子，然后却不购买不退盒子。针对这个问题，当时唯一的号称“联系芝麻信用进行处罚”的措施，只有打电话追着用户。其实押金模式被ofo搞得臭名昭著，而不用押金，对我们这种小型公司，很难说控制用户的诚信度。我并不知道出问题的人的数量，但是我当时和产品沟通的时候，间接了解到了违规的人数其实不少。

说实话小公司在扩大市场这一方面真的难，像衣盒这些，通过强制要求用户提交几百块的押金，然后还有钱进行市场投放，这样用户规模就算增长不快，起码不会出现这种大规模违规的现象。然而我们公司无法这样，如果加了押金一定会导致用户抵抗情绪上升，因此也会导致用户接受能力降低。不得已才采用免押的模式，然而没想到这个模式这么快就被打脸了。

另外这个版本的商品展示，是机械的随机展示，权重并没有按照用户的喜好来。下拉过程中大概率出现是重复的商品。不过这个版本我将盒子的模式完全更改为内存存储的方式，优化掉了卡顿的问题。

这个版本的评价不再是卡卡卡，而是商品数目不够，想买的一下子就没了。

6月，app由简陋转变为精致

整个六月，在连续更换2位ui之后，我们终于定下了ui的风格，并以此将页面逐个更新为新的风格。同时增加了专题和图文专题作为商品的展示模式。

整个六月只发了一个版本，但是针对这个版本提交了300多笔。不过ui定稿总算是完成了，大家都很开心，风格的统一应该会带来用户的提升。

至少当时都是这么想的。

但是发出去之后，6月的数据并不是很好看，至少没有达到想象的那种程度。一方面是因为数据量上去了，但是货品并没有上去，二来是仓库物流erp系统有些问题，造成了比较多的延迟发货问题。当时在确认订货的时候，并不支持取消订单，大量用户操作失误寄出了盒子，但是并不想要，好的人直接退了，不好的就不管，或者收到了衣服拿出来。主打的学生人群感觉更容易出现这种情况，反正是造成了数据并不好看。

6月出了一场比较严重的事故，由于在首页使用fragmentPageAdapter并且没有将缓存数据处理，导致app的内存在首页被消耗太多，因此导致了app极度卡顿。记忆中这个版本的anr达到了10%。事实上当时在测试的过程中就已经发现了这个问题，但是由于需要着急发版。每次卡着时间必须在周五发版，导致改版问题只看数量不看质量，这种质量事故其实很严重，但是产品很着急，老板很着急，开发很疲惫，测试很疲惫。

说实话其实对于小型开发公司来讲，讲究质量是一件很不靠谱的事情，在质量做上来之前，说不定市场就转向了。我们要求是周一给任务，周二出图和接口，周三周四开始做，周五提测测试完毕。如果周五提测不行，周六就加班，最迟最迟是周六提版本。这种进度在一般时候其实是ok的，但是在大改动的时候，尤其是ui改了2周才给设计稿的时候，第三周要求我们弄出来，就会导致这种情况发生。

当时我想了很多，发现其实无解，我们在提高自身效率，提升代码质量的时候，绝大部分时间都是在业务上面，而这种架构方面的问题真的很难发现并处理。很蛋疼。另外就是这种问题需要依赖测试的问题，在我们开发任务结束，开始进行bug修补的时候，这时候应该关注性能方面，然而没办法，这个时候都是和产品测试确定bug以及修改bug。这种性能优化的问题，每次都只能在发版之后，只有任务但是并没有接口和设计图的周一。于是乎我们因此发布了很多hotfix版本。

7月，app增加了很多实用的功能

首先是增加的功能，这个版本增加了收藏单品、2件打包、商品状态、匿名状态使用等功能。基本上每个都是在痛点上面的设计。另外移除了强制登陆的逻辑，这个也是痛点。

这个版本的主要改动还是针对用户在使用产品的阶段遇到的问题。以前的用户由于刚开始使用，需要强制登陆，强制设置medel，成本比较高，这样会造成用户第一次使用成本过大，另外由于之前无法收藏，导致用户看到想要的不小心刷新之后再也没办法回到原来的状态，2件打包也是为了让用户更方便的打包盒子。整个设计的逻辑这个月都很简单明了，就是为了增加寄盒率。

这个月我们的盒子也突破了1000个/月。app的uv也突破了1w。

8月，人脸升级

8月是融资之前的一个月，这个月紧锣密鼓的进行了很多的事情。具体在我8月份的git基本上没有任何提交就可以看出来。我们把ux完完整整的优化了一遍，同时将人脸也进行了一次升级作为一次融资的噱头。整个ux的优化持续了一个月，这次优化的细节主要体现在订单流程上面，订单流程增加了很多状态，同时对于用户退货的流程做了很大规模的退货。主要的初心我个人猜测就是因为之前退货的流程太过突兀，用户一来可能看不到退货的入口，二来退货过程中细节不好，导致用户可能不一定在这个页面会进行下去。

总之这一版主要功能还是为了保障以购用户退货的过程能够顺畅而做出的优化，另外人脸识别算法部门提供了一个v2的版本，这个版本主要是将人脸从建模变成抠图，看起来仿佛是更好了。

另外这个月是融资之前的一个月，8月末就正式启动了融资。

9月，数据爆炸

9月份市场做了很多推广的努力，外加运营部门做了一些调整，优化了搜索引擎，导致app那一阵用户量猛增，由平时的1万ui猛升到了8wuv，当时在appstore排行榜还占到了最热区域。但是服务器重建人脸的效率实在是太慢了，重建队列很多都是堵死状态，我们太依赖好买衣导致他们的缺点在我们这边无限的暴露。而且这个月好买衣的后端leader跑路，前端leader跑路，走之前特地嘱咐了我们服务器的问题。但是当时我们这边重心没有放在这个上面，服务器出现人脸丢失，黑脸，没头，还有没头发的问题，在之后的几个月基本上是无限爆出，我们这边后端压根不涉及这些，核心竞争力没法把握好，导致后续在后端的稳定性上面吃了大亏。

不过9月是进入好搭之后感觉最兴奋的一个月，这一个月数据不断的刷新，让人感觉8月的加班是有意义的，而且这个月的盒子数也顺利的从之前的几百个，突破到了2000+个，至少对我们来讲，这一阶段的里程碑是达成了。

10月，a轮找到金主

10月由于是国庆节，外加母亲动手术，我大约半个月没有工作，这个月最繁忙的一周是a轮找到了金主之后的一周，投资人对我们提出了很多的要求，数据当时比较中庸，主要是加盒率和购买复购率比较低，而盒子数量和使用用户则比较好看。当时产品那边的想法是提高会员数量，这样可以使的会员转化率增加，会员的表现一直有比较高的复购和加盒转化率。

当时介于商品本来缺货断码就比较严重，因此开辟了一个会员专区，专门提供给会员特供的商品。这个版本上去之后的数据并没有显示，但是uv开始逐渐的降低了，十月份到最后的时候，我记得uv从2万掉到了1万2左右。

11月，强制用户登陆

由于之前将强制登陆和设计medel的步骤给去掉了，导致很多用户在很低的时间成本下，反复叫盒子，然后不够买不寄回，这样导致很多衣服被薅羊毛薅走了。这个现象持续了好几个月，但是这个月开始对这个现象做处理。

我们将新的强制登陆逻辑加上，为此付出了2周的开发周期，并且还delay了一次。但是中途也遇到了很多的问题，问题主要展现在关于medel的接口我们这边不是很了解，需要和好买衣沟通，另外就是服务器不稳定，导致线上环境建模总是失败，导致这样的强制引导很容易出现劝退现象。不过为了能够将羊毛党拒之门外，貌似我们在信用体系下可以做的也就是这样了。

12月，融资失败

到了12月，仿佛寒冬一下子来临了，各处裁员。

刚开始以为融资都进入ts了，应该可以稳定，结果还是没躲过，12号的时候说投资人因为一些问题准备不投了，这就很蛋疼了，毕竟已经等了超过一个月的ts了，最后说不投，基本上就是断炊了。然后ceo去跑了一趟，回来之后说又融到了。但是比较神奇的是开始要求我们砍业务。砍掉盒子模式。

很奇怪，融到了为什么要砍。结果吃饭的时候技术leader说其实并没有融到，ceo只是不想说而已。砍业务是因为吃不消损耗了，每个盒子都是亏的，用户热情还很高，这样钱吃不消使用。

于是连我们12月在做的功能都连根拔掉了，砍掉了订单，盒子，支付，会员等等，最后要接上淘宝客，等于我们的版本绕了一圈，回到了1.9.3的版本了。

哎。这样子，我们的好搭盒子就彻彻底底的死了。

总结

从开发者客观来讲，对这个产品是有感情的，当我来的时候，安卓组那个人准备离职，我在2个月的时间里面独自支撑着并不熟悉的项目。

加班加点在好搭仿佛都是家常便饭，年中的时候统计了一下已经累计了10天的调休。

可是有什么用呢？开发者仅仅是一把刀子，这个刀子或许锋利，或许迟钝，但是如果将锋利的刀子不断砍伐一些无用的东西，这有什么意义呢？

刚开始的时候说我们暂时不需要考虑基础建设的问题，后端，前端，移动端，都是走一步看一步。后期发现基础建设出了问题的时候，却又浪费了大批量的时间来重构。创业公司感觉永远逃离不了这个魔咒。

当听到一直维护的项目突然被砍掉，转成别的项目的时候。心里只有一声叹息。

问题出在哪里？

最近一直在想，leader离职的时候说过一句话，“论盒子模式，我们绝对是数据跑的好的”，但是为什么落的如此下场？

信用模式

盒子模式首先将衣服寄到了用户手里，然后让用户选择购买或者退回。这中间给了用户极大的自由，前期我们尚且能通过小规模投放来控制风险，后期接入了小红书推广，导致大量学生涌入，很多人仿佛占到了便宜似的拼命下盒子，下完了拿到货不退不购买，导致大量订单逾期坏单。造成了巨量的成本亏损。

商品量不足

由于是商城模式的app，对商品量的把控一定要比较高，但是从数据上来看，常年缺码SPU高达40%，造成了好衣服没货，坏衣服卖不出去的问题。加上前期并没有做好消息推送这个环节，对缺货商品的订阅上的过慢，也导致了大量用户的流失现象。

medel不够稳定

medel不够稳定是一直存在的问题，首先渲染消耗太多，最高每日光服务器就要跑掉2w块。其次是就算这样仍然不够稳定，不清楚是算法还是好买衣的问题，总是出现光头，绘制失败，没脸的问题。这个问题其实很严重，特别是我们这种主打虚拟试衣模式的app，基本上就是断腿了。

这个问题其实是有解的，开始的时候就可以选择重构那边的代码。但是怎么讲呢，兵熊熊一个，将熊熊一窝，关于这个问题从我入职的时候每次会议必谈，直到leader来了之后禁止我们开会讨论这个。从开始leader就没有想重构，他或许想的是在半年内我们可以拿到a轮融资，之后可以选择完整的重构，或者是想着干脆就不重构了，等着别人来