硬件设施服务数字化转型解决方案_影石Insta360：如何创造无限可能？

从需求池管理到迭代开发、缺陷跟踪，影石数字化管理师实现了向 Teambition 的迁移。在敏捷 Scrum 规范和 Teambition 的加持下，产品经理专注于价值挖掘、产品调研、竞品分析，开发专注于写代码，版本从提测到上线的时间也由 3 周缩短到了 3 天，有了颠覆性的变化。

 

 

影石创新科技股份有限公司

盲盒开箱、周末出游、美食探寻……自媒体的蓬勃发展让记录和分享日常变得简单，一部手机、一条 Vlog 即刻记录当下的感受与见闻，让瞬间变成永恒。有一群人，他们热衷于挑战极限运动，他们热爱最大胆、最疯狂的创意和想法，他们不断尝试、把别人口中的不可能变成可能。为了用极致的影像来帮助他们捕捉每一刻的精彩，影石Insta360诞生了。

七年来，影石不断推出创新影像产品，拿下 41% 的全球全景相机市场占有率，打破日本理光、美国 Gopro 等国外影像巨头垄断行业的旧格局，将产品销往 200 多个国家和地区，成为全景相机领域“天花板”。从马尔代夫福阿穆拉环礁 10 多米的水下深处，到珠穆朗玛峰 8848 米海拔的雪山顶，都留下了影石用户打卡的踪迹。

如此一家发展势头强劲、注重技术创新的企业，是如何提升研发团队效能的呢？一番追溯后，我们发现影石在创立之初就开始了和 Teambition 的缘分。软件项目管理负责人 Seven 担起从 0 到 1 建设敏捷项目管理体系的担子后，影石和 Teambition 的合作又向前迈进了一步。Seven 个人做事推崇极简，认为敏捷改造需要的是一个重视交互、简洁高效的工具而不是一个面面俱到的工具，这一点和 Teambition 的理念不谋而合，而且和同类产品相比，Teambition 在核心功能、易用性、可扩展性、数据安全、售后、价格等维度的表现也更符合影石的诉求。

 

Teambition 可以将所有人的工作量化、将模糊的任务可视化、将开发进度在任务看板的切割下变得透明而易于消化，无论一个项目多么复杂、无论每个成员多么不同，Teambition 都能让他们连接并运转起来。

—— 刘靖康影石创始人

 

痛点

需求全部记录在本地文档上，研发任务靠口头传递，Bug 依托其他平台来管理，隐性沟通成本高。

版本说明记录的内容往往较粗略、晦涩难懂，任务流转难。

仅用“好一些”、“差一些”之类的词语来形容工作成果，不能为日后的工作提供具体指示。

 

解决方案

钉钉项目：简洁易懂、可视化的统一作业平台，承载起所有的需求、任务与 Bug。

钉钉项目：各方精准对齐，减少主观臆测，低成本获取可视化、数字化、高价值的信息。

钉钉项目：量化过程指标，丰富考核维度，实现研发效能翻倍提升。

 

01｜统一平台：需求、任务、Bug 集中管理

研发管理上线后，Teambition 助力影石完成了最核心应用——Insta360 APP 的敏捷改造。Insta360 APP 是协同相机硬件为运动发烧友和摄影爱好者提供的创作工具，可以用来拍摄和剪辑视频并提供丰富的剪辑素材。曾经，APP 的需求全部记录在本地文档上，研发任务靠口头传递，Bug 依托其他平台来管理，一座座无法串联的信息孤岛给研发团队带来了很高的隐性沟通成本，致使版本从提测到上线需要花费 3 周的时间，迭代周期和进度也不可控。

Teambition 为影石提供了简洁易懂、可视化的统一作业平台，承载起所有的需求、任务与 Bug。研发团队梳理出【产品 Brief—业务价值评审—技术可行性评审—Ready 需求池】这一需求工作流，以故事卡为单元拆分需求池中的需求，再把故事卡放到迭代里，让项目呈现出一个渐进明细的过程。通常来说流水线越往后，被卷进来的资源就越多，处理异常需要耗费的成本就越高，影石基于 Teambition 构建的这一套流程实现了集中管理、质量左移，让坏消息早点传出来，把异常卡在前期。

 

 

 

02｜卡片流水线：任务高速流转

以前，开发虽然也会写版本说明，但记录的内容往往比较粗略、晦涩难懂，导致测试经常要问开发“你提交了哪些内容？”“我要测试什么？”现在影石借助 Teambition 的工作流和卡片呈现出横向的流水线和纵向的泳道，用低成本获取可视化、数字化、高价值的信息。开发和产品精准对齐，减少主观臆测，避免投入最终成为沉没成本；QA（质量保证工程师）不用问任何人，自助查询 Ready for QA 状态下的卡片就能知道开发提交了什么内容；产品经理也可以通过查看卡片所处的状态来判断某个功能的开发进度；当某一个状态内堆积的卡片过多时，项目经理就明白这是该他上场催节奏的时候了。状态维护便捷，信息不言自喻。

 

 

03｜量化过程指标，落地敏捷研发

作为软件项目管理负责人，Seven 希望可以恰到好处地量化过程指标，既不要钻到细节里去增加无谓的统计成本，也不要和以往一样仅用“好一些”、“差一些”之类的无法横向或纵向比较的词语来形容工作成果，因为这些词语并不能为日后的工作提供具体的指示。换言之，Seven 希望把过程指标精简控制到“非要不可”的程度。

量化指标分为上线前的指标和上线后的指标，上线前的指标主要看“快”和“好”。所谓的“快”即速度指标，一方面可以用 Teambition 的燃尽图查看故事卡有没有跟着基准线推进并预测剩余工作是否能按计划完成；另一方面还能用迭代开始前的计划工时和封版后的实际剩余工时来计算人均生产力。所谓的人均生产力即每人每天能够产生多少可以直接上线的需求，比如一个工程师工作一天能产出 0.3 人天可以直接上线的需求，那就代表剩下的 0.7 人天被 Debug 和其他杂事占用了。如果人均生产力突然下降，就需要分析是迭代变更太多、在讨论中消耗了隐性成本还是杂事太多影响了开发工作。

 

 

所谓的“好”就是 Bug 少，毕竟在 Bug 比较多的情况下，即便通过打补丁、调代码等各种方式去解 Bug，代码的稳定性也会受到影响。影石在 Teambition 实现敏捷开发后，用统计功能提取迭代周期内新增的 Bug 数和迭代消耗的实际工时数（工时按「天」录入），计算得出 1 人天需求产生的 Bug 数，实现研发效率的人天考核数值翻倍提升，向行业优秀水平迅速迈进。

版本上线后考验的则是开发团队与测试团队对软件质量的控制水平，即缺陷逃逸率。假定迭代周期内发现了 26 个 Bug，迭代版本上线后发现了 5 个 Bug，则缺陷逃逸率 =5÷（26+5）。之所以要考核这个数据是因为 Bug 就像是雪球，会越滚越大，越往后被卷进来的资源就越多，版本上线后还会把用户也卷进来，重大的 Bug 甚至会影响品牌口碑。这项数据同样可以用 Teambition 的统计功能提取，PM 新建自定义图表后按迭代筛选缺陷的数量，在筛选条件中添加执行者还能对特定成员的缺陷逃逸率进行计算，丰富考核维度，结果一目了然。

 

 

从需求池管理到迭代开发、缺陷跟踪，影石实现了向 Teambition 的迁移。在敏捷 Scrum 规范和 Teambition 的加持下，产品经理专注于价值挖掘、产品调研、竞品分析，开发专注于写代码，版本从提测到上线的时间也由 3 周缩短到了 3 天，有了颠覆性的变化。影石创始人刘靖康也曾谈到：“ Teambition 可以将所有人的工作量化、将模糊的任务可视化、将开发进度在任务看板的切割下变得透明而易于消化，无论一个项目多么复杂、无论每个成员多么不同，Teambition 都能让他们连接并运转起来。”