一次关于产品架构的分享会

这是在公司的一次内部分享会,领导给的课题,让我针对公司的一个数据分析软件,做一次产品架构的分享。

拿到这个任务的时候,其实我是比较为难的,对于产品架构,如果没有对具体业务有深入的了解,也很难做出建设性的规划。

不过领导说,介绍一些方向性的东西,可能是未来几年要做的事情,不需要特别具体。

这么说的话,我信以为真的放心了。

背景

公司是一个立足于国家研究所的第三方软件公司,前几年的业务方向,基本上是外包项目制的,根据客户的需求,驻厂做定制化开发。

从今年开始,公司创始人觉得这不是长久之计,于是,想要把这些零散的项目,凝聚成一些产品,向客户提供服务。

但是,做产品的效果似乎不是很好,因为公司大都是技术开发人员,产品相关工作一直是项目经理担着,而项目经理也是技术出身,同时身上也有对应的开发任务,他们疲于应付客户的需求,很难跳脱出来,从宏观的角度,去考虑一些规划性的东西。

于是,公司决定要招聘产品经理这个岗位,而我,机缘巧合的成为了公司招聘的第一个产品经理,目前也是唯一的一个。

我的工作目前没有特别明确的边界,也没有给我具体安排到某一个项目组里,现在除了分担一些项目经理手头上有关需求类的工作,就是做一些产品规划。

产品

接触的第一个产品,是公司的一个数据分析软件。

这是前些年给客户做定制化开发,项目团队留下来的一个软件版本,后来在此基础上,又做了一些整合开发,形成了一个初步的产品。

该产品目前比较混乱,一共有 3 家客户在使用,但是,每一个客户使用的软件版本又不一样。

而实际上,该产品解决的是同一类业务需求,只是针对不同的客户,交付了不同的软件版本,而且,不同版本之间差异性还挺大,猜测应该是 copy 了一份核心代码,针对不同的客户,再重新开发交付。

所以,开发团队需要在 3 个不同的版本上面,分别根据对应客户的需求,做版本迭代以及交付,这里的交付依旧指的是项目合同制。

这样的结果就是,开发团队苦不堪言,需要维护 3 份不同的软件版本,同时,也会导致产品越来越分裂。

出现这样的结果,主要原因是客户方比较强势,且定制化的需求很多,而公司前期基本上都是开发团队驻厂开发,中间除了 CEO 进行商务的对接,剩下就是开发人员的事了。

结果自然是,客户方说做成什么样,开发人员就做成什么样,没有人去做需求的统筹分析,没有人去做产品的规划。

产品架构

背景说完了,该干活了,产品架构这种东西,我也是第一次搞,以前写规划报告,都是特别虚的东西,动不动就未来 5 年要做成什么样。

这次面对一堆技术开发人员,这种特别虚的东西,想来也不会受人待见。

但是,谈到「架构」这个词,本来就比较虚,实际不了,只能是谈一谈,产品未来几年的发展方向。

想清楚之后,就开始做呗。

任何事情都可以按照做产品的思路来开展,就把「产品架构图」当作一个产品,把「画产品架构图」当作「做产品」。

用户就是领导以及同事,背景以及需求上面谈到了,也都清楚,接下来就是做市场调研,其实就是看看网上有没有可借鉴(抄)的,看看类似的软件平台如何画的架构图。

经过一轮调研之后,就画出了第一版,现在看来,实在不堪入目。

做产品就是一个不断迭代的过程,一定要紧密的跟用户进行沟通,于是,拿出这一版,跟用户(对应的项目经理)进行讨论,听取用户的意见反馈,然后对产品进行迭代升级。

期间沟通了 3 回,也改了 3 回,直到该项目团队的所有成员,都提不出修改意见了。接下来,我就开始整理需求,准备做产品初版发布,没错,产品架构图也是要有版本号的。

最终发布了 v0.2 的版本,如下图:

拿着这个图,在分享会上,我夸夸而谈产品未来规划,原本以为从此走上人生巅峰,受世人敬仰。

谁知道,果然被打脸了,说好的只谈方向性的东西呢?说好的规划呢?

为什么分享会上,大家都在谈论功能如何实现,技术怎么落地的话题?对我画的这个图,丝毫没有兴趣,也没提出任何的建议。

好吧,产品经理果然跟程序员不是一路人,我默默的听他们聊了好长时间。

后续

不过,这个图,领导倒是还算满意(可能跟他不做技术很久有很大的关系),也许是看我分享会的后半程比较尴尬,于是,又给我布置了一个任务。

他看到架构图中,有个「微服务」的字眼,可能对这个词比较感兴趣,于是,让我继续深入一下,研究一下微服务的相关内容。

殊不知,我对「微服务」的理解,也仅仅只是知道字面上的意思。

不过,我很喜欢这种倒逼我学习的感觉,产品架构图不也是第一次画,这不都分享完了嘛。

微服务嘛,应该也不过如此。

后面才知道,还是 too young too naive 啊,微服务这个话题有点深。


针对这次分享会,我也整理了一份演讲稿,放在我的小专栏上了,有兴趣的,可以订阅我的小专栏查看。