这是在公司的一次内部分享会,领导给的课题,让我针对公司的一个数据分析软件,做一次产品架构的分享。
拿到这个任务的时候,其实我是比较为难的,对于产品架构,如果没有对具体业务有深入的了解,也很难做出建设性的规划。
不过领导说,介绍一些方向性的东西,可能是未来几年要做的事情,不需要特别具体。
这么说的话,我信以为真的放心了。
背景
公司是一个立足于国家研究所的第三方软件公司,前几年的业务方向,基本上是外包项目制的,根据客户的需求,驻厂做定制化开发。
从今年开始,公司创始人觉得这不是长久之计,于是,想要把这些零散的项目,凝聚成一些产品,向客户提供服务。
但是,做产品的效果似乎不是很好,因为公司大都是技术开发人员,产品相关工作一直是项目经理担着,而项目经理也是技术出身,同时身上也有对应的开发任务,他们疲于应付客户的需求,很难跳脱出来,从宏观的角度,去考虑一些规划性的东西。
于是,公司决定要招聘产品经理这个岗位,而我,机缘巧合的成为了公司招聘的第一个产品经理,目前也是唯一的一个。
我的工作目前没有特别明确的边界,也没有给我具体安排到某一个项目组里,现在除了分担一些项目经理手头上有关需求类的工作,就是做一些产品规划。
产品
接触的第一个产品,是公司的一个数据分析软件。
这是前些年给客户做定制化开发,项目团队留下来的一个软件版本,后来在此基础上,又做了一些整合开发,形成了一个初步的产品。
该产品目前比较混乱,一共有 3 家客户在使用,但是,每一个客户使用的软件版本又不一样。
而实际上,该产品解决的是同一类业务需求,只是针对不同的客户,交付了不同的软件版本,而且,不同版本之间差异性还挺大,猜测应该是 copy 了一份核心代码,针对不同的客户,再重新开发交付。
所以,开发团队需要在 3 个不同的版本上面,分别根据对应客户的需求,做版本迭代以及交付,这里的交付依旧指的是项目合同制。
这样的结果就是,开发团队苦不堪言,需要维护 3 份不同的软件版本,同时,也会导致产品越来越分裂。
出现这样的结果,主要原因是客户方比较强势,且定制化的需求很多,而公司前期基本上都是开发团队驻厂开发,中间除了 CEO 进行商务的对接,剩下就是开发人员的事了。
结果自然是,客户方说做成什么样,开发人员就做成什么样,没有人去做需求的统筹分析,没有人去做产品的规划。
产品架构
背景说完了,该干活了,产品架构这种东西,我也是第一次搞,以前写规划报告,都是特别虚的东西,动不动就未来 5 年要做成什么样。
这次面对一堆技术开发人员,这种特别虚的东西,想来也不会受人待见。
但是,谈到「架构」这个词,本来就比较虚,实际不了,只能是谈一谈,产品未来几年的发展方向。
想清楚之后,就开始做呗。
任何事情都可以按照做产品的思路来开展,就把「产品架构图」当作一个产品,把「画产品架构图」当作「做产品」。
用户就是领导以及同事,背景以及需求上面谈到了,也都清楚,接下来就是做市场调研,其实就是看看网上有没有可借鉴(抄)的,看看类似的软件平台如何画的架构图。
经过一轮调研之后,就画出了第一版,现在看来,实在不堪入目。
做产品就是一个不断迭代的过程,一定要紧密的跟用户进行沟通,于是,拿出这一版,跟用户(对应的项目经理)进行讨论,听取用户的意见反馈,然后对产品进行迭代升级。
期间沟通了 3 回,也改了 3 回,直到该项目团队的所有成员,都提不出修改意见了。接下来,我就开始整理需求,准备做产品初版发布,没错,产品架构图也是要有版本号的。
最终发布了 v0.2 的版本,如下图:
拿着这个图,在分享会上,我夸夸而谈产品未来规划,原本以为从此走上人生巅峰,受世人敬仰。
谁知道,果然被打脸了,说好的只谈方向性的东西呢?说好的规划呢?
为什么分享会上,大家都在谈论功能如何实现,技术怎么落地的话题?对我画的这个图,丝毫没有兴趣,也没提出任何的建议。
好吧,产品经理果然跟程序员不是一路人,我默默的听他们聊了好长时间。
后续
不过,这个图,领导倒是还算满意(可能跟他不做技术很久有很大的关系),也许是看我分享会的后半程比较尴尬,于是,又给我布置了一个任务。
他看到架构图中,有个「微服务」的字眼,可能对这个词比较感兴趣,于是,让我继续深入一下,研究一下微服务的相关内容。
殊不知,我对「微服务」的理解,也仅仅只是知道字面上的意思。
不过,我很喜欢这种倒逼我学习的感觉,产品架构图不也是第一次画,这不都分享完了嘛。
微服务嘛,应该也不过如此。
后面才知道,还是 too young too naive 啊,微服务这个话题有点深。
针对这次分享会,我也整理了一份演讲稿,放在我的小专栏上了,有兴趣的,可以订阅我的小专栏查看。