引言
在IT和Banking市场里面，有很多Change Manager、Release Manager的职位，亦有很多Change and Release Manger。骤眼一看，Change和Release很相似，但其实是完全不同的范畴。这回会先将讨论Release Management的流程，亦会讨论项目管理三大Readiness(Business Readiness, Product Readiness及Operation Readiness) 的特色和分别。
什么是Release Management?
一个软件由完成到发布，会经历大量的调试和准备(如下图)。当中包括Request for Changes and New Features、Release Planning and Design、Software Build、Review、Testing、Deployment、Support、Issue Reporting and Collection。不同项目管理的构架(framework)可能对Release步骤的定义会有所不同。
但简单来说，Release Management的目的，都是确保三方面准备好。包括Business Readiness (i.e. Project Scope/ Timeline那些定义清晰)、Product Readiness (i.e.产品都开发好和测试完) 和 Operation Readiness (i.e.公司本身对产品有支援)。
1. Project Readiness (a.k.a. Business Readiness) — 项目的准备程度
现代软件开发过程极度分散，例如一个新加坡的手机APP，很可能是由印度开发、香港管理、中国做测试、新加坡(localmarket)做市场规划，还有英国/欧洲做UXUI Design (User Experience User Interface Design)。
在一个全球协作的环境下作开发，虽然更能利用各地的优势(例如印度大量的IT专才、香港项目管理经验)，但亦令发布管理的复杂程度大大提升。基于地域、时差、语言、文化(这亦很重要的)的差异，很容易造成沟通不足，各个持份者不太知道项目的进度和需求，从而导致结果期望落差(i.e.你制造出来的东西不是我想要的)，影响软件发布的进程。而且全球协作的开发亦有可能拖慢软件发布进度，例如英国设计人员下午修改了一小部份Homepage的设计，要等到明早上午才能通知印度开发人员开发，并在中国工作时间内进行测试。如果开发出来的结果不符合预期或设计师想多作一些修订，这将要多几天的沟通时间，才能完成。亦有部份时间，设计师、开发人员在改善产品时，可能不清楚部份功能是否符合当地法律要求(e.g.产品能否显示"全城最便宜"的字眼、数据处理能否跨境进行)，亦需要花时间和当地法规部门作沟通。
而这些项目管理的樽颈，并不一定在全球协作的环境才会发生。如果部门与部门之间距离很远(e.g.不同楼层、不同大厦)、涉及第三方的供应商，亦会造成沟通、项目需求管理不清的问题。
总括来说，大型项目管理有三大问题:
• 持份者工作进程缺乏透明度(Lack of visibility)
• 管理和法规 (Governance and regulation), i.e. 项目能否通过所有规定?
• 需求管理 (Requirement management), i.e. 结果是不是顾客想要的
因此，在发布管理(release management)的过程中，如何管理时间(timeline)、沟通(communication)、品质(Quality)和需求(requirement)将成为关键。在软件发布时必须确保整个Release 步骤定义清晰，当中包括:
• Scope of change and Priority of change
• Plan and activity schedule
• Release Team composition and roles
• Training, logistics, and communication requirement identified
• Strategy for release
2. Product Readiness — 产品的准备程度
在三个准备程度(Readiness) 中，Product Readiness是最容易理解的。简单来说，就是在软件发布前，产品要准备好。
但在现代软件开发的框架下，企业并不一定等待整个产品完成后才发布。只要产品有一定程度功能准备好，就会先发布这个功能。而这个做法正正是行业之间经常说的 MVP (minimum viable product) approach. 举个例子，例如银行A想发布手机银行APP，当中包括转帐、投资、信用卡不同的功能。银行A可以先完成转帐功能(MVP 1)，将其发布。之后再开发投资(MVP 2) 和信用卡(MVP 3) 功能，再将现有手机银行APP 升级。这样的做法可以更快令用家接触到新的产品，亦能帮助企业测试市场反应，令开发出来的产品更符合市场需要。
而发布的功能，除了要经历不同的性能测试(e.g. Unit Testing, Integration Testing, System Testing, Penetration test, Accessibility Test, etc.)，通常也会做最少两个UAT(i.e. Alpha Test, Beta Test) 才会变成 Release Candidate 发布。
而每个UAT 都会收集到大量的Feedback (如下图的Feedback Loop)，项目小组(Project Working Group) 会研究每一个Feedback，再将其定义为Feedback (用家的意见)和Defects (软件缺陷)。如果是用家的意见(Feedback)，项目小组会将其纪录(Backlog)，并会在软件发布后再将改善。相反，如果是软件缺陷(Defects)，小组会立即跟进，并赋予优先程度。若然是重大的缺陷(Critical Defects)，例如功能A 完全不能运作，项目小组要先将其修复才能进行另一个UAT。若然是中等(Medium)的缺陷，例如是Homepage Banner 不能显示，小组会先进行纪录，并确保在软件发布前改善，但无阻下一个UAT 的进行。优先程度比较低(Low) 的缺陷，则可能在软件发布后才进行修复。不竟所有企业都有资源问题，有问题未必需要立刻弄好。
3. Operation Readiness — 营运的准备程度
在Release Management Cycle 里面可以看到，Build、Review、Testing、Deployment、Support、Issue Reporting and Collection。当中Support 就是 Operation Readiness 重要的一环。而Release Management 就是确保顾客和支援的员工，有足够的培训 (Training) 和沟通 (Communication) ，令他们在软件发布前中后，都对发布的功能有一定的认识。
对企业内部的员工而言，Support 包括前线(Front office) 和后勤 (Back office)员工的技援。在前线员工方面，例如是Call Center 或者是Sales，Release Management 要确保他们都得到足够的培训。在顾客询问他们资讯时，前线员工能够有信心回答。因此，在软件发布前，项目小组会举办不同的工作坊(Workshop)，并确保前线员工都能参与。而在举办Workshop的同时，亦会收集前线对功能的疑问，并将其集结为常用问题集，在Workshop 之后发放给员工。而项目小组亦会制作Quick Reference Guide，方便员工查看。而对于后勤员工，项目小组会确定软件的BAU Model (Business As Usual)，当中包括确定Support Team 是那一小组、软件的负责人(Owner) 是谁、如果有项目需要转变时，流程应该是怎样。
而对于顾客方面，Release Management 需要确保软件发布前中后都有足够的沟通。因此，项目小组可能在发布时两个星期，就会向受影响顾客发放提醒电邮，通知顾客将会有新的软件推出。而在软件推出期间，项目小组亦会制造FAQ 来解答顾客问题，并制造反馈渠道，例如电邮、电话或邮寄地址，收集用户意见，并逐一解答。小组亦会制作 Quick Reference Guide 方便顾客使用软件。而在软件推出后，小组亦会向顾客提供永久查询热线，来解答软件使用时的问题。
总括而言，Operation Readiness 包括:
• 前线人员的培训: Workshop, Quick Reference Guide, FAQ
• 后勤的支持: Product Owner, BAU Model, Support Team
• 顾客的沟通: Pre-launch Email, At-launch Reference Guide, Post-launch Communication, Email and hotline
