1. 背景
软件产品在经历前期一系列的设计，研发，测试等流程，进入到实际的部署使用环节，整体流程可以分为两大块：
- 前期的大量成本投入阶段。这里就是上面提到的"设计、研发、测试"。
- 后期的成本回收，赚取利润阶段。比如这里提到的"部署使用"。
对于赚取利润阶段的"部署使用"来说，如果这个软件产品采取的是类似支付宝/12036这样的集中部署方式，那么出现问题基本都是自己内部维护，影响相对可控；但是对于本文将要重点讨论的"本地化部署"场景下，客户现场环境的千差万别，以及涉及研发，测试/技术支持，实施，终端用户多方参与人员等等，对于可能遇到的问题种类和数量，稍有经验的都应该会对此刻骨铭心。
针对"本地化部署"场景下的软件产品在使用过程中所遇到的问题，我们可以将其解决方案以逐级递进的方式划分为：
- 面对面沟通解决；
- 解决方案文档形式；
- 提供简单的可执行修复程序；最典型的如shell / bat脚本；
- 提供界面化的修复程序。
针对以上四种方案，本文尝试阐明一些基础性的认知，并且对其进行逻辑上的论证。因为在实际的工作过程中，我发现不同的团队，团队内部对其的理解千差万别，出现"问题解决慢，难以断根，问题改进缓慢"等诸多问题，进而造成软件产品在持续演进过程中质量问题无法被遏制，甚至隐约表现出下坡路的迹象。
2. 前置知识
正式开始介绍前，我们有必要先对几条基本理念达成一致，方便之后进一步的交流讨论。
2.1 软件产品赚的是规模效应的钱
首先我们要明确的一个基本理念是"软件是一个边界成本低的特殊商品"，相较于初始巨量资源的投入，后期的分发成本基本可以忽略不计。
2.2 虽然软件是群体分工协作的产物，但各岗位利益诉求存在显著差异
如果做出来的软件产品始终局限在有限的用户范围内，除了极少数的场景外，这类软件产品的生命周期肯定不会太长，那么依附于这个产品之上的从业人员，其职业生涯自然也会出现问题。
因此，上至公司，中至领导，下至一线从业人员，其实都是对于产品的规模效应有着一致的利益诉求的。只是对于不同的视野下，各方的感受程度不太一致：
- 对于公司和领导，明确直接的盈利要求被直接摆在面前，不由得你把脑袋埋进沙子里。
- 但对于一线从业人群，当制度无法将利益进行显著捆绑时，干多干少，干好干坏都不影响我拿这一个月工资，那大多数人的选择自然是顺着人性一路滑下去。
3. 化学反应
以下让我们针对不同的组合，探究下"四种方案"在不同环境下的表现：
3.1 "问题解决的四种方案" + “规模效应"
| 方法 | 优点(单个项目) | 缺点(单个项目) | 优点(规模效应) | 缺点(规模效应) | 补充说明 |
|---|---|---|---|---|---|
| 面对面沟通 | 解决问题速度快 | 知识无法沉淀，只保留在极少人头脑里；面临遗忘和单点依赖等风险 | 无 | 成本居高不下，效率低，且没有改进的空间 | 直接让研发与现场实施面对面，采取一对一的强联系的方式来解决眼前的问题 |
| 文档 | 无 | 对使用者要求较高（你抱怨对方看不懂文档的次数越多，说明你自己都认可对使用者要求高，所以不要语言上说什么要求不高，你的行动更有说服力） | 知识可以被沉淀，实现低成本复用；降低单点依赖风险 | 对于编写人员存在较高要求 —— 换位思考，长期维护等意识 | 无 |
| 脚本 | 隐藏问题和解决方案细节，大幅减少低级错误造成的浪费 | 编写脚本工作量较大 | 同"单个项目" | 对于编写人员存在较高要求 —— 换位思考，长期维护等意识 | 无 |
| 界面化配置 | 除了脚本的优点外，更为友好的用户操作体验，更少的低级错误产生可能性 | 编写工作量更大 | 同"单个项目" | 对于编写人员存在较高要求 —— 换位思考，长期维护等意识 | 无 |
以上四种方案还具有如下特点：
- 四种方案至上而下，对研发的要求逐级提高。
1.1 “面对面沟通”是最符合人性的 —— 想到什么直接上手干，有什么疑问直接开口问；突出一个即时满足，解决眼前问题就好。
1.2 相较于之下，"文档/脚本"等方案既要思考用户操作习惯，又要考虑各类系统的兼容性，更得时刻注意的文档/脚本实时性，这对脑细胞实在是太不友好了，累！ - 单项目模式下，四种方案至上而下成本是逐步增加的；但规模效应下却是反过来。
- 单项目模式下，位于前面的方案对于研发更为省力，尤其是当研发的职责中不包含文档这一项时 —— 研发只负责口诉问题解决方案，由专门的技术支持人员来进行文档编写。
- 由团队最终的选择来逆向推导，可以很清晰地分析出：绝大部分团队成员的认知里就是一个个项目这么干下去，规模效应压根不在其考虑范围内；即使规模效应出现，那我就一个人你能拿我怎么滴 —— 我又没闲着，我只要表现得在忙就行，忙什么无所谓。虽然规模效应是这些岗位存在的意义，但意义这玩意太长远了，考虑着太累。
3.2 "问题解决的四种方案" + “不同的利益诉求"
随着软件体量的扩展，以及规模效应之下，相应的团队里势必会产生更为细化的分工，例如一开始可能是由研发直面用户，然后慢慢分工出来测试，技术支持，实施等等岗位。
在本文探讨主题"四种解决方案"之下，以上的细分岗位可以进行归纳总结为两大类：研发和其他。
是的，此类场景下测试/技术支持人员/实施可以近似看作产品的最终用户，他们是有着相似的利益诉求 —— 产品最好没问题，如果出现问题希望能够尽快得到修复，越快越好。
| 职责定位 / 成本最低 | 单个项目 | 规模效应 | 补充说明 |
|---|---|---|---|
| 研发 | 面对面沟通 | 界面化配置 | |
| 其他 | 面对面沟通 | 面对面沟通 |
对于以上这个对比表格需要做一些解释：
- 对于各方而言，尤其是对于软件产品服务的提供方（研发/测试/技术支持等），基于眼前的短期利益而言，他们是和最终用户有着一样的利益诉求的 —— 直接面对面沟通方式解决掉眼前问题，方便快捷。
- 但是在规模效应的加持之下，解决方案的选择就开始产生分歧：
2.1 终端用户的诉求"尽快解决问题"造成其依然偏向选择"面对面沟通"方式解决问题 —— 有专人服务，不用承担导致问题可能进一步恶化的责任；而且我是掏了钱的，理应享受这样的待遇。
2.2 但是对于诸如研发/测试/技术支持这类的服务提供者，这个时候就不再是"面对面沟通是最优解"了，大量的用户解决问题的诉求，相较之下非常有限的支持团队，如果采用"面对面沟通"方式去解决，那公司商务的工作就只剩下跟客户道歉了。
4. 如何应对
"四种问题解决方案"在"规模效应"，"不同的利益诉求"的组合加持之下，团队需要形成一个健康的基础思想认知，以及相应的成熟处理流程体系。
4.1 基础思想认知
- 工作量不会消失，而只会转移。作为研发-测试-技术支持-实施这样链条体系而言，问题存在时间越长，离起始点越远，问题解决的成本也就越高，团队为此需要付出的代价也就越大。
- 行文至此，其实我们一直尝试将研发这个岗位从整个处理流程中单独摘出来进行讨论。如此操作的根本原因一来是我自身就是一个研发，拥有着相关切身感受；二来则是最根本的 —— 研发是最有希望改变这个"老鼠跑圈"死循环的，他们有这样的能力，现在是需要补齐这个认知和意愿。不能将应对单个具体实际项目这种低工作压力状态的思维，一成不变地应用到规模效应下的软件产品维护中。
- 四种解决方案，所体现的其实就是"个人利益和团队利益"，"短期利益和长期利益"，"过程负责还是结果负责"的抉择。
- 在"单项目"这种符合人性（目标明确，反馈迅速等）的低工作压力模式下，问题解决效率和成本要求势必不会太高；但是一旦规模效应开始发挥威力，效率和成本问题将不断直接拷问团队的极限，这个时候团队是选择迎难而上，锐志进取；还是抱着原有解决问题方式，"咱就这个效率了"；这必然导向两条截然相反的结局。
4.2 处理流程体系
针对以上"四种解决方案"在规模效应下的选择问题，这里我们跳过诸如"分析问题是否具备普遍性"等前置操作；直接进入"如果属于普遍性问题"时，四种方案的推荐选择如下：
- 面对面解决第一次
- 解决完问题之后开始编写注意事项说明文档，并且开始思考将文档进行脚本化。
- 随着相同问题的继续出现，持续优化文档和脚本，逐步将修复操作从文档过渡到以脚本执行为主 —— 注意这一步切换采取小步快跑的方式实现（内部以最快速度普及验证），以实现尽量快的切换。
- 待脚本稳定之后，视问题解决的ROI，考虑进行最后的“界面化的修复程序”选项。
演进过程中，研发负责持续跟进脚本/界面修复程序的正确运行，进行解决方案沉淀，实现脚本/界面修复程序的逐步智能化。其他岗位人员只负责执行程序并确认问题被修复，其他事情都不应该关心。如此来减少其他岗位人员对于该类方案的抵触，提升其使用意愿。
4.3 组织结构
这一步就比较务虚，而且本人这方面并没有多少经验，所以只做简单的总结。
- 组织结构调整。对于设计为规模效应的软件产品而言，其人员选择是一定存在比较高要求的，如果人员能力和职业素养存在较大的差异，建议直接进行替换。与其花时间培养，不如花时间寻找。
- 利益绑定。将软件产品的收益与团队成员的直接利益绑定，从制度上将"结果导向"和"职业素养"思维倒逼出来。
- 以固定的频率置换产品研发人员去参与实际项目。感受实际的项目压力，避免躲在温室里自嗨。
5. 一些"刺耳"的话
其实这篇行文完全不在我的计划里，而且在过往职业生涯里，我也一直都是按照"规模效应"场景来要求自己面对问题时候的思考；因此以上文字并没有进行长期的显性思考和总结。
不过最近一年多新的工作环境下的观察，使得我见证了另外的选择，这个选择让笔者难受，但细致思考分析却有着其合理性。
所以以下只是一些并不针对任何人的吐槽（将它们从大脑有限的内容里倒腾出来，留出空间给宝贵的逻辑思考）：
- 上面说的"问题解决慢整个处理链条上都跑不了"，这个其实就属于"结果负责"，但往往链条上的各岗位所秉承的却是"过程负责" —— "死道友不死贫道"，只要火不烧到我这里怎么都行的心态。至于全链条上的成本，嗯，只要不是我来承担就行呗。
- 对于当前由"实施-技术支持-测试-研发"所构造出来的问题解决层次体系，动不动就被轻易击穿前三者，而将问题露到研发这里来，研发自身觉得这种情况好受吗？
- 以上的问题我在不同的场合隐含地表露过，对方的第一反应是"又不是我的问题"，“你是不是在责怪我”？反应那是相当之强烈，远比"怎么快点解决这个问题"要急切得多。
- 对于研发，“不断抱怨实施/技术支持/测试人员不靠谱”这说明你并不信任他们；但在实际操作上采取的“文档大于脚本”解决途径似乎表面你又是信任他们的；这两个看着矛盾的操作底下其实是有着统一自洽逻辑的 — 尽快把包袱甩出去，出问题大家一起扛，实在没办法/甩不出去了再说。
- 文档之所以成为脚本/界面化修复程序/面对面沟通之外的首选：
5.1 规模效应下面对面沟通实在忙不过来，我又不能不解决，自然得找个方式。
5.2 脚本/考虑的因素太多，不如写个文档教材把责任甩出去，况且文档还不是由我来写，我只要出张嘴就行，还能显示优越感 —— 你们测试怎么连这个命令都不知道啊。
网友评论