做事的边界

我对这个话题体会最深的描述是来自软件架构设计专栏中的一篇文章，下图即出自其中：

事的边界

这张锯齿状的图说的是软件在设计过程中人出于能力和职责范围，双方合作过程面对的状态，我认为这也是平时合作做事时候，对人和事的边界状态的很好的描述。

它显然是不可工作的，而它就是事情真正的状态。不管是在管理多么优良的企业，只要从事的是知识型创造性的工作，工作的边界即总是这个样子。想要通过流程改造将其切口合并，也是可能的，然而可能性有其（管理）科学研究的价值，而没有对现实中真实存在的组织管理的意义，原因是成本和收益的关系必将导致其得不偿失。管理上的努力就如同对分形图放大，放大后还会是这个样子。

因此现实世界中事情能够做到足够好，靠的是合作的力量，在原文中作者称之为弱者道之动，就如下图：

事的嵌合

淡色的部分就是最终可以工作时候的样子，结果是一种嵌合，双发都要承担之前对方突出的职责，并且都要让出之前已经拥有的能力的部分对应的权力（那些锯齿尖）交于别人。

这就是合作的价值所在。

从个人来讲即要求个人素质能力要有所外延，才能在最终合作的蓝图中自己需要承担的那部分有所准备。

而会让人烦恼的一类合作者就是未懂得这个边界先锯齿后嵌合的顺序，而是反过来根据自己锯齿状的边界去切，边界之外一概不管，边界之内寸土不让。自然事情就前进的辛苦，效率底下。

末了，引用下同样这位专栏作者的另一篇文章的内容作为泛化的这一类问题的总结：

我刚入行的时候（其实现在很多人还有这个误区），当我们发现需求做错了，实现和设计不一致的时候，我们都会做出一个判断：这是需求文档写得不够严谨，设计文档不接地气。这个判断方向基本上是缘木求鱼。我是认为干了好几年，还是抱这种心思的工程师，基本上架构设计水平也就到此为止了。因为你始终不相信事实，而去相信你的理想了。你写了几年的程序，一直以来需求文档都不够严谨，设计文档一直不接地气，甚至从来没有改进过，你还不断相信，你有一天能写出“严谨”的文档？你完全被你的个人想象蒙蔽了眼睛，从来没有好好看过这个世界啊。