一般的话，需求这里大的环节有：
- 产品内部评审
- 设计师内部评审定稿
- 产品与研发评审
- 单个需求细化
- 用例评审
开发过程中的差异，主要来源于职责划分，工程形态，基础建设上
- 工程形态：组件化/非组件化
- 基础建设：工具链、脚手架。研发效率其实不仅仅和团队的沟通效率有关系，基础建设其实占了很大的比重。
- 职责划分：性能优化，业务迭代。不同业务之间，都可能不一样。比如和政府对接，就会有很多紧急需求。经常要紧急合码，而且还没得商量。
- 个人成长，技术提高
- 保证不影响团队开发/提前暴露风险：准入
- 集成方式：按业务、按需求
按业务/需求集成方式对比：
- 按业务集成
- 问题暴露晚：产品在合入宿主之前，卡口相对宽松的。业务内合码的卡口，全凭业务自身对质量的重视程度。最终可能导致产品质量难以把控。
- 问题集中，不好拆分：集成时暴露的问题只能定位到业务方，而要进一步定位，需要依赖业务i进行拆分。虽然统一所有业务的基础合入流程也能细化一部分，但业务过多以后，也难以维护。
- 单个需求 delay 导致业务 delay：如果业务要等某个需求上车，就会直接导致版本 delay。
- 按需求集成：
- 集成成本高：一次业务的集成，被拆成了多个需求单独合入。每个需求都需要独立执行一遍所有的流程。
- 容易集中合码：众所周知，截止当天效率是最高的。如果业务足够独立，可以每个业务不同截止时间，来避开集中合码的情况。
- 问题零碎，精力分散
- 性能指标卡口
- Facebook 单元测试、自动化测试
- 灰度：周期、量级
- 关注数据
- 业务指标、性能指标
- 线上异常
- 风险应对