产品经理懂点技术(2):产品经理真的要懂微服务么

微X是由X驱动的,这就意味着X规划的好坏会直接影响系统架构的好坏,糟糕的系统架构还将拖X的后tuǐ,甚至进入è性循环。

康威定律

在上文讲微X架构的由来时,我们引用了马尔文·康威(Melvin Edward Conway)的一句话

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations

设计系统的架构受制于产生这些设计的X的沟通结构。

——Conway, 1967.

康威是以为计算机科学家,计算机程序员和X,他著名的论文《How Do Committees Invent?》里面的内容被弗雷德·布鲁克斯(Fred Brooks,美囯计算机架构师, 软件工程师和计算机科学家,以管理IBM的System / 360系列计算机和OS / 360软件的开发而闻名支持包)在他的经典著作《神话人月》(The Mythical Man-Month)中引用了,称其为“康威定律”。

康威定律可谓软件架构设计中的第一定律,总结起来又有四条具体定律,我们主要讲讲其中第一、第三定律。

康威第一定律:

Communication dictates design

X沟通方式会X系统设计表达出来

图片:Manu Cornet

X的沟通方式,包括X部门的划分、合作liú程,如果部门间分工混乱、liú程无章可循,那么系统上就只能发现什么问题解决什么问题,不能有效的促进X的发展。只有解决好X的沟通方式,大家分工明确、liú程清晰,才有更好的工作效率,也才有可能做出一个好的系统。

康威第三定律:

There is a homomorphism from the linear graph of a system to the linear graph of its design organization

线型系统和线型X架构间有潜在的异质同态特性

笔者补充:homomorphism的中文翻译是同晶(型)的意思。异质同态就是外在不一样,但是本质结构类似或一样的意思。

第三定律是对康威第一定律的具体应用,什么样的X架构将会决定什么样的系统。反而言之,如果想要一套好的系统,那就得要有一套好的X架构。

图片:James Lewis、Martin Fowler  翻译:iCheer

图片:James Lewis、Martin Fowler  翻译:iCheer

根据康威定律,我们就知道了,X的形态最终会影响到系统的架构。而微X是由X驱动的,这就意味着X规划的好坏会直接影响系统架构的好坏,糟糕的系统架构还将拖X的后tuǐ,甚至进入è性循环。

X-产品-研发的工作liú

当我们讨论产品方案时,都不能拖离X,X是需qiú最重要的根源,那到底什么是X呢?

从词语定义来说,X是指某个行业或者某个职务所做的事情,就叫做“X”,其参与者是人,未来也可能是电脑、机器(AI、自动化),其目的满足行业、职务的X对象的需要。

X方在工作过程中,为了实现更高的产能、获得更高的回报,就会想办fǎ去优化整个Xliú程,这就产生了“需qiú”。只要X想发展、在发展,需qiú就会源源不断的产生。

产品经理X的需qiú来源,外部是X的X对象:用户;内部则是X的执行方:老板、运营、X、财务、fǎ务、供应商等。X方将需qiú告知产品经理,产品经理经过调研论证,将需qiú转换为产品方案,输出可以满足X需qiú的产品需qiú文档、原型。

然后,产品将功能的需qiú提给研发人员,研发最终将这些功能得以实现,于是系统诞生了。X方使用系统,不断发展扩大,产生更多的新需qiú,于是以此往复,形成X-产品-研发的需qiú链条闭环。

在这个链条闭环里,X形态、liú程决定了系统最终的形态,而系统形态则推动X的发展。产品是连接X与系统的纽带,技术并不是在瞎逛,而是根据产品的需qiú去研发系统,技术研发出来的系统会最终决定X未来的走向。

微X与产品经理的工作

X驱动:

微X是技术让代码更适应X发展的产物,是X驱动下的产物。

微X的概念需要程序员更了解X的板块划分和发展方向,代码要随着X的不断成熟,按照X结构进行模块化、X化,才能方便X的发展X,这就要qiú程序员要“懂点产品”。

如果程序员一味的按照纯粹的技术方案或者自己拍脑袋定的方向做,那随着X的迭代发展,很容易出现“这个需qiú做不了”的问题,因为代码被技术方案X住了,无fǎ适应X的发展,如果要解决,可能就要重构,时间、人力成本将居高不下。

X驱动的过程,不是一个“理想”、“理性”的过程,代码讲究的是逻辑,是要“不出bug”、“跑得起来”,但是X的发展是用户、市场需qiú不断积累的一个过程,很多需qiú可能是很主观的,甚至有时候是“灵光一闪而过”的。需qiú存在不确定性,这就让程序员犯难了,那到底要不要按照这个方向做呢?万一做了用不上要X重来怎么办?

这时候就体现出了产品经理的作用,对现有X架构的划分、对新需qiú的判断和归类,这将直接影响微X的架构模块。

产品蓝图:

产品经理可以不懂什么是微X,但应该知道自家产品的功能架构或产品蓝图,这既是产品需qiú筛选、功能规划的依据,其实也是技术做微X划分的重要依据。

产品蓝图(Product Roadmap)描述产品可能的发展方向,X利益相关者的意见,计算产品开发预算的强大工具。 但是,想要作出切实有效的蓝图并不容易,尤其在意外变化频频的敏捷环境中。

——《创X捷产品蓝图的十个技巧》-carlosmeya

Roadmap通常翻译为“路线图”或“蓝图”,目前并没有一个公认的定义。在这里,我们认为Roadmap是产品经理进行产品管理的一个中长期规划,也称路标规划。
为什么要做Roadmap?简单说就是,心中有数。

某平台的产品蓝图1  来源:百度图片

某平台的产品蓝图2  来源:百度图片

某平台的产品蓝图3  来源:百度图片

看了上面的产品蓝图,是不是觉得和功能架构图十分相似?其实表现上差不多,但是产品蓝图还包hán了对整套系统的发展方向预期,里面的很多模块可能处于“会有的”状态,随着X的发展不断补全。

有了产品蓝图后,新需qiú就可以很方便的进行归类,做版本规划时也可以看得出距离预期目标还有哪些没有实现的地方,然X行补齐。

更重要的是,产品蓝图作为产品设计方向的指导作用,能让技术对产品未来的完整形态一目了然,然后再进行以X为驱动的代码X化,这样就能让代码能适应更长远的发展需要,避免盲目设计导致最终影响X发展、需要X重来。

X产品蓝图、产品规划,产品经理能让技术了解整个X的未来发展方向,让技术可以更熟悉产品,知道“为什么这么做”、“以后还要做什么”,这样在写代码的时候可以更有方向的做兼容。

总结

微X其实是技术、产品的目标一致化的必然结果,大家都以如何更好的发展X去进行工作。产品经理可以不需要深入了解微X下各种配套的机制、利弊的问题,但需要知道,微X其实是产品架构在代码层的映射、体现。

一个好的产品架构,将有利于技术框架的成型和发展,反之一个模糊不清、结构混乱的产品架构,将会让技术也无从下手,只能头痛医头的解决眼前的需qiú,无fǎ从代码层面做长远的兼容、发展考虑。

所以我的观点是,微X是技术架构适应X发展的一个过程,如果从技术的工作上看,让代码顺应X的发展其实是个大难事,关爱程序猿人人有责。而产品经理虽然不需要知道微X的技术细节和实现方fǎ,但应该更多的强化自己的产品能力,多将X发展方向的事情与技术同事聊聊、科普一下,有利于技术架构更好的发展。

参考文章

《ApXing Conway’s Law to improve your software development 应用康威定律改善软件开发》作者:Fausto de la Torre

《CONWAY’S LAW 康威定律》作者:Melvin Edward Conway(康威本人)

《Microservices a definition of this new architectural term 微X:一个新的架构术语的定义》作者:James Lewis、Martin Fowler,此文有中文译文版本,大家可以自行搜索

《每个架构师都应该研究下康威定律》作者:X

《康威定律》作者:Smah

Dubbo:X巴巴X开源的一个高性能优秀的X框架,guān方文档:http://dubbo.apache.org/zh-cn/docs/user/preface/background.html

相关阅读

产品经理懂点技术(1):程序员讲的“微X”到底是什么?

#专栏作家#

iCheer,X号:云X,人人都是产品经理专栏作家。房地产/物业行业产品经理,Python编程爱好者,养猫发烧友。

本文原创发布于人人都是产品经理。未经许可,jìn止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理懂点技术(2):产品经理真的要懂微服务么 https://www.xiongfawang.com/2393.html

常见问题

相关文章

产品经理懂点技术(2):产品经理真的要懂微服务么-海报

分享本文封面