针对海量的需求，产品经理或项目经理没有相应的规划，需求是提了，那什么时候做？什么时候上线？哪些需求先做？这都是个问题。
比如下面的某需求列表的截图：
虽然对这些需求标记了优先级，但没有规划出具体的研发周期。
存在的问题
当公司或团队规模较小时，工作随意而快捷：客户早上提了需求，产品经理在黑板上写写画画，不必写正规的 PRD，直接和研发人员沟通就行；不必做回归测试，产品经理简单试试功能，晚上请研发工程师操作，产品就能上线了；不需要运维部署，速度快，效率高。这种现象在初创团队和创业公司中很常见，业务开展初期，问题多，想法多，市场变化快，没有条条框框的约束，拼的就是速度！
随着公司规模变大，团队人数增多，作坊式工作方法不再适用：缺少流程制度，会让多人协作变得混乱失控；没有统一优先级裁定，会让跨部门项目引发争执；没有需求管理规范，会让业务部门抱怨产品研发部门配合不力，产品研发部门抱怨业务部门不靠谱，团队关系剑拔弩张。
需求太多：怎么排优先级，哪些需求要先做？
规划凌乱，没有目标：接收过来的需求太碎，不知道产品的目标和规划是什么，容易让一线的产品、开发等角色陷入漫无目的的状态；就是一直在工作、在开发，但对产品的长期规划不清楚、不明朗；
需求太大，开发周期太长：长时间的研发周期，容易让产品团队和研发团队疲惫，同时较长时间内看不到产出；
上线时间不明确：这里跟第 1 点是类似的，这么多需求，是全都做完上线？还是做完高优先级的就上线？还是说什么时候做完，什么时候上线？
需求饥饿问题：有些比较低优的需求，常常会被高优的需求插队，导致这些低优需求一直排不上、无限被延期；某天忽然想起这个需求了，然后又手忙脚乱地进行开发；
针对需求太大、开发周期太长的问题（第 3 点），稍微再展开说下。有的决策者认为开发一个需求也是开发，同时开发多个需求也是开发；虽然「可能」最终的上线时间是差不多的。但实际上这两种开发模式是完全不一样的，所谓“一鼓作气、再而衰、三而竭”，更长的研发周期，意味着研发同学投入的时间更长。一是容易让研发同学疲惫；二是让后续阶段的同学等待时间更长；三是更长时间内看不到产出；四是研发功能太多，每次都做出个庞然大物出来，再进行测试和上线，容易导致研发和测试同学忽略很多细节（非有意，只是事儿太多了），产生更多问题。
比如一个需求的上线周期是两周（开发+测试+上线），但多个需求糅合到一起开发的周期可能是三周或者四周，甚至更长时间。两周上线一次的节奏，老板和用户更能及早地体验到新功能；但对于四周的上线周期，老板和用户则需要等待更长的时间，老板们甚至觉得这 1 个多月都在干啥了。
这种情况下，如何才能保证产品研发团队高效运转？如何保证软件产品能够按计划交付？如何让用户满意？要解决这些问题，就必须从作坊式的生产模式转变为标准化、专业化的生产模式。
优秀的项目管理是互联网公司在复杂环境下保证软件开发按计划推进、落地的关键，也是保障规模团队的产品研发效率和质量的核心要素。
双周迭代
过去版本发布没有控制节奏，有需求、缺陷完工了就安排上线，可能极端的情况是一天发几次；有时候连着做好多需求，研发好几个月再上线。上线时间不规律
双周迭代，顾名思义，是以双周（两个星期）为周期，完成一个迭代周期的产品开发流程，不拖泥带水，不拉长开发周期。在双周迭代的模式里，在研发人员还在开发当前迭代的功能时，产品经理就规划好下一个迭代的需求，工作交替进行，这样能保证设计工作和开发工作无缝衔接，在一个合理的时间周期内快速实现软件产品的升级迭代。它是软件开发中最常见的软件敏捷开发方式。
不过迭代的周期也不必一定要固定成双周的时间，得看团队和产品迭代的节奏，也可以实行单周迭代或月迭代。
适合什么场景
「双周迭代」适合什么项目和团队呢？主要是用于长期迭代，并且需求和问题比较频繁的项目。短期项目或者较长周期才有需求的，不适合迭代模式，比如一个极端的例子，公司官网几年才需要一次更新的这种，就不适合。
尤其是 APP 的发布迭代，尤为明显。因为 APP 的发版比较麻烦，任何小问题的修改和调整，都得需要发版，而发版还得需要各种 APP 商店的审核，上线周期尤为漫长。
比如我们就固定双周的周四封版发版，能在这个版本内开发完毕且测试完毕的，就放在这个版本迭代中；否则就放到下个版本迭代中。若自己作为乙方，本身就比较弱势，在规划迭代中的需求时，请给自己留出足够的时间，来应该甲方的各种要求。
在双周迭代模式中，产品经理和研发人员能够更加聚焦当前周期内的任务，而不会被已经上线和未排期的任务产生干扰。并辅以「故事墙」、「甘特图」等功能，可以只看当前迭代周期内的任务完成情况。
如何执行
假如我们要执行双周迭代的制度。应该如何执行？
双周迭代的开发周期是：单周开发、半周测试、后半周上线，如第 1 周开发，第 2 周的 1-3 天测试，周 4 上线。当然，每个需求的开发难度都不一样，有的可能 1 天就开发好了，有的可能需要 5-6 天的工作日；同时，也并一定当前迭代所有的需求都一起放到第二周的周 4 上线（理想情况下是一起上线）。具体问题、具体分析。但总得来说，本迭代周期内的所有需求和问题，尽量都要上线。
如何执行：
产品拆分需求，将需求拆分到「单周开发、双周上线」的粒度，如果不行，就继续拆分； 按照需求的轻重缓急，将需求进行排序；
有个需求池，将拆分好的需求放到需求池中，等待评估排期；
在下一个迭代周期来临之前，产品和技术一起研讨，每双周或单周评估一次，评估下一迭代或下下迭代中，要排期开发的需求；
在进行排期时，一定要预留出部分的时间，来处理突发事件或技术需求，如甲方的个别紧急需求、线上重大 bug 等。还有一些开发自己的需求，比如一些性能优化、数据迁移、服务器部署等等。
可能存在的问题
前期在刚执行双周迭代模式的时候，肯定多多少少存在一些问题，比如
单个需求拆分不合理，导致开发时间过长，本次迭代内无法上线；
都是紧急需求，都想放到当前迭代中，导致该次迭代中分配的需求太多，做不完；
当前迭代的需求太少；
临上线前发现某需求有问题，是强行上线，还是下个迭代再上线；
不过几次迭代后，大家也都有经验了，在拆分需求、评估需求工期、分配任务时，就会好很多。
虽然可能会有些问题，但我们总得要迈出这一步。
双周迭代真的这么神奇吗？
有些人可能有疑惑，就区区一个「迭代」，真的能解决这些问题吗？
其实任何方案只是计划或规划，最终还是要看团队的执行效果。要是所有人都不当回事儿，还是按照自己的节奏走；或者已经排在这个迭代中的需求，要么不想做，要么做的一堆 bug。那要是保持这些心态，什么开发模式都是扯。
在没有规划的开发团队里。研发人员不知道产品经理都排了哪些需求，总不能每次来一个需求就扔到群里；研发人员对负责的产品的长期规划，就没有很好地认识。同理，产品经历也不知道研发团队什么时候能做这些需求，什么时候能排上期（毕竟之前已经往群里扔了好多需求了）。产品经理应当知道所有需求的轻重缓急，应当对产品有个未来的规划。如果所有需求都是紧急需求，那就相当于所有需求都不是紧急需求。
其实无论是「双周迭代」，还是「单周迭代」，抑或是其他开发模式，都是为了需求可控、有计划。项目管理的核心目标，是平衡好软件产品交付中的成本、时间和质量三者之间的关系。在现实中，这三者往往不可能兼得，但我们总是希望通过各种科学的管理手段，尽量确保软件项目能够在可控的成本范围之内，符合质量的按期交付。
项目管理软件
我目前接触使用的几款软件，在敏捷迭代开发模式中，表现的都好挺不错。当然，还有很多其他的项目管理软件，只是本人并没有深入地了解和进行体会。
tapd
企业微信中内置一个「tapd」的应用，tapd 是腾讯高效协作平台，凝聚腾讯多年研发协作经验。提供看板、文档、迭代计划&跟踪、产品需求规划、缺陷跟踪管理等丰富功能，帮助团队可视化工作进展、沉淀分享项目知识、提升团队协作效率。
若公司本身就是在使用企业微信作为协作沟通软件，那 tapd 就更方便了。tapd 除了他的功能比较齐全而且免费外，也在企业微信的生态体系中，默认使用企业微信的账号体系，无需注册，并且在需求单、bug 单发生变更时，能够及时给相关人员发送通知。这里多一嘴，我建议各个公司，如果有条件的话，一定要更换成企业级的沟通协作软件，比如企业微信、钉钉、飞书等。因为这些企业 IM 不只是单纯的聊天沟通，他更是一个完整的协作平台。参见文章建立以企业 IM 为中心的沟通协作模式。
企业微信的「tapd」应用默认是专业版，完全免费。关于迭代功能的使用，目前已足够使用。但还是缺少一个甘特图的功能，这个得需要升级到企业版才能使用。各版本功能的对比：https://www.tapd.cn/version。
在 tapd 中还可以调整和增加工作流，使所有流程都清晰可控。如下图，我自己又新增了「测试中」和「待上线」两个流程。
ones
ones 是多种功能的集合，项目管理仅是众多功能中的一项。若团队中使用 ones 来做项目管理，其他功能模块也都能在这个生态中联动起来。
同时，项目管理中的需求还可以跟 wiki 进行关联：
像各种维度的数据的统计，它也都是有的，这里就不一一截图介绍了。
也有各种插件可以来对接钉钉、飞书、企业微信等通知功能。
