系统工程团队的建设

2018-05-18votextech125

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

  系统工程的概念与历程

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

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

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

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

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

  以下就对比一下这两个议素:1,什么是“系统工程”与 2,“做什么(系统工程)”与“怎样做(开发)”的分工。

  系统工程的本质

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

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

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

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

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

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

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

  系统工程与开发的分工

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

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

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

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

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

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

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

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

  分辨三种需求:客户(市场)、产品、产品部件需求,并能恰当应用它们

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

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

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

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

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

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

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

  系统性思考

  能分别做什么,与怎样做

  具备异地思维

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

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

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

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

  结构性分析

  面向对象分析

  用例分析

  质量屋

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

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

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

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

  建立系统工程团队的步骤

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

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

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

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

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

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

  希望从事系统工程的意愿

  思考产品应用方面的兴趣

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

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

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

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

  结语

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

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


给我们留言

看不清?点击更换验证码

联系我们

+86-13961165615

27654982

:27654982@QQ.com

:9:30-22:30

QR code