为什么产品经理需要关注开发模式

、为什么产品经理需要关注开发模式？

1. 开发模式即工作模式

首先我们要达成一个共识：产品经理除了收集分析需求、抛出草案、定方案、输出原型、prd、流程图、架构图等专业工作之外，还需要负责协调资源、上传下达等保障整个研发顺利进行的工作。产品经理是贯穿始终从头走到尾并对最终结果负责的人。

互联网软件研发周期中的各团队参与情况和当前项目所处的阶段，大略划分的话可以有如下关系：

完成软件开发所要进行的工作和各团队之间大致有如下关系：

为什么有交叉？

• 设计工作不仅仅是产品经理设计产品方案，拿到产品方案后研发团队需要构建同样重要的技术方案。
• 测试方面，测试团队肯定是主角，进行项目质量的整体验收。除了这些还有研发团队研发过程中的单元测试，提测前的整体自测，还有产品同学的辅助测试和上线后回归测试等。
• 至于部署方面，硬件方面的事情自然运维团队去处理，但设备选型则是技术方案的一部分。另外有的公司是技术团队负责发布代码，有的是运维同学进行发布。

各团队之间看起来相互独立，各司其职，实则紧密相连，不可分割。无论开发模式是不是技术团队该关心的事，它都不可避免地会影响整个研发过程。各团队为了消除这种影响，需要调整工作方式去配合，这样才能释放出相应模式的优势力量，达到整体最佳。

2. 熟练掌握开发模式的好处

第一：加入一个新团队，能识别出当前团队正在采用的开发模式，可以快速适应节奏展开工作，更顺利更少犯错。试想如果人家在采用敏捷开发，而你带着瀑布开发的思维投入工作并产出，团队首秀上来就挖坑，想想都觉得可怕。

第二：清楚团队当前工作模式的优势和局限，在局限性方面就可以提前做好准备，不至于当问题发生时措手不及，处于被动的局面被牵制住。问题的产生很有可能是团队工作方式的弊端带来的而非你个人能力的问题，这个锅不能背。

第三：以第二点为基础，清楚局限可以有意识尽所能去优化，无论对个人发展还是公司效率，都是极好的。

二、各开发模式相互对比

一款产品不是孤立的，它是和自身、公司、竞品、行业、用户群等相互关联的，共同作用下的一个结果，我们研发一款产品，是基于一定需求痛点，服务于特定人群的。在信息过载、要求快速响应的互联网世界里，开发过程的灵活性和用户参与程度被越来越多的关注和利用。

当下公司所采用的开发方式有N多种，每一种都是特定场景下的特定产物，没有绝对的优劣，适合最重要。我们先从操作灵活性、用户参与度两个维度对当下流行的开发模式做一下全局预览。

三、5种常见开发模式介绍

我们选取了4种典型的开发模式进行说明，这4种模式有的是默认选择的，可能你在用但是你自己没意识到；有的是当下热议的；有的是用于增加项目透明度可以随时引入新的变更需求的；有的是应对老板一声令下要求即刻上线的。

1. 瀑布式开发

各个阶段从上到下，一步一步地走，是不是很像瀑布，水从上流淌而下。

瀑布模型式是最典型的预见性的方法，是开发方法论的老大哥，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。只能一个阶段一个阶段的执行，不可回溯。每个阶段都需要独立评估，准确无误的输出，完整的文档。上一个阶段结束前，下一个阶段不能开始。直到最后部署交付，期间都拿不到切实可应用的项目。

这是大多数团队默认采用的一种模式，甚至常用到自己在用它，但是都不知道它就是瀑布式开发。采用瀑布开发方式的用户常见于新负责的项目经理因为这种方式对项目的估计非常方便。项目开发中涉及到的几乎一切都预先计划，从而便于确定预期的开发成本和开发时间，非常方便地把整个项目置于自己的掌握之下。

缺点也很明显，任何人都不能预知未来，做出来的方案也都不是完美无瑕，计划赶不上变化，每个阶段环环相扣，任何一个阶段出问题，都可能导致延期甚至项目失败。另外对于开发人员而言就可能显得太严酷了。因为测试过程在开发阶段之后实施，子系统测试所暴露的问题可能需要立即修改代码，而开发人员一般在同一阶段也会从事其他的开发任务，而所需要的软件修改可能会降低开发人员的生产率和工作质量，这样就显著增加了计划架构的成本。

2. 增量和迭代开发

增量和迭代其实是两种开发方式。

增量开发是把项目切割成N个相对独立的模块。像堆积木一样，每次迭代会增加新的软件模块，而在先前添加的模块中几乎没有变化。开发过程可以顺序进行，也可以并行进行，并行开发提高了交付速度。