ABAP开发的项目管理问题

在项目中一年多了，昨天讨论到管理的问题，引发了一些思考，贴出来和大家讨论，请大家批判，手下无需留情
不知道怎么贴图，有个图片，原文： http://blog.imalex.net/2007/10/2 ... project-management/

ABAP开发是基于SAP R/3系统的二次开发，ABAP开发项目是整个SAP ERP系统实施项目中的一部分，项目的输入是来自实施顾问团队的“开发需求”，输出是R/3系统中的程序。

ABAP开发与以产品为核心的开发有很大的不同，开发一个产品通常是软件产品的构思着提出创意、想法，不断的改善设计，形成一个比较完善的产品形象，功能明确、结构清晰。大多数情况下能按照软件工程的一般过程，即需求分析、设计、开发、测试等过程进行。通常是从底层到表层构建一个完整的、独立的软件产品。

ABAP的开发需求是业务顾问团队提出的，业务顾问团队则是分析用户的需要，将其转化为有效的用户需求，提交给开发团队。ABAP开发的性质是二次开发，即在SAP R/3系统之上构建应用，对系统标准功能不能满足的地方进行补充，主要包括离散的各个模块、跨模块报表，标准程序逻辑的增强，基础数据补充维护，SAP标准功能之外的功能性扩充。而这些开发，是离散的，而且是不断提出的，由于通常客户驱动开发进度，且项目进展很大程度上受客户主管意愿之约，因此开发流程控制、过程控制、质量控制往往无法顺利开展。另一个问题就是项目团队往往由多方面组成，且进入项目的时间并不固定，难以达成默契。

虽然我现在只经历过一个ABAP开发项目，但我想ABAP开发项目的混乱，在国内应该是大同小异，控制的好的当然会有，但应该不多，我这个项目的实施方也不是小公司，因此推断整个行业状况大致如此了。

仅从我个人的一点体会提出ABAP开发项目管理的一些原则：

1 开发团队的输入严格界定，即开发需求需经过严格的审批和控制，仅由1人作为沟通点，这个人不是负责需求细节的沟通或开发，而是要控制需求的质量。

2 质量，必须有量化、硬性的指标规定，不能主观判断，因为个人的能力是有限的，不论从工作量还是从知识的了解深度都是有限的，那么量化的指标应当包括：必须填写的项次是否填写准确，需求提出的流程是否符合规范，程序功能是否描述清晰（需细化，如目的、运行方式、用户偏好等），有了量化的指标，才能硬性的执行。

3 责任，需求的提出者、文档的撰写者、程序的开发者、测试者要落实的人，并且在某一时期内负全部责任，负责不表示一定要受到惩罚，但若没有规矩，怎成方圆?

4 约定，无论是业务顾问团队还是开发团队，都应当遵守一定的约定，如：某一字段名称、文本描述，程序命名规范等，约定不可能在项目开始的阶段就制定出来，一定是逐渐出现，但是，一旦出现，就应形成约定，且应严格遵守。

5 审核，各个过程都应当有人负责审核，审核的依据应是量化、硬性的标准，靠个人的判断等于没有审核，原因就在于个人的压力、视野、能力都可能导致判断失真。

6 文档，一份文档在不同的人手中出现多个副本，多个版本，就等于失去了存在的必要，不知道哪个是最新的版本也就失去了参考的价值。因此文档必须管理妥当，尽最大努力避免一份文档出现多个副本。

7 开发与支持，相信绝大多数人都没有意识到ABAP开发和ABAP支持的区别，举一个简单的例子：业务顾问认为一个报表的数据有问题，跟另外一张报表数据对不上，于是业务顾问发送邮件给一个开发人员，希望他能帮忙看看这是怎么回事，那么这名开发人员要做的事情是查看报表、程序逻辑，分析运行结果、差异，答复顾问，这是一个支持过程，而非开发过程；而当业务顾问提出一个报表开发的需求，开发人员需要创建程序，这才是开发过程。当ABAP开发与支持混在一起的时候，两者的效率和质量都大大降低了，遗憾的是，我们的项目中没有区分这两项工作，因此应当明确定义团队成员的职责（可以轮换），而不应该工作内容混杂。

8 管理工具，我认为不使用工具与使用工具之间的差距，直接反映在成本上应在30%以上，因此花费一个项目的开发经费20%以下是完全值得的，而且越早越好。例如我们的开发团队：每年的成本在50万左右，我认为投入10万元购买开发工具用于提高效率是很合适的，况且开发工具的购买往往第二年以后费用会低不少的。开发工具可以帮我们解决很多很多的问题，最主要的是实现信息管理及检索，减少沟通成本以及沟通不畅造成的损失。

9 项目经理，项目经理的职责是通览全局，把握大方向，控制流程，调度开发资源，降低风险。项目经理不应当参与到开发的细节中，不应当亲自跟踪每一个细节（重要的除外，工作狂、精力超级旺盛的除外），他的重点应当在于及早发现导致风险的因素，提出解决方案。遗憾的是，我们的项目中也没有这个角色。

10 例会、个人日报/周报，例行制度可以提高开发人员的纪律性。

最后，也是最重要的，就是 执行。不论什么管理原则、实施方法，如果制定，就一定要执行，否则不仅这一条成为一纸空文，还会成为害群之马，不能执行的规定，相互之间助长气焰、滋生病态的开发过程，最终导致的是人人疲惫不堪，开发漏洞百出。因此，一条原则的坚持执行，远比面面俱到的理想过程要有价值。


原文地址：http://www.itpub.net/thread-878127-1-1.html