前言
A一边看代码，一边感叹：真垃圾啊！这都能写出来！！旁边的B盯着屏幕，时间不知不觉过了1个小时，“是啊！这究竟是几波人写出来的XXXX”。两人站起身，去吸烟室点燃一根香烟，屏幕上还有 60万行 待阅读...
有人认为，遗留系统首先是一个还在运行和使用，但已步入生命周期衰老期的软件系统。从最近接触到的一些案例来看，不仅年老的平台需要改造，一些“年纪轻轻”的平台也提出了“整容”或者“复刻”的诉求。
什么情况下，需要改造
不是所有的遗留系统，都要求被改造。决策者会考虑周期、资金、当前痛点的可替代方案、业务方面的领域知识、技术实力等因素。
提出改造诉求的客户有如下一个或多个痛点，甚至更多别的原因：
- 业务发展迅速，系统原有的技术架构不能很好适配新的发展趋势；
- 系统的掌控权（更新、运维等）不在自己手上，希望通过改造工程掌控“熟悉的陌生人”；
- 系统老化，运维成本太高，技术选型也要更新换代，否则后继无人；
- 系统出现性能问题，影响数据的准确性等，可能误导业务决策；
- 系统数据存储方式太零散，希望跟随新的战略步调，完成多个系统的整合；
- 系统技术选型与当前政策冲突，存在法律隐患
遗留系统改造项目中，需要BA参与？
对遗留系统改造项目进行简单粗暴的分类，有这么几种：
- 咨询型。例如一个或多个大煤球系统，希望通过成熟的技术实践完成微服务拆分。
- 交付型。例如，无代码，有系统，竭尽全力Copy；有代码，有系统，努力阅读并理解代码，增添新的功能......
在这样的项目中，技术的依赖性很强，如果有代码，大家会达成共识以代码逻辑作为验证的参考说明。与新产品的开发相比，BA从客户侧获取的信息有限甚至会有错误......
这样的项目依然需要BA。BA的工作重点在于，使团队和客户都能“知其然，知其所以然”。
如果碰巧上了项目，BA面对的难点和挑战
能被客户花大价钱请我们来操刀，除了技术方面对我们的崇拜和信赖之外，可能是因为 他们 自己做不了或者不愿接手。
没人想打开一个潘多拉魔盒，尤其是知道它是魔盒的人。
现在，命运之神将你选为“屠龙少年”，稳住，你还有团队的支持，接着，我会诚实地告诉你可能面临的3大挑战：
- 【上下文缺失】和端到端交付的新产品不同，BA极可能没有Inception Report来参考，也并不能从客户方拿到“粗略却还有点用”的全量PRD。毕竟，这个系统已经增量迭代很多年。所以了解业务背景和梳理系统刻不容缓；
- 【期望管理】如果你参与的是咨询类型的改造项目，客户自然万分希望你是一个“领域专家”，对他们的平台有着“解决方案”级别的熟悉程度，并能提供很多不同的妙计，甚至帮助业务人员规划出新的“增长点”；如果你参与的交付类的改造项目，除了客户的期望，团队对BA的基本诉求是：请告诉我要开发点什么。请告诉我，我开发的东西，对哪里会有影响。是的，没人想看到引入bug。
- 【快速启动，迭代管理】项目I0，眼看一周（不超过2周）的时间留给自己。团队中BA：Dev= 1: 8（or 更多）。Deadline追问：如何高效完成，确定Scope、制定交付计划、需求澄清&分析&确认&拆分、撰写Story、准备IPM。
当然，新问题会随着时间推移慢慢冒出来，好消息是，问题总会有办法解决。无解的话，忘了我。
BA需要做什么？可以做什么？最好能做到什么？
一份参考List.png
以上，只是一份参考List。从Unkown到Kown，再到Clear的过程中，可以使用很多工具，比如电梯演讲、服务蓝图、SWOT等等。无论挑选哪个工具，从目标出发：让业务更清楚，不再是黑盒。团队和客户也都on the same page。交付出可用的有价值的产品。帮助客户实现目标。
仅仅copy的话，的确很无聊，有种浪费生命的感觉。但是，抱怨之余，我们可以思考，如果自己是这个平台的设计者，我会怎么设计，我会怎么优化。在这个领域，我是否能够的了解，可以成为领域专家。
另外，大家不要忽略：
- 【团队协作】团队成员间的配合特别重要。尤其在交付型项目中，我们需要带着问号去思考，不断验证信息。BA、QA、Dev，不同角色的输入要彼此验证，客户的信息也不一定100%可靠。你瞧，这是个极好的机会去磨练自己问题诊断和分析的能力；
2.【用户式走查】像用户一样去使用这个系统，无论多难用；
3.【上下游梳理】遗留系统和外界千丝万缕的联系，对项目的进度和上线有很大的影响。在启动阶段，甚至上线前，有必要反复确认。
写在最后
刚接触到“遗留系统”时，好奇、憧憬，一闪念后，变成了发愁。我不清楚自己的定位，更担心太多未知的不可控事件打乱计划。
幸好，项目内外很多大佬不吝赐教，给了不少锦囊妙计，迷雾渐渐消散。可爱又给力的团队们，齐心协力，一起升级打怪。大家摸索着，总结着，把问题变成经验。衷心感谢大家，也感谢自己。
希望，改造之后，下一个A和B，会赞叹：这么棒的系统！好厉害啊！
网友评论