SAP研发管理精要(1)

记者 郑大奇  http://www.ccw.com.cn

企业管理本身流程错综复杂，用软件把这些错综复杂的关系梳理成一个智能、顺畅的“有机体”，又需要各种逻辑运算和数据处理。不仅如此，面临几十个行业各不相同的需求和成百上千个企业各具特色的企业“个性”,同时又要组织遍布于全球各地几千人的开发队伍,SAP如何驾驭管理软件开发这一浩大的工程?

1972年，德国，曼海姆的IBM公司。任职销售顾问的Hasso Plattner在等待着公司对自己建议的回复。他的建议就是开发财务软件包，用现成的软件包取代昂贵的定制应用。

当IBM公司回绝了他的建议之后，他和4名做软件工程师的同事离开了IBM，白手起家创办SAP软件公司。

而今，每天早上，世界500强中80%的公司都会进入由SAP公司提供的管理和协同商务平台，进行高效率的工作。一向好斗、性格倔强、勇于接受挑战的SAP联合主席兼首席执行官Plattner在经历了SAP的诸多风浪之后，当他看到SAP在软件市场低迷的情况下，2001年第三季度仍旧实现了赢利预期，前三个月的收入达到50亿欧元，收入增长率为23%，高兴地评论道: “虽然近来软件市场，特别是美国市场有巨大的变化，客户纷纷推迟软件的购买计划，但对于现在最有效的解决方案，企业还是愿意投资的。越来越多的企业转向SAP，因为他们相信SAP能给他们带来更高的投资回报率、更优秀的功能和便捷的集成。”

这家总部位于德国沃尔多夫市，号称“全球最大的企业管理解决方案供应商、全球第三大独立软件供应商、全球领先的协同电子商务解决方案供应商”的软件巨人目前在全球的120多个国家和地区拥有1.65多万家客户，向全球提供基于“五大支柱”战略的产品，这就是mySAP SCM（供应链管理）、mySAP PLM（产品生命周期管理）、mySAP CRM（客户关系管理）、SAP Portals 的Enterprise Portals（企业门户）和SAPMarkets 的Exchanges（交易集市）。

而你是否知道，在全球，SAP拥有员工2.5万多名，在总部，SAP的开发人员有5000多名，而SAP的开发实验室和开发中心更是遍布全球多个角落：德国慕尼黑，美国硅谷，法国，加拿大，中国，印度，澳大利亚，日本……如何调度这只由几千人组成的开发大军？如何将几千人隐于无形的智慧聚合起来打造商业智能方案，而这方案又凝聚着来自世界顶尖企业先进的管理实践和管理理念？

董美婷，目前是SAP中国公司北方区咨询顾问经理，在负责整个咨询队伍的同时，还负责协同商务解决方案中心。1997年6月加入SAP的她，有机会亲身体会了SAP研发的精髓。刚开始加入SAP的她，担任技术顾问；1998年初，SAP中国公司成立开发中心，她担任开发中心的负责人；2000年，SAP投资1000万美元，组织30多个研发人员，建立了SAP中国协同商务解决方案中心，她被任命为负责人。在此之前的9年时间里，董经历过中科院软件所和中国惠普两个单位。

董美婷以一个典型的中国开发者体验着SAP博大精深的管理软件研发过程，同时，以SAP中国公司技术总监芮祥麟为核心的研发队伍也逐渐被纳入到SAP全球研发计划中。

在咖啡厅、足球赛中工作

在SAP德国的办公室里，研发人员通常是4个人一组坐在一间20平方米左右的房间，他们使用那些租来的具备最高性能的设备，利用SAP自主开发或者第三方提供的开发管理工具，遵循着SAP研发“机器”特有的“程序”编程序、抓bug。通常，他们会在宽带上浏览公司的公共平台或者互联网，以获得某一部分现成的可复制的文档，或者在自认为合适的时间学习e-learning课程（例如语言、项目管理等）。而在公司里，咖啡厅可以供他们悠闲地坐下闲聊，SAP认为无论你聊什么，总会对工作有所帮助的，比如加深了了解和沟通。而如果你觉得工作累了，设在公司内部的健身中心、网球场都可以免费使用。每到周末大家可以开车到风光旖旎的小镇，在山顶的足球场上踢足球，附近的居民们会赶来加油、呐喊，足球赛会使很多平日里不认识或不熟悉的同事熟悉起来，他们在工作时需要协助或者讨论或者启发，这样他们会很容易地知道找谁合适。而每一个月他们都会参加一项叫做团队建设的活动，大家集体出去，或者爬山，或者滑雪，总之是大家可以一起参与而又需要相互协作和沟通的活动。SAP中国的员工每个月同样也会去参加团队建设的活动，而董美婷所带领的30多名研发员工也会在月中及时地聚在一起，讨论一个阶段以来在某些项目上的得失。

严谨的德国人对于写软件有着比打造精美工艺品更细腻的心思。有时，一个字段会讨论上两个星期。如果需要，随时会有一个非正式会议在咖啡厅开始。对于产品经理的需求，他们会逐字逐句地推敲，以确定这是否就是客户工作所需要的。

值得一提的是，每天，SAP全球的开发人员都在使用着SAP独有的开发语言ABAP——高级商业应用语言展开工作。SAP认为做管理软件并不需要追求技术的时髦，SAP看重的是: 满足需要，在功能、流程、速度、稳定性上的表现要优先于其他。基于这种语言的技术平台还可以使SAP的产品与各种系统无缝连接。

管理软件“流水线”

通常，新产品或新版本的诞生，需要走过六道“工序”，这就是产品规划阶段(Product Planning)、需求形成阶段(Specification)、设计阶段(Design)、实现阶段(Implementation)、测试阶段(Test)和技术支持阶段(Maintenance)。事实上，这六道工序并不像一般硬件产品的流水线那样，这六个阶段或者交叉，或者平行，总之构成了一个复杂的统筹项目。

由于SAP提供的各种解决方案要面对不同用户千差万别的功能需求，在项目开始之前，需要进行非常详尽的规划，以决定功能的取舍和增强，这一阶段决定着产品的发展方向，也是项目成败的关键。同时，这一工作也要求参加项目的SAP和非SAP人员进行充分的交流沟通，从而为将来的开发打下基础。特别是对于那些比较复杂、跨模块的项目，需要在模块间的功能开发和工作进度上作出统一的规划，以避免重复开发和集成问题。

通常，规划阶段的工作可以按三个步骤进行。第一步是收集和评估开发需求，为新产品或升级现有产品而从各种渠道收集用户需求和意见。如果是升级现有产品，则由开发组对开发请求进行评估，并作为新版本开发的基础；如果是新应用模块开发，则由项目的产品管理小组和开发经理对实际应用和流程进行分析，并提供粗略的开发计划，为下一步的决策做必要的准备。第二步则是开发规划的决策阶段，主要是分析整个项目的可行性，以及确定项目开发的优先级，对于比较重要的或者是策略性的项目，通常是由部门主管或执行董事参与决策。第三步，则需要制定详尽的开发计划，包括功能划分、工作分配、进度控制等。

走完规划阶段，项目组以及产品经理则开始对软件产品进行分析，确定各种用户需求的优先级，并决定哪些功能将在系统中实现，以及实现的程度和方式。这一阶段的工作需要与用户及咨询顾问进行大量的面对面交流，在得到用户需求的同时，也需要将项目的进展及时通报，以得到反馈。需求形成阶段作为开发阶段的基础，最终形成的需求文档需要从用户的角度对产品进行描述，对各种功能模块的描述要尽量明了，因为此文档也将是产品实现和测试的基础。同时，文档还要就产品可用性、运行性能等方面进行规定。

当项目组拿到了具体详尽的需求文档后，设计阶段开始启动。在设计阶段，由各功能模块的负责人组织小组成员，一起建立模型（如数据模型、功能模型、过程模型、对象模型等），创建必要的数据结构和函数，同时，对程度元素的命名原则、开发规范及模块间的接口等作出定义。由此形成的设计文档成为项目实现的基础，并且是软件维护的重要参考，所以，此文档应当尽量详细。此阶段的工作以用户需求为基础，为用户提供有效的解决方案，设计的好坏将直接影响到系统的功能和性能。

当某种功能比较复杂时，设计文档通常可以分成两类: 一类是粗略设计，参考系统中现有的过程、工具和函数库，以确定可以复用的对象，使用系统中现有的对象和技术可以提供新功能的可靠性，降低开发成本；第二类是详细设计，包括对数据字典、程序对象、用户界面、处理流程以及各个对象之间的接口定义进行详细的设计。

设计阶段之后，就进入了具体的开发阶段，即实现阶段。实现阶段是以设计文档为基础来创建数据字典和程序对象。SAP对ABAP程序开发有比较完整的指导文档，并要求开发人员按照SAP的开发规范创建用户界面。在R/3项目开发中，规范性与技术同样重要，由于一个项目通常是由很多开发人员协同完成的，程序的可读性和详细文档对于项目来讲是非常重要的。在开发的同时，文档开发人员为相应的功能模块创建在线文档、培训教材等必要的用户文档，这需要开发人员的密切协作。此阶段同时也是开发测试阶段，开发人员需要对新的模块进行测试、代码检查、可用性测试等，并进行开发人员间相互测试，以便在开发阶段保证模块的质量。

实际的测试阶段从具体的开发阶段就开始了，此谓开发测试，而正式的测试则是在质量经理（QM）主持下，由质量管理小组、产品管理小组及用户共同参与进行非常完整、细致的测试。它不只面对单一功能单元，而是根据用户需求文档、设计文档并按用户实际流程设计出测试文档，对系统的可用性、性能、用户界面、表达统一性、文档、翻译等进行全面测试。

同时开发人员需要密切配合，及时修改发现的错误。测试阶段的工作是软件提供给用户前的最后一道工序，它直接关系到软件的质量。所以，此工作需要非常周密的安排，就这个意义而言，QM也担负着保证软件质量的责任。

SAP的技术支持分成三级: 当地支持（Local Support）、地区支持（Regional Support）和开发支持（Development Support）。当用户遇到的问题无法由前两级完成时，这个问题就会送达开发人员，由开发人员确认错误来源，并提供正确的响应。这一过程可以包括在用户系统中修改程序、文档，如果问题所涉及的功能比较广泛，SAP内部相关的开发人员会协同工作，共同解决问题。随后的分析会对问题或需求有更加深层的总结，一旦需要，新的需求会被包括在新版本的开发中。SAP还会提供Hot Packages和Hot News，以帮助用户及时处理系统中的错误。

管理Bug的“程序”

在董美婷看来，Bug产生的来源可以分为流程错误和程序错误。

流程错误是非常致命的，它会导致系统无法实现用户的需求，它通常发生于项目规划和设计阶段。对于这方面的错误，SAP有相应的机制加以控制。在用户需求分析过程中，产品管理小组与用户之间进行协同工作，同时经验丰富的项目经理和开发经理也会参与，最后形成的用户需求和项目规划文档还要由专门的小组进行周密的分析和检查。尤其是在模块设计阶段，这种检查更加严格，通常这一阶段的检查是由资深专家组成的小组来完成的，其成员会有来自于其他项目的，从而保证了系统设计的质量。

程序错误是在所难免的，SAP除了利用测试阶段的工作来减少Bug的同时，还用以下手段在开发阶段尽可能地避免Bug: ①自我测试，要求开发人员在完成自已负责的模块后，马上进行测试，消除模块内部的错误；②相互测试，要求开发人员之间测试对方的模块，由于不同开发人员的思维、开发方式的不同，对方会很容易找到一些自已很难发现的问题；③代码检查，通常是由资深开发人员及开发经理来进行，从模块功能、性能、可用性、编码规范、模块集成性等角度进行全面检查。这一工作会在系统实现的各个阶段定期进行。SAP还提供了如CATT等辅助测试工具。

对于系统的后期维护阶段，SAP也有对Bug的完整的管理流程。这可以以开发支持为例来说明。例如，当用户系统发现Bug时，如果当地支持和地区支持都无法处理时，此维护请求会被提交相关负责的开发人员。开发人员负责尽快修改用户系统中的Bug，或为用户提出修改建议和解决方案，同时，也需要在更正（Correction）系统中进行修改，以便以补丁（Patch）的方式提供给所有用户。但对Correction系统中的修改有非常严格的管理，并需要一定的步骤：①与开发经理讨论并征得许可; ②在OSS系统中创建修改申请，并对Bug所在版本、症状、解决方案作出详细的描述和解释，作为用户/顾问将来处理此Bug的参照；③开发人员在Correction系统中修改程序，消除Bug，同时要求进行仔细的测试；④开发人员将修改请求转给另外的开发人员，通常是开发经理或资深的开发人员，由其来进行更严格的测试，此次测试不但要测试Bug是否真正解决，还要确认对程序的修改是否影响了其他程序或模块，以避免带来新的问题。

这些修改会定期以Hot Package和Hot News的方式提供给用户，用以修改用户系统中的Bugs，但由于R/3各模块之间的相关性/依赖性很强，Patch的发布需要各模块特别是应用模块与Basis模块之间的协调和同步。

推荐到鲜果：