就像美食一样。吃过的未必都记得，但是记得的一定得是吃过的。
记忆中只有做外部顾问时期，才会认认真真的写项目的回顾。那时候几乎一个项目就会记满了一个笔记本。包括前期的项目沟通，我需要提前准备的内容，到达项目目的地后跟客户方的沟通记录，当然也包括在各种装机、培训、实施过程中的详细记录。只要是觉得跟项目有关联的，我都会一笔一笔写下来。
离开乙方，转做in house 甲方已经将近3年半，经历折腾的完整的项目也才两三个。而本周完成切换上线的一个移植项目，却让我重新拾起了记录、回顾的欲望。原因有如下几个：
- 这是第一个转做甲方之后，最类似于之前做乙方时候的项目。也就是说，项目实施期间完全按照我个人的风格，非常集中的调度一批人，硬生生给扛下来。个人色彩浓，并且项目的进度安排非常严谨，目标明确、交付明确。
- 项目特殊。项目scope比较简单，就是把一套中国公司一个部门使用的，但是服务器位于美国的应用系统搬迁移植到中国本地，不包括功能增强、也不包括需求变更。看起来简单明了，但是暗藏的坑和困难也显而易见：中国本地没有懂的人；虽然同属一个集团公司，但是美国总部的支持比想象的差，充满了玩政治的味道，自然配合度也好不到哪去；所以从initiate 到项目预算申请、审批，一直到正式实施迁移，时间跨度将近2年。
- 实施期间碰到的坑多，完全就是边实施，边熟悉系统。
回顾这个项目，虽然不大，但乘着还有些体会，整理如下：
- 铺垫和准备工作。为了达成项目目标，需要提前很久把系统现状了解清楚，同时要找准时机。比如这系统因为性能原因导致大面积用户访问出现的问题的时候，迅速与美国达成协议，获得高层的一致同意。另外，找到local的vendor，提前开始知识技能储备。这两项工作，必须准、力度大，且落实到位。
- 切换所需要的资源协调。移植项目，其实是有标准的资源要求模版的。哪些是用户，哪些是L1、L2、L3的支持人员，谁是开发leader，谁是测试，谁是BA；找准了才能开始建立联系，并且这kick off的时候能involve所有相关的人。同时，也才能制定出比较准确的非生产环境迁移、测试以及切换脚本(Run Book).
- 永远切记找到对的人。多方、异地资源的协调，总是要把“谁说了算”这一条放这脑海里。
- 切记要做完整的、全过程的测试。按照用户的操作过程，每一个步骤、每一个页面、每一个发出的订单、每一个issue出去的pdf，每一个客制化的报表、form和邮件通知，都需要严格录制为测试脚本，一步一步测试。
- 时刻了解最终用户的期望。大到scope，小到切换后是否需要跟之前的上线的庆祝仪式有什么区别，都要时刻跟用户保持沟通。特别是中国本地没有懂的人，也就意味着切换完成后的运维团队是全新的，经验不足，更别说能够充分了解公司的业务和客制化的功能了。这些弱项，一直要跟不移植的前提下用户的pain point做比较，甚至可以反复提出。
从上周录制了开篇的一期Podcast开始，仿佛找到了一个出口。一个以防自己自言自语严重的出口，一个开始回顾我的工作内容并企图从中获得更多经验教训的出口。也期望自己，在逼不得已的工作旅途中，多多思考，多找些共同性，更多的明白自己在做什么、为什么做以及怎么做到的。
Bonjour Rafe 