“我们需要一个新系统”常常只是讨论的起点。系统背后究竟要改变哪个业务结果、服务谁、替代什么、由谁维护，才是决定项目成败的关键。
不少数字化项目在开始时看起来十分顺利：需求列表已经写好，供应商开始报价，团队也安排了负责人。但做到一半，大家才发现对“完成”的理解并不一致。管理者想看实时数据，一线人员只希望少填几张表，技术团队则在等待迟迟无法确认的数据接口。
下面七个问题适合在立项会、需求访谈或首次方案讨论时逐一回答。不需要一次得到完美答案，但每个问题都应该有明确的当前判断和待验证项。
一、最想改变的业务结果是什么？
不要先回答“做一个网站”“上一套 CRM”或“接入 AI”。这些是手段，不是结果。更有用的表达通常包含一个具体场景和一个可观察的变化，例如：
- 让销售人员每天整理客户记录的时间从一小时降到十五分钟；
- 让访客在三分钟内找到适合自己的产品并完成询价；
- 让管理者在当天而不是月底看到库存异常。
结果未必都能立即量化，但至少要能被观察。否则项目上线后，只能用“页面做完了”“功能可以点”来证明价值。
二、谁会在什么时刻使用它？
“公司员工”和“目标客户”都太宽泛。财务、销售、渠道伙伴和首次访问网站的采购人员，任务、知识和耐心完全不同。描述核心用户时，可以补齐三个信息：他是谁、当时要完成什么、所在环境有什么限制。
这样的场景会直接影响字段数量、移动端优先级、离线策略和数据复用方式，比“支持移动端”更能指导设计。
三、现在的流程到底怎样运行？
不要只看书面制度。真实流程往往散落在表格、微信群、个人经验和临时口头确认中。新系统如果忽略这些隐性步骤，用户会在上线后重新发明一套绕开系统的办法。
可以跟随一次完整任务，记录触发条件、参与者、输入信息、判断节点、交付结果和异常处理。尤其要问：“如果信息不完整怎么办？”“谁有权修改？”“最常见的例外是什么？”例外通常比标准路径更能暴露设计难点。
四、哪些数据已有来源，哪些需要新建？
很多需求在原型里只是一个漂亮的数字，真正实施时才发现没有稳定数据源。启动前应给核心数据标注来源、负责人、更新频率、质量问题和访问限制。
如果同一个“客户名称”在三个系统里有三种写法，先确定主数据规则；如果某项指标只能依赖人工汇总，就把人工成本和错误风险写进方案。数据问题不会因为新界面上线而自动消失。
五、第一阶段什么可以不做？
范围控制不是删减价值，而是优先完成最短的有效闭环。一个判断方法是：如果去掉某个功能，核心用户还能不能完成前面定义的任务？如果可以，它可能适合进入后续迭代。
第一阶段最好围绕一类用户、一个高频场景和一组关键数据展开。过早覆盖所有部门、所有终端和所有例外，通常会让验证周期变长，也让真正重要的问题被功能数量掩盖。
六、上线后谁来负责？
产品上线不是项目结束。内容谁更新、账号谁审批、数据异常谁处理、需求由谁排序、供应商出现问题谁联系，这些都需要明确的责任人。
如果没有专职团队，可以建立轻量机制：指定业务负责人和技术接口人，每月固定一次数据与反馈复盘，为日常小修改保留预算。没人负责的系统会很快停止进化，最后只能用一次大改版解决累积问题。
七、如何判断这次投入值得？
给项目设定一组有层次的信号：是否按计划上线属于交付信号；有多少目标用户持续使用属于采用信号；时间、转化率或错误率是否改善属于结果信号。
不要只挑容易上涨的数字。访问量增加不代表询盘质量提高，注册人数增加也不代表用户获得价值。指标应回到第一个问题：我们到底希望改变什么？
把答案写在同一页纸上
这七个问题的价值不在于形成厚厚的立项材料，而在于让不同角色看到同一幅图。把当前答案控制在一两页内，对不确定项标记负责人和验证时间，并在每次重大范围变化时重新检查。
当目标、用户、流程、数据、范围、责任和衡量方式能够相互对应，技术选型反而会简单很多。项目也会从“完成一份功能清单”，变成“推动一次可以被看见的业务改变”。