日常随笔：基础架构争取业务共建的方法

工作场景：基础架构团队想要做一个事情，人力有限，想要业务部门配合共建，如何说服对方并形成比较好的落地？

难点：如何说服对方参与？基础建设非业务团队核心目标，如何保证业务投入精力以及持续性？

比较好的共建方式：一个事情，对业务团队来说，可以讲的是对业务的价值，对架构团队，讲的是沉淀和复用的价值等。

误区：对业务团队来说，搞一些基础建设当然是好事，但不是正事，所以讲出来不会深刻，只会让别人觉得，挺好的，但也就一般般好，对于级别低的同学来说，可能足够好了，但是对于级别高的同学，那只是你应该做的。

对基础架构团队，不必动不动就上升到公司或者集团的高度，对于集团来说这是一件很有普遍意义的事情，所以不管你是什么团队，大家需要都能站在这个角度考虑问题，参与共建，这样的想法是偏执的。

所以，不管是业务开发自己，还是想要争取业务开发共建的基础团队，都需要站在自己的定位上看问题看价值。

所以，争取业务开发的共建，首先要做的不是定一个事情，大家看起来都觉得挺好的，也挺好玩的，然后拉一伙人就开干。特别是在绩效制度之下，往往不能很好的落地，因为业务开发很有可能无法全情投入，而且他的老板可能也无法让他全情投入。

所以，更好的方式，可能是，让基础建设的事情成为他们的业务目标，为业务解决了什么问题，做一次分析，然后把信息同步给业务方（业务的产品/业务的开发老大），最好能够与业务目标关联，成为大家的共同目标，从上至下，去落地推动，这样，大家即参与了一个挺好玩的事情，也完成了绩效，既有普遍的意义，又有业务意义。

至于如果与业务目标关联，这个就比较微妙了，不能一厢情愿，也不能过于保守，什么是一厢情愿？例如，你觉得你做了一个性能优化的方案，增加页面打开速度，你觉得这当然是好事，提升用户体验，这必然是每个业务必然要关注的，问题就来了，性能好当然是好事，其他类似的还有为项目引入单元测试等，这些事情当然是好事，但他们是业务的痛点吗？产品/运营/商业部门对这些问题的关注程度如何？对用户数/转化率的影响够直接吗？当然，如果深究起来，这些必然是有联系的，这就是为什么说这些事情当然是好事的原因，好事但是不够深刻。不是所有业务的瓶颈都在性能上，对于c端来说，如果性能体验明显有问题，那这当然是会明显影响转化的，这种情况下它就不止是一个好事，而是必须要做的事，但是对于某些b端应用，不明显的性能差异，基本不会影响转化或留存，所以，你去晋升的时候，讲到这里，业务方的评审的感受可能是这位同学在技术上感觉还挺有想法的，但是对业务好像没有太大帮助，勉强鼓励一下吧，但是如果技术做的事情，能够尝试从多个角度去观察和分析业务的规划和痛点，然后把技术植入其中，最后带来的效果肯定不是如此，业务方会觉得你对他们帮助特别大，老板也会觉得你思考做事更深刻。如何做到深刻而不只是挺好的？最最前提的是要对业务有透彻的了解和理解，能够发现业务痛点和技术的关联，例如某个保险业务，之前大量使用人工处理订单，如果可以大量向线上转化，可以帮助业务解决人力/效率/推广量级等非常核心的问题，那如何向线上转化，这里可能涉及到好多个点，需要和产品/业务做几轮深入探讨，发现技术可以在架构上做针对的设计，提升出单的覆盖范围/提升出单的成功率，为此，需要做那几件技术上的架构设计支撑。这里只是举个例子，核心还是抱着技术的经验，去熟悉和分析业务的场景，解决影响深远的问题。