话说工作的“边界感”

一句话的合作例子

今天有一个业务的运营同学匆匆忙忙找到我，说要跟我这边有一个问题，业务要合作，然后已经提前和我老板打过招呼了。事情是这样的，我这边负责的是工作台门户，然后作为一个平台业务，有大量的客户需要找到对应的服务商来给自己定制门户。然后这位同学负责的是定制业务，所以要统一把所有的定制业务全部收口，但是这位定制同学的业务没有对应的技术研发同学，所以他就找到我的老板同步了这个情况。

分工协作的本质

其实问题的合作方式是比较简单的，但是当她跟我说最终客户定制界面也由我来开发的时候，比如定制的费用是多少、定制的时间要求等等，我就觉得问题有些奇怪了。因为按照常理来说，我负责的是工作台，但是由于有定制业务相关的逻辑，所以我要处理一定的业务逻辑，但是让我去承担这个定制页面的开发，我觉得是有问题的。

举一个简单的例子，假如我现在是一个博物馆，原来用户是直接可以免费没有任何阻挡地进入博物馆的，但是突然有一天市政府说所有公共设施要收费了，那么对于博物馆的工作人员来说肯定是支持的，但是突然你又告诉我，我这个博物馆还要去维护全市统一的收费系统，这个就是不合理的。哪怕他找我的主管沟通结果也是一样，因为我和我的主管是属于博物馆体系的工作人员，他也没有义务和责任去维护整个所有的公共设施的收费系统。但是作为公共设施系统的一部分，如果有统一的收费规则，那么对于博物馆来说也是要遵守的。

所以这面就引出了我对于业务边界上面的一个思考。我经常看到同学给我转发一段话，说跟你老板打沟通了业务的合作情况，你的老板觉得非常不错，于是这位同学就匆匆忙忙的找到我来开始谈业务，谈实施细节并且需要我快速落地。而实际上这种所谓的业务协同的情况大部分也只会停留在沟通的层面，在最终落地的时候，往往和业务同学的预期不相符。在业务同学眼里看来，就是你们阴奉阳违，恨不得马上就开始投诉。

这里面非常核心的一个误区就是业务同学往往没有划清业务界限和系统界限的边界。对于业务同学来说，边界可能不会那么明显，但对于一个系统开发的同学来说，业务和边界是非常明显的，因为系统是物理存在的，有着天然的“隔离”。所以对于业务同学，如果想要顺畅的推动业务，必须要事先清晰的划分参与方的角色和业务边界，并且可以进一步了解到系统边界在哪里。

这个由谁来做就涉及到了一个很大权责问题。简单来说就是我做了有什么好处，换句话来说做这件事和我的职务目标有什么关系？如果没有关系，我为什么要做？就算同一个公司，也有很多需要完成的事，比如公司保洁不到位，我作为公司的员工，是否也立即从事保洁？

如果是我的职务目标，我的责任有多少？我承担了既定的责任，那我是否能够承担起对应的权利？在我上次借用的博物馆的例子可以看到，如果我承担了全市的公共系统的收费设施的维护，那么我的权利在哪里？如果我的权利只是在博物馆这一个地方的收费上面，那么这就变成了权责不对等。

但是如果我做成了全市公共收费系统，并且能掌管全市所有公共设施的收费业务，那么对于这个收费系统的开发权则是相等的，但是对于我本身职务的权责又是不等的，因为公司请我来管理博物馆的，而非管理整个全市的收费系统。

所以在思考业务推进的时候，首先就要思考系统的边界和权责对等关系，如果这一层面没有理清楚的话，合作大概率是不能完成的。而很多的业务同学就以“我和你老板谈好的东西，为什么你不去做”这么简单的方式来拷问协同关系，我觉得是非常的幼稚的。

所以我希望其实我们在去和别人沟通业务的时候，往往要带着权责，带着边界的思考，去和对方去讨论，去协商，去沟通。简单来说，我在跟你聊之前，我要知道你的系统，你的业务边界在哪里？我跟你聊的时候，我要清晰地告诉你，这个事情做了对你有什么好处，对我有什么好处，哪部分应该你做，哪部分应该我来做。只有在这样的一种沟通方式下面才是真正合理的，真正是可以落地的沟通和协作方式。

而在这些问题没有达成一致之前，由谁来做都没有定下来的时候，应该先去往上升，在顶层设计里面去规划去重新思考如何从组织设计的方式去让业务协作自然的发生。

总结

这里再总结一下，这里是一个小的心得。这个案例也告诉我们，我们去沟通协同的时候要有边界感，包括业务的边界和系统的边界。只有把边界理顺了，合作才有可能。