扫码阅读
手机扫码阅读

聊聊如何建设团队的创新氛围

41 2024-01-30

这是鼎叔的第四篇原创文章。

行业大牛和刚毕业的小白,都可以进来聊聊。

持续创新改进的能力,是区别卓越团队和优秀团队的分界线。

本文从测试团队为例,分享团队应该如何建设创新氛围。非测试团队同样可以参考本文的经验方法。不管是技术,产品,运维,还是行政,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么?

测试人员一定要写测试报告么?一定要处理代办测试流程么?一定要提交缺陷报告么?是否可以“培养”一个机器人代替他完成这些基础工作,工程师只用干预和优化结果即可?

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

相关文章:聊聊测试工程师的核心能力模型

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483685&idx=1&sn=27996ba9b016972a33870d68dbc2a103&chksm=c24fb447f5383d515768df5f653b05652f9dee0a2cb366527722a0177ac0c9bba00569583e9b#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 4636
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线