Question

工程做不做得了，是不是技术问题？

这是一个关键的设问，涉及很多方面。例如其一，工程在时间与空间上可能达到的规模，是否可以通过组织团队或项目来满足；其二，工程中可能出现的问题，是否可以在技术上解决；其三，工程所需要的资源，是否可以持续供给。第一个问题，是工程在系统架构领域中的技术问题；第二个问题，是工程在产品/业务领域的技术问题；第三个问题，则是工程背景下的商业环境问题。

工程自身的技术问题，是类似于“过程、方法、工具”这样的、传统而学术的工程视角下的问题，是把工程作为技术并对其中所涉及的干系者（人和物）的统一管理。但是这种管理又具体与上述三个方面（架构、技术、环境）的问题无关。例如，我们在工程中所讨论的过程是以瀑布模型（分析－设计－开发－测试等环节）为基础的，它根本上与“怎样一个具体的架构、技术与环境”无关。这也是《人月神话》一书中“银弹”的核心，即我们是否可以找到一个与具体情况无关的工程方法。

这在根本上，就是“唯技术论”的思维。而一个具体工程下所需的管理与组织，却并不能基于“技术思维”而得到。正如我一再强调的：

真正的管理者，是不会看“管理的技术书”的。

管理的总的决窍，在于一以贯之。无论是什么，吐啊吐啊就习惯了。 3 就如一个著名的组织行为观点所说：改变不了思想，就先改变行为；行为改变了，慢慢地思想也就改变了。对于大公司的体制来说，往往需要“我们”是被改变的那批人，并且往往是“先从行为改起”。在本质上，这是形成企业发展的一种势态，当大家的行为模式、方法、习惯以及思想趋同时，要做的事情便可以顺势而为了。

真正的组织管理者，既在寻求组织的不变性，又在这种不变性中看到变化的机会。组织中的大多数人只是被左右挪动的一枚职务角色，甚至像刺秦的力士一样连名字都不为组织所知。正因为如此，探索并形成有利于“工程实务”的组织结点，是大多数公司在“软件研发管理”上的痛中之痛。

在这样“探索并形成的某一个组织结点”下的一个工程（或项目），便是我所谓的“具体工程” 4 。这个工程具体而微：有人、有事、有目标，也有可资借鉴的过程、方法与工具。这个工程借鉴但并不照搬任何一个既已存在的模型或过程方法论。这个工程的首要任务是完成具体的“某件事情”，这既包括让大家清楚地认识到这个事情的目标（可能表达为产品或产品线上的阶段等）、收益以及风险，也包括构建让所有成员都能有效投入的职业氛围。不过，它并不为“明天公司是否以此为范本”而负责。

那是别人要的，不是你要的。

1. 引自《程序员修炼之道——从小工到专家（评注版）》，第 7 章。 ↩
2. 引自《羊城晚报》（2011.07.28）的文章，《日本孩子长大后最想做什么》，作者唐辛子。 ↩
3. 这既是温水青蛙式的风险，却又是组织行为的精义。 ↩
4. 我们此前的许多讨论并不适用于“开源工程”，但这句话是绝对的例外。具体工程是一种从对“工程的结构元素”的认识出发，试图在特定背景下形成适宜的工程方法的思维方式，本书的讨论可作为这一思维的一个示例。 ↩