查看原文
其他

一个失败的技术型产品

大飞码字 大飞码字 2022-09-07

做个一个技术型的产品,是很多技术人员梦寐以求的事情。


一个是可以满足自己技术的梦想。

一个是可以由技术人员来主导。


2017年初,我遇到了这样的一个机会,内部讨论想做一个数据分析类的产品,给到B端的开发者使用。虽然当时觉得市场不一定会很大,但还是很兴奋的,毕竟是一个地道的技术型产品。


产品的需求,规划,系统的设计,搭建,测试,上线,全部都是由技术人员主导的,产品经理在里面更多的是辅助的角色。


这个任务下来后,我们遇到的第一个问题是:不知道要做什么!


不知道这个产品具体是怎样的,用户会有什么样的需求,我们需要提供怎样的服务,系统应该要怎么来设计和搭建。


另外一方面,时间上有明确的规划,半年后一定要上线第一个版本。



深入理解需求



刚开始接到任务的时候,一脸懵逼,后面拉上决策这件事情的领导,负责的产品和几个核心的开发同事,就这个问题展开了讨论。


经过几次的讨论和对市场上现有数据分析类产品的拆解分析,最终明确了我们产品的具体需求。


简单描述如下:


产品层面提供多维度实时查询,转换漏斗,留存分析,路径分析等常用的数据模型;数据采集支持程序打点和配置打点(我们创新的一个能力)。


系统层面,为了满足实时的需求,在数据采集延时和数据查询延时上,都提出了明确的性能指标。


整体的需求目标确定下来后,接下来就是方案的设计和实施了,这个时候,时间已经过去了一个半月。



找有经验的同学喝咖啡



接下来,又遇到了系统设计的问题。数据系统我们虽然有耳闻,有了解,但团队内的同学都没有实际的经验。


首要的是系统的选型。这是特别关键的一环,如果错了,会影响产品的性能指标,可扩展性,甚至是产品的对外表现形态。


当时也是一脸懵逼,一时间不知如何着手,没有更好的办法,只好先安排几个同学去看论文,查资料,但我知道这肯定不是最高效的办法。


后来想到了其他团队有做过类似的系统,当时的第一反应,是找几个比较熟悉的同学,去跟他们聊聊。


说干就干。


因为我在整个大团队的人缘还不错(嘻嘻,自夸下),所以很容易就约到了一个同学,请他去我们的咖啡厅,点了一杯喝的,就开始聊了起来。


第一次聊完后,脑海里有了较清晰的系统的结构和需要关注的点,以及他们踩过坑,后面又找了几个相关的同学了解了更多的细节。


跟几个相关的同学聊完后,心里已经比较有谱了,这个过程大概花了一周的时间。



研究资料,来回探讨



在明确了总体的方向后,就拉上团队同学开始分工了。


我们接下来的任务是:系统的选型,整体的架构设计,各个子系统的设计。


结合其他团队的经验和我们自身的分析,决定采用开源系统+自定制组件的方式进行。


接下来的事情有两个。


一个是确定整体的系统架构。


一个是确定每个部分的组成,子系统是采用开源还是自研,如果采用开源,应该选择那个系统更加合适。


这是一个来回探讨的过程。


我们分析对比了几个开源的系统,结合我们自己的需求目标,先看系统本身提供的特性是否满足需求目标,比如需要支持实时入库,需要支持实时查询,需要支持多维度的快速分析等。


中间过程也是比较曲折,大家在一些系统的选择上也产生过分歧。


我记得当时在核心模块的选型上,分成了两派。一派支持采用成熟稳定的方案;一派支持使用最新开源出来的系统。


一直争执不下,后来,我们觉得这样的争执,太浪费时间。


所以决定兵分两路,去分别认真细致的在网上搜集:系统支持的特性,前人踩过的坑,系统内部存储模型等。


一个个详细地列出来,经过大家逐一的对比分析后,最后决定采用成熟稳定的方案。


新开源出来的系统,虽然号称性能更好,但存在几个比较大的坑,而且在系统扩展性上做的不够好,而性能的问题可以通过堆机器的方式先解决,后面可以再做成本优化。


经过三个月的时间,我们完成了产品需求的细化,系统选型,系统概要设计和详细设计的事情,终于进入到了系统的实施阶段。



紧张的实施



由于剩下的时间也不多了,只有三个月。


这三个月除了要完成后台系统的搭建,还要配合客户端,产品,前端同学完成数据链路的构建,产品细节设计,数据可视化展示等工作,也是挺赶的。


这个过程中,遇到最棘手的问题,是跟客户端的版本。


我们内部客户端的发版是有固定时间排期的,每次需要合入的特性,都要提前报备,排期,要不只能等到下个或下下个版本了。


产品里面有一个特性是支持程序打点和配置文件打点,都是需要客户端支持的。


我记得当时没有留心这个问题,安排了一个同学跟客户端开发那边讨论,觉得方案没问题,就没理会了。


两周后去问,客户端同学说,因为这次需求排的太多,把我们的需求给安排到下个版本了,而下个版本要一个月之后。


当时就慌了,所剩时间本来就不多,而且客户端的功能,是整个数据链路的第一环,如果没有发布,后面所有的环节都只能测试,而无法在真实的环境走通。


一拖就又要拖一个月了,而项目所剩的时间已经只有两个月不到。


后来经过多方沟通,还上升到了更高一级,才给排进去了。


虽然后来被上级给批了一顿,不过总算排进去了。



煎熬的两个月



距离项目立项半年后,整体产品终于上线了。


一开始内部邀请了十几个种子用户来使用,他们提出了不少的改进建议,也有用户反馈这个东西挺好的,那时候,我们内心听了也挺开心。


中间我们进行过几次的迭代,fix 各种bug, 增加新的特性,改进已有的交互,后台提升系统的性能等。


开发团队还自己做过客服,一个个的电话回访客户,了解了产品被谁使用,用在了什么地方,和其他的一些情况。


不过,产品最终没有取得预期的效果,没有持续下去。


失败的原因有来自于市场和产品本身,也有来自于团队。


市场和产品的原因,这个数据产品本身依赖于另外一个业务,当时那个业务没有如预期的做大起来,后面回过头来看,推出这个数据分析类的产品有点超前了。


团队的原因,原来支持我们做这个产品的老大走了,后面新来的老大对这块不太感兴趣,也不愿意投入更多的人力去做。


最终,这个项目也被晾了起来,目前已经交接给了其他的团队在维护。



结语



虽然从产品的角度,这个产品最终失败了,但从技术的角度,我们觉得还是做的不错的,在无经验,无外援的情况下,从0搭建起了整个数据系统,并且在延时,性能等指标上也达到了我们预期的目标。


团队成员也在这个过程中得到了很大的成长,特别是有两个新入职的新人,在这过程中表现的很好,得到了很大的锻炼,后面也成长为了团队的主力。


我自己也在这个过程中,经历了一个技术产品的完整流程。从想法提出,需求提取,产品设计到系统选型设计,项目实施到上线,再到后面跟进用户数据,跟进用户反馈,来迭代改进产品的整个过程,也是获益良多。


这是一个失败,却也让我们获益良多的一个技术型产品。




推荐阅读:

十年工作生活路

关于信息差赚钱

一个历时五天的 Bug

我的程序员进阶之路

我的一个抉择

我的程序员蜕变之路



你好,我是大飞。十年互联网人,资深架构师,技术leader。

如果你喜欢我的文章,就给公众号加个星标吧,方便阅读。





您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存