近期笔者因为工作原因，开始启动team内部部分技术项目的重构。在事情启动的过程中，内部对于这件事情的定性和投入有一些争论，但最终还是敲定了下来。其中部分争论点主要在于产品形态，因为事情涉及到跨部门合作，所以产品形态怎么符合双方的利益是比较重要的。在这个前提下，然后才是技术设计上面，怎么能够迎合长久合作的需要。

因此，今天笔者就简单聊一下，怎么去做到让技术架构设计和预期产品形态能够做到有效平衡。

首先，因为产品形态决定技术结果，所以需要经过讨论去确定核心的产品效果。笔者所在的team距离具体业务比较近，而面临的跨部门合作场景主要是和infra部门合作，那么这里面的分歧点就是，infra部门对于业务需求提倡开放性，而距离具体业务比较近的部门则更加倾向于打造相对封闭而有竞争力的产品。为了解决这个分歧，最终讨论产品效果是让infra提供架子，笔者team的能力作为核心组件接入，这样就能够达到双方对于最终产品效果上的共识。当然，不同企业不同部门情况不统一，但这个事情还是要确定的。

其次，由产品形态反推技术设计，必然涉及到架构演进的部分，从现有的技术架构出发，怎么演进到最终态，花费多少时间多少人力，如果要拿技术/业务结果的话有哪些阶段性产出，不同阶段之间架构演进会有什么样的变化，每个阶段投入产出比怎么样，这些都是作为架构师需要去考虑的。在笔者的case里面，笔者所要重构的是一套变更风险观测基建，所以架构演进主要采用分模块演进的方式，第一阶段面向观测能力，提供统一的技术接入和调度协议；第二阶段面向观测调度，提供类流水线+低代码的编排方案；第三阶段将整套调度编排做持续迭代，适配各类业务变更观测场景，并完善数据度量分析等周边功能。这样，这套变更风险观测基建，就可以兼顾短期和长期的落地需要，逐步成为公司内部标准化的方案。

最后，在实际执行技术架构实现的过程中，也需要保持足够的主动性，推动研发和非研发的事情都得到解决。虽然下面的话有点阿里味，但道理是没有错，那就是因为相信，所以看见。以这样的基础，跨部门合作也会更加有凝聚力，大家也更愿意互相信任，让整个事情做到成功。当然，悲观的来讲，唯一不变的是变化，也许一些宏大的技术构思，最终也会因为种种原因无法落地，但这并不重要。重要的是，你能够用技术掌控人，解决人的问题，这才是作为一名技术架构师存在的价值。