登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 行业 > IT > 运用“投产窗口”,掌握IT需求交付“脉搏”

运用“投产窗口”,掌握IT需求交付“脉搏”

返回>

2019年01月18日    作者:乔东    来源:微信公众号“IT管理工匠”

A-A+

  在许多的拥有大量IT系统的机构中,往往都安排有“投产窗口”,即预先规定好的需求交付的投产时间段(也有的将需求投产与其他的系统环境变更合并在一起,统一为“变更窗口”)。这一时间窗口的规定,对需求交付投产的时间做了一定的限制,常规情况下不允许在窗口之外的“随时”投产。


  “投产窗口”的作用往往会被理解为是出于生产系统稳定性和投产人员工作量的考虑,但实际上其作用不仅如此,“投产窗口”对机构中需求交付中开发、测试、投产等各个环节的工作节奏都会产生直接影响,会成为组织级需求交付管理工作的“脉搏”。


  我们先来看看,如果没有“投产窗口”的统一约束,允许随意安排业务需求的投产时间,那么可能会面临的情况是什么?


  在开发环节,面对众多的需求,一个应用系统需要建立许多的分支并行开发,然后根据不同需求的时间要求,安排不同分支版本的投产先后顺序。在现实中,由于受到各方面因素的影响,这个时间顺序往往是不稳定的,所以通常的做法是在开发中保持各个分支,在能够确定投产时间时再将其归并到主线上,耗费大量额外成本,特别是当顺序发生变动时,会造成大量的返工和出错的可能(如果直接将不同需求在一个版本中进行开发,当需要拆分版本时问题会变得更加复杂,所以通常情况下都宁可采用分支归并的策略,尽量避免版本拆分)。


  在测试环节,在组织针对业务需求的测试时,经常需要所涉及的若干应用系统共同组成测试环境。在同一时间内,一个测试环境只能支持一个测试项目,同时支持多个并行的测试项目很容易造成相互干扰。所以如果要对众多的并行分支进行用户测试时,为避免相互干扰,往往需要更多套测试环境,大大增加了对测试环境资源的需求(理论上每个分支的版本都应该有一个独立的测试环境)。而且,即使分支版本通过了测试,在归并到主线版本之后,仍然需要再次进行测试,以确保分支归并过程的正确性。


  在投产环节,如果应用系统过于频繁的进行投产,不仅会大大增加应用系统运维的工作量,对于应用系统稳定性也会带来更大的风险。根据以往的实际统计,应用系统故障的发生,与应用系统的投产动作是密切相关的,新版本投产后的一段时间,往往就是应用系统出现问题的高峰期。


  从上述情况可以看出,如果任由以颗粒度可能很小的业务需求为单位自行安排各自的开发计划,可以“随时”投产,如果每年完成上千个大大小小的业务需求,必然要大大增加软件开发管理的复杂度,增加对各方面资源的要求,增加额外的开发工作量,对生产系统的稳定性也会有不利的影响。这种缺乏统筹协调的“百花齐放”,表面看上去非常灵活,但最终在整体开发效率和质量效果上却可能会适得其反。


  那么接下来,再看看安排了投产窗口之后的情形。无论投产窗口是每季、每月还是每周,都会提前有一个明确的投产时间点,凡是计划要在同一个投产窗口中投产的业务需求,都可以包含在同一个“目标版本”中,可以大大减少并行开发分支的数量。而且,“投产窗口”的时间顺序,自然就已经决定了各“目标版本”的顺序,使所有业务需求的开发具有了较好的计划性(由于有了“投产窗口”的限制,需求部门也会更加主动的配合选定相应的窗口)。这样,一个“投产窗口”实际就对应着一个批次的业务需求及其涉及的各应用系统版本。在采用了“投产窗口”的机制后:


  在开发环节,对于能够确定计划在同一时间窗口投产的业务需求,各个相关应用系统都在对应此“投产窗口”的目标版本中开发此项需求。在同一个“投产窗口”中不论要完成多少项需求,都可以在同一个目标版本中实现,也就不再需要维持大量的并行分支,各个需求之间的相互影响也更容易分析清楚。由于直接在同一个目标版本中进行开发,也就省去了之前的分支归并带来的开发和测试工作。


  在测试环节,对应一个“投产窗口”属于同一批次的业务需求和应用系统版本,可以作为一项大的开发任务,共同组织测试环境资源和安排测试计划,支持同一批次版本中所有需求的测试,这样在很大程度上缓解了对测试环境资源的需求压力。在这一管理方式下,需要测试管理人员能够综合这个批次中所有业务需求的测试要求,统筹安排测试环境,规划测试数据和测试案例的选择,协调测试的进展。例如一个典型的例子就是,许多需求都涉及特殊日期时点的处理要求,就可以把同一批次中所有特殊日期的测试要求在测试方案中进行统筹安排。


  在投产环节,按照“投产窗口”组织投产,客观上合并了众多零碎需求的版本变动,从而缩减了投产本身的工作量,对于提高系统稳定性确实有明显的帮助;


  从上述情况可以看出,在“投产窗口”的指导下,实质上是提前约定了相应的投产批次,业务需求的时间计划都尽可能纳入某个目标版本的批次当中。基于“投产窗口”倒推,就可以安排出同一批次业务需求或软件版本的“测试窗口”,对于更前期的开发环节给出了更为具体的时间要求。从而形成每个批次的“脉搏”。


  在《矩阵式研发管理如何加强需求维度的管理》一文中已经提到,需求交付管理不仅仅是传统意义上的需求管理,还要包含开发、测试、投产等各个环节中面向业务需求的跨系统的组织协调。正是由于业务需求与应用系统之间的多对多的矩阵关系,在需求交付的这些过程中,需要对包含在同一批次中的业务需求和应用系统版本进行整体性的跟踪管理,要控制好每个批次所要交付的“需求-系统”矩阵的内容,在整个交付过程中尽可能保证矩阵内容的稳定,需求交付管理、应用系统的版本管理,都需要建立与之相配套的管理策略。


  打个比方来说,各个“投产窗口”像是连续发车的班车,各个业务需求都需要选择搭乘哪一班,在同一辆车上的都要按照共同的节奏前进,终点站就是所有需求的投产交付。乘公交出行,减少私家车上路,也能够减少各方面的资源需求。


  “投产窗口”的间隔要适度选择,会直接影响到需求交付的节奏,需要兼顾市场响应速度和内部管理成本两方面的要求。在同一机构当中,不同要求、不同复杂度的业务需求也可以采用不同的策略。“月度”投产窗口是比较常见的,对于市场响应及时性要求高的也可以安排“每周”,对于一些只涉及单系统的小需求,也可以安排“每周”甚至“每日”,对于一些特定的大型开发项目,也可以安排专门的时间窗口。

责任编辑:王兴钊

标签:IT
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3

京公网安备 11010202007990号


PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设