一种更好的规划、构建和交付产品的方式——Ryan Singer 与 Shape Up 方法论

摘要

Ryan Singer 是 37signals（Basecamp）的早期员工，在该公司工作了 17 年，亲历了从三人团队到成熟组织的全过程。他将这段经验提炼为《Shape Up》一书，提出了一套与传统 Scrum/Agile 截然不同的产品开发方法。Shape Up 的核心理念有三：第一，用胃口（Appetite）取代估时——先确定愿意投入多少时间，再反向设计可在此时间内完成的工作范围；第二，通过塑造（Shaping）环节，让产品、设计和工程三方在项目启动前共同推敲方案，将模糊的概念转化为可执行的具体构想；第三，将完整的想法交给团队，而非将需求拆成一百张工单碎片，让团队自主决定实现路径。六周（最多）是 Shape Up 的时间上限——足够完成有意义的成果，又短到可以预见终局。如果项目偏离轨道，不是简单地削减范围，而是退回塑造模式重新审视。Ryan 强调，Shape Up 并非只适用于 Basecamp 那样的特殊环境（没有销售部门、设计师写代码、创始人深度参与），他通过咨询实践帮助各类公司——从初创到千人规模——因地制宜地采用这套方法。对话还涉及项目经理角色的上游化转型、如何识别"该换方法了"的信号，以及与 Jobs-to-be-Done 框架的衔接。

正文

从 Basecamp 早期说起：紧迫感与高效协作的种子

Ryan Singer 的故事始于 2003 年。当时 37signals 的旗舰产品 Basecamp 刚启动，整个团队只有三个人：Jason Fried（创始人）、David Heinemeier Hansson（DHH，程序员）和 Ryan 本人（负责 UX 和编码）。三人高度整合，每个人都在写代码——Jason 也在模板里做 HTML 和 CSS，David 负责主体编程，Ryan 则与 Jason 进行那些简短却极其密集的讨论。

有两个约束深刻塑造了他们的工作方式。第一，DHH 每周只投入 10 小时。Ryan 回忆道，David 告诉 Jason 他想用 Ruby 来尝试构建 Basecamp——此前他们合作时用的是 PHP，而 David 爱上了 Ruby 这门语言。后来大名鼎鼎的 Ruby on Rails 框架，正是从 Basecamp V1 中提取出来的。但当时 Ryan 所知道的只是：每周只有 10 小时的编程时间。

第二，Jason 有一种强烈的紧迫感——"什么时候能看到成果？什么时候能交付？什么时候能让别人用上？"这种创始人的推进欲，加上 David 极其有限的时间，迫使团队必须极度高效地利用每一分钟。Ryan 和 Jason 的协作方式是在大本子上用记号笔画几笔，突然就找到那个想法——"这就是我们要去构建的东西"，然后等 David 下次上线时，能自信地说"这个行，这个做了我们兴奋的事"。

这种短促、高强度、协作式地"把想法敲定到足够清晰"的过程，正是后来 Shape Up 中"塑造"（Shaping）概念的种子。Ryan 强调，它不是一个人坐下来写文档，也不是做一堆需求，更不是做一份漂亮的 Figma 文件来代表一个可能的功能——它是"这个怎么样？那个呢？哦，也许这样可以！"那种在白板前反复碰撞、共同破解难题的过程。

从有机生长到体系化：Shape Up 框架的诞生

37signals 没有融资，Jason 和 David 的招聘策略极其缓慢——每次只加一个人，让组织自然适应。这种有机生长让自然的工作方式得以传播了大约十年。但大约在 2013 年前后，团队遇到了第一个"等等，发生了什么？"的时刻。

Ryan 记得那个项目：已经进行了六七周（当时六周周期还没有固化到 Shape Up 中），项目评审会上，一个负责一半工作的新人展示进度，预期是"差不多该交付了"，结果却是"这里有很多未解决的问题"，而且"我们提问题后也得不到快速回答"。他们开始意识到——这不但交付不了，甚至看不到终点。

那是 Ryan 意识到"这事不会自动、有机地一直延续下去"的时刻。团队需要弄清楚"项目顺利时为什么顺利？我们做了什么不同的事？如何将之体系化，使其在持续引入新人时仍然可复制？"Ryan 主动承担了这个责任，Shape Up 框架由此开始成形。

Shape Up 的三大核心要素

Ryan 将 Shape Up 概括为三个"大东西"：

第一，不见终点不启程。 团队不会拿一个大概念然后问"这东西估时多少？"不会说"我们需要建一个日历"然后做一堆 Figma 文件或写一堆需求文档再去要估算。他们反过来：先问"我们的胃口（Appetite）是多少——我们最多愿意花多少时间才能看到成果？"然后从那个时间约束倒推，设计出能在这个时间内完成的工作范围。Ryan 用买房买车做类比：你先有预算，再在预算内做取舍——想要更快的引擎就得放弃别的，想要好开又得考虑长途旅行的空间。经过大量实验，他们发现六周是能看到未来的最大窗口——六周之内，团队有较大把握可以反推出能在此时限内着陆的方案。

第二，塑造（Shaping）。 这是那些高强度协作会议的正式化：如何把固定的可用时间和可变的范围组合在一起，找出一个在业务愿意花费的时间内可行的方案版本。关键是产出要让所有人都能"看到那个想法"——不是笼统的"日历"或"仪表盘"或"通讯录构建器"，而是"双月点阵网格 + 可滚动的日程视图 + 新建按钮"这样具体的构想。

第三，把完整的想法交给团队。 不做"碎纸机"——不是把一个想法拆成一百张工单然后祈祷它们还能拼回去。而是给团队一个他们能理解的完整构想，让他们自己决定如何分解任务、如何跟踪进度。结果是团队——尤其是工程师——的参与度大幅提升：从"这是你的工单"变成"这是你理解的东西，现在你有机会发挥创造力来实现它"。

Ryan 特别强调，这三个要素可以选择性采纳。不需要全盘照搬——可以从团队最痛的问题入手。

胃口而非估时：为什么六周是上限

对任何经历过"估时两周的着陆页实际花了六周"的产品经理来说，胃口的概念极具说服力：与其估时，不如先说"这个着陆页对我们没那么重要，我们只投入两周，能做多少做多少，时间一到就翻篇"。

但 Ryan 指出一个关键细节：六周是上限，不是固定长度。如果一个增长团队的某项工作一周就能交付，完全可以用一周的时间箱。问题在于，六周这个上限做了真正的工作——它迫使团队问出好问题："我们到底认为能着陆的是哪一块？"如果设定六个月的交付目标，你根本无法预见所有要解决的问题；而设六周上限，团队有更大把握在进入之前就把未知的复杂度暴露出来。

对于功能开发——那些需要有足够价值才能卖得动的东西——两周几乎做不出有意义的增量。如果硬用两周冲刺，就会陷入"再来一个冲刺、再来一个冲刺"的循环，永远看不到终点。六周（有时四周）是一个足够长的块，让团队能真正推进到某个成果。

Lenny 指出一个隐含要素：团队承诺的是胃口，如果进度不达预期，不是延期，而是削减范围。Ryan 承认这很微妙——在现实中，如果你到六周末发现情况不妙，不能简单地把让这个项目有价值的核心范围砍掉然后宣布"我们六周内交付了"，那会摧毁士气。Shape Up 书中有一个"断路器"原则：如果项目六周内明显无法完成，直接取消并重新思考。但几乎没几个团队有这种魄力。Ryan 建议的更现实版本是：不要继续投入到一个看不懂的东西里，把项目从构建模式退回到塑造模式——换一批人、换一种对话、换一类问题去弄清楚模糊在哪里、到底没理解什么。

Ryan 引用 Bob Moesta 的话总结："你没法把十磅的东西塞进五磅的袋子。"不能拿一个不管多大的项目扔给团队然后说"自己想办法，六周内削减范围交付有意义的东西"。

塑造：不是写文档，也不是画 Figma

Ryan 指出，很多团队尝试 Shape Up 时最常见的做法是产品团队要么做一堆 Figma 文件，要么写一份包含大量需求和背景的 PRD。问题在于：当这些产物作为"塑造结果"交给团队时，项目往往会爆掉。Figma 文件与工程团队首次接触时会发生"现实检验"——很多方案行不通，得推倒重来。没有工程参与的全链路方案化，通常是一剂苦药。

更大的挑战是：UI 表面之下有太多看不到的东西——从 A 到 B 的流程怎么走？哪些逻辑分支？后台发生了什么？工程团队得戴上"X 光眼镜"去研究这些图，才能理解下面真正在发生什么。

Ryan 用家居翻修做类比：你可以有最漂亮的卧室效果图——床两侧从墙壁伸出的精美壁灯、完美的渲染和颜色——但如果你没检查那面墙里有没有电线，你可能得砸开墙壁重新布线，成本和时间会天翻地覆。

塑造做得好的标志是： 产出一份让工程师、产品人和设计师都说"我看懂了，我知道该怎么去构建"的图纸或示意图。Ryan 以书中日历功能为例展开说明。

日历案例：从模糊到清晰的塑造过程

在塑造日历功能之前，团队首先要"定界"（Framing）——把问题收窄。客户反复要求日历功能，但如果你直接建"日历"（等于 Google Calendar），谁也不知道边界在哪里。通过理解客户的真实需求，他们收窄到：客户的核心痛点是在现有的日程视图中只能看到已安排的事项，看不到空白时段——他们需要看到"空位"来安排新事项。这是一个很好的定界。

然后进入方案推敲。Ryan 给出一个经验法则：如果塑造得好，通常可以用不到十个"活动部件"来描述。 对日历功能来说：双月并排的点阵网格（类似 iPhone 日历月视图上的圆点），点击有圆点或没圆点的日期后，下方滑出一个日程视图显示该日已安排事项，加上月份前翻后翻导航和创建事件按钮——大致就是这些。这不是笼统的"日历"，而是"双月点阵网格 + 可滚动日程视图 + 在空白处新建事件"。这样所有人都可以就"这是否能在六周内完成"展开真正务实的讨论。

Lenny 总结道：塑造的产出本质上是一个用户体验层面的架构——关键屏幕、按钮和流程的线框/草图，加上关键组件——不是规格文档，不是最终设计，也不是一句用户故事。

Ryan 补充：如果团队要投入六周的工程时间，而方案还只是"也许有办法看到空白"，但"怎么做"是个问号，那就是在拿宝贵的时间冒险。六周工程时间的获取本身就不容易，公司里还有无数其他力量在争夺工程师。要让团队高效运转并创造性参与，他们需要在问题侧（关于空白时段）和方案侧（双月点阵网格 + 日程视图 + 按钮）都有清晰度——当然，高保真设计和编码中仍有无数有趣的创意任务，但那是一个他们都能装进脑子并据此工作的东西。

细节的度：因人而异的"清晰度拨盘"

Ryan 提到他在现实中最常看到的失败案例始终是"细节不够"——工程师跑回产品方说"从你这里得不到足够信息"。但他也理解为什么有人会紧张：给资深工程师规定"我建议你用这种方式来实现这个数据库模式的变更"，对方肯定不高兴。

关键洞察：团队需要的细节量是一个可调节的拨盘，取决于谁在团队里。 如果构建团队里有较初级的人，而塑造环节有资深工程师参与，那就可以给初级人员更多指引——"我们建议这样、这样、这样来做"——因为初级人员不知道怎么做时不会问，他们会隐藏自己的困惑，然后在项目后期爆发。反之，如果有顶尖人才、长期信任，当然可以留出更多空间。

另一个角度：如果构建团队中有人觉得自己应该在基本方案决策中有一席之地，更好的做法是直接把这个人拉进塑造环节，让他在那里发挥技术角色——前提是他具备相应的技能、视角和知识。核心原则始终是：如何把人放到能发挥其优势的位置上，给他们最大的创造空间，同时给予最大的清晰度。

"兔子洞"与"定时炸弹"：在启动前排除风险

Ryan 用一个 FinTech 案例说明塑造中排除风险的重要性。一家金融科技公司发现用户在注册流程的某一步大量流失——需要填写大量信息。他们发现可以从合作银行那边把数据直接导入，省去用户手动填写——提升转化率、消除一步用户体验——看似完美。

但他们没有去看的是：进入代码后，那一步注册实际上不是一个步骤，而是三条分支——取决于客户对接的是哪家银行。听起来很美好很简单，一进代码才发现"哦等等"，现在要做决策了。如果是在项目中期——已经分配了资源、大家已经承诺在做这件事、第四周才发现这个问题——那就是一个糟糕的处境。

但如果是在塑造环节——项目还没启动、还没开绿灯——有一位工程师在房间里，就像那个坚持先打开墙壁看管道才给报价的"脾气暴躁的老水管工"。他只需要片刻时间打开代码，找到相关部分看一眼："比我们想的复杂。"这时不是"完了项目更大了"，而是可以展开真正有价值的权衡讨论：三条集成分支，各自多大？只做一条算不算赢？三条全做要多花多少时间？值不值得？这就是在项目启动前讨论真正重要的问题——"我们不是在失败，我们在处理那些能让之后成功交付的难题"。

塑造会议的实战要领

Ryan 在"Shaping in Real Life"课程中举办工作坊，一个有趣发现是：人们不习惯这么快地工作。"我们现在在做什么？决策是什么？想法是什么？我们不是去画个东西、在文档上评论、明天再聚——我们现在从零开始有什么想法？"

假设问题已收窄（日历 = 看空白时段），业务愿意投入六周——那么我们能想出什么方案？关键是不仅要尝试想法，还要主动去打破它们：画出一个想法，让技术人指出"这个行不通因为……"，让产品人审视"技术上确实简单，但如果我走一遍客户场景，我们其实没交付那个价值"。

Ryan 还特别提醒不要在一条路上钻牛角尖——三个小时围绕一个想法的细节转圈。要会退后一步："这个方案是可滚动的日程视图——想法 A。那完全不同的方式呢？如果不要日程视图，纯月视图行不行？试试画出来。"

时间投入： 一次三小时的会议可以非常有生产力，帮助团队厘清已有的方案方向、主要的缺失部分（比如"日历点阵网格有了、日程视图有了，但多天事件怎么办？"）。然后可以暂停，有人做些草图或技术探针（Spike），再回来开一次三小时——或者第二天再来。如果项目不需要发明新算法、新数据库或新 AI 模型，而是在现有技术栈上组合构建，那么问题清晰、时机合适的情况下，大约三次会议就能得出结论。

参与者： 必须有产品人（理解业务背景和客户）、设计师、以及那位真正知道系统内"尸体埋在哪里"的资深工程师——不只是头衔资深，而是真正理解老系统如何运作、什么可行什么困难的人。如果只有产品和设计，方案等工程人看了之后再来一轮推倒重来，那就不快了。所有必要信息必须在同一个房间里。

协作工具： Ryan 直言在塑造环节不能用 Figma——不是 Figma 不好，而是高保真工具不利于快速协作。书中介绍了两种技术：面包板（Breadboarding）——描述"点这个按钮、走到这里、这个计算运行、得到这个结果、然后可以选择去这里或那里"；粗笔素描（Fat Marker Sketch）——用粗记号笔在白纸上画出关键交互和布局。关键不是做"模糊版的 Figma"——那种"仪表盘在这里、四个报告在那里"的模糊线框毫无用处——而是要让看的人说"哦，我明白了"。塑造完成的终极检验：把它交给一个技术人员，他说"我知道该怎么去构建了"。

从 Sprint Kickoff 到 Shape Up Kickoff：根本区别

在 Scrum 世界里，Sprint Kickoff 通常是由一个不做构建的人（Product Owner）创建一堆工单——写工单的人不理解涉及的实际工作，工单里藏着大量未知和定时炸弹。这就是 Ryan 所说的"碎纸机"——把一个完整想法拆成碎片。

在 Shape Up 世界里，Kickoff 交付的是一个已经塑造好的完整想法——"双月点阵 + 日程视图 + 新建按钮，去做吧"。团队是专业人士——就像建筑工人看懂图纸，你不需要告诉他"现在拿锤子去那边"。

Ryan 建议一个实用练习：在 Kickoff 时，让构建团队把塑造的结果画一个九宫格——九个主要实现范围。六周 = 30 个工作日，除以 9 ≈ 每格 4 天。这个简单练习能带来大量清晰度：团队能立刻感知"范围太大了"，也能发现初级工程师的实现思路可以由资深同事纠正——"我们以前做过，如果不用这个方法会碰到那个麻烦"。这些指导时刻极其宝贵。

为什么是九？Ryan 引用认知科学的"七加减二"原则——人脑一次能保持的工作记忆项数上限。九是上限，超过十个就进入了"工单地狱"——一百件事什么也说明不了。核心问题是：我们是否有一个能装进脑子的全貌？能不能"看到整座城堡"？

何时该换方法：痛点信号

Ryan 被问及"什么信号说明该认真考虑 Shape Up 了"。他沿项目全链路梳理了痛点：

最上游——问题定义模糊： 销售和客户谈完有了想法，CEO 淋浴时有了灵感，产品团队做了研究有了论据——但如果只是说"日历""仪表盘"而不协商那到底意味着什么，就会遭遇"不断膨胀的模糊团"，很难得出"对，这就是我们要去做的"这样确凿的结论。

中游——产出物不被吸收： PRD 写了很多真实重要的东西，但那种封装方式在那一刻不被吸收——你写了文档，但说句残酷的，谁真看了？即使试着看了，因为缺少塑造——没有收窄到"是这个、是那个、是那个，就是这样运作的"——读完也脑子里什么也留不住，只有一百万个要解的拼图碎片。Figma 文件则引来工程反弹——"做不了""不是这样工作的"。

下游——构建中问题不断： 本以为达成了共识，但越来越多问题冒出来，越来越多未预见的复杂度，感觉不是越来越接近终点，而是越来越难。

Ryan 还回应了"功能工厂"的批评。他理解这个批评的核心——没有协商价值和成果，只是有人说了就建，结果建出来没人用、产品膨胀。但他的观察是：如果你真有一个功能工厂——持续稳定地产出功能——你可能相当健康，只需要给工厂的入口换一种不同的原料。 大多数团队真正挣扎的是：东西不动、在拖、看不到终点、越来越倦怠。

从何开始：试点项目

对于想尝试 Shape Up 的团队，Ryan 不建议一上来就做六周全流程。他建议先找到一个试点项目：问题对所有人都足够重要、值得认真做；不太小（否则练不到新肌肉），也不太大；可能三到六周。先花力气收窄问题，然后开塑造会议，尽最大努力去做。

一个现实的约束是：如果工程团队下周就空出来了，那你只有一周时间来塑造。这种"工程即将可用"的实际压力，反而比"无休止地写文档、评论、反馈"的宇宙更健康——它迫使团队在有限时间内聚焦产出。

Ryan 最重要的提醒： 如果只采用六周周期而不同时采用塑造，结果就是"不知道该做什么"——六周内一边做一边摸索，时间耗尽，感觉像是暂时逃离了 Scrum 仪式，但并没有可庆祝的交付成果。

产品经理角色的上游化转型

Ryan 观察到，很多团队中的 PM 花大量时间在构建阶段内"追着项目跑"——确保人们不掉进泥里、不断推动进度，这更接近项目管理而非产品管理。

在运转良好的 Shape Up 团队中，PM 的工作重心向上游移动：不再是"如何让这个正在构建的项目不陷入困境"，而是"如何理解业务背景？如何收窄问题？如何与 CPO 来回协商，找到核心？如何论证哪一块问题值得花几周？"——深入理解业务、问题、客户领域，论证值得投入时间的价值切片。这才是 PM 在 Shape Up 世界中真正能贡献的地方，而不是做仪式主持者或流程看护人。

Lenny 将此与 AI 时代 PM 角色的演变类比：当 AI 工具开始帮你构建，更核心的问题变成了"到底该建什么？我建的东西对不对？可不可能成功？"——这和 Shape Up 中 PM 前置到问题定义和方案塑造的逻辑如出一辙。

Basecamp 的独特性：不是每个公司都能照搬

Ryan 坦承，离开 Basecamp 后他才意识到自己过去有多"特殊"：

• 每个设计师都写代码——不只是 HTML，而是能在本地运行应用、进入视图渲染的位置去调整样式。这意味着设计与工程之间没有那堵墙，没有"拿着 Figma 文件去找工程师然后希望被粉碎"的时刻。
• 创始人始终在问题定义中——没有远在天边的高管设大目标、中间隔一层 PM、再隔一层构建团队。Jason 和 David 始终在场，所以"我们在解决什么、为什么做、为什么要花这个时间"始终有极高清晰度。
• 没有销售团队——所有销售和营销都由创始人完成，意味着没有争夺工程时间的不同力量来源，没有"为了追加销售需要这个功能"的压力。
• David 做到了每六周工程团队都有清晰的跑道——用六周一段的方式，年复一年，工程产能始终聚焦于产品，而不是迷失在重构、基础设施和"技术债"中。

Ryan 强调，这不意味着你必须成为 Basecamp 才能用 Shape Up。但它意味着：如果你们习惯在工程和设计之间有一堵墙，那想开始塑造的人就得学会"把谁聚到一起、怎么开那个会、怎么互动"——那些在 Basecamp 可能都在同一个人脑子里的知识，在其他公司需要刻意组合。

从理论到现实：Shaping in Real Life 课程

书出版后，Ryan 开始与各类公司交流，发现大量"书里没覆盖"的问题。最典型的：项目总是超期，他问"给我看看你们的塑造工作"，对方给他看 PRD 或 Figma 文件——"那和书里说的不一样"。他进一步追问，发现根本没有工程师参与。

第一次咨询项目中，他帮一个陷入困境的团队选择了一位最适合的工程师参与到产品和设计的塑造中——"啊，我回到了我熟悉的世界"。这个发现成为他后续工作的核心：必须把工程拉进塑造环节。

他的妻子听到他每次通话都在重复同样的话，催他做个课程。这就是"Shaping in Real Life"课程的由来——专门解决书里没覆盖的现实挑战：如果你的设计师不写代码？如果工程时间极难争取？如果公司有 Basecamp 不曾面对的各种压力？

Jason Fried 发推说要出 Shape Up 第二版，Ryan 说他也看到了那条推文。他理解 Jason 想做的是更新"37signals 自己是怎么做的"——他们一贯的强项是非常清晰地展示"这就是我们的做法，爱用不用"。但 Ryan 认为，如果他再写一版只讲 Basecamp 怎么做，会错失大量机会——那么多人需要的是"如何让它靠近我的处境"。所以两条线并行：37signals 的第二版是"山顶上的灯塔"，Ryan 的课程则是"帮你从山脚往上攀的脚手架"。

与产品战略的衔接：需求侧与供给侧

Ryan 补充了一个重要链接：有时候项目交付不了、缺乏清晰度，根源其实比"塑造不够"更上游——输入端就不够清晰：我们到底不知道客户想要什么，不确定价值在哪里。

这里有一步 Ryan 称为"定界"（Framing）的工作——在塑造之前，先搞清楚"问题到底是什么"。这又连接到产品战略，连接到 Jobs-to-be-Done（待办任务） 框架。Ryan 在这个阶段会借助 Bob Moesta 的需求侧工作——弄清楚需求在哪里、人们在挣扎什么、他们试图搔的那个痒在哪里。

可以将整个链路理解为：需求侧（Jobs-to-be-Done / 客户研究）→ 发现机会和意义 → 供给侧（Shape Up / 塑造与交付）→ 将机会转化为可交付的成果。

Ryan 推荐两本书：Clay Christensen 等人写的《Competing Against Luck》适合理解 Jobs-to-be-Done 的总体精神；Bob Moesta 的《Demand-Side Sales 101》则更实操——如何做访谈、如何思考"挣扎时刻"（Struggling Moment）。虽然书名带"Sales"让产品人可能敬而远之，但它其实是对"人们到底在试图解决什么"的深度剖析。

咨询实践与最终建议

Ryan 的咨询通常从 CPO 或 CTO 联系他开始。最理想的情况是这两位已经对"需要改变"达成共识。然后一起确定：谁适合做试点团队？业务上有什么项目适合做试点？Ryan 帮助收窄试点项目的定界、指导团队学会塑造技能、给出塑造会议的反馈。

关于"什么阶段的公司最适合 Shape Up"，Ryan 说 37signals 直到不得不体系化时才体系化——创始人在时一切自然流畅，但当他们开始雇人、尝试放权、创始人退后一步时，问题开始浮现。最早的触发点是： 创始工程师第一次放手让新员工承担责任，或创始人/CEO 第一次把事情交给 PM——这些期望与现实的落差，就是问题的种子。

最常见的求助来自产品加工程约 30-50 人的团队——"我们以为把人放到了正确的角色、做了该做的事，但一切就是在磨，我们为什么这么慢？"另一个极端则是已运转多年、工程团队与产品团队各占一个山头、什么也出不了门的大公司——这时的问题已经在高管层造成紧张、互相指责，需要更艰难的对话来推进。

Ryan 最后的建议： 如果你还不熟悉 Shape Up，不必勉强——"等到更痛的时候再说"。改变很难，如果只是因为陌生就抗拒，可能问题还没到那个份上。但如果你已经试过各种方法、甚至换过产品负责人和 CTO 但问题依旧——"我知道这不舒服，我也不认识谁用过，但我们不能再这样下去了"——那就是该尝试的时候了。