就像美食一样。吃过的未必都记得,但是记得的一定得是吃过的。

记忆中只有做外部顾问时期,才会认认真真的写项目的回顾。那时候几乎一个项目就会记满了一个笔记本。包括前期的项目沟通,我需要提前准备的内容,到达项目目的地后跟客户方的沟通记录,当然也包括在各种装机、培训、实施过程中的详细记录。只要是觉得跟项目有关联的,我都会一笔一笔写下来。

离开乙方,转做in house 甲方已经将近3年半,经历折腾的完整的项目也才两三个。而本周完成切换上线的一个移植项目,却让我重新拾起了记录、回顾的欲望。原因有如下几个:

  1. 这是第一个转做甲方之后,最类似于之前做乙方时候的项目。也就是说,项目实施期间完全按照我个人的风格,非常集中的调度一批人,硬生生给扛下来。个人色彩浓,并且项目的进度安排非常严谨,目标明确、交付明确。
  2. 项目特殊。项目scope比较简单,就是把一套中国公司一个部门使用的,但是服务器位于美国的应用系统搬迁移植到中国本地,不包括功能增强、也不包括需求变更。看起来简单明了,但是暗藏的坑和困难也显而易见:中国本地没有懂的人;虽然同属一个集团公司,但是美国总部的支持比想象的差,充满了玩政治的味道,自然配合度也好不到哪去;所以从initiate 到项目预算申请、审批,一直到正式实施迁移,时间跨度将近2年。
  3. 实施期间碰到的坑多,完全就是边实施,边熟悉系统。

回顾这个项目,虽然不大,但乘着还有些体会,整理如下:

  1. 铺垫和准备工作。为了达成项目目标,需要提前很久把系统现状了解清楚,同时要找准时机。比如这系统因为性能原因导致大面积用户访问出现的问题的时候,迅速与美国达成协议,获得高层的一致同意。另外,找到local的vendor,提前开始知识技能储备。这两项工作,必须准、力度大,且落实到位。
  2. 切换所需要的资源协调。移植项目,其实是有标准的资源要求模版的。哪些是用户,哪些是L1、L2、L3的支持人员,谁是开发leader,谁是测试,谁是BA;找准了才能开始建立联系,并且这kick off的时候能involve所有相关的人。同时,也才能制定出比较准确的非生产环境迁移、测试以及切换脚本(Run Book).
  3. 永远切记找到对的人。多方、异地资源的协调,总是要把“谁说了算”这一条放这脑海里。
  4. 切记要做完整的、全过程的测试。按照用户的操作过程,每一个步骤、每一个页面、每一个发出的订单、每一个issue出去的pdf,每一个客制化的报表、form和邮件通知,都需要严格录制为测试脚本,一步一步测试。
  5. 时刻了解最终用户的期望。大到scope,小到切换后是否需要跟之前的上线的庆祝仪式有什么区别,都要时刻跟用户保持沟通。特别是中国本地没有懂的人,也就意味着切换完成后的运维团队是全新的,经验不足,更别说能够充分了解公司的业务和客制化的功能了。这些弱项,一直要跟不移植的前提下用户的pain point做比较,甚至可以反复提出。

从上周录制了开篇的一期Podcast开始,仿佛找到了一个出口。一个以防自己自言自语严重的出口,一个开始回顾我的工作内容并企图从中获得更多经验教训的出口。也期望自己,在逼不得已的工作旅途中,多多思考,多找些共同性,更多的明白自己在做什么、为什么做以及怎么做到的。

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.