一个失败的技术型产品

 
做个一个技术型的产品，是很多技术人员梦寐以求的事情。
 
一个是可以满足自己技术的梦想。
一个是可以由技术人员来主导。
 
2017年初，我遇到了这样的一个机会，内部讨论想做一个数据分析类的产品，给到B端的开发者使用。虽然当时觉得市场不一定会很大，但还是很兴奋的，毕竟是一个地道的技术型产品。
 
产品的需求，规划，系统的设计，搭建，测试，上线，全部都是由技术人员主导的，产品经理在里面更多的是辅助的角色。
 
这个任务下来后，我们遇到的第一个问题是：不知道要做什么！
 
不知道这个产品具体是怎样的，用户会有什么样的需求，我们需要提供怎样的服务，系统应该要怎么来设计和搭建。
 
另外一方面，时间上有明确的规划，半年后一定要上线第一个版本。
 
深入理解需求
 
刚开始接到任务的时候，一脸懵逼，后面拉上决策这件事情的领导，负责的产品和几个核心的开发同事，就这个问题展开了讨论。
 
经过几次的讨论和对市场上现有数据分析类产品的拆解分析，最终明确了我们产品的具体需求。
 
简单描述如下：
 
产品层面提供多维度实时查询，转换漏斗，留存分析，路径分析等常用的数据模型；数据采集支持程序打点和配置打点(我们创新的一个能力)。
 
系统层面，为了满足实时的需求，在数据采集延时和数据查询延时上，都提出了明确的性能指标。
 
整体的需求目标确定下来后，接下来就是方案的设计和实施了，这个时候，时间已经过去了一个半月。
 
找有经验的同学喝咖啡
 
接下来，又遇到了系统设计的问题。数据系统我们虽然有耳闻，有了解，但团队内的同学都没有实际的经验。
 
首要的是系统的选型。这是特别关键的一环，如果错了，会影响产品的性能指标，可扩展性，甚至是产品的对外表现形态。
 
当时也是一脸懵逼，一时间不知如何着手，没有更好的办法，只好先安排几个同学去看论文，查资料，但我知道这肯定不是最高效的办法。
 
后来想到了其他团队有做过类似的系统，当时的第一反应，是找几个比较熟悉的同学，去跟他们聊聊。
 
说干就干。
 
因为我在整个大团队的人缘还不错(嘻嘻，自夸下)，所以很容易就约到了一个同学，请他去我们的咖啡厅，点了一杯喝的，就开始聊了起来。
 
第一次聊完后，脑海里有了较清晰的系统的结构和需要关注的点，以及他们踩过坑，后面又找了几个相关的同学了解了更多的细节。
 
跟几个相关的同学聊完后，心里已经比较有谱了，这个过程大概花了一周的时间。
 
研究资料，来回探讨
 
在明确了总体的方向后，就拉上团队同学开始分工了。
 
我们接下来的任务是：系统的选型，整体的架构设计，各个子系统的设计。
 
结合其他团队的经验和我们自身的分析，决定采用开源系统+自定制组件的方式进行。
 
接下来的事情有两个。
 
一个是确定整体的系统架构。
 
一个是确定每个部分的组成，子系统是采用开源还是自研，如果采用开源，应该选择那个系统更加合适。
 
这是一个来回探讨的过程。
 
我们分析对比了几个开源的系统，结合我们自己的需求目标，先看系统本身提供的特性是否满足需求目标，比如需要支持实时入库，需要支持实时查询，需要支持多维度的快速分析等。
 
中间过程也是比较曲折，大家在一些系统的选择上也产生过分歧。
 
我记得当时在核心模块的选型上，分成了两派。一派支持采用成熟稳定的方案；一派支持使用最新开源出来的系统。
 
一直争执不下，后来，我们觉得这样的争执，太浪费时间。
 
所以决定兵分两路，去分别认真细致的在网上搜集：系统支持的特性，前人踩过的坑，系统内部存储模型等。
 
一个个详细地列出来，经过大家逐一的对比分析后，最后决定采用成熟稳定的方案。
 
新开源出来的系统，虽然号称性能更好，但存在几个比较大的坑，而且在系统扩展性上做的不够好，而性能的问题可以通过堆机器的方式先解决，后面可以再做成本优化。
 
经过三个月的时间，我们完成了产品需求的细化，系统选型，系统概要设计和详细设计的事情，终于进入到了系统的实施阶段。
 
紧张的实施
 
由于剩下的时间也不多了，只有三个月。
 
这三个月除了要完成后台系统的搭建，还要配合客户端，产品，前端同学完成数据链路的构建，产品细节设计，数据可视化展示等工作，也是挺赶的。
 
这个过程中，遇到最棘手的问题，是跟客户端的版本。
 
我们内部客户端的发版是有固定时间排期的，每次需要合入的特性，都要提前报备，排期，要不只能等到下个或下下个版本了。
 
产品里面有一个特性是支持程序打点和配置文件打点，都是需要客户端支持的。
 
我记得当时没有留心这个问题，安排了一个同学跟客户端开发那边讨论，觉得方案没问题，就没理会了。
 
两周后去问，客户端同学说，因为这次需求排的太多，把我们的需求给安排到下个版本了，而下个版本要一个月之后。
 
当时就慌了，所剩时间本来就不多，而且客户端的功能，是整个数据链路的第一环，如果没有发布，后面所有的环节都只能测试，而无法在真实的环境走通。
 
一拖就又要拖一个月了，而项目所剩的时间已经只有两个月不到。
 
后来经过多方沟通，还上升到了更高一级，才给排进去了。
 
虽然后来被上级给批了一顿，不过总算排进去了。
 
煎熬的两个月
 
距离项目立项半年后，整体产品终于上线了。
 
一开始内部邀请了十几个种子用户来使用，他们提出了不少的改进建议，也有用户反馈这个东西挺好的，那时候，我们内心听了也挺开心。
 
中间我们进行过几次的迭代，fix 各种bug, 增加新的特性，改进已有的交互，后台提升系统的性能等。
 
开发团队还自己做过客服，一个个的电话回访客户，了解了产品被谁使用，用在了什么地方，和其他的一些情况。
 
不过，产品最终没有取得预期的效果，没有持续下去。
 
失败的原因有来自于市场和产品本身，也有来自于团队。
 
市场和产品的原因，这个数据产品本身依赖于另外一个业务，当时那个业务没有如预期的做大起来，后面回过头来看，推出这个数据分析类的产品有点超前了。
 
团队的原因，原来支持我们做这个产品的老大走了，后面新来的老大对这块不太感兴趣，也不愿意投入更多的人力去做。
 
最终，这个项目也被晾了起来，目前已经交接给了其他的团队在维护。
 
结语
 
虽然从产品的角度，这个产品最终失败了，但从技术的角度，我们觉得还是做的不错的，在无经验，无外援的情况下，从0搭建起了整个数据系统，并且在延时，性能等指标上也达到了我们预期的目标。
 
团队成员也在这个过程中得到了很大的成长，特别是有两个新入职的新人，在这过程中表现的很好，得到了很大的锻炼，后面也成长为了团队的主力。
 
我自己也在这个过程中，经历了一个技术产品的完整流程。从想法提出，需求提取，产品设计到系统选型设计，项目实施到上线，再到后面跟进用户数据，跟进用户反馈，来迭代改进产品的整个过程，也是获益良多。
 
这是一个失败，却也让我们获益良多的一个技术型产品。
 

作者：大飞码字