江苏龙网

  1. 首页 > 资讯 > 科技 > >

趣投稿产品经理懂点技术（2）：产品经理真的要懂微服务么( 二 )


产品经理接触的需求来源 ， 外部是业务的服务对象：用户；内部则是业务的执行方：老板、运营、商务、财务、法务、供应商等 。 业务方将需求告知产品经理 ， 产品经理经过调研论证 ， 将需求转换为产品方案 ， 输出可以满足业务需求的产品需求文档、原型 。
然后 ， 产品将功能的需求提给研发人员 ， 研发最终将这些功能得以实现 ， 于是系统诞生了 。 业务方使用系统 ， 不断发展扩大 ， 产生更多的新需求 ， 于是以此往复 ， 形成业务-产品-研发的需求链条闭环 。
在这个链条闭环里 ， 业务形态、流程决定了系统最终的形态 ， 而系统形态则推动业务的发展 。 产品是连接业务与系统的纽带 ， 技术并不是在瞎逛 ， 而是根据产品的需求去研发系统 ， 技术研发出来的系统会最终决定业务未来的走向 。
微服务与产品经理的工作
业务驱动：
趣投稿产品经理懂点技术（2）：产品经理真的要懂微服务么
本文插图
【趣投稿产品经理懂点技术（2）：产品经理真的要懂微服务么】

微服务是技术让代码更适应业务发展的产物 ， 是业务驱动下的产物 。
微服务的概念需要程序员更了解业务的板块划分和发展方向 ， 代码要随着业务的不断成熟 ， 按照业务结构进行模块化、服务化 ， 才能方便业务的发展壮大 ， 这就要求程序员要“懂点产品” 。
如果程序员一味的按照纯粹的技术方案或者自己拍脑袋定的方向做 ， 那随着业务的迭代发展 ， 很容易出现“这个需求做不了”的问题 ， 因为代码被技术方案禁锢住了 ， 无法适应业务的发展 ， 如果要解决 ， 可能就要重构 ， 时间、人力成本将居高不下 。
业务驱动的过程 ， 不是一个“理想”、“理性”的过程 ， 代码讲究的是逻辑 ， 是要“不出bug”、“跑得起来” ， 但是业务的发展是用户、市场需求不断积累的一个过程 ， 很多需求可能是很主观的 ， 甚至有时候是“灵光一闪而过”的 。 需求存在不确定性 ， 这就让程序员犯难了 ， 那到底要不要按照这个方向做呢？万一做了用不上要推倒重来怎么办？
这时候就体现出了产品经理的作用 ， 对现有业务架构的划分、对新需求的判断和归类 ， 这将直接影响微服务的架构模块 。
产品蓝图：
产品经理可以不懂什么是微服务 ， 但应该知道自家产品的功能架构或产品蓝图 ， 这既是产品需求筛选、功能规划的依据 ， 其实也是技术做微服务划分的重要依据 。
产品蓝图（Product Roadmap）是描述产品可能的发展方向 ， 统一利益相关者的意见 ， 计算产品开发预算的强大工具 。但是 ， 想要作出切实有效的蓝图并不容易 ， 尤其是在意外变化频频的敏捷环境中 。
——《创建敏捷产品蓝图的十个技巧》-carlosmeya
Roadmap通常翻译为“路线图”或“蓝图” ， 目前并没有一个公认的定义 。 在这里 ， 我们认为Roadmap是产品经理进行产品管理的一个中长期规划 ， 也称路标规划 。为什么要做Roadmap？简单说就是 ， 心中有数 。
趣投稿产品经理懂点技术（2）：产品经理真的要懂微服务么
本文插图

某平台的产品蓝图1 来源：百度图片
趣投稿产品经理懂点技术（2）：产品经理真的要懂微服务么
本文插图

某平台的产品蓝图2 来源：百度图片
趣投稿产品经理懂点技术（2）：产品经理真的要懂微服务么
本文插图

某平台的产品蓝图3 来源：百度图片
看了上面的产品蓝图 ， 是不是觉得和功能架构图十分相似？其实表现上差不多 ， 但是产品蓝图还包含了对整套系统的发展方向预期 ， 里面的很多模块可能处于“会有的”状态 ， 随着业务的发展不断补全 。


推荐阅读


上一篇：加热器电热汇分享加热器使用注意事项

下一篇：互联网圈里人途虎养车辟谣股东退出，盘点那些差点被谣言“毁掉”的知名企业