1. 为什么每个团队都需要一个“愿景Vision”说来也怪我在帮团队做敏捷转型辅导的时候最常被问到的不是“Sprint怎么排”也不是“看板怎么画”而是“我们到底在做什么、为什么做这个”。这个问题听起来特别虚但它恰恰是 Scrum 体系里最容易被跳过、却又最不该被跳过的一个环节——愿景Vision)。Scrum 模式语言一共有三十多个核心模式第二册里这张“愿景”卡牌排在很靠前的位置这个排位本身就说明一个问题它是一切的地基。没有愿景的 Scrum 团队就像一个没有目的地的自驾车队每辆车都加满了油、检查好了轮胎、导航也都开着但导航里根本没输地址。你说它能不能跑能跑。但它跑到哪儿去、跑得对不对全凭感觉。这篇文章我想跟你聊透这件事愿景在 Scrum 里到底是什么、它和产品目标有什么关系、一个靠谱的愿景描述长什么样、怎么带着团队把它写出来以及我在实际项目里踩过的坑。如果你正带团队、或者正准备启动一个跨部门协作项目这篇内容值得你留出十五分钟慢慢看。先说清楚一个前提愿景不是老板拍脑袋的一句话也不是挂在墙上没人看的标语。它是团队所有决策的“第一判据”。Sprint 排期有分歧的时候回看愿景需求优先级有争议的时候回看愿景技术方案犹豫不决的时候回看愿景。它得能用而不是好看。这里也顺便说一句不是只有互联网公司需要这东西。我做过的传统制造企业数字化改造项目、医疗设备软件项目、还有教育培训类的产品重构凡是开场认真聊愿景的后续推进的顺畅度远超那些直接闷头开干的。凡是嫌愿景“太虚”直接跳过的三个月后几乎无一例外会出现方向漂移、成员倦怠、交付物对不齐的典型症状。2. 拆开“愿景”这张卡牌它到底在说什么2.1 愿景、产品目标、Sprint目标三者的定位区别接触过 Scrum 的朋友都知道Scrum 指南里最近几年开始强推“产品目标Product Goal”但很多团队分不清愿景和产品目标的关系经常把两者混成一个东西。我用一个三层结构帮助团队理解愿景Vision最顶层回答“我们为什么存在、要为世界带来什么改变”。它的时间跨度通常在一年以上甚至可以跨越多个产品版本。产品目标Product Goal中间层回答“在接下来这个阶段我们要达成什么状态”。时间跨度通常是几个月一个愿景可以驱动多个连续的产品目标。Sprint 目标Sprint Goal最底层回答“这一个迭代我们要交付什么有意义的增量”。时间跨度就是一到四周。这三层是一层套一层的。Sprint 目标服务于产品目标产品目标服务于愿景。我见过有团队把愿景写成一句特别抽象的口号“让世界更美好”然后产品目标和 Sprint 目标跟这句口号完全对不上。这就是典型的断层。反过来说一个健康的团队应该能做到随便拉一个开发成员出来问他“你这个 Sprint 做的功能跟产品目标有什么关联这个产品目标又是怎么支撑愿景的”他能清楚地讲出这条逻辑链。如果讲不出来说明愿景只是贴在墙上的装饰品没有真正进入团队的决策系统。2.2 模式语境为什么标题要带“第二册【Scrum 模式语言8】”如果对敏捷或 Scrum 的历史有了解你会知道它不仅是一套流程框架更是一套不断沉淀的管理模式语言。这套语言里面每一张卡牌都对应一种已经验证过的团队协作模式而“愿景”被编在第八位不是偶然——从模式语言的编排逻辑看前几个模式都是在讲团队的基本形态和协作契约从“愿景”开始话题才从“我们怎么一起工作”转向“我们为什么而战”。我之前带一个模拟项目X的时候团队成员来自三个不同部门有做硬件的、有写软件的、还有负责运营的。第一次开场会我让他们分别用一句话描述这个项目是要做什么结果三个部门的答案几乎完全不一样甚至有两个部门的描述听起来根本不像同一个项目。后来我拿出一小时专门带着他们做愿景梳理就是这个简单的动作让后续三个月的协作摩擦减少了一大半。这件事让我彻底相信愿景不是“有最好”而是“必须有”。尤其跨职能团队、跨部门团队、远程协作团队人员背景差异越大愿景的统合作用越明显。2.3 它解决的问题方向漂移、优先级争议与士气损耗我们逐个拆开看。方向漂移是愿景缺失最直接的后果。没有参照物每个成员都会根据自己对项目的理解做“局部最优”的决策。做出来的东西单个看都合理拼在一起就成了一艘哪里都不靠岸的船。优先级争议在缺少愿景的团队里会高频发生。产品经理觉得功能A重要技术负责人觉得架构改造B重要运营说用户增长C重要。三边都有道理但如果没有一个更高维度的判据这种争议最后靠什么解决要么靠嗓门要么靠职位要么靠拖延。而有了明确的愿景争议就变成了一个工程问题这个功能是否让项目更接近愿景描述的那个状态是就做不是就说明理由。士气损耗这件事闷头写代码的团队体会最深。当一个人不知道自己每天写的代码最终要把用户带到哪里去他的工作就会慢慢变成“完成需求列表上的勾”。这种状态最危险因为它表面上看起来一切都是正常的——任务都完成了Sprint Review 也开得挺好但只要出现一点点外部扰动团队就会迅速出现无力感。我在一个做了快两年的项目里见过一位技术很强的工程师某天突然私下跟我说“其实我做这个模块已经大半年了但我一直不太清楚它到底给谁用、解决什么问题。”这句话当时听着也就是一句感慨后来想想这正是愿景长期缺位埋下的一颗雷——不是他不负责是没有人给他一个“负责的理由”。3. 愿景描述里必须有的三样东西和一个常见误区3.1 三要素拆解受益对象、核心价值、成功标志愿景不是说给投资人听的漂亮话它是说给团队成员听的行动指南。在我验证过多个团队之后一个真正可用的愿景描述至少需要具备三个要素第一明确受益对象。愿景描述里必须出现“谁”。这个“谁”越具体越好。比如“让三线城市的家庭用户能够负担得起的在线教育资源”这就比“为用户提供优质教育服务”好得多。受益对象越清晰团队在做取舍时越容易判断这个改动对这个具体人群是否有价值第二定义核心价值。光有对象还不够还要说清楚“帮他们改变了什么”。注意这里说的不是功能是改变。功能是“我们做了什么”价值是“用户因此获得了什么”。比如开发一个记账软件“功能”是记录每一笔收支“价值”是用户对自己的财务状况有掌控感不再焦虑。第三给出可衡量的成功标志。愿景听起来务虚但它必须能够被“翻译成”可衡量的东西。不一定要写具体数字至少要有一种明确的判断方向。比如“成为区域内覆盖率最高的在线课程平台”这句话虽然没有写死具体占比但它给出了一个清晰的衡量维度——覆盖率而且有个排序上的参照。我见过好多团队写愿景的时候洋洋洒洒一篇小作文读起来文采飞扬但仔细一看既没有对象也没有价值更谈不上衡量。这种愿景写出来就只是为了“有”而不是为了“用”。3.2 常见误区愿景不是“功能清单”也不是“空口号”说完了三要素必须得点两个最常见的误区。误区一把愿景写成功能清单。有人写愿景会写成这样“我们要做一款具备A功能、B功能、C功能的工具类产品”。这是把愿景和产品规格搞混了。功能是服务手段会随着时间变化甚至被替换但愿景关注的是目的。比如某教育产品的愿景是“让每一个想学习的人都能低成本获得优质课程”那它可以先用直播模式实现也可以改成录播模式未来还可以尝试VR虚拟教室。功能会变愿景不变。误区二把愿景写成空洞口号。“追求卓越、创造价值”这类词放在任何公司的文化墙上都对放在任何一个项目的愿景描述里也“都对”——但正因为哪里都对它就哪里都不具体。团队看完以后没有任何行动指令。我之前见过一个内部数据平台项目愿景写着“打造业界领先的数据基础设施”每次评审会争论功能优先级的时候这句话完全帮不上忙因为“业界领先”四个字谁来解读都有一套自己的标准。真正有用的愿景宁可写小一点、具体一点也不要写大而全。明确指向某一个群体、某一种改变、某一种成功这才有约束力。有约束力的东西才能用来做决策依据。3.3 一个可参考的愿景描述模板很多团队不是不想写是不知道怎么写。我实操下来觉得最顺手的模板是下面这个结构你可以直接用我们要为明确受益对象创造核心价值/改变最终成为/达成可衡量的成功标志。比如我以前带过的一个企业内部知识管理系统团队一开始写的愿景是“提升公司知识共享效率”后来按模板改成我们要为新入职三个月的员工创造“快速找到可信资料”的体验帮助他们把入门上手时间缩短一半最终让知识库成为全公司开工前默认首查的资源。改动不大但整个团队在做优先级决策的时候明显有了抓手凡是能帮助新人更快找到资料、能让知识库在检索体验上更顺滑的事情优先做凡是跟这个目标关联弱的事情都往后排。这个愿景支撑了后续五个季度的迭代决策一直没失效。4. 实操怎么在三天内带团队把愿景聊出来4.1 准备工作哪些角色必须到场、需要带什么资料愿景梳理这件事不是找个文笔好的人关起门来写。它需要相关角色的集体参与。我建议至少要包含这些角色产品负责人PO他掌握产品方向、用户反馈和业务目标。技术负责人或技术骨干他了解现有技术栈的边界和未来扩展性能判断愿景是否可实现。迭代经理/Scrum Master他熟悉团队的节奏和协作状态负责引导讨论进程。业务方或用户代表有人直接代表受益对象发言避免团队凭空想象用户需求。这几种角色里最容易缺位的是用户代表。很多团队说“我们就是用户我们懂”但我见过太多次“团队以为用户喜欢”和“用户实际想要”之间出现巨大落差的情况。条件允许的话最好拉一个真实用户或者距离用户最近的运营同事进来。准备的资料不需要多重点三份现有的产品资料、原型或上线版本如果有的话过往用户反馈、投诉、访谈记录业务侧的阶段目标或商业诉求。这些东西不是用来给愿景“找答案”的而是用来“对照校准”的——讨论过程中随时可以翻一翻确认我们没有跑偏。4.2 第一天发散与对话收集所有人头脑中的“愿景碎片”第一天只做一件事让每个人说出自己心目中这个项目成功以后的样子。不要打断、不要评价、不要一上来就写句子。操作上我惯用的方法是每个参与者用便利贴写下三句话这个项目做到最成功的状态用户在经历什么那个时候团队在做什么跟现在最大的不同是什么用一句话向一个陌生人介绍这个项目你会怎么说写完之后贴到白板上开始合并同类项。你会发现有人写的是用户感受有人写的是商业指标有人写的是技术愿景有人写的是行业地位。这些碎片看起来八竿子打不着其实正对应了我们前面讲的三要素受益对象、核心价值、成功标志。第一天不急着收敛只要能完成“把所有人脑子里的愿景碎片都摆到桌面上”这个目标就算成功。节奏上我建议控制在两小时以内中间休息一次。超过两小时人就开始疲劳讨论质量会明显下降。4.3 第二天收敛与共创把碎片拼接成方向共识第二天的任务是把第一天的碎片拼接成几个候选方向。我习惯先把所有便利贴按“对象 / 价值 / 成功标志”分成三组。分完以后让团队投票选出每个维度下最有共鸣的两到三个关键词。这个过程不需要太民主化不需要每个人发言表态因为愿景不是靠投票凑出来的而是靠讨论“碰”出来的。这里有个很关键的主持技巧当出现分歧时不要立刻追问“哪个对”而是换一个问题——“如果我们选了A那么哪些事情我们未来就不做了”这个问题特别能帮助团队看清选择的代价。我记得有一次项目里团队在“追求极致性能”和“加快业务覆盖”两个方向上僵持很久。后来我问了上面的问题选“极致性能”意味着宁可让部分地区晚半年上线也要打磨体验选“业务覆盖”意味着可能要暂时接受一些体验上的不完美。问完这一句团队自己就有答案了——那段时间他们手里的资源根本撑不起两条线同时推进必须二选一。第二天结束时目标是把方向收敛到一到两个候选框架用我们前面给的模板各写一版。4.4 第三天打磨定稿加上“成功的样子”与边界说明第三天是精修日。团队成员分别读一遍候选愿景逐字逐句找出“读起来含糊、让人产生歧义”的词。比如“高质量”这种词一定会被挑出来——什么叫高质量性能指标多少还是用户满意度多少把这些含糊词全部替换成有具体指向的描述。这个过程如果有条件一定要录像或者记录原话勾当。团队经常会改出两三个候选版本反复朗读比较直到所有人念同一句话的时候产生了相近的画面感。我曾经在一个项目里团队为了一句话的措辞争论了将近四十分钟。最后定稿的那一刻全场反而安静了——没有掌声只有几个人不约而同点了点头。那个瞬间让我印象很深因为我知道愿景真的出现了。定稿之后还建议补一个动作写下“成功的样子”和“这不是什么”。前者是愿景达成后外部可能观察到什么变化后者是明确排除的方向防止团队未来被诱惑偏离主线。这两段话平时用不到但关键时刻——比如有人提出一个方向非常好、但跟原愿景不一致的建议时它们是强有力的保护机制。4.5 常见痛点参与度低、分歧过大、被业务干扰怎么办实操中一定有人会说“这事跟我有什么关系”或者有人全程刷手机不发言。我的经验是不必强求每个人都在愿景讨论中热情高涨但要保证每个人的声音都有机会被听到。可以设定每个环节每个人至少发言一次主持人点名邀请而非逼迫。分歧过大的时候先回到第一天收集的用户反馈。用户怎么说、用户在意什么这些客观素材比个人偏好更有说服力。被业务侧临时塞进来的新需求打乱讨论时记录到“停车场”列表暂停讨论等愿景定稿后一起评估。这些执行层面的事情一两个团队踩坑之后总结出来能省后面无数次的返工。不管你是第一次开愿景会还是已经带过好几个团队把这几条细节记住都会让过程顺畅不少。5. 从愿景到落地让一句话真正影响每一天的工作5.1 把愿景翻译成产品目标再翻译成Sprint目标愿景写完了贴在墙上、写进文档只是第一步。真正让它产生价值的是后续的层层翻译。我在实际操作中会用一张大的“层级策略表”管理这种翻译关系层级关注周期典型表达团队的使用方式愿景一年以上“为某类用户创造某种改变”决策断分歧时使用产品目标一到两个季度“实现核心流程完整跑通”等阶段性质规划路线图、排定重点Sprint目标一到四周“完成注册与首单体验闭环”迭代排期与每日站会的焦点这个表不用做得特别正式但最好每个 Sprint 开始前团队能用几句话讲清楚“这个 Sprint目标是在为哪个产品目标做贡献而那个产品目标又是愿景推进到哪个阶段的证明”。这样讲了几个迭代之后成员自然会建立起目标感。5.2 一个真实项目里的层级翻译示例拿我之前做过的一个在线预约类产品来举例。愿景团队最后定稿的版本让忙碌的上班族在五分钟内完成线下服务的筛选和预约成为他们手机里最常打开的生活服务工具之一。临近第一个季度的产品目标完成核心预约交易闭环稳定支持每日一万笔预约请求不发生拥堵或服务不可用。对应它的一周 Sprint 目标打通从选门店到支付成功主路径上最后一个超时故障保证模拟环境下连续两小时无失败订单。你看这三层出来之后团队每一个人不论前端还是后端、产品还是测试都能清楚知道自己这一周的任务和愿景之间的关联。这个关联感就是团队内生动力的来源。5.3 愿景需要定期回访季度回顾时问三个问题愿景不是写一次就完事。外部环境和用户需求在变团队对愿景的理解也会随着项目推进而变化。我建议每个季度至少安排一次愿景回访不用很长二十分钟以内问三个问题这个愿景还成立吗我们最近做的事情哪些是推进愿景的哪些是偏离的愿景需要调整吗如果需要具体改哪里有一些团队用“北极星指标”来代替愿景我们讨论过如果北极星指标是一个明确的数字建议它更多对应产品目标那层而不是愿景。愿景关注的是“为什么”数字关注的是“多少”。两层都清楚团队才不会只盯着数字忽略了意义也不会只讲意义却没有衡量手段。6. 直接在实施现场能用的愿景工作坊的流程速查与常见问题排查6.1 一个可以直接搬到项目里的愿景工作坊日程表很多朋友看完前面的内容可能觉得“道理我懂了但真到现场还是不知道先做什么、后做什么”。我这里整理一份可以直接拿去用的三日愿景工作坊日程包含每个环节的时间和要产出的结果时间主题关键动作产出物第一天 10:00-12:00愿景碎片收集每人写3张便利贴轮流展示便利贴墙第一天 14:00-15:30分组归类按对象/价值/成功标志分组分类后的信息块第二天 10:00-12:00方向投票与冲突讨论最快找出最高共鸣选项无法议定则用“代价问题”探底候选方向列表第二天 14:00-16:00愿景框架撰写用模板写2-3个候选版本候选愿景描述第三天 10:00-11:30打磨与朗读定稿逐字剔肉、替换含糊词、集体朗读最终愿景文本第三天 11:30-12:00补充边界说明写出“成功的样子”和“这不是什么”配套说明文档第一天宜放在一周的前半段精神饱满第三天一定不要放在周五下午否则人都不在状态。这是我血泪教训之一。6.2 典型问题排查愿景无人喝彩、愿景变成口号、愿景被频繁推翻问题一愿景写出来了但团队没人放在心上。大概率是愿景讨论时参与度不够或者写出来的东西不是大家认可的方向。这时候不要急着公示愿景应该重新召集一次小型工作坊聚焦在“价值”和“对象”这两个要素上再做一次对齐。问题二愿景越写越像口号起了反效果。这种情况要回头检查是否缺少“用户”和“改变”两个要素。口号和愿景的根本区别是口号不需要行动指引愿景必须给出行动的方向。可以用三要素模板重新裁剪把一切不可行动的词都删掉。问题三愿景老是被业务新需求推翻。要么愿景本身太脱离业务现实要么缺少边界说明。后者尤其常见。前面提到“这不是什么”这个边界清单就是用来在外部压力来临时保持团队定力的。如果愿景频繁被动摇先检查边界写得够不够清楚而不是急着改愿景本身。6.3 一图流愿景落地过程中的拦路虎清单这里把我在多个项目里反复见到的拦路虎列出来对照检查你的团队有没有中招产品负责人一个人把愿景定完其他人全程围观愿景开会时热情高涨开完会没有进入任何执行机制用词高度抽象团队各人理解完全不一致只做了愿景没有翻译到产品目标和Sprint目标从不回访愿景一年前是什么样现在还是什么样为迁就某些临时诉求而在愿景上打“补丁”越补越乱。这些问题就算不能全部避免至少要先看见。看见了才有机会修正。个人在实际带团队过程中最深的体会是愿景的产出过程往往比愿景最终的文字本身更有价值。因为那个过程逼着一群背景各异的人把自己对项目的理解、期待和担忧全摆上桌互相碰撞之后再重新拼出一个共同画面。这个过程一旦完成团队就不仅仅是拿到了一句话而是拿到了一种难得的默契。如果你正准备启动一个新项目或者发现现在的团队虽然忙忙碌碌但总觉得哪里飘着、使不上劲我建议你先别急着优化流程、调整排期。先花一个下午认真回答一个问题我们到底在做什么为什么这件事值得我们投入那么多时间。答案清晰了后面的路会顺很多。
