如何推动复杂的功能变更
最近的两个项目，我经历了极其相似的一幕：“一句话的简单功能实则是浮露在海面的冰山一角，慢慢挖掘就会引出复杂的功能变更”，而在开始的时候我们都浑然不觉，只是隐约觉得日子好像有些难过。
拉响警报，识别复杂
故事初始
项目A
客户：“我们要向其他的国家扩展市场了，现在需要团队导入某国经销商的数据，以复用整个业务流程。”
团队：“好的，没问题”。
项目B
客户：“我们想要区分用户账号的归属，然后将服务的套餐额度按部门售卖。当前正在和外部系统同事沟通，看看是否有部门标识字段供我们使用。”
团队：“合理，那我们就等待更新”。
几天后
项目A
团队：“有问题！新国家的经销商没有主次层级结构，这会影响现有业务处理。”
客户：“新市场确实没有。”
团队：“那怎么办？这种情况没办法拓展新市场数据。”
客户：“我是某系统管理员，我可以配置用户和经销商关系，也许能解决我们的问题。”
团队成员面面相觑：好费解，这怎么能解决我们的问题呢，方案和问题的联系是什么？
客户内心：怎么开了这么多次会，一点进展都没有！虽然很有限，但我已经说了我知道的信息。
项目B
客户：“外部系统那边没办法很好的区分部门，我们自己搞定部门编号吧。”
团队：“额，那我们看看。”
客户：“行，时间不太多，留了一周时间给这个功能，得尽快开始。”
团队内心：这也太赶了，这个功能到底想干啥还不是很清楚。
窘境与危险信号
回顾上面2个场景，我发现了极其相似的窘境：
“团队和客户均对需求缺乏理解，彼此等待对方的输入，难以取得实质性进展。”
客户对需求缺乏理解的主要原因是：项目的拥有者大多是了解系统的关键流程的，但随着系统功能的增强，用户流程的复杂化，业务功能的背后隐藏了太多的重要细节。相关功能的全链路及重要细节往往需要开发团队的补充。同时客户自身对功能变动的期望也需要时间进行整理。
而开发团队对于需求的陌生感，源于未能从客户测识别出核心的功能变更，以及团队自己也需要更多时间对系统相关进行串联整理。客户初期对于功能的认知，如我们所言，也存在一个渐进的过程，这可能带来坏的影响，具体体现为
对需求的描述重点有所偏差。如在项目B中客户最核心的功能需求其实是由套餐绑定到用户变更为绑定到组织或一组人，而非区分部门编号。
客户按自己对需求的理解提供了一种方案，但这种方案或者是无效有误导性的，或者是未能让团队理解的。如项目A中，客户提出的方案让人费解，但其实是期望以“用户（所属一个经销商）和其他经销商的关系配置”来代替之前由”经销商与经销商的关系配置“搞定的业务逻辑（如权限限制，价格配置等）。
该窘境的出现通常也标识着 — 该功能是复杂的。至少复杂到只具备业务理解或系统理解的一方难以独自把握它的复杂性。作为项目的管理者需注意 — 这是一个危险的信号。如果你对功能复杂度和变更范围没有底，那将意味着它有可能是一个远远超出预期的复杂需求。
打破窘境的关键，是团队要准确识别出核心的业务变更，这样将获得思考的主动性。因为团队可以以此为基线继续思考，粗略判断出业务变更的真实范围。比如在项目B中，核心业务变更是“由套餐绑定到用户变更为套餐绑定到组织”，那么假设我可以区分不同部门的账号，为了完成这个功能，至少有哪些现有模块儿受到影响呢？无需看代码我立刻就会想到“套餐分配模块、套餐计算扣减模块、套餐信息展示功能”这些工作都将受到影响，以及还可能要新增“用户识别/分配组织，现有生产环境用户数据迁移”等功能和任务，这样对比之前客户着眼的“如何区分用户部门”这一小而具体的任务，识别出来的功能变更范围，简直就是云泥之别。
最后总结一下我们在该阶段的目标：团队应该在与客户的沟通中，从小的、具体的、不紧急的、重心有所偏差的任务中跳脱出来，识别出最核心的业务变更。然后尝试以模块儿的视角，识别出该变更的影响范围。将功能变更的本质及复杂度摆在客户面前，这将强而有力地推动事情的进展。
深入模块，确认期望
协同共创
项目A
客户：“这个功能替换确实复杂，你们画一下流程图方便我们讨论吧”。
团队：“好的，我们来准备。我们约几次workshop进行讨论吧”。
客户：“可以”。
项目B
团队：“我们来产出一个spike文档，尝试梳理功能变更方案，完成后我们约一下会，按模块来确认一下期望细节。”
客户：“好的”。
几天后
项目A
团队：“之前，经销商的层级关系在我们的业务中全流程是这样的。。。今天我们只关注在权限限制这里，下面我们深入到现状流程图。。。如果我们想用新的方案替换必将产生的变动将是。。。”
客户：“业务上会有A、B这几种特殊情况，新方案我能看到的问题是。。。”
会议室中，workshop如火如荼的进行着。。。
项目B
团队：“我们的spike文档按照受影响的功能模块划分为A、B、C、D。先来说一下A，现状用户旅程是。。。我们理解的期望是。。。”
客户：“第一条期望是我们想要的，没有问题，能大约得看一下变更后页面吗？第二个期望我们有不同的补充可以一会儿聊。”
团队：“好的，变更后页面是这样。。。”
方法与可视化效力
在前期迷茫的沟通中，我们识别出了核心的功能变更诉求。接下来要做的就是艰苦的探索和思考了，因为任何有效的讨论都是前提条件的，那就是有具体的问题以及有人能够掌控讨论的流程和进度，这意味着有一个能够提供较多输入带领讨论的人。上面的workshop或者spike文档的讨论都是在此之后的。
探索和思考的过程中，我们使用的最有效方法就是现状（As-is）和期望（To-be）分析，加之以不同程度的可视化手段。全过程都需要业务人员和技术人员的紧密配合。
首先需要识别出全部的As-is。出于对当下业务流程的理解，我们已经大约知道受影响的功能模块是哪些，现在就是深入每个模块细节的时候了，这需要业务人员先进行准确的业务场景定位。业务人员可以通过浏览系统页面或者已有的业务资料将受影响的业务场景进行整理和描述，然后技术人员通过粗略阅读相关代码进行细节补充和准确理解。这二者互不可少，直接开始代码的阅读，海量的代码范围将带来不必要的烦恼；如果只进行业务流程的梳理，缺乏背后的处理逻辑补充，细节理解的补充，将对方案真实的可行性及复杂度评估产生影响。这个阶段，我们只专注于功能的As-is信息梳理，暂时将To-be放下，需要在工作完成后对系统了然于胸。
然后进入到To-be的思考环节。To-be是真正的将核心业务变更，结合现状进行思考和产出的过程，在这一阶段中，我们会基于对期望的理解，描述变更后的业务场景将会如何。这个阶段，我们会有如下但不局限于此的思考产物
- 要想达到业务期望，必然的变更是什么。
- 哪些变化需要客户进一步的输入，以决定哪种方案更好。
- 我们的方案倾向是什么，权衡有哪些，建议是什么。
- 是否有明显的方案可行性硬伤及风险，有没有解决的可能性。
将这些思考产物进行梳理和总结，就形成了与客户讨论会议中的具体问题和确认目标。
在整个思考和讨论的过程中，我看到了不同可视化手段的必要性和表达效力。可视化手段包括文字描述，流程图，Figma原型图。
在梳理As-is和To-be的过程中，我会结合使用文字描述和流程图。在人脑活动 — 思考 — 这一过程中，如果能够看到具体的信息，将会降低逻辑串联的复杂度，有效避免模糊和凭空想象。所以当我在梳理As-is时会用文字或流程图将事实记录，方便反复阅读与理解。在思考和设计To-be时，更是会参考As-is的描述将To-be进行设计，如果有复杂的问题，也会明确将问题、条件及可能性进行描述，然后根据思考进行修改。所以文字描述和流程图是整理逻辑和过程的有效手段，可以有力帮助我们进行有效地、完整地、逻辑缜密地思考。当然具体以文字描述为主还是流程图为主要看我们每个模块的复杂度，相对简单就使用文字描述，相对复杂就使用流程图。最后Figma等原型图则是整套方案大体梳理完毕后的可视化手段，原型图并不能高效力地帮助思考和梳理逻辑，但确实是方案尘埃落定、最后一环的表达，让我们明确知道，具体的变动结果是什么样子的，让我们识别出，还有哪些用户体验细节需要进行补充。
拆卡评估，计划迭代
故事最后
项目A
客户：“这么多次workshop后，我们取得了很好的进展，明确了想要的方案。我们下面计划一下和相关方的同步会议，开始功能变更的推进。”
项目B
团队：“明确了我们的业务期望和变更方案后，我们新拆出14个任务，每个任务评估了大小后大约需要2个开发一个月的工作。”
客户：“方案没有问题，但时间上确实远超出了我们之前的预期，我们需要进行额外的项目管理沟通会议。看看下一步的安排。”
艰难混沌的日子终于看到了明朗的前进方向，大家身上的压力终于得以释放。当然还有很多工作需要开始，但我们都信心满满，就像首战告捷那样士气高涨。
评估与工作推进
业务期望和实现方案确定之后，就是将具体的功能进行拆分和评估的环节了。其实功能的具体变动在第二阶段As-is到To-be的过程中就可识别出来，只是当时的聚焦点仍在期望确认与方案可行性确认之上。现在则需要更多聚焦于工作的管理上，如根据任务的依赖关系，与当前系统的兼容情况进行合理的交付安排。
而工作量的实际评估，往往会影响客户的决策。如我们的项目A，涉及到大量和其他团队的合作，我们组织了一个功能同步会议，以建立彼此的定期沟通和共享，自身团队一侧则开始了部分兼容性功能的开发。而项目B则因为我们确实地受限于工期，我们进行了方案替换，如将“套餐绑定到组织”替换为了“用户间的套餐共享”，去掉了组织的概念我们剪掉了很多的工作量，但之前所有的努力并没有白费，正是因为之前的所有整理与讨论，使我们能够在1～2个小时内，成功构想出另外一个完整可行但业务策略上有所让步的方案，并且得到了客户的同意和认可。
总之，推动复杂的功能变更并不是一件容易的事情，但是经过有序而有效的努力之后，我们确实地完成了一件非常有趣、有价值和有成就感的挑战。