24｜节点四：如何减少语义上的分歧？

谢谢老师的课程！ 今天思考第三个问题，不知道学生的做法属不属于建模。对于不同职能不同背景的群体，要用一个模型来“统一”语义实在太难了。学生一般的做法，会建三份“模型”: 1. 从产品和marketing的视角，以漂亮点的ppt“构建需求模型”到最后的运营数据报表模型。 2. 从开发和交付的视角，以UML和demo代码为主，只要给开发和测试人员，趟平坑让他们舒服就好。 3. 从运维和安全的视角，以网络拓扑图和安全认证交互图为主，一方面是需要通过安全团队的audit，另一方面是确保不同的开发阶段和环境下，不block住开发和运维做trouble shooting就行。 在实践过程中，就是反复地迭代性地去给不同职能的团队“填空”，满足他们需要知悉的信息。

郭老师，take away~~~ 分享。以前做了一个1000多万的社区项目。老团队开发了6个月失败了，为什么？对问题没有定义清楚，边界不明确。边界不明确反应对需求理解不到位、战略不清晰~~~经验缺少和概念缺失是导致失败的两种原因，概念缺失属于无解的失败，认知有问题~~~

感觉这两节课挺重要。但是不知道为什么 学习下来没有之前课程的那种收获感

抽象建模能力是架构师和项目经理必备的能力，这也是这行的基本技能。幸亏在读大学的时候，参加过2次数学建模大赛

还是没太看明白,假如老师遇到第23节案例的问题,具体会怎么处理?

🤔☕️🤔☕️🤔 * 📖：每个角色都有自己的语境，每个角色大部分时候不知道总共有多少角色，而架构师正好在跟所有角色交流的结构洞里，所以由架构师去统一语境，就显得天经地义。 * 🤔：某个项目的交集而言，架构师的确跟所有集合都有交集，所以显得统一语义这事情就非架构师不可。如果公司有很多项目，多年持续下来，是否已经有很多公共的语义已经潜移默化中统一。在某个具体项目上，拥有相同背景和经验的人，在一起语义的一致性越高，大家交流也会更有默契，甚至就是一个颜色和一声叹息，就Get到最关键的情绪和诉求。这么推测的话，架构师除了硬邦邦制定统一语义，还可以暖融融跟大家产生连接，让大家之间产生连接和信任，很多语义问题是否也会得到改善，至少会多问一句，你刚才那个是不是这个意思嘞。 * 🤔：针对某个名词，尤其是较抽象的词，或者是需要切身经验的词，很容易到最后发现，原来你在说这个呀，或者在心里互道一声傻子。有种办法，那把这个名词，放到一个过程里，大家都对这样的过程有类似的经验，那就更容易达成共识。典型如傻子，那肯定是五百个人心中，有五千三百九十五种傻子的样子，其实最典型的傻子只有一种，那就是在心里念着对方傻子的傻子。其实谁都不傻，但都喜欢看对方是傻子，这就是犯傻的傻子。 * 🤔：忽然觉得，架构师得像建筑师一样，把素描作为基本功之一。关键时刻，时序图、流程图、活动图，都顶不上一张素描写出来的意，更容易让大家达成一致认识。

著名的认知语言学家乔治·莱考夫，是当今世界上对文字游戏研究得最透彻的人之一。乔治·莱考夫有一个特别重要的观点，任何语言都有它的框架，也就是前提。 语言的框架，指的是每个词语背后那个默认的信息。乔治·莱考夫认为，语言的力量其实就来自这个框架。

建模过程能探索问题根因，从而在解决方案层面根据问题类型做好对标，调研业内做法。

你以为的，我以为的，他以为的。 关联系统比较多，大家都在各自的语境里生活。 沟通成本极高。

mark | 2022-2-27