“ 要改变现状，解决痛点，需要提出解决方案，并得到各干系人的支持，这个过程需要结构化的方案文书、扎实的数据作为重要理据和游说技巧。”
作为为用户提供技术支持的一部分，我们需要为新用户创建测试环境。
按照原来的流程，我们需要为每一个新的测试环境创建新的虚拟网络。但为每个新环境都创建新的虚拟网络的旧做法产生了以下问题：
创建虚拟网络需要两个外部团队的配合，需时两到三周，造成创建新测试环境的周期也因此被拉长；
当为每一个新的测试环境都创建独立的虚拟网络时，相当于要为每个环境分配一段固定大小的不可重复的IP地址范围。从实际使用的数据来看，整体IP地址资源的利用率很低。当被分配的IP资源用完后，我们就需要请求外部的网络部门进行网络扩容，但IP地址资源的利用率低的问题将使我们的网络扩容请求被质疑；
开发系统的厂商也不断警告，不断创建新的虚拟网络可能会触及到系统设计的上限，使得新的环境无法创建。
为了解决这些问题，我们一直在研究是否可以用一个大的共享虚拟网络分配给新的测试环境，这样就不需要再为每一个新环境创建一个新的虚拟网络。
但是这个方案需要考虑对现有用户的影响，而且方案涉及到我们部门服务流程的变更，也需要得到部门所有干系人的支持，最起码不要有强烈的反对意见。
在这个过程中，我们需要以下三板斧。
01
—
结构化的方案文书
我们对采用共享虚拟网络的可行性，进行了长期的研究。
通过研究，我们的结论是，这个方案是可行的，而且为了兼容用户的各种特殊需求，我们把共享虚拟网络方案作为将来创建新的测试环境的可选方案之一（当然这会是我们给用户的首选方案），而如果用户有特殊需要，我们仍然保留创建新的虚拟网络的选项。
为了完整表述整个新的方案，我们为方案写了结构化文书，其结构为（以本文话题为样例）：
| 总结 | |
| 提供共享虚拟网络方案作为将来创建新的测试环境的首选方案。 | |
| 要解决的痛点 | 主张的变化 |
| （如本文开头所述） |
|
| 好处 | 实施计划 |
（与痛点一一对应） |
|
有了这个完整、清晰的文书，我们就可以把它分享给部门各干系人阅读，并开会进行解释，得到支持。
02
—
扎实的数据作为理据
在研究的过程中，我们对这个新方案的影响和现状进行了大量的分析。
这个过程考虑到了新的方案所带来的风险和影响，并为这些风险和影响进行了规避，比如在新方案中，依然为有特殊需要的用户保留了旧的做法。
更重要的是，我们在这个研究过程中，得到了在原来为每个环境创建新的虚拟网络的情况下，整体IP地址利用率只有16%的数据。
由于创建新的虚拟网络时，必须指定IP地址范围的大小，这个大小在虚拟网络创建后也不能改变，而且这些IP地址是外部网络部门分配的一部分，在不同的虚拟网络中不能重复。
在旧的做法里，我们需要为每一个虚拟网络，也就是每一个新的环境，预留足够大的IP地址范围，因为我们无法预知用户在每个环境中的实际用量。
这就相当于我们在一块土地上，为每一个环境创建一个独立的房间，而每个房间的大小是固定的。从实际的数据来看，有些房间快住满了，IP地址使用率超过90%，但绝大多数房间只用了几个IP，只有百分之几的利用率，平均下来，整体IP地址利用率只有16%。
而这块土地的大小也是固定的，是外部网络部门经过协商分配给我们的，如果这块土地用完了，我们就需要向外部网络部门申请一块新的土地。
但我们知道，外部网络部门已经在抱怨我们的IP地址利用率低的问题，在我们无法有效提高IP地址利用率的情况下，我们将很难说服他们投资扩容网络设备为我们分配新的土地。
因此，通过研究现状得出了整体IP地址利用率只有16%的数据成为我们要立即实施共享虚拟网络这个新方案的重要论据。
我们常说用数据驱动决策，这就是一个很好的例子。
03
—
逐个击破的游说技巧
我们有了完整、清晰的方案文书，有了扎实的数据作为重要论据，按理说，要得到干系人，也就是部门内各个同僚的支持，只需要在例会上跟大家过一遍即可。
但其实我知道团队中有一个同僚一直是不支持这个方案的，而且，从和他多年合作的经验知道，他有一点完美主义情结，对所有短期缓解方案都不感冒。
所以，可以想象，要想在一次例会上全体通过这个方案并不现实。当你知道要说服的人里面有硬骨头时，需要改变一下策略——逐个击破。
其实这个方案并不是现在就想到的，我在一年多前就让自己的团队研究过各种方案。目前这个方案是最简单的，也没有外部依赖，可以立即实施。之前在跟部门各个同僚私下交流时，已经基本摸清大家的态度。
除了前面提到的那个同僚不同意外，其他人基本没有什么异议。
而且这个方案我也跟领导过了，他也表示支持。他也给了我一些说服同僚的建议。
如果这位同僚还是坚持己见，我会坚持这个方案是服务流程的变更，我会负起全部责任，不需要得到他的批准，和他讨论是尊重他，并收集我们可能考虑不到的意见。
再不行，有领导和其他同僚的首肯，也是我最后的皇牌。
那位同僚不同意的理由以及我的意见是：
为每个环境分配独立的虚拟网络是最初为了实现网络隔离的架构设计；
我的意见：由于各虚拟网络在网络上是互通的，并没有实际的隔离作用。
系统厂商提出过另一个方案，可以简化创建新的虚拟网络的过程，大大减少创建过程中的外部依赖；
我的意见：这个方案需要厂商对系统进行大版本升级，目前升级没有时间表，而且这个方案无法解决IP地址资源利用率低和虚拟网络数量上限问题。
他不认为本文提除的问题有急迫性；
我的意见：我们作为负责技术支持的团队认为这是我们每天都面对的痛点。
他认为这是一个架构变更，需要架构委员会的评审；
我的意见：我们认为这是服务流程的变更，并没有改变架构。
在和他进行几番讨论后，我最终还是得到了他的理解，这里运用到的技巧是淡化冲突，我强调新的方案并不是替代旧的做法，而是在旧的做法的基础上，为用户提供一个新的选项，当然这是我们首选的选项。所以，新方案跟旧做法是共存的关系，不是替代的关系。
最终，虽然我们并不没有达成完全的共识，比如他认为这个新的选项应该是最后的选项，而不是首选的选项，但他并不会反对我们立即实施这个方案。
于是，这个方案现在正在按照实施计划进行落实。
04
—
总结
要改变现状，解决痛点，需要提出解决方案，并得到各干系人的支持，这个过程需要结构化的方案文书、扎实的数据作为理据和游说技巧。
觉得文章不错，顺手点个“点赞”、“在看”或转发给朋友们吧。
相关阅读：
关于作者
关注公众号看其它原创作品
坚持原创高质量软件交付相关文章
觉得好看，点个“点赞”、“在看”或转发给朋友们，欢迎你留言。
2949
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
