Registra qué cambia, qué depende de ello y quién debe decidir. La petición pasa a formar parte del trabajo cuando su alcance y sus condiciones quedan acordados.
Localiza la versión de referencia
Antes de estimar el esfuerzo, reúne el encargo aprobado, sus entregables y las aclaraciones aceptadas después. Identifica qué versión está utilizando el equipo y cuál tiene el cliente. Si hay diferencias, resuélvelas primero: evaluar una nueva petición sobre documentos distintos produce dos respuestas aparentemente razonables.
Atlassian explica la línea base de un proyecto como una referencia para comparar el plan y sus cambios. En un servicio pequeño puede bastar un documento fechado con alcance, responsables y pendientes. Mantenerlo accesible ayuda a conversar sobre una referencia común.
Describe el cambio con un antes y un después
En un ejemplo ficticio, un estudio acordó preparar cuatro páginas de un catálogo a partir de textos aprobados. El cliente pide incluir una segunda versión por mercado. Anota si se trata de traducir, revisar información diferente o producir otra selección de productos; esas opciones requieren trabajos distintos aunque el mensaje inicial parezca breve.
Escribe una frase de antes y otra de después: “Una edición con cuatro páginas” y “Dos ediciones con diferencias aún por definir”. Añade el motivo que comunica el cliente. Una corrección para cumplir lo ya acordado debe distinguirse de una petición que amplía el resultado; revisa el caso antes de clasificarlo.
Revisa los efectos sobre el conjunto
- Entradas: qué información o materiales nuevos se necesitan.
- Trabajo: qué parte se conserva, se adapta o se rehace.
- Dependencias: qué revisión, proveedor o entrega espera ese cambio.
- Condiciones: qué fechas, recursos o acuerdos necesitan reconsiderarse.
- Decisión: quién puede aceptar la nueva versión y qué falta para hacerlo.
La orientación de Atlassian sobre control de cambios separa la solicitud de su evaluación y aprobación. Aquí proponemos una ficha ligera para hacer visibles esas preguntas. Si todavía falta un dato importante, conserva la estimación como provisional e identifica la condición que podría modificarla.
Ofrece una respuesta que permita elegir
Una respuesta ficticia puede decir: “Podemos mantener la edición acordada y preparar después la segunda, o revisar las dos juntas cuando tengamos los textos por mercado. Necesitamos decidir cuál de estas rutas prefieren antes de confirmar el nuevo calendario”. Explica qué conserva y qué modifica cada alternativa.
Conserva por escrito la decisión y sus condiciones en el canal acordado. Una petición recibida y una alternativa enviada son estados distintos de un cambio aceptado. La guía de seguimiento de propuestas ayuda a retomar una decisión pendiente con contexto.
Actualiza la referencia que usa el equipo
Cuando se acuerde el cambio, registra la nueva versión, qué reemplaza y qué continúa vigente. Avisa a quienes producen, revisan o esperan la entrega. Comprueba si un archivo anterior sigue circulando y dónde debe consultarse el documento actual. La explicación puede ser breve si permite reconocer la diferencia.
La ficha de traspaso de tareas sirve para trasladar las nuevas entradas y criterios a otra persona. Actualiza también la muestra que se revisará y el punto de aprobación si cambió la forma de entregar. Una instrucción corregida en tu ordenador todavía necesita llegar a quienes trabajan con ella.
Cierra el cambio con una observación útil
Al terminar, compara lo previsto con lo que realmente exigió el cambio: material faltante, revisión adicional o una dependencia que no estaba visible. Guarda esa observación junto con el cierre. Si varias peticiones repiten la misma duda, aclara el alcance de futuras propuestas o prepara una opción específica.
Nuestra guía de validación de servicios ayuda a revisar supuestos de entrega. El registro de cambios aporta evidencia de esos supuestos durante el trabajo. Su utilidad está en conservar decisiones y aprender de casos concretos, sin convertir una sola experiencia en una regla para todos los clientes.
When a Client Requests a Change, Return to the Agreed Scope
“It is a small change” might mean fixing a typo, adapting a deliverable or adding another outcome. A clear response begins by comparing the request with the version of the work both parties are using.
Record what changes, what depends on it and who must decide. A request becomes part of the work when its scope and conditions have been agreed.
Find the reference version
Before estimating effort, collect the approved brief, deliverables and later accepted clarifications. Identify the team’s version and the client’s. Resolve differences first: evaluating a new request against different documents produces two apparently reasonable answers.
Atlassian describes a project baseline as a reference for comparing the plan and its changes. For a small service, a dated document with scope, owners and open questions may suffice. Keeping it accessible supports a conversation around one shared reference.
Describe the change with a before and after
In a fictional example, a studio agreed to prepare four catalog pages using approved text. The client asks for a second version by market. Record whether this means translation, different information or another product selection; these involve different work despite the brief initial message.
Write one before sentence and one after sentence: “One four-page edition” and “Two editions with differences still to be defined.” Add the client’s stated reason. A correction needed to meet the existing agreement should be distinguished from a request expanding the outcome; review the case before classifying it.
Review effects on the whole
- Inputs: what new information or materials are needed.
- Work: which parts remain, change or need redoing.
- Dependencies: which review, supplier or delivery waits on the change.
- Conditions: which dates, resources or agreements need reconsideration.
- Decision: who can accept the new version and what is needed first.
Atlassian’s change-control guidance separates a request from evaluation and approval. Our lightweight record makes these questions visible. When important information is missing, retain a provisional estimate and identify the condition that could change it.
Offer a response that supports a choice
A fictional reply might say: “We can retain the agreed edition and prepare the second afterward, or review both together once the market-specific text is available. We need to choose a route before confirming a new schedule.” Explain what each option preserves and changes.
Keep the decision and its conditions in writing through the agreed channel. A received request and a proposed alternative are different states from an accepted change. Our proposal follow-up guide helps revisit an open decision with context.
Update the reference used by the team
Once agreed, record the new version, what it replaces and what remains in effect. Tell the people producing, reviewing or awaiting delivery. Check whether an old file is still circulating and where the current document belongs. The explanation can be brief if it makes the difference recognizable.
Our task-handoff record helps pass new inputs and criteria to another person. Update the review sample and approval point if delivery has changed. An instruction corrected on your computer still needs to reach everyone working from it.
Close the change with a useful observation
At completion, compare expectations with what the change actually required: missing material, additional review or an unseen dependency. Keep the observation with the closure record. If requests repeatedly expose the same uncertainty, clarify future proposal scope or prepare a specific option.
Our service-validation guide helps review delivery assumptions. A change record supplies evidence about those assumptions during the work. Its value lies in preserving decisions and learning from concrete cases without treating one experience as a rule for every client.
客户提出变更时，先回到已经约定的范围
“只是小改动”可能是修正错字、调整交付物，也可能是增加另一个结果。清楚回应之前，应先把请求与双方正在使用的工作版本比较。
记录改变什么、影响哪些依赖以及由谁决定。范围与条件达成一致后，请求才成为工作的一部分。
找到共同参考版本
估算工作量之前，收集批准过的任务说明、交付物，以及后来接受的澄清。确认团队和客户分别使用哪个版本，先解决差异。基于不同文件评估新请求，会产生两个看似合理的答案。
Atlassian 将项目基线说明为比较计划与变化的参考。小型服务可以采用注明日期、范围、负责人和待办的文件。让文件容易查阅，有助于围绕共同依据讨论。
用变更前后描述请求
虚构案例中，工作室约定根据已批准文字制作四页目录，客户后来要求按市场再做一个版本。应记录究竟是翻译、不同信息审核，还是另一组商品选择。初始消息虽然简短，不同解释对应的工作却不同。
分别写一句变更前与变更后：“一个四页版本”和“两个版本，差异仍待定义”，再补充客户说明的原因。为满足既有约定而作的修正，与扩大结果的请求需要区分，先核对案例再分类。
检查对整体工作的影响
- 输入：需要哪些新资料或材料。
- 工作：哪些保留、调整或重做。
- 依赖：哪些审核、供应商或交付等待变更。
- 条件：哪些日期、资源或约定需要重新考虑。
- 决策：谁能接受新版本，此前还缺什么。
Atlassian 的变更控制说明区分请求、评估与批准。我们的轻量记录让这些问题可见。缺少重要信息时，应把估算保留为暂定，并指出什么条件会使它改变。
提供能够帮助选择的回应
虚构回复可以是：“我们可以先保留已约定版本，再做第二版；也可以等各市场文字齐备后一起审核。确认新日程前，需要先决定采用哪条路径。”说明每种方案保留与改变什么。
通过约定渠道书面保存决定与条件。收到请求、提出备选方案，与接受变更是不同状态。本站提案跟进指南帮助带着背景重新讨论未决事项。
更新团队使用的参考文件
达成一致后，记录新版本、替代什么、哪些仍有效。通知制作、审核或等待交付的人。检查旧文件是否仍在流传，以及现行文件放在哪里。只要能辨认差异，说明可以简短。
本站任务交接记录可以把新输入与标准传递给他人。如果交付方式变化，也要更新审核样本和批准时点。仅在自己电脑上修正指令，还需要把它传给实际使用的人。
用具体观察结束变更
结束时比较原先预期与实际需要：缺失材料、额外审核，或之前没发现的依赖。把观察与结束记录保存在一起。如果多次请求暴露同一疑问，应澄清未来提案范围，或准备专门选项。
本站服务验证指南帮助检查交付假设。变更记录提供执行过程中的证据，其价值是保留决定并从具体案例学习，不把一次经历推广到所有客户。
Fuentes y método
Fuentes consultadas el 18 de octubre de 2026. Los escenarios y cifras ilustrativos son ficticios. Las fichas y ejercicios son propuestas editoriales originales, sin resultados de clientes ni pruebas de proveedores atribuidos. Editorial standards · Disclosures.
