17|通用技能(下):架构师如何保障交付与沉淀知识?
该思维导图由 AI 生成,仅供参考
保障交付
降低不确定性
- 深入了解
- 翻译
- 解释
- 总结
架构师在架构活动中扮演着重要角色,保障交付和控制复杂度至关重要。本文强调了保障交付的关键性,指出降低不确定性和复杂度、最小化架构方案是实现高质量交付的关键。在互联网时代,不确定性和复杂度是架构活动的主要挑战。为有效应对这些挑战,架构师需要从问题域层面分解架构规划和交付方案,增加架构设计方案的结构性,并按多种方式分割交付模块。文章还强调了控制复杂度的重要性,以及通过结构性设计和分割交付模块来降低不确定性和复杂度,提升软件架构的质量和稳定性。此外,沉淀知识对于保障架构活动的思考与决策质量至关重要,同时为企业未来的架构活动提供宝贵经验和方法论。架构师需要通过有效的知识沉淀来保障架构活动的质量,并通过文档来驱动思想实验,创造历史的过程。文章强调了最小化架构方案和沉淀知识的重要性,为架构师提供了有益的指导和建议。
《郭东白的架构课》,新⼈⾸单¥68
全部留言(23)
- 最新
- 精选
- 罗均非常感谢老师精彩的课程! 这节课的第二个问题,比较有挑战性。有一项技能,不知道是否合适?学生还无法用准确的语言表达这门技能,姑且暂用【洞察全局 Global Insight】,这个想法来自于《毛文选》的第一篇文章《湖南农民运动考察报告》——毛主席当年如何进行“接地气”地考察,又如何基于“数据”洞察当时湖南省乃至全国的革命形式。 能否问一下老师,在老师以往的工作经验中,在加入一家新公司时,大约需要多长时间可以对这家企业的业务模式和技术架构有非常清晰的认识,清晰的程度足以支持老师在大型的架构活动中进行“垂直领悟划分”?乃至于定义清晰的“最小必要原则”?在此中间,有哪些难忘的“坎”可以分享给学生吗?
作者回复: 我过去一般不仅仅是进入一家公司,而是换一个行业。换了好几个行业了。 我进入之后,三个月之内不会有任何管理动作, 一般都是观察和理解。 三个月以后我会小范围出手,在我之前有经验优势的领域做一些团队和架构的建议。 然后看数据效果。 这时间开始我逐渐对我比较熟知的领域会有自己的决策建议, 但是不会行驶我的否决权。 我一般在一年到一年半之后形成自己的认知,会行驶否决权。也就是我对一个产品技术是否是公司现阶段所需要,有比较强烈的观点。
2022-03-03211 - 欧阳绍聪我前面不太确定,听完后才发言。少了人的维度,人的成长,不仅是自己,还要能成就别人。我个人觉得是少了成就别人,这个不知道算不算是基本素养了。
作者回复: 其实我自己的感觉这个真的是非常划算的一件事。 我们身边很少有白眼狼。 你成就别人就是肯定是一个回报很大的事情。 真正缺少的是成就别人的机会。
2022-03-027 - kq yang卡尔·波普说,只有写下来的东西才是能够批判的东西。我们人脑并不是一台逻辑引擎,它只是一个信念和证据反复迭代的玻尔兹曼机,一个模式工具。我们头脑混乱、冲突却可以自以为和谐地相处,直到它被写下来接受自己的,他人的,历史的批判。 知识的沉淀这我有点不同看法。参考桥水基金和得到李育辉的组织管理课程。知识管理的精华并不是知识本身,也不是工具化思维。他们都有点太死板了。不能完全走出德鲁克说的“工具不能替代思考”的局限。知识沉淀的精华在于如何度量组织所有成员的知识储备,以及任何时候快速接入所需要的人进行决策推进的能力。静态的知识,可以认为谷歌已经全部容纳,但是正如科斯定律试图表明的,让那个能最轻松解决问题的立刻出现,才是最大的美德。两个例子中都对具体该怎么做给出了较好的回答。
作者回复: 好怪啊, 我好像回复过了。。。 Anyway, 我们其实没有讲的知识管理,只是说通过文档来驱动更高质量的逻辑思考。 不过你讲的“组织知识”,我其实觉得大趋势不是这样。这种沉淀在人脑中的知识(Tacit Knowledge)在驱动价值创造上明显输给了同样不可解释和结构化的大模型。 感觉未来整体的趋势还是把人脑中的知识尽量结构化、标准化,和规模化变现。 不过我没看过你讲的这个理论, 就是分享一下直觉而已。
2022-03-0325 - Henry特别赞同最后推演的观点,这种推演不是为了证明事情一定能成功,而是为了证明一定不成功。证明成功在复杂的商业环境下几乎不可能,但证明一定失败则要简单得多。这是一种负责的表现,也是努力的正确方式。
作者回复: 是的。这是最最不应该省的时间。 但是经常看到公司在这里省时间。
2022-09-19归属地:美国4 - Right数据的最大价值体现在运用,而不是存储。被动地记录、整理文档只是存储而已,如果不对其进行主动地思考和运用,那这些文档便毫无意义,更谈不上什么共识的建立。 我曾待过一个公司,强制要求项目过程中任何行为都得落盘文档,一个需求下来能产生大量文档内容,然而这些文档对于后续项目的帮助非常有限,同一个坑可能会被踩几次,即使这个坑之前早已记录。 那如何真正地去运用文档、沉淀知识,说实话我至今还在探索答案,非常期望老师后续能详细讲讲这一块的具体实践。
作者回复: 文档的召回其实非常关键。 不过我倒是觉得类似平台模式的机制, 也就是一个链接创作者和消费者的文档管理平台, 来提升一个组织内知识传播和利用是很高效的。 平台提供文档检索、推荐、标签、反馈机制(点赞/阅读数量)和激励机制, 通过时间沉淀高质量的创作者、知识、传播链已经被证明有效。 个人层面的知识积累我觉得更多要关注ROI, 而不是文档这样的技巧。知识很多, 但是能够为你创造短期和长期价值的其实不多。
2022-03-0323 - Henry关于被动文档特别想提一点,就是对被动文档的整理。最好是在项目结束后,对文档做一轮整理,方便后人学习,没有整理过的文档看起来效率真低,是一种负担了。
作者回复: 赞同的!
2022-09-19归属地:美国2 - ibrothergang在看这篇文章之前,觉得知识沉淀就是一个知识文档收集归类的过程,顶多在需要的时候,不需要到处去寻找。 看完这篇文章之后,才发现如果仅仅是一个收集过程,可能永远是单向的。就好比有很多人在自己的网盘里收藏了几十个 G 的文件一样。如果不经常拿出来晒一晒这些知识文档,容易发霉,最后一点用处也没有。
作者回复: 不但没用处, 有时候还会有坏处。 因为很多人误以为文档写了, 自然就为公司沉淀了体系化的知识, 其实不然。
2022-03-082 - 人间四月天非常赞同,回顾自己做项目经历,也是用同样的方法,可能很多读者感觉比较理论,实际上,可能很多人没有做过复杂项目,或者没有想用最小成本创造最大收益去深入思考和实践,再次强调一点,靠无限堆人做项目,是对成本的蔑视和不负责任的,这应该就是架构师站在公司视角考虑问题的根本和价值。
作者回复: 谢谢啊!
2022-03-022 - Henry思考题1:在直播和短视频公司做过一个直播带货项目,这个项目中最大的不确定性来自于目标不确定。我负责交易支付结算部分,我觉得当前主要目标是支持业务快速试错,我的的应对方案: 1. 结构化。结合自己的经验对系统做了领域划分,抽象出了领域层,这一层基本基本不会变,将变化控制在应用层,在迭代中再继续将应用层不变的部分沉淀到领域层,这样整个系统是结构化的,能在迭代中保持较低的复杂度 2. 抽象接口。在上面领域抽象的基础上,对接口做抽象,适应性更强 这个项目最终没成。官方说法是资源不足。我的理解是目标不明确,因为业务始终没有结合现有用户做分析,所有的决定都是拍脑袋,所以我认为这个项目败在没有一个明确的目标,没有目标的规划都是没有意义的,成功概率极低。 思考题2 我想补充一个员工激励。架构活动中并不是每个阶段都是有趣的,实施过程还是挺枯燥的,架构师一般不直接管理员工,又要组织架构活动,所以需要有激励员工的能力,保持团队的活力,提高凝聚力。 思考题3 爱因斯坦吧,近代物理最牛架构师,谁实施成功谁拿诺贝尔奖,开玩笑的。 说个正经的,智能柜。我看过这个项目早期文档,竟然还包含了详细的公式推导,这也是我见过的为数不多的包含公式推导的PRD
作者回复: 的确很多物理学家和哲学家都是思想实验的大师!
2022-09-19归属地:美国1 - Geek_42abae可能每个公司对架构师的定位不同,我总感觉文章中说的是大公司首席架构师那种。我们这架构师是配合项目负责人的,那比如知识沉淀,大概率是项目负责人的职责了。
作者回复: 知识沉淀在各个粒度都有的。 一线研发也要做知识沉淀。
2022-09-19归属地:美国