系统工程团队的建设

在项目的层面上，建立一个系统工程团队，对于有效实施需求管理与需求开始，是非常有帮助的。CMMI 在需求管理与需求开发的领域里，没有明确要求建立系统工程团队。这不代表CMMI不重视系统工程。因为CMMI第一个过程域就是需求管理，真正反映CMMI对需求的重视。只是CMMI只重视“做什么”，而不是“怎样做”，才没有好像规定EPG一样规定建立系统工程团队。EPG是过程管理领域，任务上与项目非常不同，一定需要一个不同的团队。需求的工作是项目的一部分，规模不大的项目，可能只有一个全职或是兼职的系统工程师，也不一定需要有一个系统工程团队。但是这个系统工程能力是必须的。如果踏实地实施需求管理与需求开发，很快项目就可以体会到系统工程的必要性。在一个典型的研发团队，大概5-8个成员之间，就需要有一个系统工程师。

系统工程的概念与历程

系统工程，在项目里面，就是处理有关最终产品的整体议素的人员。最明显的就包括需求与系统设计。其实在项目更高的层次，比如在产品部，也需要有人制定产品的概念。这一般都与市场与客户的要求有很大的关系。这一个层次的需求开发人员，很多企业都称为市场或是产品的“分析员”。他们的职责大概就是定义产品的概念。这就是“市场需求”，或是“客户需求”。有些组织，市场需求可能也是项目的一部分。一般来说，在市场需求（产品概念）之后是有一个质量与决策的关卡的，就是企业需要决定是否开发这么一个产品。所以通常的做法，都是产品部与研发部是两个不同的项目。这里谈的“系统工程”，是指研发项目里的系统工程。

当我还在一线工作的时候，在项目的层面，对于“系统工程”这个概念，企业已经明白系统工程程的重要性。大学也有比较专门的学科培养系统工程人员。这些人员毕业之后，就充当了各个层面的系统工作，其中也有项目里的系统工作。这就有一个持续多年的争议。当时的学术界的主流，还是认为系统设计是系统工程的组成部分，应该由系统工程人员充当。这些人员对开发需求是没有问题的，但是系统设计就很有困难。

在系统工程不很普遍的时候，系统设计就由比较有经验的开发人员负责的。事实证明，系统设计需要开发经验，因为他需要连接市场需求与实现这个需求的开发工作。这些有经验的开发人员，就自视为“架构师”。其实这个岗位，在我的工作经验中，是没有在企业中明确的。但很多开发人员都会说自己是“架构师”。很多时候，在一些公开的研讨会里，我就会遇到很多很多人自我介绍为“架构师”。我就会问他们，“好的架构具备哪些特征？”他们大部分都回答不出来。可见要做好架构设计，也需要一定的系统概念。

到了从大学毕业的系统工程人员出现在项目的时候，这个问题就变得很有争议性，到底开发人员负责架构设计呢，还是系统工程师？实际上，架构设计还是以有经验的开发人员负责为主。可是结构设计要做的好，真的需要有系统概念，也需要有开发经验（注意：这是“怎样做”的问题）。学术界的观点与培养系统工程人员的努力没有错。这是如此培养出来的系统人员，需要`企业提供积累经验的机会。这才能成就称职的系统工程人员。

其实在这个争议之中，我希望大家看到两个议素：系统观念之中的“做什么”与“怎样做”的分工。学术界考虑的，是系统观念，是理论上的问题，所以主张系统工程师负责架构设计。但是架构设计与“怎样做”比较接近，与制定需求的“做什么”的思维有比较大的冲突。这是一个现实的问题。实施起来，实际问题当然比理论更重要。

以下就对比一下这两个议素：1，什么是“系统工程”与 2，“做什么（系统工程）”与“怎样做（开发）”的分工。

系统工程的本质

到底系统工程是什么？我的经历，在项目的层次，由于架构设计由有经验的开发人员负责，系统工程师的工作就是需求开发、编写需求。这比理论上的系统工程范围小了一点。“系统”这个概念，就是全部的，整体的意思。CMMI 里提到的系统概念包括：干系人、限制、依赖、集成、接口、等等。也提到目标驱动。其他的有对客户、用户的了解，明白产品的使用、生产、销售、等等。其实是比较广泛的。从这里也可以看到，系统概念对制定能让客户满意的产品是很重要的。

首先，系统观念，就是考虑整体。如果我们了解项目管理的话，就会知道项目需要考虑项目的限制与依赖。这些听起来好像与项目无关的事情，其实可能对完成项目、满足项目目标有很大的影响。这些考虑到表面无关，其实有关键影响的因素，就是系统观念的一部分。其中影响很大的，就是干系人这个概念。

从项目级的系统工程来看，工作上的干系人就有客户、用户、开发人员。在考虑得远一点，还可以考虑生产人员，市场人员，维护工程人员等等。对这些人的了解越深，越能合理地平衡各个方面的要求。当然，最容易感觉到的，影响也是最直接的，就是客户与用户。

系统工程人员需要了解客户与用户。客户是出资购买产品的人，目标肯定是要满足他的业务。了解他的业务，就变得非常重要。经常有人就问，我们连自己公司的业务也不一定了解，怎样可以了解人家的业务。这个问题的来源，在于我们的管理是任务驱动的，只要员工服从，不鼓励员工发展自己的思维。在国家已经认识到“创新”的重要性的时候，我希望我们的领导能多鼓励员工的创意。这就需要多信任员工，提供更大的权限、容许某些错误（这就要优化我们的以绩效为主的考核体系了），才能培养这类的创新型的员工。

要了解客户的全部业务是不需要的，也不一定可能。但是我们需要了解到可以解答清楚“为什么客户愿意购买这个产品”的程度。你要知道这个产品如何帮助客户提升他的利润。所以需要知道客户业务的性质，他的卖点在那里？他的利润哪里来的？等等这些问题。至于用户，就需要知道他们的职责是什么？他们的操作程序如何？这个产品怎样才可以对他们提供最大的帮助？

要解答这些问题，一种能够“异地而处”的思维能力是很必要的。善于系统观点的人，就可以看到整体的利益，自己团队的利益，甚至其他团队的利益。有这种态度与能力的人，应该都是组织的“资产”，都可以为组织提供更大的价值。但是在现在的考核体系之中，是不鼓励这类态度与技能的。我们是否可以想象一下，一位卓越的系统人员，面对自己绩效与组织整体绩效之间，能选择组织整体绩效的，是否对组织贡献更大？所以这样的员工才是高素质的员工。这个为他人、为整体着想也是系统思维的一部分，是系统工程必备的素质，是发展需求开发的技术、技能的基础。

在这里我希望最强调一下，素质是技能的基础，就好像需求管理，是提升需求开发技能的基础同一个道理。如果大家参考过《专业态度、行为、与道德》，可能还可以记得“尊重他人，是个人修养的基础”这个说法。也知道“专业态度是行业可持续发展的基础”。这就是为什么：《智慧永遠填補不了道德的空白》。希望能与各位同志共勉。

系统工程与开发的分工

从上面的讨论，大家可能已经看到系统工程里的需求工作，与实现需求的开发工作其实是两个不同的技术领域。在规模比较小，或是规范水平不足的组织，由于开发的整个过程，一般都是由同一个人担任，同一个人分担了需求开发、方案设计、与实施、甚至测试等方面。对于这样的安排，已经习以为常，不一定感觉到系统工程与开发的分别。

实际上，在开发的过程中，“做什么？”与“怎样做？”是两个非常不一样的技能领域，但是我们还不一定知道他们的分别是多么重要。我在成长的过程中，也是从不能分辨这两个不同概念开始的。我们往往用一些实现的方法，来描述与表达我们需要的东西。比如，我们会要求：“给我做一个木的小平台，上面有一个弹簧，弹簧下面可以放一些老鼠爱吃的食物。如果把弹簧扳起来，老鼠来的时候可以弹下来夹住老鼠的工具”。这是一个特殊设计的老鼠夹，包含了“怎样做”的信息。我们也可以说：“给我做一个能夹住或是捕抓住老鼠的工具”。这是一个“做什么”的要求。这样的要求，可以让设计人员找到更合理，更适合的实现方案。

“做什么”是系统工程的需求语言。“怎样做”是开发人员的设计语言。

这两种思维模式非常不一样。但是在简单的产品上是分别不大的，在复杂的产品就有很大的不同了。比如：CMMI 要求产品需要备选方案。因为产品复杂，希望设计充分平衡各种需求，是最适合的设计。如果我们不会用需求语言，只会用设计、实施的语言，能根本不能考虑备选方案。

这样把“定义产品”的需求开发工作，与“实现需求”的开发工作分开，是软件研发走上规范轨道的一个象征。我自己也经过一段时间刻意地锻炼才能有效地把这两种思维分开。有了这个分工，很多需求管理的概念才能顺理成章地高效实施。如果还是同一个人做需求与开发，不要说需求的质量不一定好，实现需求的开发工作也将会很不规范。这样就不一定能树立规范的、按需求开发的文化。

就是因为设计与实施在技术上比较接近，但需求开发就很不同。需求开发的技能，与开发的技能有很大的分别。建立系统工程师团队，把需求开发分开，可以把研发复杂、高端产品的水平提高，效果将会很大、很明显的。

系统工程的活动与技能要求

因为在项目层面的系统工程师主要是负责需求开发的工作，所需的技能，主要就是需求抽取、分析、分配，并把结果描述清楚，有利实现满足客户的产品。按CMMI 的思路，系统工程师需要：

分辨三种需求：客户（市场）、产品、产品部件需求，并能恰当应用它们

产品内、外、各种接口的定义、描述、与管理

首先，系统工程人员就需要能分辨这三种需求。一般来说，项目的系统工程主要是从市场需求转变成产品需求与产品部件需求。市场需求是产品部人员制定的，代表企业的市场方向与策略。但是项目接受市场需求之后，必须能明白其中的内容。所以项目的系统工程师也需要对市场、客户有一定的认识。

在这里提一下“接口”的重要性。管理好接口，是模块化开发的必备条件。接口的管理，包括定义合理、明确，并且任何部件的实现，都必须符合接口的定义。合理的接口，一定要考虑“必须”与“灵活”。接口管理，也能提高研发效率，因为大部分的问题，都变成是部件内部的问题，容易受控。这一点很重要。

项目系统工程师的工作主要是定义产品的功能、性能、操作模式、生产与维护等方面的详细需求。产品需要满足用户的需要，所以产品需求的主要干系人就是用户。然后就是产品在整个生命周期中的成本、效率、与价值的考虑，我们希望产品需求能让开发与生产人员容易明白，不会在开发与生产过程中造成混乱。就是开发、生产、维护等方面的人员也都是干系人。这些干系人其实就是产品需求的用户。质量就是让“客户”满意。从这一个角度看，系统工程师需要了解产品用户与下游活动的需要，并且能让他们满意。

了解“客户”，就是对他们的职责、操作、语言的了解。我年青的时候，接受过很多抽取需求的训练。基本上都是一些让我不要遗落任何角度的系统性思路。我觉得大部分这些方法都没有大用。最实在的，还是以目标驱动的工作模式中磨炼出来的经验。在进行上面的工作时，必会遇到与需求相关的、各种各样的议素、思考角度、方法、工具等。明确满足客户这个目标，识别好客户，面对这些问题，并解决他们。这样，需求开发的技能就能不断提高。

抽取需要之后，就是需求分析。需求分析，就是平衡个方面需求的重要性，以达到它们之间的平衡与一致，并确保需求是全面的与完整的。这些完整的需求，还需要从产品的角度组织起来，以功能与使用的方式进行描述（还记得CMMI 的需求开发么？）。最后就是把需求分配到产品的部件里。从开始到这个阶段的工作，项目的系统工程师都是主导。越靠近产品的方案，如架构、部件的部分，与开发人员的协调、讨论就越频繁。需求的工作，到最后的分配，就是以项目经理为主导，系统工程师与开发人员一起把需求分配到不同的版本。之后就是需求实现的监控。系统工程师负责从技术上监控需求实现的正确性。

总结上面的内容，系统工程的技能要求包括：

系统性思考

能分别做什么，与怎样做

具备异地思维

能抽取各个产品干系人的需求

了解客户的业务、用户的操作、语言

分析需求，定义能满足客户的产品的功能、性能与使用

我鼓励系统工程人员学习以下的方法与工具，我觉得他们对我的帮助很大：

结构性分析

面向对象分析

用例分析

质量屋

本文不能详细介绍这些工具。简单来说，一个好的需求分析方法与工具，都可以在产品需求到部件需求的整个分析过程使用同一套表达模式，让系统工程师与开发人员的沟通变的顺理成章。这方面我认为面向对象分析做的比较好。在面向对象的方法，能把结构性分析很多、很复杂的步骤，简化成很直观、很简单的步骤。而且很好地用同一套表达模式贯连产品需求与部件需求。其实面向对象分析可以全面替代结构性分析。

用例分析对操作方面的问题很有用。但是对于早期一点的需求分析就不很理想。

质量屋是一个非常好的需求分析工具。它可以帮助抽取比较深入的客户与产品需求。这是其他工具不能做到的。但是它不能很好地支持下游的需求分配到部件需求的活动。

这些工具都很有用，不过最重要的，还是系统工程人员从工作之中认识到需要这些工具的情况，才能真正了解这些工具的作用、好处与价值。

建立系统工程团队的步骤

如果重视需求，要把需求的工作做好，就需要建立系统工程团队。很多组织的系统工程基础都不理想。当前没有系统工程师不是一个不开始组建系统工程体系的理由。要建立系统工程团队，大家最容易想到的，就是找几位甚至一位系统工程师，轰轰烈烈地直接成立一个正式的系统工程小组，开始接受一些培训，承担一些需求的工作。其实这种“立竿见影”的方法，效果往往不好。原因在于文化。文化不是一下子就可以转变的。在文化没有转变、系统工程水平没有上去之前，是很难有绩效的。我反而鼓励从缺乏需求文化的现况，“过渡”到比较规范的、能够有效发挥作用的系统工程团队的情况。

“过渡”是一个比较漫长的过程。我们可以从识别有系统潜能的员工开始，尽可能不给现有的操作做成过多的干扰，必须得到领导的认可与支持，慢慢地培养几位系统工程人员。哪怕就是一位，也算是一个开始与进步。

第一步就是非正式地识别对系统工程有兴趣的员工。基本上是想办法得到员工对自己在以下问题的评价：

对现在的开发工作的满意程度

对一般开发工作本身的意愿

对系统工程与需求开发的理解程度

希望从事系统工程的意愿

思考产品应用方面的兴趣

等等。这个可以用问卷方法。更好的，需要用一些实际的观察与员工日常工作上表达的兴趣。最好的人选，是那些对系统性议素的兴趣明显高于开发性议素的人员。

向这些对系统工程有兴趣的员工，开始提供一些系统工程方面的培训，多和他们交流系统方面的议题。向他们不经意地透露用户与产品的使用价值的重要性，并观察他们在工作上的反应。这样就可以判断他们是否有这方面的倾向与潜能。

基本上，系统工程师慢慢地从开发任务过渡到产品定义任务。但是需要鼓励关注产品的应用，能够了解客户与用户，并且能够分别 “做什么” 与 “怎样做” 这两种语言。

在项目里，系统工程师与其他人员的比例，包括开发与测试，大概是1比5到1比10。这要看测试人员的多少。在从没有分工到有专职的系统工程师的过度，可以从一个项目开始，把需求任务慢慢往心目中的未来系统工程师身上集中，向他提供支持，鼓励项目重视与尊重定义的需求，并在组织里积累经验，让需求文化慢慢建立起来。最后慢慢扩展到所有项目，都由专职系统工程师负责需求的工作。这个分工，将会让需求更能满足客户、用户，实现需求的质量与效率都会有所提升。

结语

系统工程要解决的问题，就是更有针对性、更能满足客户与用户的产品。这种产品才能有竞争力，让企业成功。这就是系统工程的意义。要把系统工程做好，就需要关注用户，并且要把产品的定义与实现分开，让两个领域都能提升各自的技能，开发出高质量、具备高度竞争力、让客户满意、让企业成功的产品。

建立项目的系统工程团队，是这个努力的关键一环。