方案好看却未必可行：用TELOS核对项目的五个现实条件

方案很有吸引力，演示也顺利，主管因此准备批准实施。但真正投入工作后，团队才发现旧系统不能稳定连接，维护人员没有时间，原先承诺的上线日期更无法兑现。知行社为教练家讨论项目可行性：在支持一个想法之前，分别核对技术、经济、法律、运营和进度条件，让热情与实际承载能力相互校验。

TELOS是这五个英文维度首字母组成的检查框架。它提醒团队不要只检查技术能不能做，也要确认资源、运行和时间是否支持。五个维度不是标准化测评，没有普遍有效的通过分数，顺序也不必须固定。本文的工作问题由知行社独立编制，涉及专业事项时仍需要相应角色给出判断和授权。

可行性首先需要一个清楚的方案范围

如果只说建设数字化平台，任何检查都会变得含糊。先说明服务谁、解决什么工作、包含哪些功能、哪些部分暂不纳入，以及当前希望批准哪个阶段。可行性针对某个版本和特定条件，不能因为一个小样演示成功，就认为完整方案已经可实施。不同范围应分别记录，避免讨论期间默默增加要求。

还要说明与现有工作的关系。新方案是替代原流程，还是增加一个渠道？旧资料是否需要迁移，谁能够停止旧服务？如果两套流程长期并存，运营成本与人员负担都会变化。教练可以帮助负责人看见这些隐含假设，但具体系统、合同和业务影响应由相应人员确认，不能靠会谈推测替代实际调查。

可行性检查应服务一次明确决定，例如是否批准试验或是否允许扩大。资料深度与决定后果相匹配。低风险试用不一定需要完整商业论证，涉及长期承诺的项目则不能只凭简短清单。写清现在必须知道什么，什么可以在试验中继续学习，能够同时避免过度分析和仓促批准。

技术维度：能演示不等于能持续工作

技术检查不仅看功能是否存在，也看容量、连接、可靠性、维护和必要权限。供应方展示理想环境中的操作，与企业真实数据和业务高峰下的运行不同。请技术角色说明已经测试哪些场景、尚未测试哪些场景，以及失败时怎样处理。不要把演示的流畅感直接翻译为长期稳定的保证。

对管理者而言，最有用的问题往往是关键依赖。如果方案需要某个接口、特殊设备或唯一专家，条件变化会怎样影响交付？有没有替代办法，谁能够确认？教练可以让负责人把技术术语转换成管理后果，而不要求其假装懂全部细节。例如接口未开放意味着哪些任务不能完成，等待多久会改变原计划。

也要核对数据质量。再先进的工具，输入信息缺失或口径不一致时也可能输出不可靠结果。项目需要谁整理数据、怎样确认准确性、出现错误谁修正，都应进入计划。把准备工作视为员工顺便完成，常常是成本和进度估计偏差的来源。技术条件包括实际准备，不能只写采购某项产品。

经济维度：看完整周期，而不是只看购买价

购买费用之外，还可能包括配置、迁移、培训、维护、停机以及管理协调的成本。经济可行性不是所有收益都能精确换算成钱，而是尽可能呈现重要成本与收益，说明估计依据及不确定范围。涉及正式预算应由财务角色核对，教练不能以一句长期会省钱替代测算。

收益要说明由谁获得、什么时候出现和依靠什么条件。减少录入时间不代表组织一定获得等额可用资源，节省出来的时间是否能用于其他工作，还需要实际安排。员工体验改善有价值，但不能随意编造转化数字。可以将可估算收益与难以货币化的影响分开写清，避免为了证明方案值得而制造虚假精度。

比较应采用相近范围，包括维持现状、调整现有流程和采用新方案。现状也有成本，但不能将其描述得极坏来帮助新方案通过。对最可能改变结论的假设做适当敏感性检查，看看使用人数或维护成本变化时，选择是否仍成立。小幅变动便推翻结论的方案，需要更谨慎的承诺。

法律维度：把专业问题交给有责任的角色

这一维度关注方案是否涉及合同、知识产权、个人信息或相关规范要求。本文不提供具体法律结论。负责人需要及时邀请有资格或有职责的专业角色，明确哪些事项必须核对、需要哪些文件、谁有权确认，以及未确认之前哪些工作不能开始。不要把清单上写了合规当成已经完成专业审查。

资料使用权限尤其容易被忽略。组织拥有一份文件，不必然意味着能够把它用于所有用途；员工愿意提供信息，也不必然解决全部使用边界。教练可以帮助管理者识别自己并不知道的条件，并落实咨询和审批行动，不代替法务解释适用规则。专业核对的结果应进入方案，而不是独立存放后无人执行。

如果必要条件不能满足，不能让其他维度高分抵消。项目可能技术成熟、预算充足，但仍需要调整范围或停止。团队应将这种条件写为明确门槛，避免在综合平均分中消失。管理者承担的责任是安排正确核对并遵守结论，不是要求专业角色为已经承诺的决定寻找通过理由。

运营维度：交付之后谁让它继续有用

新方案上线后，谁接收请求、维护资料、处理异常和解释变化？这些工作若没有岗位和时间，项目可能完成建设却无法持续运行。运营可行性应让真实使用者参与，而不只是由发起人描述未来。请其走一遍典型任务，说明哪个步骤增加负担、哪里需要培训、哪些旧工作可以相应减少。

不要把员工是否喜欢新系统简单当成接受度。反对意见可能来自操作成本、责任不清或信息质量问题，也可能来自不熟悉。不同原因需要不同安排。培训可以帮助掌握功能，不能解决缺乏权限和重复录入。教练帮助管理者听见具体困难，不以积极心态要求员工承担设计尚未解决的缺口。

同时确认客户和协作方的使用条件。一个内部看来方便的入口，可能让外部参与者更难完成任务。必要时安排不同能力和工作环境的人试用，并保留替代渠道。运营适配不是一次满意度问卷，而是观察方案能否在真实工作中稳定产生预期价值，以及异常发生时有没有人负责回应。

进度维度：日期必须建立在依赖之上

进度可行性应说明工作顺序、关键依赖、审批窗口和资源可用时间。总工时够，不代表任务能够同时开展。资料未确认时无法迁移，接口未开放时无法测试，这些依赖会限制安排。主管希望的日期可以作为目标，但不能被直接复制为承诺，负责人需要解释实现它必须具备哪些条件。

估计时考虑现实工作。参与者可能同时承担日常任务，不会因项目成立就自动拥有全部时间。请相关负责人确认可提供的资源，不能把人的姓名写进计划就视为支持到位。对高不确定环节保留合理检查点，发现条件变化时及时调整，而不是每周重复报告原日期并将延误留到最后暴露。

还要核对错过日期的后果。有的上线窗口可以调整，有的涉及必要协同和外部承诺。不同后果需要不同备用安排。教练可以问，如果关键依赖延迟，你准备改变范围、增加资源还是调整时间？这些选择不能事后全部交给一线员工加班补救，需要提前明确谁有权作取舍。

虚构案例：知识平台先检查运营再谈扩张

以下为虚构教学情境。一家咨询团队希望建立客户知识平台，采购方案看起来价格适中，技术演示也符合预期。负责人准备全面上线，教练请其用五维检查当前版本。技术团队发现权限管理可以实现，但资料分类尚不一致；财务核对后发现维护和编辑工作未计入原先预算。

专业角色进一步确认客户材料使用边界，需要先排除部分内容。运营讨论发现专家愿意分享，但没人负责持续更新。团队因此选择小范围内部版本，由明确的编辑角色维护，只放可使用的资料。进度也改为先整理内容和测试权限，再邀请有限用户，没有继续沿用原来的全面上线承诺。

试验期间，使用者反馈查找路径太长。负责人调整栏目，并查看更新任务是否能在实际时间内完成。决定扩大之前，再次核对五个维度，而不是把初次检查当成永久许可。案例的重点不是证明平台一定值得建设，而是说明不同条件互相影响，某个维度的变化可能要求重新调整方案。

用教练对话提高检查质量

教练可以邀请负责人分别说出每个维度最有把握的证据和最不确定的条件。若全部回答都是应该没问题，可以追问谁已经确认、确认基于什么，以及仍有什么未知。问题的语气应帮助思考，不能像盘问一样把客户推入防御。承认不知道，是安排下一步核对的起点。

也要检查客户是否因个人投入或组织期待而选择性呈现资料。可以请其描述最可能让方案无法运行的条件，再比较目前准备是否足够。这个问题不是鼓励悲观，而是给积极判断增加边界。对于较复杂的项目，专业人员与实际使用者的意见比教练个人的想象更重要，应安排进入正式决策过程。

检查结束时，把结论写成通过、附条件继续、补充信息或暂不继续，并记录责任人与再查时间。不要只写总体可行，留下所有条件没人处理。若方案范围发生实质变化，应重新核对受影响维度。知行社希望可行性工作帮助团队减少漂亮方案与真实工作之间的距离，让批准建立在能够兑现的条件上。

可行性材料还需要区分证据日期和适用范围。一个供应条件已经过时，一个测试只覆盖少量用户，都可能影响判断。保留这些说明不是增加文书负担，而是让后来的人知道结论能够支持多大的承诺。项目从试验走向扩大时，最重要的工作之一，就是确认旧证据是否仍然适用。