与我合作的自由开发者工作指南
原文由 Michael Lynch 于 发布，订阅该博客
过去七年里，我一直在聘请软件开发者和其他自由职业者。虽然大部分代码都是我自己写的，但聘请其他开发者能极大地提升效率，让我有时间去处理业务的其他方面。
如果合作关系管理得当，与自由职业者合作会非常高效，但也有上百种可能出错的方式。最好的开端，是双方对合作关系达成共识。
下面的文档说明了作为自由开发者与我合作是什么样的体验。我会在发布的每一个开发岗位招聘中附上这份文档，并在合作开始后付费请合作者仔细阅读。它能吸引工作风格与我契合的候选人，并在录用后缩短上手时间。
我以 Creative Commons BY-4.0 协议发布这份指南，欢迎你复用或改编。
概述
本文档说明了我与自由开发者合作时所采用的流程和约定。
如果你在与我合作前阅读本文档，可以快速浏览，看看这种工作方式是否适合你。如果你在合作期间阅读本文档，请认真通读，并将阅读时间计入工时。
黄金法则
我希望以我期待被对待的方式来对待你。
沟通
我把有效沟通看得高于一切。
宁可过度沟通，也不要沟通不足。在分享解决方案时，最好能说明你为何选择这个方案，以及你尝试过哪些其他路径。
高效了结邮件
我主要通过邮件沟通。
我的邮件风格是 Cal Newport 所说的“以流程为中心”。简单来说，每封邮件通常代表一项任务或一个问题，我们的目标是用尽可能少的来回把问题解决。这要求我们双方都认真构思邮件内容，而不是为了清空收件箱就草率地回一封最快的答复。
糟糕的邮件往来
下面是一个虚构的糟糕邮件往来示例。自由职业者没有在一开始花时间想清楚自己需要哪些信息，而是一个接一个地零散提问。
自由职业者：图片格式你更倾向哪种？PNG 还是 JPEG？
我：PNG
自由职业者：尺寸应该是多大？
我：800x600px
自由职业者：在小尺寸设备上需要自适应缩放吗？
我：需要，在视口小于 768px 时，尺寸应为 400x300px。
高效的邮件往来
与之相对，下面这组邮件往来回答了同样的问题，但方式更有规划、也更高效。
自由职业者：想请教你对图片的偏好，能否告知以下几点？
- 格式（PNG 还是 JPEG）？
- 尺寸（像素）？
- 是否需要在小尺寸设备上自适应缩放？
我：感谢你考虑周全的提问！
- 格式请用 PNG。
- 视口小于 768px 时尺寸为 400x300px，其余情况下为 800x600px。
邮件回复时效
我期望邮件在一个工作日内得到回复。换句话说，如果我在周二下午 3 点给你发邮件，我期望在周三下午 3 点前收到回复。如果你还没有完整的答案，也请先回复确认收到，并告知预计何时能给出完整答复。
偶尔回复时间超过一天也可以，但应该是例外而非常态。你也可以对我抱有同样的期待。
会议
会议适用于那些用文字沟通效率低下或根本无法沟通的话题。但会议成本很高——它会打断专注、限制日程安排，所以我会尽量减少会议。
我用邮件来传达事实，用会议来进行互动式讨论。例如，如果我们要评审一份设计文档，就不需要在线一起阅读。我们可以事先各自读完，把会议时间留给实时讨论。
我每个月也会安排一到两次会议，只是为了轻松地见个面、聊一聊。只靠邮件沟通有时会让人觉得冷漠和紧张。
| 讨论话题 | 备注 |
|---|---|
| “我们能约个会来讨论这个项目的截止时间吗？” | 不合适：这是一个简单的问题，不需要开会。 |
| “我的下一个 pull request 你可能不太好审，能开个会我给你讲讲吗？” | 不合适：如果代码复杂到难以理解，开会不是解决办法。 |
| “我对新架构有个想法，能打个电话聊一下吗？” | 不合适：我更希望先看到文字说明，读完之后再讨论。 |
| “你的设计文档要求我们使用 Postgres，但我想了解一下其中的约束条件，并探讨其他选项。” | 合适：这是一个复杂的决策，很可能需要大量细碎的来回沟通，实时讨论会比邮件更高效。 |
| “你在代码评审中给我提过关于‘内聚性’的反馈，但我感觉我们还没完全达成一致，能约个会讨论一下吗？” | 合适：如果我们已经尝试过文字沟通但没有奏效，会议就是把问题谈清楚的好方式。 |
面试
我从不通过正式面试来做录用决定。
我会请你提供过往作品示例，或通过邮件问几个问题，但我最关心的是我们能否良好协作。如果你是合适的候选人，我会按你的正常费率安排一个范围很小的试做任务。人们通常把这种方式称为“以合约代替面试”。
如果我请你开始一个付费试做任务，即使之后我们决定不再合作，我也会为你的时间付费。唯一的例外是如果你没有诚意完成任务（例如，在一个编程任务上计费十小时却一行代码都没交付）。
事前准备
自由职业者最有价值的地方，在于尽量减少我监督工作所需的时间。这就要求在提问之前先做好功课。
你完全可以放心求助，但我希望你在力所能及的范围内先自行解决问题。如果实在无法解决，请告诉我你已经尝试过哪些方法。
不好的提问
- 我该如何在电脑上安装 Flask？
- 如何在 Google Docs 中链接到特定章节？
- 数字 443 在我们的服务器配置中有什么含义？
好的提问
- 我对需求文档第 3 节有些不理解，“client”指的是最终用户，还是 API 的客户端？
- 我尝试安装你的软件时，出现了错误提示
FooBarBaz。我已经重读了安装指南，也搜索了已有的 issue，但还是找不到原因。你知道问题出在哪吗？
工作时间
我不指望任何人一周工作超过五天。除非你另有说明，我会默认你周末不工作。
我周末和美国主要节假日不工作。周末你当然可以给我发邮件，但我会在下一个工作日才回复。我也会尽量避免在美国东部时间中午之前发邮件。
你可以自由安排工作时间，但我希望你的工作时间能与我的工作时间有部分重叠，我的工作时间是 10am-6:30pm ET。
我不要求你每周固定作息，但你的时间越可预测，我就越容易准备好与你时间相配合的任务和反馈。
反馈
在项目期间或结束后，我经常会主动征求反馈。自由职业者往往对改进流程或协作方式有很有价值的想法，只是有时在被直接询问之前不太好意思提出来。
我通常会问：
- 有没有什么改变能让工作更顺畅、更愉快？
- 有没有哪类工作你想多做一些？少做一些？
截止时间
我很少需要紧急交付，所以通常由你自己来设定截止时间。你需要对自己的截止时间负责，不需要我来提醒。
不要让截止时间悄悄过去却毫无消息。如果你告诉我周二美国东部时间下午 3 点前交付，到周二晚上还没收到任何消息，我会很焦虑。我会猜测你是完全忘了这个任务、需要从零开始，还是已经快完成了、几小时内就能交付。
如果你预计会错过截止时间，请告诉我。越早预警越好。最晚也应该在截止时间当天告知延迟。
一般来说，只要我能据此做出相应安排，延迟不是什么大问题。如果某个截止时间对我很重要，我会提前说明。
设定截止时间时，请使用精确、明确的时间表述：
- 还不错：我会在周五下班前发给你
- 更好：我会在 12 月 8 日美国东部时间下午 5 点前发给你。
- 不好：我过几天就能准备好。
- 太模糊。
- 很糟：准备好了我会告诉你。
- 极其模糊
时间盒
在我们合作初期，我会请你限制每周或每个里程碑的计费工时。这样做是为了在了解你的开发速度以及我们是否合拍的过程中控制成本。
如果你快达到上限但还无法完成，请留出时间整理已完成的工作，并通过邮件发给我，说明哪些已完成、哪些未完成，以及预计还需要多少小时。
超出约定工时上限的时间我将不予支付。
随着我们合作的深入，我会逐步提高或取消工时上限，给予你更多自主权。
文档
我非常重视文档。
如果项目有成文的流程或 GitHub 模板，请遵守。如果文档要求你做的事情看起来不对，请告诉我。不要想当然地认为说明已经过时或与你无关。
当你开始与我合作某个项目时，你就是其上手文档的新负责人。如果你因为文档写得不好或缺失而遇到阻碍，请提交修改来填补空白。
请认真为你编写的代码撰写文档。尽量让代码自解释，但对于代码本身无法表达的信息，请加上注释。新代码的注释详尽程度应与周围代码保持大致一致。
# Number of days per week (seven) <-- BAD comment
DAYS_PER_WEEK = 7
# This is a workaround for a bug in FooComponent, which crashes the process
# if we call it immediately after writing to disk. <-- GOOD comment
time.sleep(5)
代码质量
比起交付速度，我更看重质量和可维护性。
在实现可运行的代码后，再寻找简化或重构逻辑、让代码更直观的机会。如果多花一倍时间能让代码简化 30%，对我来说就是值得的。
代码评审
我会对所有代码变更进行彻底的评审，并提供详细的反馈。
我的评论不是为了批评你或让你难受。我严格评审是为了理解代码，并使其达到我可以长期维护的状态。
以下文章解释了我的代码评审流程：
代码风格
我的项目遵循 Google 的代码风格指南：
在可能的情况下，我会使用自动化工具来强制执行风格规范。
Git
我使用 Git 进行版本控制。你不需要是 Git 专家，只要了解基本操作即可：
- 克隆仓库
- 创建分支
- 提交
- 推送和拉取变更
- 变基提交（偶尔需要）
GitHub 权限
我遵循最小权限原则分配访问权限。如果你在我的某个公开仓库上工作，可以直接 fork 并开始提交 pull request，无需额外权限。
我使用的两个 GitHub 集成需要烦人的广泛权限：CircleCI 和 Reviewable。这两个应用都要求对你 GitHub 账号下所有仓库的写入权限。如果你不放心授予这些权限，就需要为与我合作的工作单独创建一个 GitHub 账号，以便授予这些工具完整访问权限。
提交规范
有些开发者认为每一次提交都美好而神圣。我不这么认为。
对我来说，重要的是 main 分支要有清晰合理的提交历史。在其他所有分支上，你想怎么提交都行。你可以针对每一条评审意见提交一次，也可以一次性提交所有修改。用哪种工作流都可以。我使用 GitHub 的 squash and merge 功能，所以每个 pull request 最终都会压缩为一次提交。
如果你提交的 pull request 包含多次提交，我会阅读 pull request 的标题、描述和评论。我不会逐一查看每次提交，因为我默认那只是你的中间过程。文章 “How to Write a Git Commit Message” 描述了我偏好的贡献记录风格，只不过我要求的是应用于 pull request，而非单次提交。
测试
创建 pull request 时，你有责任确保所有测试在持续集成中通过。在提交代码供我评审之前，请先修复任何构建失败。
如果你新增了功能或改变了行为，请更新自动化测试以覆盖新行为。
如果你修改的功能难以通过自动化测试，请手动测试该功能以验证新代码。如果实在找不到测试方法，请在提交评审时提醒我这部分未经测试（这种情况应该极其罕见）。
计费工时
我认为你为与我合作所做的几乎所有事情都属于可计费的工作。
可计费工作示例
- 与我沟通（包括邮件、视频会议和面对面会议）
- 阅读我要求你阅读的文档（包括本文档）
- 研究与工作相关的技术或方法
- 散步思考复杂问题
不可计费工作示例
- 因为与工作相关就把一整本书从头读到尾
- 读一章是可以的。
- 因为硬盘损坏而修理工作电脑
- 选购新的人体工学椅
费用
我期望你自行提供作为自由开发者开展工作所需的基本工具（例如电脑、网络、电费）。
对于任何能让工作更高效或更愉快的软件、服务或设备，我很乐意承担费用，只需事先征得我同意。
如果我请你购买与工作相关的物品，我会在下一张账单中为你报销。
监督
我相信你会如实申报工时。我永远不会要求你“证明”工时，也不会要求你在系统上安装任何监控软件。
如果我们在 Upwork 这类内置监控功能的平台上合作，我会始终将监控功能设为可选。除非工时出现严重不符，否则我不会查看监控数据。即使出现这种情况，我也会在查看数据前先与你沟通。
进度更新
很难精确规定多久汇报一次进度，这需要一定的判断。
对于范围明确的任务，例如已经充分理解的功能开发，每 8 到 10 个计费工时分享一次进展即可。对于范围不确定的任务，例如缺陷排查或需要尝试探索的功能，争取每 2 到 4 个计费工时更新一次。无论如何，未更新状态的最长时间不应超过 3 个计费自然日或 10 个计费工时，以先到者为准。
分享进度最好的方式是通过能体现进展的 pull request。理想情况下，你可以拆出一部分已完成的工作形成一个完整的 pull request；如果不行，也可以分享一个 pull request 并标记为“draft”，表示仍在进行中。在排查缺陷期间分享进展时，请更新 GitHub issue，总结你已排查的内容和收获。
如果你想就工作的一些宏观问题进行私下讨论，可以通过邮件联系我，但请尽量将讨论保留在 GitHub 上。
付款
请每两周为你的工时向我发送一次账单。预计在收到账单后的五个工作日内付款，通常会更快。
我不支付奖金或小费。我希望你的报酬是透明的，不必去猜测那些由我酌情决定的不确定收入。
我会根据你的偏好，通过 PayPal、Payoneer、ACH 转账（仅限美国）或邮寄支票（仅限美国）付款。
合约结束后的工作
合约结束后，我绝不会再就你的工作提问或要求免费修改。在合约期内确认你已交付我要求的所有内容，是我的责任。
如果我在付款后发现你工作中的问题，我会自行修复，或向你提供额外的计费工时来处理。
税务
如果我在单个日历年内向你支付超过 600 美元，出于税务需要，我会需要一些表格。
知识产权
如果我们在某个项目上合作且我希望保留知识产权，我会向你发送一份电子签署的合同，其中声明我将购买你为我编写的代码的版权。
该合同仅涉及我付费请你完成的工作，不包括你在付费工时之外创作的任何内容。
封面插画：Loraine Yow。
你是客户还是自由职业者？我很想看看类似的文档，或听听其他人是如何处理这个问题的，欢迎在评论区分享。
评论
登录后参与讨论