一个项目成不成很多时候在“开始做”之前其实就已经埋下了结果。现实工作中很多项目之所以后面越做越乱并不是因为中途谁执行得不够认真而是因为项目在启动阶段就没有把最关键的几件事想清楚这个项目到底要解决什么问题这个问题是谁的问题为什么现在必须解决解决之后希望带来什么业务结果这个问题是真问题还是表面问题这是一个功能问题、体验问题、表达问题还是商业问题PM、UI、UX 三个岗位在这个阶段分别应该做什么很多团队一进入项目就急着做三件事开始列需求开始画页面开始讨论功能但真正成熟的团队在项目启动阶段更重视的是另一件事先建立对“业务—用户—机会”三者关系的共同理解。因为如果这一步没有做好后面的 PRD、原型、设计稿、开发排期都会建立在不稳固的基础上。项目也很容易陷入一种典型状态做得很忙讨论很多页面很多文档很多但所有人理解的其实不是同一个问题所以项目启动阶段最重要的不是“立刻产出方案”而是先完成一次高质量的判断这个项目为什么值得做以及应该从什么角度开始做。而这一步从来不是 PM 一个人的事也不是 UI 和 UX 后置参与的事。相反越是好的项目越会在启动阶段就让三者进入同一个问题空间。一、为什么项目启动阶段最容易被低估很多人会觉得项目启动阶段不就是“开个启动会、对个目标、然后开始干”吗实际上项目启动阶段是整个项目中最具战略价值、也最容易出错的阶段之一。因为它决定了后续所有动作的起点。如果启动阶段判断偏了后面就会出现三类非常典型的问题。1. 误把表面诉求当成真实问题这是最常见的一类错误。比如业务方说“我们想新增一个会员弹窗提高转化。”“我们要做一个提醒功能减少客户流失。”“我们想优化首页感觉现在太普通了。”“我们需要做一个新版本让用户更有高级感。”这些都是很常见的“需求表达”但它们通常都只是表层方案并不等于真实问题本身。举个 ToC 例子。某工具类 App 的业务团队提出“希望增加一个‘限时优惠弹窗’提升会员购买率。”如果团队直接进入执行PM 可能会开始写需求UX 可能开始画弹窗流程UI 可能开始设计促销界面。但如果稍微往前追问一步可能会发现用户不是没看到优惠而是没理解会员价值当前主要流失发生在“试用结束”而不是“进入会员页”不同用户群对价格敏感度完全不同真正的问题不是“缺弹窗”而是“价值感知不足 决策链路断点”也就是说业务方提出的是一个想做的动作而项目真正需要解决的是一个转化问题。如果不先区分这两者项目一开始就会偏。2. 误把内部视角当成用户视角项目启动时团队很容易从自己的角度看问题。比如业务方从目标和 KPI 出发PM 从需求池和版本节奏出发UI 从界面表现和风格升级出发UX 从流程可用性出发研发从实现成本和架构限制出发这些都合理但如果没有一个共同过程去对齐很容易出现一种现象每个人说的都对但说的不是一件事。例如一个 ToB 项目管理层提出“我们要提升销售跟进效率所以增加一个‘客户意向标签系统’。”PM 可能理解为给客户增加标签字段支持筛选和分类提升线索管理效率UX 可能理解为销售在什么场景下打标签标签如何帮助后续动作标记流程是否顺手UI 可能理解为标签显示方式列表和详情页的信息层级状态颜色和视觉区分如果没有进一步讨论“真正的效率问题到底在哪里”大家会很快投入各自熟悉的解法。但最终上线后销售可能还是觉得不好用。为什么因为真正的问题可能不是“少标签”而是客户状态定义不统一跟进动作和标签没有形成闭环标签过多反而增加决策负担销售人员不知道何时必须打标签管理层想看的是阶段推进不只是静态分类所以项目启动阶段最重要的不是“谁先动”而是先把问题放到业务视角 用户视角 使用场景里重新看一遍。3. 误把“立刻产出”当成“高效推进”很多团队对“效率”的理解是赶紧定方向赶紧拆需求赶紧出原型赶紧评审赶紧开发但项目启动阶段真正的效率不是马上开始做而是尽早减少错误判断、错误方向和错误投入。启动阶段花 2 天把问题想清楚通常比后面花 2 周返工更高效。尤其在下面这些项目里启动阶段的判断质量几乎决定项目成败复杂 ToB 流程产品影响核心转化的 ToC 改版多角色协作系统0 到 1 新功能探索存在多部门诉求冲突的项目涉及技术约束较强的项目所以从项目管理角度看启动阶段不是“预热”而是决定后续投入是否值得的判断阶段。二、项目启动阶段到底要解决什么问题一个成熟项目在启动阶段至少要回答六个问题。这六个问题也是 PM / UI / UX 三方必须对齐的基础。1. 我们到底在解决什么问题注意这里不是问“我们要做什么功能”而是问当前项目想解决的核心矛盾是什么这是业务问题、用户问题还是组织效率问题这个问题是否足够重要值得一个项目投入比如ToC 例子“会员购买率低”不是问题定义更好的定义方式可能是新用户进入会员页后无法快速理解付费权益导致付费转化低试用用户在试用结束节点缺少价值回顾和决策引导导致正式订阅率低ToB 例子“审批太慢”不是问题定义更好的定义方式可能是当前审批流程中关键信息展示不完整导致审批人频繁跳转查看详情降低处理效率审批节点责任边界不清导致流程停滞和重复沟通问题定义越具体后面方案越容易收敛。2. 这个问题是谁的问题很多项目会默认“用户都一样”但真正有效的启动阶段一定会追问谁是主要用户谁是实际使用者谁是决策者谁是付费者谁受到的影响最大尤其在 ToB 项目中必须区分使用者管理者采购者决策者维护者举个例子某企业知识库系统启动一个“智能搜索优化”项目。如果不区分角色团队可能以为“用户搜索不到内容”就是统一问题。但进一步看会发现一线员工想快速找到答案提高处理效率主管想统一团队知识口径管理员想降低知识维护成本企业采购方关注培训效率和知识沉淀价值不同角色问题重点不一样。项目如果只按“一个用户”来理解很容易失焦。3. 为什么现在要做项目不是“永远可以做”而是总要在某个时间点启动。所以启动阶段必须回答为什么是现在这件事和当前业务目标的关系是什么不做的成本是什么现在做的机会窗口在哪里这个判断非常重要因为它决定项目优先级是否成立。例如ToC某功能与新用户增长节点高度相关某订阅策略改版恰逢大促节点某体验优化关系到核心转化漏斗ToB大客户上线前必须补齐某能力当前投诉集中暴露某流程问题公司战略转向需要补充平台能力如果没有“为什么现在”的说明很多项目看上去都“值得做”但实际上不一定适合此刻投入。4. 这个问题到底值不值得做这一步其实是机会判断。不是所有问题都值得变成一个项目。项目启动阶段必须做一个基本判断影响面有多大价值有多大成本有多高风险有多大是否有更轻量的替代方案这就是我们常说的“价值判断”。例如某 ToC App 想做“个性化主题皮肤商城”。从体验和品牌层面看似乎有空间。但如果当前产品连核心留存都不稳定这个项目再有想象力也可能不是当前最优先项。某 ToB 平台想做“自定义仪表盘拖拽布局”。从产品能力上看很高级但如果大多数客户当前最痛的是报表口径不一致那么“展示层灵活性”就未必比“数据可信度”更值得优先投入。所以项目启动阶段不是“看到机会就开工”而是要做取舍。5. 这个问题应该从哪个角度切入同一个问题不同切入角度会导向完全不同的项目方案。例如业务方说提升新用户留存可能的切入角度有功能价值理解不足首次使用路径太复杂激励机制不够内容供给不匹配新手引导策略问题业务方说提升销售跟进效率可能的切入角度有跟进提醒缺失客户信息展示不清录入动作太重阶段推进规则不清团队协同信息不同步项目启动阶段最关键的不是急着选方案而是先做“切口判断”。这个阶段 PM、UX、UI 都要参与因为PM 更擅长看业务目标与优先级UX 更擅长看用户路径和阻力点UI 更擅长看信息表达和操作效率问题如果只从一个岗位出发切入角度往往不完整。6. 我们怎么判断项目后面做得对不对这是很多团队启动阶段最容易漏掉的一步。项目一开始就应该想成功的标准是什么我们后续看什么指标什么结果说明方向对了什么结果说明方案需要调整例如ToC 会员项目成功标准可能包括会员页点击开通率提升试用转正式订阅率提升页面停留时长变化用户对权益理解度提升ToB 跟进提醒项目成功标准可能包括跟进逾期率下降商机推进周期缩短销售漏跟进投诉减少功能使用率达到预期如果启动阶段没有提前定义结果判断标准后面很容易变成项目做完了页面也上线了但没人真正知道它到底有没有价值三、PM、UI、UX 在启动阶段分别做什么这是这一篇最核心的部分之一。很多人以为启动阶段就是 PM 的主场设计师后面再进。这种理解在今天已经不够用了。更成熟的启动方式应该是PM 主导方向判断UX 补充用户与场景洞察UI 提前介入信息表达与体验预判。三者不是同时做同样的事而是从不同专业角度帮助团队更早把问题看完整。1. PM定义问题、判断价值、收敛方向PM 在启动阶段的核心职责不是立刻写需求而是先完成三层判断。第一层问题判断PM 要明确当前要解决的核心问题是什么这是症状还是根因是单点问题还是系统问题第二层价值判断PM 要回答这个问题影响什么业务目标值不值得投入优先级是否成立当前阶段做它是否合适第三层方向判断PM 要决定项目从哪个角度切入目标用户是谁第一阶段范围如何控制哪些先不做也就是说启动阶段的 PM 最重要的工作不是“把方案说满”而是把问题讲清、把方向收紧、把目标框出来。PM 在启动阶段常见输出项目背景说明问题定义目标拆解用户与业务影响分析初步范围与边界成功指标草案初步里程碑判断2. UX补齐用户视角把“业务诉求”翻译成“真实使用问题”UX 在启动阶段不能等 PM 把需求全部写完再介入。因为很多真正影响项目方向的判断本来就需要 UX 提前参与。UX 在启动阶段重点看四件事第一用户是谁核心用户是谁高价值用户是谁新手和老用户是否有差异不同角色用户的目标是否一致第二用户当前怎么做用户现在如何完成任务哪一步最费劲哪一步最容易放弃哪些动作是高频哪些是低频但高价值第三用户为什么这样做用户目标是什么用户犹豫点是什么用户认知偏差在哪里用户说的问题和真正的问题是否一致第四问题是流程问题、认知问题还是表达问题这是 UX 在启动阶段特别重要的判断。例如同样是“用户不完成购买”原因可能完全不同看不懂价值操作流程太长缺少信任感价格比较成本高关键信息出现太晚如果启动阶段没有 UX 的判断项目很容易把“用户不转化”简单理解成“要做更刺激的运营动作”。UX 在启动阶段常见输出初步用户问题假设关键场景描述用户路径草图主要阻力点判断研究计划或轻量访谈提纲初步机会点分析3. UI提前参与信息表达判断而不是等方案确定后再“出视觉”很多团队会把 UI 放在很后面认为启动阶段还没到 UI 发挥的时候。这是一个很常见的误区。因为很多问题表面看像需求问题或交互问题本质上其实和信息表达密切相关。UI 在启动阶段虽然不一定马上产出高保真设计但应该提前介入看三件事第一当前问题是否与信息层级有关例如关键价值没有被优先看到页面重点不明确主操作和次操作区分不清状态表达混乱信息密度过高导致理解成本上升第二当前问题是否与界面模式有关例如这个场景是不是根本不该用弹窗列表页是否应该切换为卡片模式当前表单结构是否过于线性页面布局是否限制了操作效率第三后续表达和规范成本是否可控例如这个方向是否会引入新的组件模式是否与现有设计系统冲突ToB 场景下是否支持后续扩展ToC 场景下是否符合品牌调性UI 提前参与的意义不是“抢 UX 的工作”而是帮助团队尽早发现有些问题不是功能不够而是表达方式错了。有些问题不是用户不会用而是页面没有让用户快速理解。UI 在启动阶段常见输出当前界面问题初判信息层级与重点表达建议界面模式风险提示设计系统影响预判视觉方向初步建议四、三者在启动阶段到底怎么一起工作这一部分我们按之前讨论的思路讲“协同判断”和“工作方式”不再混乱拆散。项目启动阶段PM、UI、UX 并不是各做各的。更合理的方式是围绕同一个项目完成四轮协同判断。第一轮统一问题定义这一步的目标是把“别人提来的需求”翻译成“团队真正要解决的问题”。典型输入可能来自老板或业务部门客户反馈销售诉求数据异常市场变化产品团队主动发起这时三者关注重点不同PM 关注这个问题和业务目标的关系是什么值不值得变成项目是短期补丁还是中长期能力建设UX 关注这是不是用户真实问题问题是否存在关键场景差异用户目标和业务目标是否有冲突UI 关注当前问题里是否包含明显的信息表达问题是否有界面层级、状态传达、操作引导方面的根本缺陷这一步的结果不是立即确定方案而是形成一个统一表述我们真正要解决的问题是什么。第二轮统一项目目标当问题定义清楚后三者要进一步统一项目目标。注意项目目标不是一句空话“优化体验”或“提升效率”而应该尽量可判断。例如ToC 会员项目不说“优化会员页体验”而说提升试用用户转正式订阅率降低用户对会员权益的理解成本提升核心功能价值感知ToB 审批项目不说“优化审批流程”而说缩短审批人完成处理的平均时长降低因信息不完整导致的跳转查看次数提升复杂审批场景下的操作准确率在这一轮里PM 负责把项目目标和业务结果挂钩UX 负责把目标转译成用户行为与体验目标UI 负责预判哪些目标可能涉及重点表达、页面结构和视觉引导第三轮统一切入点同一个问题可能有很多做法。启动阶段非常重要的一件事是尽早统一“我们第一刀从哪里切”。例如一个“新用户留存低”的问题切法可能有优化注册流程优化首次引导强化核心价值展示做激励体系调整首屏内容推荐缩短首个任务完成路径这里三者的分工是PM 判断哪个切法和当前业务目标最相关哪个切法最符合资源与节奏哪个最适合作为 MVP 验证UX 判断哪个切法最可能降低用户阻力哪个切法能最直接改善任务完成率哪个切法更符合用户当前决策路径UI 判断哪个切法在表达上最有改善空间哪个切法对页面认知成本影响最大哪个切法更适合快速验证统一切入点的意义是避免项目一启动就什么都想做最后什么都做不深。第四轮统一验证方式在项目启动阶段三者还要提前统一一件事后面怎么判断这个项目方向是不是对的。这是协同里非常容易被忽视、但非常关键的一步。例如ToC看会员页点击率还是订阅率看留存还是任务完成率看首屏停留还是功能使用深度ToB看任务完成时长看错误率看培训成本看客户反馈满意度看功能使用覆盖率在这一步PM 更偏结果和业务指标UX 更偏任务完成、路径顺畅、可用性表现UI 更偏信息理解效率、关键操作识别、表达一致性反馈这样做的好处是后面项目推进时团队不容易出现“大家在做同一个项目但各自按不同标准判断成败”。五、项目启动阶段的一个可落地 SOP下面给你一个更适合培训和实际工作使用的启动阶段 SOP。这部分你后续拿去讲团队培训会很有用。Step 1接收项目输入输入可能来自老板或业务诉求客户需求数据异常用户反馈团队主动优化提案此时先不急着下结论只做信息收集。Step 2PM 做初步问题归类先判断这是业务增长问题用户体验问题界面表达问题流程效率问题系统能力问题组合型问题这一步输出初步项目背景和问题草案。Step 3UX 做场景与用户问题初判快速看主要用户是谁核心任务是什么当前阻力点在哪是否需要补充访谈 / 走查 / 用户反馈分析这一步输出初步用户问题分析。Step 4UI 做表达与模式风险初判快速看是否存在明显信息层级问题是否存在界面模式不合理是否需要考虑组件、规范、视觉方向影响这一步输出表达与设计风险提示。Step 5三方对齐会议围绕四件事达成共识问题定义项目目标第一阶段切入点后续验证方式注意这不是方案评审会而是项目理解对齐会。Step 6决定是否进入正式立项 / 需求定义如果判断问题成立价值成立方向成立切入点清晰再进入后面的需求调研、研究、方案定义阶段。如果没有成立就应该继续补充信息而不是硬推进。六、ToB 和 ToC 启动阶段三者协同重点有什么不同这个部分也很关键因为你的专栏一直强调 ToB ToC 全场景。ToC 项目启动阶段更强调“机会判断 用户行为判断”ToC 更常见的启动问题是用户为什么不转化用户为什么留不住为什么某功能打开率低为什么用户理解不了价值为什么流量来了但没形成行为所以 ToC 启动阶段三者协同重点一般是PM商业目标、增长目标、转化结果UX用户动机、决策路径、行为阻力UI价值感知、首屏表达、转化引导例如注册、订阅、内容分发、裂变、活动转化等项目。ToB 项目启动阶段更强调“流程问题 角色问题 复杂度判断”ToB 更常见的启动问题是流程效率低多角色协作混乱信息展示不完整配置能力不足培训成本高客户投诉某个步骤不好用所以 ToB 启动阶段三者协同重点一般是PM业务流程闭环、角色边界、平台价值UX任务效率、异常场景、认知负担UI信息组织、状态表达、组件模式、一致性例如审批、CRM、ERP、工单、知识库、报表平台等项目。七、启动阶段做到什么程度才算真正做得好这一点是为了体现“能力标准”也是你这套专栏和普通内容拉开差距的地方。一个项目启动阶段做得好不是开了会、写了背景、分了工而是至少满足下面几个标准。合格标准能说清项目背景能描述主要问题能知道项目大致目标三方知道自己要参与什么这只能算“启动了”。熟练标准能把表面诉求和真实问题区分开能识别项目涉及的是业务问题、体验问题还是表达问题能完成 PM / UX / UI 三方基本对齐能明确第一阶段切入点和初步验证方式这说明团队已经具备比较成熟的启动能力。优秀标准能快速识别问题根因和错误切法能在启动阶段就减少后续返工风险能把业务目标、用户目标和设计目标统一起来能让三方围绕同一个问题工作而不是各自产出能为后续需求定义、方案设计和项目推进建立稳定基础这才是高水平团队的启动能力。八、结语项目启动阶段不是“准备动作”而是第一次真正的项目判断很多团队把启动阶段看得太轻。但实际上项目启动阶段不是热身而是项目第一次真正开始发生的地方。因为从这一刻开始团队要做的已经不是“接一个需求”而是定义问题判断价值识别用户统一目标选择切口约定后续验证方式更重要的是这个阶段不能只是 PM 一个人想清楚而必须让 PM、UI、UX 三个角色从一开始就进入同一个问题空间。因为只有这样后面的需求、原型、界面、评审、开发、验证才可能真正围绕同一个方向推进。所以这一篇最想强调的一句话是项目启动阶段真正要启动的不是流程而是三方对问题、用户与机会的共同理解。当 PM 不再只看需求UX 不再只等方案UI 不再只接设计而是三者从启动阶段就一起进入项目项目的质量往往就已经向前迈了一大步。