38｜能力维度三：如何提升解决跨领域冲突的能力？

我要设计一下变更管理工具，这个工具在变更评审后需要每个干系人会签，是否同意变更。有了这个工具，可以解决由于变更评审不充分引起的故障类型的团队间的冲突了。感觉需要做好沟通管理，制定评审/会议机制来发现问题是必须的，在实践的过程中，不断优化机制。

🤔☕️🤔☕️🤔 * 我要设计一个“关键术语”提取和分析工具。当多个领域互相交流时，记录下来的聊天记录、会议记录、会议录音、需求文档、设计文档等材料，自动提取其中用到的关键术语，分析大家交流时是否已经出现歧义。譬如：一个新需求文档，撰写导入到现有系统，就能够分析出，当前文档里用到术语，跟现有系统术语之间是否存在歧义。这样可以有效保证一个知识系统里，概念的持续性和稳定性，这样也更能够让大家达成共识。

之前一直想不明白高级架构师为什么那么热衷于推行长期方案，以至于影响到业务线的进度也在所不惜。看了这篇文章后我有点理解了，原来这一切的努力都是为了对抗熵增，不受制约的熵增最终会毁掉整个系统，并且这个速度会很快。

我要设计一个类似于文档记录的工具： 1.和涉及到多个团队负责人沟通需求是否明确 2.抓涉及多个团队的主要流程点，风险点 3.定期和团队负责人沟通进展，保证项目的可控 4.随着项目的深入，根据代码实际情况思考架构可能存在的问题 就是类似于文档，有这几项是必填的，保证各团队之间沟通到位。 我觉得这里的跨域架构师最大的一个挑战就是协调，沟通。还有老师提到的，在有冲突的时候，有勇于决断的气魄，实事求是，不怕得罪人

🤔☕️🤔☕️🤔 * 📖：领域间问题 vs 横向问题 * 🤔：领域间出问题，大概率是扯皮，也就是扯你做还是我做，原因大概率是收益不明显。要么，把利益的平衡点调整一下，直到大家抢着做，这是基本招数。此招的问题在于，团队会越来越趋利，直到金山银山都不放在眼里。要么，找到高人去看见看不见的方面，吃苦在当下，收获在未来。此招能使的必要前提，得有这样的高人现身。不过，领域之间也存在不可调和点，毕竟在遇到大量新问题面前，当下的领域都是曾经遇到问题的形状，不一定适配新问题。领域间问题，会导致最后出现横向问题，但是横向问题，却不一定直接来自领域间问题。典型如性能，如果领域间互相推，最终在领域之间暴露出性能问题，可是各自领域管好自己家里事，依然会有性能问题暴露出来。 * 📖：架构师、兼职架构师、跨领域架构师 * 🤔：这让我有点迷糊，能对应初级、中级、高级嘛，似乎也不对劲。如果说架构师解决当下问题的技术方案，则兼职架构师就得解决当下加上时间轴这个维度后的技术方案，再则跨领域架构师更得解决当下加时间轴再加组织结构这个维度后的技术方案。当下+时间轴+组织结构，就是架构师在当下这个点、兼职架构师在未来这条线、跨领域架构师在组织之间这个面。架构师的当下需要技术深度的能力，兼职架构师的时间轴需要见识远度的能力，跨领域架构师的组织结构需要软技能加硬风格的实力。 * 📖：找不到任何乐趣的人，学不到任何真正的知识。 * 🤔：赞同+⭐️⭐️⭐️⭐️⭐️xN。我自己现在的学习和探索，就很受《发现你的天赋》这本书的影响。要去接触那些让自己激动的点，让自己起生理反应的点，那些地方可能就是自己的天赋所在。在自己的天赋指引下的学习和探索，就自然有无穷无尽的原生动力。在别人看来的所谓的坚持不懈，在自己的视角，实际上完全无任何坚持感，只有乐此不疲无穷无尽去折腾的劲头。

关于跨领域的软件开发协同工作，学生有一个天真想法，就是要设计一个工具，这个工具可以： 1. 前端可以模拟主要的核心的用户场景。在实际开发前，要确保终端用户的场景，是赞助者和决策者都需要的。并且确保整个架构活动过程，用户场景不能偏离赞助者与决策者的期望。同时也确保背后所有跨领域的开发团队，对即将交付给用户的产品有一个非常清晰的认知。 2. 这个模拟用户场景的前端，必然依赖于计划开发的API，对于未开发的API，可以通过polyfill或mock的方案应对。首先确保用户场景的全局统一。 3. 在前端界面不再有类似Jira的task或issue管理，只有API管理，一切开发围绕API的状态进行。例如API的状态会有：polyfill_mockup, delivered_without_test, delivered_with_bug, delivered_partially, delivered等。第1点描述的虚拟用户场景前端页面，在browser的console中，前端的中间件会打印出调用某API的当前delivered状态。 4. 基于API管理的其他属性有：依赖API，开发时长（根据依赖API的状态，开发时长的计算方法不同，可以作为对此API开发效率的一个参考KPI，目的是暴露出开发短板），用户场景覆盖率(也可以是测试覆盖率)，失效用户场景描述(可以上传截图和log)等等。 以上的想法还不太成熟，请老师和各位大神指正。

老师，我这里有个疑问，如果是跨公司合作设计解决方案架构，算不算也是跨域架构师呢？相对来说，比产品线间跨域协同更加复杂，不同公司文化迥异，但这类“生态型”合作又非常重要，单打独斗已经越来越艰难，如何解决跨公司，跨文化领域的冲突，老师有没有什么好建议？

请问：招聘中“跨域架构师”的正式名称是什么？

郭老师，take away~~~这篇有点难。从思维方式和格局和见识维度理解"跨域"~~~ 思维方式，递归思维和系统思维，自顶向下和全局最优。递归思维和系统思维是亲兄弟~~~ 格局和见识，经历的团队规模、组织结构、业务模式、逻辑复杂度、数据规模、并发量、一致性，产品思维等有量级的积累，才能"跨域"~~~

我想设计一个工具，能够实时记录突发的好的idea，会议或者私下交流中偶现的问题，并能够标记关联性。对于落地技术方案变形的案例要有实时的反馈机制，并能够结合历史案例进行归纳分析，推动后续结果良性发展。