从自由职业者到工作室：准备第一次工作交接

选择能够清楚描述的工作单元

不要只说“帮我处理客户”，而应选择可审核的结果，例如根据已经批准的信息准备六份商品资料。明确什么输入启动工作、什么文件代表完成，以及哪些部分仍由你负责。如果必须讲完整个创业故事才能解释任务，范围可能还需要缩小。

这是运营练习，并非建议某一种雇佣安排。扩大产能前，先检查服务是否已经定义清楚。本站服务验证指南讨论需求与交付假设；本文讨论如何把选定任务交给另一人。

提供可以直接使用的起始资料

在虚构案例中，资料包包括商品表、一份已批准的样例、允许使用的图片、格式说明和缺失信息清单，不包括通过聊天分享的密码或其他客户文件。只提供任务必需的访问权限，并说明现行版本保存在何处。

开始前，请执行者指出一项缺失输入。如果商品尺寸未知，流程应允许标为待确认，而不是编造。批准过的样例展示具体判断，并不意味着所有新情况都完全相同。

分开执行、决定与审核

GitLab 手册描述了对活动承担责任的个人。我们参考其中的区分：明确承担责任与参与工作不是一回事。对小任务，写清谁准备成果、谁处理范围问题、谁批准结果。

在虚构商品案例中，协作者可以修正格式并指出事实矛盾；创办者决定范围变化，并向客户询问缺失事实。双方都不能未经工作量检查就承诺新期限。还要写清审核者不在时由谁处理。

在仍容易调整时进行第一次审核

不要等六份资料全部完成，才发现对样例理解不同。先约定审核一份有代表性的记录，再完成整组。把结果与任务说明对照，指出缺失规则，而不是只说“这不是我想要的”。

Atlassian 提供了明确合作方式的工作约定练习。我们的改写是一段简短讨论：问题通过什么渠道提出、何时能回复、何处审核、如何报告阻碍。约定必须放得进真实日程，本站工作日规划指南可以帮助预留时间。

填写这份交接记录

• 预期结果：能够接受审核的文件或状态。
• 输入：现行来源、批准样例与允许使用的材料。
• 自主决定：执行者可以自行解决什么。
• 升级问题：哪些事项继续前必须咨询。
• 中间审核：检查哪个样本，由谁审核。
• 结束条件：标准、交付位置与已声明的待办问题。

先使用一个获准处理的真实案例填写和试用，再推广到所有任务。执行期间指令改变时，记录新版本以及需要知情的人。这是本站原创工作辅助材料，不是流程认证。

既评估成果，也评估协调

结束时记录更正、反复出现的问题，以及实际观察到的协调时间。不要把所有返工归因于新人，它也可能说明输入缺失或标准从未被解释。同样，一次顺利交付不能证明长期产能。

下一次任务前，修改一项造成困惑的指令或样例。如果调整影响客户承诺，通过约定渠道说明。本站提案跟进指南可以帮助保留背景与下一步。当必要决策不再依赖猜测时，工作室才开始像团队一样运作。