备注说明：相关总结属于个人学习笔记，请勿商用，感兴趣的可在极客时间订阅该《乔新亮的CTO成长复盘》专栏学习，谢谢~

例子：
1.老板要你自研一款分布式数据库，决定让你来负责项目实施，一个月能不能搞定上线？ 你为了表现咬咬牙加班搞一个月，结果延期了，自己也累死。
2.公司的新产品要上线了，老板和产品经理们一同规划了一艘“航空母舰”：功能极其强大、性能业界领先、UI 非常漂亮，同时希望一个月就上线。结果呢，团队奋战了几个月，不但产品的设计和研发处处受阻，上线时间还遥遥无期……

无论是什么问题，只要存在，就一定有其合理性；
无论是什么问题，只要合理，就一定有专业的解决办法，因为那些专业人士总是能确保自己不掉入陷阱。

考虑限制

限制产品的输入与输出
如果你是产品的负责人：

• “输入”就是其他人对你承诺的“契约”；
• “输出”一般理解为承诺给用户的“契约”，指的是产品的对外能力，通常受到输入的严重影响。

输入：

比如，因为资金有限、服务器不够，所以我们无法承诺服务器在 300 万并发压力下保证 TP 90 = 2s，反之，只有当并发压力不高于 200 万时，我们才可以做出承诺。

两大维度限制：

• 业务限制
• 技术限制

业务限制

第一，Time（时间）、Resource（资源）、Scope（范围）三要素。
时间和资源的含义都比较明确。范围：为产品的功能规划或能力范围。范围出现变化，时间和资源也会相应出现变化。

第二，法律法规与政策限制。
好的产品设计是向善的，这是始终不变的。

第三，组织文化限制。
要符合公司企业文化

第四，地域因素限制。
不同地域也会对产品落地造成限制，具有高技术壁垒的底层基础设施产品，如果放在三线城市进行孵化，就会面临团队人才不足的情况

第五，风险承受能力。
薄利多销且过于依赖场景的业务，风险承受能力可能就会有所欠缺。比如今年，疫情对许多线下业务几乎造成了毁灭性的打击。

第六，市场因素限制。

技术限制

第一，遗留系统限制。
已经上线的老系统没有架构和文档。导致可能的变数。
新系统上线的时候，架构师的一个重要工作便是做系统的上下文架构设计、明确周边依赖，对于需要和周边遗留系统进行集成交互的组件或模块，要高度重视。

第二，团队技能限制
一些团队刚刚经历了“大换血”，新成员需要成长。此时若要保证产品输出不变，势必需要在其他维度有所补充。

第三，现有基础设施限制。
企业的竞争壁垒来自于产品，
IT 基础设施也是产品。基础设施强，团队能力就强，输入限制就少；
反之，基础设施弱，团队能力就弱，输入限制就大。
比如资源扩容的时间、访问数据服务的复杂程度、测试回归的能力等，都是非常重要的限制因素，对于研发速度、研发质量都有巨大的影响。

第四，标准规范限制。
一些企业会对研发语言有所限制。在某些情况下，精通 Java 语言的可用工程师比较少，但仍然要求用 Java 语言完成开发，这也会对输入产生限制。

第五，实施限制。
在实施方面，企业往往也会有所限制。比如，流程性的规定一般会对研发时间有所限制，做排期时需要纳入考虑。

输出：

输出，是给用户的契约，我们在产品思维、高可用设计等章节都有所提及 —— 要给出清晰、可量化的、符合 “SMART 原则”的契约。可以说是“对契约做限制”，也可以理解成“要让契约更明确”。

在对系统进行容量规划后，架构师要对超出处理能力的流量进行流量控制。这就是一种明确的限制手段；
例子：
如果机房只有一根光纤，就不要承诺系统 7 * 24 小时高可用；
如果生鲜产品需要早上 7 点送达目标企业，那么原则上，晚上 10 点后就不再接单……
这些都是限制，需要将其加入服务契约中，和用户形成共识，一诺千金。明确限制，是为了更好地服务用户，这是对用户负责的态度。

产品迭代背后的项目管理

在实际工作中，每个技术人员都会通过做项目的方式，参与产品的迭代。项目管理是一门专业度极高的学问。很多项目看似是因为一些意外情况延期、取消，实际恰恰是项目管理做得不够专业。

在一个项目组里，有四类角色非常重要，

• PM（Project Manager），项目经理
• PM（Product Manager），产品经理
• Architect，架构师
• Specialist，某一领域技术专家，比如 DBA ，分布式缓存专家，大数据专家等。

项目经理要做好 WBS（工作分解结构）。项目在落地过程中，所有的节点监控、风险管理等工作，都依赖于 WBS 。

WBS 有三大分解原则：

• 将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成
• 每个任务原则上要求分解到不能再细分为止
• 日常活动要对应到人、时间和资金投入

是需要专业能力支撑的。项目经理凭什么做拆解，并确定任务间的依赖关系？答案是，要么组织产品经理、架构师、技术专家，一起分解任务；要么一人身兼四种角色，独立完成。

WBS 制定完成后，产品经理以产品设计匹配业务需求，明确业务目标和业务流程；
架构师负责整体的框架设计，明确对应组件的整体视图；
技术专家负责扫清相关的技术难点。最后，Developer（开发人员）、Tester（测试人员） 进入项目，解决工作量问题。
到头来，我们要明白，以上工作都是在输入、输出受限的情况下，保证产品不会因为执行问题而违背契约。
反过来讲，执行团队本身也是输入的限制条件。当缺乏优秀的项目经理、产品经理、架构师或技术专家时，就要相应地继续下调输出预期。

项目同样受到 Time（时间）、Resource（资源）、Scope（范围）等多方因素限制，
在执行时同样要考虑限制条件，其本质就是有“不完美”成分存在的。
通过不断的迭代，产品最终变得完美，但项目不会一次就缔造一个完美的产品。
对项目期望的合理管控，本身就是在考虑限制。

延展思考：向上管理的“限制”问题
例子：
项目经理要立项研发企业 OMS 系统，但企业基础设施建设程度一般、团队技术实力较差，因此输出的契约是“三个月上线 OMS 系统”。老板看到了，可能就会问：“怎么这么久，一个半月行不行？”

如何做好向上管理？
要做好向上管理，第一要务是具备全局思维能力，和老板站在同一个维度思考。
所谓的沟通技巧，只能锦上添花，不能雪中送炭。
全局思维，是为了对齐目标、统一话语体系，但在具体表达的时候，一定要体现自己的专业性。
你的结论是：OMS 系统三个月上线；

老板的想法是：OMS 系统一个半月上线。此时，
第一：就是利用自己的专业知识和行业一般数据，将与 WBS 有关的思考和推断表达出来，尝试让项目按照正确的节奏落地。
第二：要从更快交付的目标出发，同时将多种限制因素考虑在内，比如团队疲劳度、凝聚力、激励措施等，和老板一起想办法，把自己想象成一个专业的 CEO —— 这公司就是自己的，进而思考应该如何安排工作、如何制定 WBS。

总结：

具备全局思维、让自己变得更专业、提升自己的表达能力，通过更合理的实现路径，最终达成业务的增长目标。
限制，在企业层级，也意味着在企业发展的某个阶段，选择放弃某类用户。有放弃，才能聚焦，进而倒逼自己看到全局，和企业目标对齐。聚焦当下，学会取舍；放眼长期，持续进步、持续改进。