传统的项目管治(project governance)是 指一套确保项目成功的规则和过程,传统管治方式尝试以流程形式去管理项目。但是使用到工时单,成本和日程安排等却使更重要的事情如项目利益、风险管理、持 份者参与、质素、范围、目标控制等得不到应有的注目。这样看管治这概念和敏捷开发互不相容,但是大多敏捷开发使用者认为足够的管治对敏捷项目好处多于坏 处。
Andrew Clifford 提出引入项目管治带来以下好处:
- 改善股东价值,因为资讯系统以商业资产来管理
- 改善业务和资讯科技部门关系,因为资讯基建要求能转化成可量度目标
- 改善资讯基建投资回报,因为管理层可以留意及执行新资讯基建的使用
- 减低项目失败,因为技术和规管(compliance)要求都能及早发现
- 减低符合规管和内部标准要求的成本,因为这些都在管治框架内管理
- 减低因为不同标准要求所有来长远风险和成本,因为管理层可以清析看到符合格标准的程度
- 改善资讯系统部门作为管理商务系统方面的考衡,这对于管理外包服务更为重要
Mathew D. Laudato 指出,虽然项目管治对于工程部门很难磨合,但对资讯系统预算的使用还需向公司高层负责,他同时建议敏捷开发过程应该包括项目管治,他指出:
在每一个迭代回顾的时候应花些时间以业务角度纪绿项目的进度,这报告最少要包括有什么功能已完成、完成这些功能所花的成本、这些功能的部署安排、以及现在有多少比例的需求已完成。
丰田的 Takeuchi 和 Nonaka 对项目管治有以下观点:
虽 然项目团队很独立自主,但也不是完全不受控制,管理层放下足够检查关口去避免不稳定、含糊、压力演变成混乱状态,与此同时,管理人员也要避免硬性控制窒碍 创新,重点应放在「自我控制」(self-control)、「透过同僚压力的控制」(Control through peer pressure)、「以爱来控制」(Control by love)。
根据 Ross Pettit 的观点,敏捷管治最根本是回应以下两条问题:
- 我们的投资能否得到应有回报?
- 付运的方案能否达到我们的期望?
第一个问题是关于金钱使用的效益,回答基于事实的量度去衡量未完成的范围、已完成工作、总支出以及准确的趋势。第二条问题关于这方案的完整性,如何应付不同的企业政策包括保安、架构、质素、风险等,Ross 认为良好的项目管治可使到:
减少「惊讶」、提高信任和信心、配合公司策略的执行方案,让资讯系统较少陷入本身的问题,从而更能适应业务上的转变。
有了足够理由相信项目管治的重要性以及对项目带来的好处,现在问题是在敏捷开发项目中如何最佳引入项目管治?
Ross 提出以下方法:
- 良好管治要成就敏捷,就不可以成为日常运作的负累,要做到这点,需要一些统一而不繁累的方法在组织里收集数据。
- 要考量方案有多完整,资讯系统管治必需在整个部门有著积极参与的角式,包括资讯保安、基建、架构、风险管理、业务管理、项目管理办公室等,然后不同资讯功能的部门也积极参与这过程。
- 资讯系统管治不能变成神秘独立的圈子,相反要成企业的核合部份,我们必需以各有关人事熟识的方法来沟通,更重要的是以业务的语言和业务人员沟通。
Dean Leffingwell 提出以下方法来设置轻量的管治过程,他指出,管治模型应该:
- 订定敏捷的准则来指出敏捷对公司的意义,清楚定义敏捷、单元测试、回顾、站立会议等
- 保持轻盈,不多于三至五页
- 建议但不指定
所以敏捷的管治能成为管理和资讯科技的桥樑,重点在于避免过度管制,窒碍创作力以及在敏捷开发环境下的热诚。
查看英文原文: Agile Governance: The Bridge Between Management and IT
译者附注:
管治和规管的问题是目前企业当前流行讨论的议题,资讯系统部门难免虽要配合,不过,对于硬性加入管治过程,这也是一种浪费,特别是对于还未有相关管治过程的组织。纇似的讨论也曾在风险管理、系统保安等出现,他们都指出敏捷开发所未有顾及的范围,但同样提出硬性要求,还是需要时才加入才是比较适合的做法。
评论