跳到主要内容

3 篇博文 含有标签「engineering」

查看所有标签

ADR 模板

· 阅读需 3 分钟

ADR 代表架构决策记录,是一个迷你文档,用于捕捉不值得完整设计文档的重大架构变更。

# [已解决问题和解决方案的简短标题]

* 状态: [提议 | 拒绝 | 接受 | 废弃 | … | 被 [ADR-0005](0005-example.md) 取代] <!-- optional -->
* 决策者: [列出所有参与决策的人] <!-- optional -->
* 日期: [YYYY-MM-DD 最后更新决策的日期] <!-- optional -->

技术故事: [描述 | 票据/问题 URL] <!-- optional -->

## 背景和问题陈述

[描述背景和问题陈述,例如,使用两到三句话的自由形式。您可能想以问题的形式阐明问题。]

## 决策驱动因素 <!-- optional -->

* [驱动因素 1,例如,力量、面临的关注等]
* [驱动因素 2,例如,力量、面临的关注等]
*<!-- 驱动因素的数量可以变化 -->

## 考虑的选项

* [选项 1]
* [选项 2]
* [选项 3]
*<!-- 选项的数量可以变化 -->

## 决策结果

选择的选项: "[选项 1]",因为 [理由,例如,唯一满足关键标准的选项 | 解决了力量问题 | … | 最佳结果(见下文)]。

### 积极后果 <!-- optional -->

* [例如,质量属性满意度的提高,需要后续决策等]
*

### 消极后果 <!-- optional -->

* [例如,妥协质量属性,需要后续决策等]
*

## 选项的优缺点 <!-- optional -->

### [选项 1]

[示例 | 描述 | 更多信息的指针 | …] <!-- optional -->

* 好,因为 [论点 a]
* 好,因为 [论点 b]
* 坏,因为 [论点 c]
*<!-- 优缺点的数量可以变化 -->

### [选项 2]

[示例 | 描述 | 更多信息的指针 | …] <!-- optional -->

* 好,因为 [论点 a]
* 好,因为 [论点 b]
* 坏,因为 [论点 c]
*<!-- 优缺点的数量可以变化 -->

### [选项 3]

[示例 | 描述 | 更多信息的指针 | …] <!-- optional -->

* 好,因为 [论点 a]
* 好,因为 [论点 b]
* 坏,因为 [论点 c]
*<!-- 优缺点的数量可以变化 -->

## 链接 <!-- optional -->

* [链接类型] [链接到 ADR] <!-- 示例: 由 [ADR-0005](0005-example.md) 精炼 -->
*<!-- 链接的数量可以变化 -->

SaaS 销售绩效指标

· 阅读需 1 分钟

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

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

Patrick McKenzie: 为何 Stripe 的工程质量如此之高?

· 阅读需 4 分钟

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

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

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

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

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

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

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

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