2 篇博文 含有标签「quality」

ServiceNow 客户运营总裁 David Schneider 分享了针对旨在实现超大规模的 SaaS 公司的销售绩效指标。在过去的 5 个季度中：

• • 总合同价值达成率
  • 总管理（ACV、续订、PS）
• • 净新增 ACV 达成率
  • 销售配额达成率
  • 季度增长
  • 年度增长
• • 累计新增客户总数
  • 新客户（包括损失）
• • ACV 重复客户百分比与净新增客户的比率
• • 累计净客户总数
  • 新客户
• • 上岗代表数量
  • 每位销售代表的平均生产力
  • 销售代表年化流失率
  • 总销售年化流失率

上桌玩牌要有足够的筹码 —— 招聘足够数量的高水平人才，这些人才要足够重视质量、足够聪明。你要向她们反复强调公司重视质量的文化，形成正式的惯例检验大块工作，该修的修。

战术上，有这样一条最佳实践 —— 降低做正确事情的难度。Stripe 技术团队做出了各种各样的取舍，以便能够保证任何工程师都能够改进系统的任何部分。鼓励责任感（ownership）。

有专门的内部工具检查国际化的水平，很无聊，但是得花时间做。要注意，这又回到了公司的文化问题，当一个做这件事情的 IC 说：“我上周花了一些时间做 i18n ” 的时候，他应该会默认，领导层足够重视这件事情，以至于会回答说：“当然你花了时间做了这件事情，棒棒哒。”

“开个工单给相应的组，会有相应的人来处理” 是个好实践，但是如果你能够推动这个系统更快更好地把这个工单修掉，你就更能够激励人去开工单。

公司会给专门的途径，比如邮件组的别名，来上报产品的质量 bug。有专门的组来 triage 这些任务，或者把任务分配到合适的组来修，有专门的惯例告诉整个公司质量 bug 的修复速率。

在做重大 API 变化之前，既要做内部测试，也要做外部测试。经常问一下“谁有一个真真正正的 Stripe 账号在手头？能不能更新到 beta 版本试一下？” 人们需要专门抽出时间来做这件事情，并且详尽地记录下来形成文档 —— 想象一下，你有一群挑三拣四的客户，虽然你很可能无法像用户那样深入地、广泛地使用自家的产品，但是这样做已经比瞎猜要好很多了。

发现“一块支付代码 5 年没有碰过了，不知道它是怎么工作的，竟然没有测试”，这种情况虽然很少见，但是对于工程团队来说，是宝贵的财富。

以上所有都不是什么高科技，也都不是能够保证质量的充分条件。Stripe 从来都不会满足当下的质量水平，不会被动地说说“我们的标准很高”，而是保持“主动地一直在去做”。