该部分主要阐述了，研发互联网类的产品与研发传统类的项目相比，几个重要的差异、特点，并着重对需求和迭代这两个存在较大差异的概念做了详述。

互联网产品的研发特点

相较于研发传统项目型的软件（通常为政企类的to B应用软件），研发互联网产品（多为to C）时，会具有下列特点：

  • 需求来源的渠道和种类具备多样性，提出的时机具备无序性（没有规律，随时提出），且优先级会随多种因素的变化而改变（市场环境、政策、战略、运营事件、权利等）；
  • 需求（客户价值）是持续、快速、迭代的完成交付，对时效（需求的交付周期）要求高，团队需要具备持续快速交付需求（客户价值）的能力；
  • 产品的发展速度快，相对项目型研发，计划性要求相对较低，不能通过大瀑布式的前期规划或统筹设计来推动迭代，而对适应变化、柔性的要求高。
  • 每次迭代，各组的工作量和工作内容可能会出现不一致，因此，团队成员角色及处理任务领域的变化频率较高；
  • 随着产品的落地、业务逐渐的明朗（走向正轨），产品的发展路线由“从无到有”，逐步向“从有到优”转变，对各环节（组）的人员能力需求，从产品初期的“复合型人才”，慢慢向“专业型人才”转变；
  • 生命周期相较传统项目长（持续性），随着产品功能、用户规模、研发团队规模的递增，具有较为明显的阶段特性，所处阶段不同，技术架构、组织结构、流程都会随之更迭，需要团队具备柔性（适应变化）；
  • 使用产品的用户量级大，对性能有阶段性的要求，在不同的发展阶段、不同的资源条件下，需要通过不同的方式进行解决；
  • 对产品的非功能性需求（包括安全性、可用性、可扩展性、兼容性等）要求高，用户分布而非集中式管理，不适用于一刀切的问题处理策略，出现问题的影响面大且可控性较低；
  • 对工程的可维护性要求较高，工作成果（代码）的被调整频率高，容易积累技术债，从而带来研发效能降低等问题；
  • 业务复杂度相对较低，技术复杂度相对较高，依赖三方服务较多，技术难点的占比较大，且会带来较多的不确定性；

需求 —— 产品研发的发动机

需求是用户或业务价值的载体，是团队间流动和交付的基本单元，是串联前后职能，对齐团队目标的重要依据。就像汽车的发动机一样，推动组织向前运转，推动产品/业务向上生长。

基于前文中提到的互联网产品的研发具备持续性、用户量级、业务环境和无序性等特点，需求来源的渠道和类型是多种多样的，且需求到达的频率也是“随机的”，因此，将从“需求类型”、“需求来源”、“需求占比”三个方面进行归纳，从而认识“需求”，剖析“需求”：

需求的类型

将需求的类型进行粗略的归纳，分为2种：

  • 业务类需求：这类需求直接体现用户或业务价值，创造业务能力。
  • 支持类需求：这类需求不直接体现业务价值，但可以帮助更快和持续的交付价值，满足系统的非功能性指标。

在实际应用中，会再进行细分，例如：

  • 业务类需求
    • 新功能
    • 功能优化
    • 使用体验
    • ……
  • 支持类需求
    • 安全提升
    • 性能优化
    • 研发效能
    • 模式规范
    • 基础架构
    • 工程质量
    • 辅助工具
    • ……

需求的来源

需求的来源具有多样性，可大致分为5种：

  1. 产品规划需求

    • 来源：根据业务或商业目标，进行规划和设计的需求。通常由产品团队结合业务团队的诉求、对用户的洞察、数据分析结果，进行设计后提出。

    • 频率：随时 —— 产品会按业务线/板块、功能模块完成设计后即提出，产品总监或项目经理可控，但优先级、需求颗粒度尽可能小等因素导致的不确定性增大，对于研发团队来说，即随时提出。

    • 处理规则：按迭代节奏（时间窗口或价值窗口）依据优先级规划，迭代过程中可能会调整。

  2. 用户需求

    • 来源：内外部用户提出的需求。通常由被动（用户直接提出）和主动（收集、调查、访谈）两种方式提出，由产品经理进行规划和设计。

      被动的用户需求来源又可细分为：客服、意见反馈系统、应用市场评论、内外部用户沟通等等

    • 频率：随时

    • 处理规则：按迭代节奏依据优先级规划，紧急需求随时插入，立刻响应。

  3. 政策或Boss需求

    • 来源：政府发布了与当前业务相关的政策及限制，或内外部领导对产品的直接期望。通常由业务口、相关利益方提出。

    • 频率：随时

    • 处理规则：通常该渠道的需求多为“重要且紧急”的需求，会插入当前迭代进行响应，若需要保障上线时间，则需要重新调整迭代中其它需求的优先级。

  4. 技术需求

    • 来源：为支持更高效、高质和持续的交付价值，或需要通过某个技术手段来支撑业务的实现，或技术领先等原因，而提出的需求。通常由技术团队提出，分为主动（性能测试、内部分析、峰值预测、系统监控等）和被动（线上出现了问题、监控报警、协作团队反馈等）两种驱动力。

    • 频率：主动驱动的多为可计划的，被动驱动的多为随时的。

    • 处理规则：对于一个有经验的团队来说，大多数技术类需求都会做一定程度的提前量（比如基础设施的建设和改进、持续交付和自动化的建设、技术架构的升级、工程质量的重构、关键技术的引入、非功能性需求的优化，如性能、安全性、可维护性等），因此，此类需求通常为重要但不紧急的，一般会根据“业务类需求”规划的轻重缓急，穿插进行。也有一部分技术需求是为了满足当下业务类需求的，此时，技术类需求与业务类需求形成关联及先后关系，需要在技术类需求完成规划预研后，再开展相关的业务类需求。

  5. 线上问题

    • 来源：一线渠道对线上系统反馈的问题。通常由用户反馈、客服收集、运维监控等方式提出。

    • 频率：随时

    • 处理规则：按问题的严重级别处理，级别高则立即处理，级别低则随迭代或穿插进行。

从以上这几个需求来源都会收集到或重要、或紧急的需求，需要统筹管理（透明的、基于统一的标准和规则）。

需求的占比

从需求来源和需求类型2个方面，划分产品生命周期的4个阶段，对需求的大致占比进行描述，无客观数据支撑，基于经验，仅供参考。

意在通过不同需求在各个阶段的占比，体现出不同阶段团队关注点的变化方向。

  • 各需求来源的数量在单个产品生命周期中的占比

    0-1 前期 中期 后期
    产品规划需求 > 60% > 30% < 40% < 10%
    用户需求 < 5% < 30% > 20% > 40%
    技术需求 > 30% > 20% > 30% > 40%
    线上问题修复 0% < 10% < 5% < 5%
    政策或Boss需求 < 5% < 10% < 5% < 5%

  • 各需求类型的数量在单个产品生命周期中的占比

    0-1 前期 中期 后期
    业务类需求 ≈70% ≈70% ≈65% ≈55%
    支持类需求 ≈30% ≈30% ≈35% ≈45%

这里所说的产品生命周期，与用户和业务的增长规模相关。当一个产品达到了一个瓶颈状态，没有新的业务和新的用户进入时，不是本文关注的领域。

迭代 —— 产品研发的变速箱

什么是迭代

从需求被选择直到需求发布上线，是一个完整的需求交付周期，又称迭代。它就像汽车的变速箱一样，控制着产品前进的节奏。

产品经过一个集中开发期上线后，进入到一个长期的，持续增加功能，优化功能的阶段，需要通过定期或不定期的小迭代，完成产品的生长。一次产品迭代至少对应一次产品发布（也可能是对内灰度发布，但一定是走完了整个研发流程），至少完成一个完整的需求/功能。

与传统项目的对比

互联网产品研发的过程，多会弱化统筹式的系统分析设计和集中式的测试，而是对规范进行把控，将细节的设计和质量的把控放权到执行团队及执行人，具体执行人对需求的具体实现方式有更多的选择权和决策权。

需求流转过程中各个阶段在整体工作量的占比，如下所示（与项目型软件对比）：

项目型软件 互联网产品
需求策划阶段 50% 60%
软件设计阶段 20% 8%
软件开发阶段 10% 20%（其中：7成思考、3成编码）
软件测试阶段 10% 10%（占迭代时长）
总时长会与开发阶段重叠
验收交付阶段 10% 2%（自动化程度高）

此表仅做对比示意，互联网产品与项目型软件存在本质区别（详见“互联网产品的研发特点”），很多工作流程和节奏均不同，且各角色不只是参与其中一个阶段的工作，不适合作为实际的工作量比例划分依据。

为什么迭代计划难以评估

在规划产品迭代的时候，大家都会关注迭代的计划（什么时候能完成），但是规划、计划、实际交付之间的不一致，一直是管理软件研发过程的主要痛点之一。

Hired发布的《2019年软件工程师行业状态》调查报告对开发人员的好恶有下列描述：

38%的受访者表示他们最大的不满是不切实际的最后期限。

63%的受访者表示宁愿早期早点完成工作，也不愿意睡懒觉或加班熬夜。

产品迭代周期的规划，与业务需求规划的粒度相互影响，需求粒度又与需求响应速度成正相关性，需求粒度越小（迭代的频率越高），需求的响应速度越快。

通常，管理层或业务部门会在下列时机索要上线时间：

  • 提出需求（向产品经理澄清）的当下
  • 当知道需求即将规划（仅做需求选择）至某个迭代时，但未完成需求的产品设计时
  • 当需求完成澄清（产品向研发团队澄清）的当下，未进行软件设计时

通常，迫于压力，产品或研发团队只能拍脑袋给出一个时间。

那么，为什么软件研发的计划这么难以评估呢？

产品经理在进行产品迭代规划（需求选择/版本规划）的时候，对于需求的发布周期是拿捏不准的，没有确定需求的边界，没有细化的需求分析，没有经过系统设计，没有确定开发任务，与开发团队初步商量后，开发团队给出了一些意见，但其实也是不准确的，绝大多数情况下，只能对需求的技术可行性和技术难易程度做出粗略评估，这个阶段去做计划评估，大多基于经验拍脑袋。

当需求完成分析设计后（有了需求的“原型设计”和“UI设计”），与研发团队进行了需求澄清，进入到系统设计阶段。开发团队会根据需求，进行系统分析设计（通常是软件概要、测试用例的设计），软件设计阶段完成后，进行评估时，评估人通常为执行人或其组长，评估人通常需要理解需求、理解设计、按自己的能力，给出工作量的评估（这个评估只是对开发任务的工作量评估，并未考虑其它因素），这个阶段的评估对计划有一定的参考价值，但依然还是不够指导计划落地，因为相关任务分配到具体实现的人手中，不同的人有不同的思维方式，对同一个事情的认知能力和工作能力也不同，实际动手做的时候又会发现因没有想透的点而导致的坑。

再考虑互联网产品的特点，需求多样且随机，总有任务会插队进行，打乱节奏。各种操作下来，结果就是要么加班加点，要么计划变更。

为了让计划看上去更有效，大家在评估的时候倾向于采用放大工作量的方式（潜规则是你认为可以完成的时间 × 2或3）。大家本应该去找到自己喜欢、擅长的事情，去发挥价值，获得价值，留出来的时间去提高自己，分享经验，结果却成了工作量的买卖，而且过程是痛苦的。计划的有效性和价值就有待商榷，因为，永远不变的就是变化。

本质原因分析

产品的研发是一个偏重脑力劳动的过程，产品经理、程序员7成的时间是在思考。

正常来说，程序员7成的时间是在思考如何设计程序、问题的解决方案及学习解决问题相关的知识（这跟做数学题时的演算有点类似），实际编码的时间只占3成。国内有很多公司承接对日软件外包的工作，他们的计划性是很强的，原因是这些公司所做的工作就是上面所说的那3成编码的工作，而那7成的工作，计划性是偏弱的，因为这类工作所需成果的主要目的是要设计满足需求的程序，满足系统的非功能性需求，并减轻技术债的发生。

程序员（执行人），在软件开发阶段的工作过程中，思考时间与编码时间、编码量，目标准确性、成果质量都存在相关性：

  • 思考时间与编码时间和编码量，在个人的思维极限以内，存在负相关性，思考时间越短，编码时间越长，编码量也越多（包括返工次数）。

  • 思考时间与目标准确性和成果质量，在个人的思维极限以内，存在正相关性，思考时间越长，目标准确性越高，成果质量也越高。

评估脑力劳动要比评估体力劳动复杂、不可控，这里也一定程度的说明了，为什么计划难以评估。

如何提高迭代计划的有效性

想要提高计划的有效性也并非没有办法，对于软件工程来说，核心就是要有足够详细的设计，把过程中的不确定因素都在设计过程中排除，可以让其他人在执行的时候“照本宣科”。

而“系统设计的详细程度”、“开发周期的评估准确性”、“成本”这三者是成正相关性的，详细程度越高，需求开发工期的评估准确性越高，迭代计划（需求组合后）的准确性也越高，但需要更多的成本（更多的时间、能力及数量更高人力）来为准确性买单，且会带来需求交付的响应周期变长等负面效果。

也就是说，若要控制精确，就需要投入大量的成本进行系统详细设计工作（类似对日外包），否则，就需要想办法适应开发周期的不确定性。

精确的资源过程控制，通常在互联网这类需要敏捷的团队组织中获得不了太好的效果，变化因素多（紧急的需求或Bug、政策性的变化、业务方向的转变、Boss命令）在互联网行业中也司空见惯，尤其是互联网产品的初始阶段（业务规划不稳定）。

去思考关注计划有效性的目的本质目的是什么，也许换个角度，从人性的角度，利益的角度去间接推动计划的有效性，会获得较好的结果，例如，将团队的利益与产品绑定，产品的成功即带动团队的成功，从而激发团队的内驱力。又如，关注点在解决问题，控制方向和范围，而不是计划的准确，通过看板、站会等敏捷工具，监测需求的流转，及时解决问题，推进需求的流转。

Kevin Kelly 的《失控》中，对上述很多现象发生的原因，给出了系统的定义和解释，推荐阅读。

本系列文章是一个不依赖实际产品、团队、技术架构的，进行了泛化、抽象化的一个指南性质的文章。将分几部分来阐述“互联网产品的研发模式和提升研发效能”这个主题的关键点及可行实践，意在抛砖引玉。在实际落地时，可参考此指南，根据组织、产品及团队的特性，进行组合或优化使用。

1.引言
2.几个重要的观念
3.形而上
4.设计组织架构
5.1.工作模式设计——需求处理
5.2.工作模式设计——迭代规划
5.3.工作模式设计——其它事务
6.建立可视化协作机制
7.进行评估和激励
8.附录