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