项目中的偶然事故,背后是必然的故事

项目中的偶然事故,背后是必然的故事

01

老张刚回到自己的工位坐下,还没有来得及开电脑,技术负责人就找过来,“老张,赶紧收一下邮件,这次出现了一个大的技术事故,惊动了客户高层。”

这个项目已经交付了一年,设备安装并已经上线商用运行,其承载的业务吸引了数百万的用户,给客户带来了可观的收益,客户看业务发展迅速,于是委托欣尧在设备上继续开发了一个新的第三方业务的承载环境,这不,刚上线不久,问题来了。

“别着急,我先看看。”老张从包里取出笔记本,接上电源开机,等待接入公司的内部网络,打开Outlook收取技术负责人转给他的客户投诉邮件。

投诉信的内容言辞很激烈,在信中客户迁怒于欣尧公司,并威胁要求欣尧赔偿因事故造成的业务收入损失。技术负责人就这件事情仔细的和老张来开始解释,事情本质上产生于新上线的第三方业务,欣尧提供设备上面的平台开发,提供环境给第三方业务,当该第三方业务上线后,业务量激增,远远超过了系统本身所能承受的业务容量。

为了保证设备上其它业务不受影响,对该业务进行了限流处理,同时需要紧急扩容方案验证和实施工作,然而由于临时方案的不成熟,第一次扩容操作失败,需要继续制定可行性的方案,就在这个时候,客户投诉信就来了。

“这只是表面现象,看起来只是一次偶然发生的事故,但我觉得我们自身还是有问题的,客户投诉也不是一点道理都没有。”老张也没有直接推卸责任,接着继续叮嘱技术负责人,

“你还是让技术团队对整个事情发生的前因后果仔细分析一下,第二次扩容一定要谨慎,要是成功还好,客户满意度还可以挽救回来,但是要再次失败那就真的不好交代了。”

02

一个星期过去了,到了项目周例会的时间,技术负责人就此次客户投诉事件的前因后果进行了一次分析总结。

“首先此次事故具有一定的偶然性,新上的第三方业务有一定能够的特殊性,刚上线一周就出现用户激增到这设备容量的门限值以上,这个问题我们经过第二次设备扩容将这个问题解决,虽然引起了客户的投诉,最终结果是好的。”

技术负责人觉得有些不好意思,毕竟投诉就是投诉,给项目组带来了巨大的压力,但现在是事后总结分析,也只能继续往下说,

“但终究问题是怎么发生的,很明显我们在新增第三方业务上线前,并没有充分考虑设备的容量因素,对新业务场景也不熟悉,缺少相应的应对措施。我们的设备平台承接之前的业务都是逻辑相对简单,业务应用也不是很频繁的情况,同时业务与外部系统交互较少。但现在新增的业务我们后来重新分析了一下,系统逻辑复杂,需要实时和外部多个系统进行交互,并将业务开放给所有的用户申请。”

“面对系统设计要求如此高的业务需求,我们还是习惯性地采用原有的交付策略和流程,全过程的需求分析、系统方案、版本开发、安装调试和上线支持都想当然地按简单业务要求运作。需求分析不完整,系统方案不可靠,版本质量不过关,安装调测不严谨,缺少相应的上线前评估和上线后保障,最终酿成大错。”

“由此可见,如不能识别业务场景,制定对应的交付策略,即使此次该业务没有因为流量过高导致问题发生,想必后续也会有其它业务出现类似的问题。”

技术负责人讲到这里,老张站起来,接过话头,

“按照欣尧项目组与客户的合同范围约定,实际仅限于设备平台的建设,当然这里面包括平台的需求定制、管理服务和业务支持,但对于业务的需求、方案、开发、部署以及上线后的运维其实都不在此次合同的约定范围内。”

“当前,一方面在项目初期项目组希望通过主动帮助客户快速上线更多业务来体现设备平台给其带来的价值,很多合同外的事情我们都积极主动帮助,并没有明确合同界面的定义,也缺少项目范围管理意识。”

“另一方面,客户对这些价值业务抱有很高的期望,需要有欣尧提供匹配的方案和服务来为其创造价值,同时也可以帮助欣尧带来收益。然而实际情况却是,我们稀里糊涂的给客户做了大量合同范围之外的工作,不仅没有为客户创造价值,反而给客户造成损失,最终招致投诉。后续项目组不得不在方案、容量、定制和管理服务上继续保证该业务发展,而且无相关的收益保障,埋下了非常大的隐患。”

03

事情虽然已经过去了,项目组还是通过认真总结,对此次事件做了一次复盘,并制定了下面的三个策略:

  • 结合客户需求,对业务场景进一步识别和分类,并明确对应的交付策略。业务规划、实现、运营和服务需要分类对待,客户自由的业务欣尧需要逐个的以客户需求角度出发,提供合适方案,包括业务流程、质量标准、容量规划和管理服务等。而欣尧内部也需要将其作为平台之外单独的合同或项目来进行交付,确保既能实实在在为客户创造价值,也为公司带来收益。
  • 明确界面定义,加强范围管理,识别存量机会并降低经营风险。与客户定义明确界面,平台与业务严格区别对待,并分别呈现欣尧对其平台与业务在客户界面内带来的价值,以及合同界面外可以为其带来的价值。
  • 项目组内强调项目范围管理。所有成员牢记哪些是项目范围内的工作,哪些是项目范围外的工作,如出现客户要求范围存在灰度部分工作或范围之外的工作,需要提交给项目经理来确认,如果工作量较大则需要由项目总监或项目管理层来推动客户进行采购或审批,以便做好内外部风险管控。

欢迎关注项目经理世界(Wechat: IPMP_WORLD)您的支持就是我最大的动力,点个赞呗 ^_^


分享到:


相關文章: