Question

但这与“具体工程”有什么关系？

工程，或用来指代“其具体事务”的项目，是中层管理语境下的一个讨论对象。对系统，它依赖于具体的组织结构形态；对外，它依赖于管理层授权；对内，它依赖于团队协作并逐渐形成独立的行事风格；对局部，它依赖于产品或产品线对于“事务”的定义、限制以及相关的决策过程。

具体工程，是一个无法脱离环境约束的、对工程的定义。大多数对具体工程的成败构成显著影响的因素，都是组织行为而非具体事务的做法。

因此，如果组织在布局，那么项目多数是“求势”而不是“求实”。我曾经举过一个例子，你的主管可能会要求你 1 ：

在 Lucene 这个搜索引擎的基础上做几个示例程序。

但他不会告诉你：

公司打算选择一个开源的搜索引擎。

或者更进一步的问题是：

公司必须在使用商业产品、开源代码和自主研发一个搜索引擎之间做出选择。

再或者导致这一问题的根本原因是：

某某搜索引擎公司正在与高层探讨战略合作，而我们必须在“尝试合作”的同时，通过支持某一个开源引擎来保持战略选择上的灵活性。

如果主管所要求的“做几个示例程序”是一个项目，那么项目中的实施者又如何能看到组织在“布局”上的全像呢？这个例子的不恰当处在于：也许有人会认为“做几个示例程序”是可以放弃的棋子，而布局是那个弃无可弃的棋眼。

但除了布局者，谁又知道棋子与棋眼的区别呢？