分享一个来自码哥工作中遇到的时间紧任务重，对系统不熟悉，没有产品文档，目标就是将原有系统改造成客户本地部署运行的多重困难跨团队协作项目管理差点带崩的经历。
通过该经历重点在于给大家分享如何避免项目搞砸，以及一个项目初期、中期、收尾阶段需要做的工作重点和注意事项，如何管理项目规避风险。
项目背景
项目的目标是将公司 saas 团队的供应链金融系统移植到客户独立部署，主要有以下几个风险和难点。
- 团队内的人包括我并不熟悉该系统的业务流和系统的代码，难以分析项目的风险和改造点。
- 干系人分析不足，没有将熟悉该系统的人引入，导致风险无法识别，进度缓慢。
- 时间和人力明显不足：人力极致压榨。
- 跨多个团队协作：开发该系统的团队并没有参与此次迁移工作。
- 原系统与公司内部的接口交互需要全部通过 Http 来实现：原有的系统架构并不适用直接迁移到客户部署，部分接口能力是调用公司的其他团队实现，比如 AI 识别或用到 MQ 通信，通过 Dubbo 或者 HTTP 调用其他团队接口实现逻辑，需要统一改造成通过 Http 调用公司开放的接口实现。
图片
除此之外，该 saas 系统由于原先开发人员的技术能力较弱，以及历史渊源，框架设计不合理，可读性和可维护性比较弱的情况下，如何更好的与原维护者沟通也是一大难题。
因为技术人会容易看不上别人的代码和设计，尤其是架构确实有明显不足的时候。
打开项目代码发现这是一个披着微服务外衣的大单体巨石服务。一边骂别人系统垃圾，一边还要请求人家帮助的事情需要合理手段解决。
图片
最终发现拆了一堆的服务，可是实际上业务逻辑和系统的压力全都集中在 web-service 上。
至于拆出来的微服务，只干了一件事：myabtis 作为 ORM 框架操作数据库，也不懂这个项目的原开发和架构是怎么想的，单一职责不是这样理解的，大兄弟。
真的是「黛玉骑鬼火，该强的强，该弱的弱」。
遇到这种情况，我们一定要秉着谦虚的态度，因为还要请教他们解答项目如何迁移，需要我们想方设法用彩虹屁夸他们，让他们觉得受到尊重，虽然很反人类，可这是我们的必修课：
总之一定要一顿夸，切不可用技术人的视角把实际情况说出来，要是指出系统懂得各个不是，各种技术垃圾，你觉得别人还会帮你么？
过分悲观 or 乐观
在该项目中，由于项目距难度很大，但是大家又不知道到底有多大，就会出现过分悲观 or 乐观的情况。
于是团队内出现了一些这样的声音……
吴大佬：“这个项目一个月就要完成改造，肯定完不成，也不知道具体有哪些风险点。”
江小白：“反正完不成，爱咋滴咋滴。”
这两者均建立在对项目掌控度不够的情况下，会导致对于项目的判断失误，过分悲观会影响到项目组同学的积极性，反之会导致风险暴露在后期。
为了避免该情况发生，一定要做好项目启动会，邀请所有干系人参会。启动会的目的围绕以下几点。
作为管理者，启动会上需要做一个 PPT 来列出几个关键项，让所有参与制知道目标和职责。
图片
忽略细节
即墨菲定律，凡是觉得可能出错或小概率出错的事一定会出错，当 review 发现问题时需要深入到细节中了解和推进，避免问题最终暴露在线上。
在项目执行过程中，由于对业务和系统都不熟悉，觉得只要系统能运行起来，我们都没有改代码只是将原本 Dubbo 接口替换成 http 调用。
忽略掉了一些细节，后来才发现事情很复杂，旧系统调用了公司内部很多接口，错综复杂，而团队内没有一个人接触过这个系统，本地化部署的情况下完全无法使用，网络不通。
代码迁移和改造以及范围影响点随着一个问题的出现，在联调阶段爆炸式出现。
根本原因就是忽略了细节，没有深入拆解每一项任务。但是问题又来了，原本大家都不熟悉这个系统，又如何拆解正确呢？
这就设计到利益关联方干系人分析的范畴了。
利益关联方干系人分析
事情能不能办成，利益方一定要分析清晰。天下熙熙皆为利来，天下攘攘皆为利往。
该项目是将原 saas 系统改造成客户本地化部署运行，所以利益相关方一定要将系统的 saas 团队关联上，否则注定失败。
大家一开始想到的是需要原系统开发者提供技术支持就可以完成，这是个错误的决定。
因为不符合人性，系统成败与原开发者无关，那必然不会投入精力来帮助，让别人来帮助还会被说『帮助我们不是义务，是情意』。
这就难受了，我们求着别人心里憋屈，别人还不乐意，只怪他们本就是利益相关方，却只是将他们作为咨询身份参与，无关利益，打错打错，项目注定要崩溃。
项目一开始，我们都是去咨询原系统开发者，久而久之别人不耐其烦。
项目后期风险越来越大，码哥强烈要求原开发者加入该项目才得以将风险降下来。
只有这个项目的成败和利益与原系统开发者息息相关，项目的风险才能控制。
时间和人力明显不足
影响项目成功的关键在于干系人参与程度、高层管理者的支持、清晰的需求陈述、恰当的计划以及项目的合理预期和里程碑。
而此次项目一个运行迭代了 5 年的系统在一个月内改造完就可以断定这是一个扯淡计划。
但是人在屋檐下，人力的极致压榨，领导者就是让大家每天加班到晚上十一点半，周六日来加班实现，打工人只能冲一把。
于是乎，作为项目负责人也只能竟可能做好项目计划、降低上层管理者的预期、干系人分析，提出人力缺口，让上面的管理者去其他团队借调资源。
需求陈述不清
项目启动后因为外部各种因素感染导致项目根本没有需求文档，产品经理一句话按照当前原系统能力建设。
这也是项目容易崩的原因，连需求文档都没有。一句话照搬原有系统即可，虽然是笑话，可是就是发生了。
怎么办呢？这就特别管理者的能力了，需要了解高层管理的时间要求，以及客户希望系统的范围和质量；
码哥作为技术管理者在项目执行的过程中需要不断的和产品经理沟通去梳理出真正的需求，同时还要识别出风险，鼓励组内的开发把事情做好，解决项目部署遇到的问题以及技术难点。
遇到一心只想甩锅的产品经理那更加考验你的心态。
产品经理：“项目什么时候可以提测，风险这么高你们都不管么？你就是想让大家都陪你加班。”
所以，一定要有需求文档梳理产品的范围，一定不要就按照老系统有的功能都要有这样的一句话需求。
总结
主要遇到的问题和吸取的经验如下：
- 过分悲观 or 乐观：这两者均建立在对项目掌控度不够的情况下，会导致对于项目的判断失误，过分悲观会影响到项目组同学的积极性，反之会导致风险暴露在后期。
- 忽略细节：即墨菲定律，凡是觉得可能出错或小概率出错的事一定会出错，当 review 发现问题时需要深入到细节中了解和推进，避免问题最终暴露在线上。
- 利益关联方、干系人分析不合理：事情能不能办成，利益方一定要分析清晰。天下熙熙皆为利来，天下攘攘皆为利往。
- 需求陈述不清：项目启动后因为外部各种因素感染导致项目根本没有需求文档，产品经理一句话按照当前原系统能力建设。
- 前松后紧：不合理的规划会导致项目陷入这种状态，导致提测时问题过多，开发未自测质量差等情况。
