Question

无论敏捷工程还是传统工程，都是无法为你正在做的这件事提供直接答案的。

这件事得自己努力。

一个具体化的工程涉及三个方面的问题：人与团队，产品与用户，项目与方向。如果这些东西要被“系统化地”组织在一起，必然是需要将它视为“一件事”的，这也是它被“立项”的目的。如果这一前提不存在，则产品只是用户调研、产品设计或产品线上的一个规划，而团队则可以简单地视作“一群人”。只有要做一件事，这三个方面的东西才发生了关系，也才交织在一起成了“问题”。

要开始做“这件事”，会有不少的前提条件。例如，作为一个项目经理，你或许要求“先做三个月技术培训，再开始开发”。但事实上这些都算不上“前提”，因为你显然也可以不这么做就匆匆上马——只要你有机会在团队行进中调整大家的步伐。唯一能作为“开始这件事”的充要条件的，事实上只有一个决策性的判断：我们是否需要用工程化的方法来实现一个产品目标。这里涉及下面三点细节。

1. 是软件产品吗 ？如果这不是一个需要“软件生产”的产品，则它可能不需要“软件开发”这一过程，固而也就不需要我们的软件工程。例如，市场部门需要了解客户反馈，那么它既可以实现为一个在线聊天的客服机器人，也可以实现为包含大量职员的客服部门。而后者显然是不需要“软件生产”的。
2. 需要开发吗 ？即使是一个软件产品，获得它的方法也可能不是“软件开发方法”。例如，上述的“在线聊天客服机器人”，如果我们将它作为一个产品外包，那么“外包”这件事对于我们来说就是一个供需管理，而不是“工程化”的软件开发活动。
3. 需要工程化方法吗 ？一个研发性软件产品的开发过程，可能不是“工程化”的。例如，我们真的要在公司内立项来做上面这个产品，但我们只分配了一个开发人员或一个临时小组，产出的产品也不用于市场销售，对时间的控制也可以放得很宽轻，而且最为重要的事情是，假定这个项目是基于技术研究的，因而当它失败了也不会有什么负担，那么我们便不需要考虑“是不是需要一个工程化的软件开发方法”。

当决策判断发生了，当“应作为一个工程化的软件产品来予以立项”成为事实的时候 4 ，产品、团队与项目三者就必须立即成为“具有相同目标”的一个合作群体。这个相同目标，就是“做一件事”；这个相同目标中的道德原则也只有一个，就是“做完”。

我知道有一个项目，一个做了整整五年的项目。在项目坚持了这么久之后，是什么在支持着这个团队还保持着追求成功的激情？就这个问题，一个普通成员的回答典型、普遍而又发人深省：

“在我们的头脑里，完成一个项目是最最重要的事情。”一位成员说：“即使我们不喜欢这里，我们也不会让项目流产，我们宁愿先完成项目，然后在第二天辞职。”

这个团队就是 Windows NT 4.0 的开发团队。在读《观止——微软创建 NT 和未来的夺命狂奔》这本书的过程中，这名普通的甚至没有在这本书中留下名字的成员，说出了让我如此印象深刻的话。这样的普通成员，正是这个团队整体的职业精神的缩影。

回顾这本《观止——微软创建 NT 和未来的夺命狂奔》，我们是无法孤立地站到团队、项目与产品三个视角之任一来思考的。从根本上，具体工程最重要的话题就是这三个视角必须是统一的、系统的以及面向具体的“一件事”的。

1. 英文片名Demolition Man，马考•布莱姆比拉导演，西尔维斯特•史泰龙主演，1993 年上映。 ↩
2. 事实上，还会讨论到“目标”问题。但在传统工程中的“工程目标”并不是确指，而是使用“需求”来指代的一系列技术方法。传统工程基于“需求”而非基于“具体目标”，并且——与此相关的——它与架构的“面向问题”也是互相背离的。因此传统工程中的工程师视角下的思考，对“架构师”这一角色在团队中的融入帮助并不大。 ↩
3. 早些时候的《软件工程》教材是不讲团队、管理等内容的，但后来它们都逐渐地加入了相应内容。但老实说，这些书——例如《软件工程——实践者的研究方法》与《软件工程（Ian Sommerville 著）》等——中有关于人的讨论都是隔靴搔痒、无济于事的。这些经典的、学术化的工程方法仍是以自己为中心的，它们试图把管理学、组织学或社会学“拿来一用”，其思想离“看到一个项目自身的系统性”还相当之远。 ↩
4. 事实上三种情况的反例都是可以“立项”的，譬如组织建设或人力规划的项目，企业资产购置与管理的项目，实验性项目。它们作为项目是满足“时间、质量与成本”这样的项目要素的设定的，但却都不是工程化的。 ↩