这是鼎叔的第四篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本人专栏和公众号《敏捷测试转型》，更多原创思考文章陆续推出。
持续创新改进的能力，是区别卓越团队和优秀团队的分界线。
本文从测试团队为例，分享团队应该如何建设创新氛围。非测试团队同样可以参考本文的经验方法。不管是技术，产品，运维，还是行政，HR，财务，创新思考及实践可以无所不在。

大家对于测试团队的看法，通常离 “创新” 比较远，认为测试一般是严谨保守的，求稳为主，没有必要强调创新和变化。鼎叔的观点正好相反，测试/质量角色更应该鼓励创新行为，提供容忍创新失败的土壤。严谨保守的工作习惯往往带来更多不必要的浪费，这在日新月异的研发效能进化时代是挺危险的，一旦公司盈利形势严峻，必然要从测试成本开始削减。测试要有危机感并积极开始行动，而创新机制保障和相应氛围的激励，就是需要努力去做的。
下面分两个部分详细聊聊：健康的创新保障机制，培养成员的创新思维。

第一部分：健康的创新保障机制
健康的创新并不是经常脑爆，自由尝试各种想法，想法本身并不值钱，而团队的试错时间成本往往是巨大的。鼎叔认为健康的创新氛围建设包含这五点：打造研究型团队，创新项目管理，发挥个人意愿并和 OKR 挂钩，能力组合创新，营造出安全和幽默的氛围。

一，打造研究型团队，理论和实证并重
空想和科学创新的差别就在于此，一个宝贵想法稍纵即逝，即使把它公开提出来，距离产生确定的价值，还非常遥远。如果团队能够通过广泛学习相关理论和公式，对 “想法” 进行合理推导，并在具体项目活动中做对比实验，证实结论，那就可以有底气让创新的成果去普及，并获得更多的资金支持。具备领先力的理论水平非一日之功，需要长期的体系化学习和集体的思考碰撞。
对于一个潜在可以投资的好 “想法”，我们都要追问，有没有做过相关的理论调研和用户调查？对于打算投入人力的创新项目，我们也要追问，如何保障我们的理论是扎实的，团队如何提升相关的理论素养？哪些客观数据将证明创新的成功（足够吸引投资人）？

二，创新项目管理
创新项目和常规开发项目，还是略有不同，但是更能从敏捷项目管理的优点中受益。虽然公司和老板都是鼓励创新的，但是一旦创新机会窗口过了，或者业务压力突增，创新项目都是最容易被推迟或者中止的，因为它往往不在公司业务目标内（战略创新项目除外）。
如果我们集体认为，这个创新方向值得投资，作为项目运作，我们可以参考敏捷项目管理立项的流程，严肃立项，同时承诺提供一个大胆尝试的安全环境。
创新项目需要制定交付里程碑，比如什么时候可以展示 MVP（最小可交付价值的产品）或者初步技术方案，什么时候完成项目试点，什么时候全面推广，等等。
创新项目管理的上级干系人，定期参与成果演示会，提供专业建议，对高潜力高 ROI 的项目给予充分支持（可以追加资金和人力），对高成本低收益或者缺乏理论和数据证实的项目给予驳回。对于部门重要的创新项目，还会邀请技术委员专家们进行评审，给予帮助。

三，发挥个人意愿，和 OKR 挂钩
越是创新项目，越是进程要快，证明不可行时就快速换方向或者暂时放弃。
因此，参与创新项目的人，一定是要有强投入意愿的，最好也有相关的技术/经验基础，因为成功的创新概率很低，远低于日常业务中投入的成功概率。很多同学完成本职工作都倍感吃力，就不适合参加创新项目。
既然创新成功的概率这么低，为什么我们鼓励大家勇于参与创新活动，并纳入相应 OKR 目标？因为个人能力在创新活动中是提升最快的，团队创新更是如此。很多项目会失败，但是相关的专业见识留在了团队之中。
谷歌的工程师文化，就是把 20% 的工作时间由个人支配，完成本职分配工作以外的创新目标。这个机制成功地孵化了大量著名的产品和工具。因此，管理机制的支持，是保障创新氛围的基础。
针对对员工 OKR 内容，我会重点关注创新类投入的具体描述，不能只是空想，而是有具体做法和难度拆解的，可敏捷验收的 - 远期目标粗略，但近期目标更加详尽。

四，能力组合创新
创新想法之所以没有被其他人实现，往往是因为有门槛，而且是复杂的门槛，一个工程师形成单点的微创新已经不容易，要实现更大的创新成果，通常需要找到 1+1 大于 2 的突破口。这时 “员工能力分布视图” 就可以派上用场了，看看团队中什么人员可以火线调配，和现有人员进行能力组合创新，实现需求。例如：让自动化测试框架的高手和懂 AI 技术的工程师合作，做基于 AI 的自动化测试方案。或者，让精通协议和日志分析的工程师，和平台开发工程师合作，打造更易用的协议测试分析工具。

五，营造安全和幽默的创新氛围
安全和幽默看似不搭界的两个词，在创新氛围营造中是可以起到持续促进作用的。
安全，是鼓励员工大胆提出 “不靠谱” 甚至 “大逆不道” 的想法，从中找到创新更多的可能性，并鼓励员工对创新采取额外的行动，允许一定程度的失败和损失，创新成功是建立在大量失败的基础上的。
幽默，对于通常工作繁重和缺乏成就感的团队特别重要，让工作流程生动有趣，心情愉悦，也是重要的创新，它还能改变外界对质量团队的刻板印象。
测试团队检查产品质量的态度是很严谨的，但不代表我们不能理解产品取悦用户的 “幽默”，可以 case by case 地处理。比如，搜索某个不存在的日期的星座预言，就一定要返回 “输入错误” 这种死板提示么？采用幽默的预言结果未尝不可。

第二部分：培养创新思维并行动
创新思维是一种新想法或者新发明的概念化过程，这种思维是可以被刻意练习的，我们可以从下面这些角度来有意识的培养。

一，纵向思维和横向思维
纵向思维，是面对既定问题，先专注寻找答案，找到最合适和最正确的方法。
横向思维，是对现有的问题换一个角度进行反思（改变焦点），找到其他更合适的问题，产生新的解决思路。
举例：目前的问题- 测试执行的周期太长，如何引入高效的自动化测试方案？
纵向思维：有多种方法。找到更合适团队落地的高效测试工具；提测和执行等流程 OA 化；针对 DIFF 代码差异内容做自动化测试；接入高效的持续集成平台测试，等等。
横向思维：改变问题，测试完成的所有目标是否都必须？即，是否有必要完成所有的测试交付项，是否可以根据优先级允许有损发布？部分没有完成的测试项是否可以发布后继续测试和修复，下个版本再发布？

二，找到不同干系人关注的焦点
分析干系人的关注焦点，主要看WHERE（关注的范围）是否可以放大或者缩小，看WHY（关注的目的）想法可以达成什么样的目的。
举例一：浏览器的合作站点测试，产品运营组要求把日常测试站点数量提升三倍。
测试团队的关注焦点：任务优先级比较低，投入人力很有限，只能覆盖有限的网站层级（不超过 2 层），内容能正常打开，有限的运营商网络（三大运营商），有限的访问终端（TOP3 用户量最大的手机），用户活跃度最繁忙的时段，网站基本操作类型 OK，等等。
产品运营组的关注焦点：不能有黄赌毒和敏感信息，测试响应的时间越短越好，覆盖的站点数量越多越好，内容能访问就行。
对齐干系人关注焦点后，创新测试策略如下：引入众包用户进行内容众测，对各大合作站点进行不良内容举报，产品运营提供不良内容清单，清晰的分类定义，保证及时处理。内部测试团队大幅减少测试项和访问层级，关注访问接口可用性监控。

举例二：手机对战游戏的玩家投诉充值强化能力的效果不满意，有坑钱之嫌。
游戏数值平衡是产品策划人员精心调整的，测试团队从用户视角思考，为什么用户会投诉？有没有快速评估的简单模型，判断道具收费升级的效益是否合理？
通过测试组的多次脑暴，我们把用户关注的焦点简化为：花 100 块钱（升值某项技能），是否能带来对战胜率的合理提升？
因为早期的手机对战游戏画面比较粗糙，也没有那么大的社交影响力，所以道具本身的炫耀目的不是主要原因。那玩家充值的主要目的就是提高胜率了。
于是，我们根据 100 元充值放在每个不同的能力项上，也开发了模拟对战的自动脚本，统计前后的胜率变化；再进行搭配两个不同能力的充值，来对比胜率变化，绘制胜率对比的趋势图，最终代表用户给出结论：这个能力提升概率应该是正向的，而且不存在某个技能的充值效果过于废柴。

三，寻找替代方案
当你只有一个点子时，这个点子再危险不过了。
从现存的解决思路中，进行可替换方法的发掘，可以得到更多的解决手段。我们以 “如何做账户安全测试” 为例，看看可以找到哪些可替换的方法，如图所示：

四，质疑
质疑不是批评。
对于团队的例行做法、习以为常的目标，需多多思考：我们一定要这么做么？当初这么做的原因是什么？当初的原因仍然有效么？有其他的方法满足这个目的么？
用这种精神审视很多手头的工作，可能会找到很多浪费或者低价值的地方，也会增添了弹性交付的手段：
专职测试前必须完成开发的自测么？是否可以通过产品演示会来替代自测？
功能自动化测试都是有测试团队负责么？是否可以开发和测试共同完成自动化测试覆盖，并取消自测环节？开发交付合格的自动化脚本，测试做统一维护和将来的回归。
用例归档和缺陷归档一定要按照标准模版和详细格式入库么？是否可以用思维导图，体验旅程地图，语音（AI 识别成文字）等多种方式入库？

五，随机联想
作为一个学习型的组织，我们需要有例行的集体学习交流时间，内容不限于本业务内，可以是其他业务，其他技术领域，其他公司和行业，历史的经典，等等。
当我们在跨领域学习时，我们可以随机的联想到是否可以和当前工作的痛点发生化学反应，扩充我们的理论体系之树，这样我们经常会获得惊喜。
当我在学习架构师课程 “海量服务之道”，在资源严重受限时提供有损服务时，就会联想 “测试品质为什么不能（在一定前提下）有损交付？”，测试通过标准并不需要是雷打不动的。
当我在学习产品和设计课程，强调不要 “过度设计”，就会联想到测试设计也是一种设计，我们 “过度设计用例” 的情形经常会难以受控。
当我在学习商业投资课程时，提到的投资回报率、商业画布等知识，也会联想到，我们所有的自动化平台建设项目，也是一个商业投资，能不能用成熟的 ROI 公式和商业要素分析理论，去评估和改进我们的建设规划？

六，大胆假设
对于习以为常的规范，甚至是传统的 “价值观”，我们是否勇于假设：它并不总是正确的？
我们可以对不合理（没有明确断言标准）的 “测试项” SAY NO 么？
测试人员一定要写测试报告么？一定要处理代办测试流程么？一定要提交缺陷报告么？是否可以 “培养” 一个机器人代替他完成这些基础工作，工程师只用干预和优化结果即可？

持续的创新思维和积极地动手实践，会让团队的气场发生变化，一点都不夸张。

相关文章：聊聊测试工程师的核心能力模型 https://testerhome.com/articles/31408