开工前把问题委托写清楚：需求、价值与交付边界

团队接到一个任务，马上讨论怎样完成，后来才发现任务本身描述了一个预设方案。负责人要求开发课程，实际困难可能在支持路径；要求增加系统，实际缺口可能在责任与口径。快速执行当然重要，但执行错误的问题也会快速消耗资源。

知行社为教练家平台整理这篇文章，讨论一份能够支持共同工作的“问题委托”怎样形成。旧论坛材料关注问题定义过程，本篇将重点放在需求、价值、背景与交付边界的澄清。它不同于原因调查，也不同于方案设计：先让发起人和解决者理解究竟需要改变什么，什么条件下才值得投入。

需求先描述结果，不锁定手段

发起人可以说明谁遇到什么困难，希望形成什么状态。例如，成员在接收任务时不能判断当前优先级，希望能够获得一致的要求与确认路径。不要只说需要一场沟通培训，因为培训已经是候选手段。

结果描述需要具体情境，也要承认控制边界。团队可以提供清楚信息，不能保证所有关系立即改善；可以形成支持条件，不应承诺每个人永久留任。目标过度宽泛，会让解决者承担无法判断的责任。

对同一需求，相关者可能理解不同。先分别听取，再说明目前采用的范围与理由。定义不要求所有人立即满意，但不能把发起人的语言当成已经共同确认。教练帮助看见差异，使后续委托更清楚。

价值判断：为什么现在值得处理

不是每个不方便都需要项目。可以比较问题对服务、质量、协作与组织方向的影响，以及不处理会怎样。已有任务与资源同样需要考虑。价值不是把问题说得更严重，而是说明投入与目标之间的联系。

收益可以先以可观察状态表达，不必随意估算收入或节省比例。若需要财务判断，由适当责任人使用真实信息。文章不提供任意数字，也不以一句战略一致就证明价值。团队应知道本轮判断基于什么材料。

有些需求重要，却暂时不具备实施条件。可以先了解、缩小范围或等待资源，但说明状态与重新讨论条件。教练帮助发起人作真实选择，不以积极态度把全部需求同时排入计划。

背景不是一段介绍，而是实际约束

背景包括过去怎样处理、哪些已经尝试、得到什么反馈、目前有哪些规则与能力。理解历史有助于避免重复投入，但不能因为某次失败就断言所有相似路径都无效。说明当时条件与现在差异。

调查已有做法时，可以听取实际执行者，查看适当记录，必要时请专业人员。不同职责知道不同片段，不只听取项目负责人。信息不足的地方标明未知，不用完整叙述掩盖材料缺口。

约束需要区分性质。明确安全与专业要求不能取消，资源与日程可能需要协商，技术条件需要核实。不能一概当作不可改变环境，也不能假设所有限制都能靠创新解决。委托应让解决者知道哪些必须遵守、哪些仍开放。

把必要要求与偏好分开

必要要求是方案必须满足的条件，偏好是希望获得但可以比较的部分。比如服务说明必须准确表达范围，某种页面颜色可能只是偏好。若全部写成必须，团队难以寻找更合适方案，也可能将资源投入非关键细节。

必要要求应有依据。谁提出、为什么不可省略、怎样确认，都要能说明。不能由发起人凭个人喜好指定后称为专业标准。专业内容与批准责任由相应角色承担，教练帮助澄清，不替其认证。

偏好可以保留，但说明取舍。解决者知道哪些方面能够提出替代，才有真实探索空间。若某方案已经确定，就说清委托主要是实施，而不是要求大家重新发现同一答案。

图中需求结果、投入价值、背景约束与交付边界共同支持一份问题委托，委托再进入理解确认与方案工作。它是知行社独立编制的应用图，不表示四项填满即可解决复杂问题。定义也可以根据新信息返回修订。

问题陈述要让解决者知道要交付什么

陈述至少说明问题对象、现状与希望变化、影响范围、必要要求、资源边界、决定者，以及本轮需要的交付。交付可以是进一步分析、候选方案、原型或实施建议，不必直接要求完整成品。

语言应面向接收者。内部简称和抽象词可能让其他部门或外部支持者误解。可以让接收者用自己的话复述，说明将从哪里开始、需要哪些信息、哪些仍无法判断。复述是共同检查，不是考核理解力。

交付形式也应有目的。要求一份长报告却不知道怎样作决定，会增加无价值工作。说明谁阅读、希望判断什么、材料需要覆盖哪些条件。漂亮格式不是清楚委托的替代。

评估方式在工作开始前说明

方案怎样被判断，谁具有批准权，哪些专业检查不可省略，都应在开始前明确。否则团队可能努力满足想象中的标准，最后面对新的要求。标准可以修订，但说明新增信息与变化理由。

评估关注问题是否被回应，也关注实际条件。使用者喜欢不代表可维护，技术可行不代表符合服务范围，成本可接受也不代表没有信息风险。不同角色提供判断，正式决定责任保持清楚。

不要用多数投票抵消必要要求。投票可以帮助了解偏好，不能替代事实或专业判断。教练支持讨论透明，让解决者知道反馈如何进入决定，而不是只得到一个通过或不通过的结果。

表格将问题委托中的关键内容列出。每项不必长，但要能被接收者理解。未知也可以写入，只要说明获取信息的责任与下一步。清楚的问题陈述并不意味着所有条件已经确定。

一个教学案例：培训需求重新变成协作问题

以下案例为教学编写，不代表真实咨询项目。一位负责人要求设计跨部门沟通培训，认为任务经常反复确认。教练先了解具体事件，发现双方对需求变更后的完成标准与批准责任理解不同。

需求被重新描述为“在一类任务发生变化时，使相关岗位能够确认新的要求与资源影响”。价值在于减少冲突信息与无效返工，背景包括已有会议和记录方式。必要要求是确认责任清楚并遵守专业边界，培训形式则不再是必须。

团队委托本轮交付几种确认路径与一个有限试用建议，由相应负责人判断资源，专业角色检查要求。解决者因此可以提出简短变更说明、角色确认或针对性学习，而不必在一场课程里承担全部问题。

后续观察不同任务中的实际理解与负担。若需要培训，围绕得到支持的能力缺口设计。问题定义使方案更开放，也使交付边界更诚实，而不是否定培训本身。

定义过程也可能揭示不该启动的项目

澄清之后，组织可能发现需求证据不足、价值暂不明确或资源无法支持。这时可以暂缓或停止，而不是为了已经讨论很久就继续。记录理由与重新讨论条件，让相关者理解选择。

停止不意味着提问者没有价值。具体疑问提供了信息，组织可以保留观察。也不必把所有停止包装成成功学习，说明实际获得什么认识即可。诚实选择比强行产生项目更有利于长期信任。

如果决定先了解，明确了解问题、责任与时点，避免进入无限前期研究。定义服务于决策，不能成为不愿取舍的理由。教练可以帮助发起人说明何时足以进入下一步。

教练关注不同角色怎样理解同一段话

一份陈述写得流畅，可能仍被不同人理解成不同任务。可以分别邀请发起人、执行者、受影响者和决定者说明预期。比较哪里一致、哪里需要协商，避免开工后用我以为解释偏差。

也要留意权力对语言的影响。成员可能不敢指出目标不现实，解决者可能为了获得任务接受不清要求。教练支持具体表达与边界澄清，但不替双方承诺资源或效果。正式合同与责任事项按相应程序处理。

对于教练家平台，问题定义的价值是使工作开始前有足够清楚的共同对象。需求不等于方案，价值不等于宣传，约束不等于无从改变，交付也不等于无限责任。把这些区别说清楚，后续执行才更有机会回应真实需要。

工作开始后，如果信息改变，也应更新委托。说明哪些要求变化、对日程与资源有什么影响，以及谁作出批准。不要把原陈述当作永远固定，也不要允许不同人随口增加任务。修订有清楚路径，解决者才能持续理解当前工作，组织也能看见选择的实际代价。

接收者复述时，可以同时说明哪些部分无法承诺。例如能够提供原型，不代表能够承担长期维护；能够分析一般流程，不代表能够出具专业合规结论。发起人需要接受这些边界，并安排其他责任人。清楚委托是双方对工作条件的确认，不是要求解决者以更积极语言接受全部期待。

若组织希望征集多个方案，应说明共有材料与评估方式，避免不同解决者获得不同要求。反馈可以解释方案怎样回应问题，哪些条件尚未满足，而不只按展示能力判断。对未采用方案，也说明目前理由与材料去向。透明比较能减少后续对选择公平性的疑问。

问题陈述还可以标注哪些信息来自观察，哪些来自推测。当前需求只是某几位成员报告，就如实说明覆盖范围，不写成整个组织都存在。解决者据此安排进一步了解，避免为了满足委托而维护一个证据不足的前提。定义可以足够清楚，同时保持对未知诚实。

对于多个利益相关者，明确由谁汇总冲突要求。执行者不应自行猜测哪一方意见更重要，也不必在所有要求之间无限折中。协调与决定责任进入委托，变更有清楚路径，才能减少工作过程中反复推翻。教练帮助把冲突具体化，正式取舍仍由相应角色承担。

最后检查交付是否能够支持下一次决定。如果要求一份报告，说明读者需要据此选择什么；如果要求原型，说明希望验证什么；如果要求实施建议，说明谁接收并确认资源。交付与决策连接，材料才不会成为完成感的象征。也让团队知道何时已经足够，不用不断增加页面证明努力。