关于B端产品双周迭代交付的详细思考

1、背景作者以前在一家传统制造公司工作过产品。负责的产品线可分为电子商务B端产品，业务量每周为数百万。根据交付质量和交付周期的一系列考虑，部门在一个阳光明媚的日子里实施了双周迭代。这有点像敏捷，但事实并非如此；熟悉敏捷的人都知道，敏捷开发是一个轻流程和轻文档，其过程曲线是螺旋上升的；我们公司实施的迭代实际上是一个小瀑布项目，按照两周的节奏交付。2、过去，VS现在简而言之，过去版本的发布没有控制节奏。需求和缺陷完成后，将安排在线发布，并根据优先级进行发布；当然，在不影响业务正常发展的情况下，极端情况可能是每天发送几次。如今，按照约定的节奏，只允许每两周发布一次，遇到特殊情况需要申请紧急发布。3、在实施双周迭代的前提下，要求严格按照瀑布式流程进行。具体来说，需求或缺陷需要从内部系统中收集，并在确定承诺解决时间后进入禅宗系统。未解决的缺陷延迟或未按优先排放要求扣除项目KPI；每一次双周迭代都需要在禅道上进行维护计划，并与相应的版本和要求相关联，版本日期与常规发布日期一致，命名应符合规范，否则视为不合规，扣合规KPI；所有需求都需要分解成一个解决方案、开发和测试任务，由不同的角色创建、分配和跟踪闭环；如果任务的开始和结束日期没有定义，审计部门也将其定义为不合格，并扣除合规KPI；为各需要建立测试用例，开发后提交测试单及相关用例，不需要缺陷；系统发布或数据变更，需要通过OA流程启动，并附上相应的测试记录清单，流程批准后发布在线；双周为小项目，需求研究、解决方案设计、设计评审、开发、代码评审、集成测试、UAT测试、在线准备、发布、发布验证，无法节省。整个过程似乎非常严格，有，连接，监控，我们在两周内做了很多事情；但实际过程中总是存在各种问题，我们的出发点是平衡需求和运维完成比例，严格控制在线缺陷指标；在这两个前提下控制版本发布的节奏，促进业务端养成真正有价值的需求习惯，在有价值的事情上使用资源。4、问题暴露实施约两个月后，我们遇到了一个非常头疼的问题：上线前一天总有问题遗留下来，无法按时解决；或者上线后质量令人担忧，欠技术债，下次迭代预留时间解决。如果迭代延迟，无疑会占用下一个迭代的时间，导致下一个迭代延迟和恶性循环；即使下一个迭代从需求池中切断需求，团队仍然感到困难，似乎很难实现预期的在线目标。我们做了相应的调整，但每个发布节点仍然像魔咒一样扣在头上，一方面焦虑，另一方面进退两难；不发布意味着延迟，发布意味着错误，欠技术债务。出来混不就是怕有人说你不靠谱，喊着要你还债。团队情绪难免会陷入负面，有时甚至会抱怨协调不够积极，信息失真或沟通不到位；但幸运的是，每个人都在面对，没有逃避，一直在积极寻求改进的切入点。5、作为个人经验者，问题点分析从事大量内部产品线的开发、交付和维护，也因为双周敏捷交付是一种值得分析的交付方式。这里的各种背景和现状激发了作者的兴趣，所以我做了一些总结和思考，抛出了几个问题：1。计划水平1）需求和问题数量难以平衡：每次迭代前评估需求数量和需求数量 bug数的工作量=现有可用人员的工作量，但通常情况下，迭代中间插入了许多需求，如领导要求的组织结构变化，从事活动等。；通常这种插入需求，要么拆分迭代，要么加班；这两种处理方法或多或少会对原来的迭代计划产生影响，影响越晚，执行效果越难有效控制。2)排列计划仅依靠开发人员的个人经验，未记录历史迭代的工作数据供参考；需求/bug的数量比例和人员分配没有形成经验教训数据，开发人员的绩效没有重新分析，没有数据作为合理调整的指导。2.执行水平1）具体迭代负责人组内多条产品线未同时明确操作。产品经理负责每个发布计划，计划或原型确定后移交开发，中间过程几乎处于自由放养状态。2.执行水平1）具体迭代负责人组内多条产品线同时运行不明确。产品经理负责每个发布计划，计划或原型确定后交给开发，中间过程几乎处于自由放养状态。因此，这样的图片经常出现在发布时间附近：A：xx需求完成了吗？B：做完了。A：赶紧发测试服，提前发了很多遍。B：哦(老系统，发布挺麻烦的)。A：为什么这个需求有这么多bug？你没有自测过吗？！你按计划来了吗？A：xx需求可以测试吗？B：兄弟，你的需求还没有开始做，暂时修一个bug，找几组人协调，不容易做啊(哭脸)。A：(一脸惊恐)。在设计和开发沟工作交替之后，每个人都专注于自己手头的事情。如果他们没有被指示管理，他们通常会先做自己的事情。因此，协调存在问题，导致交付前失控；我把他归类为控制层面，也就是说，团队需要一个人来监控和协调每个人的步伐。当然，这个人的负担并不轻。2)一个人做一系列的工作，比如商务谈判、项目管理、数据分析、测试，甚至做一些与开发相关的工作(很少)。重点是每周处理各种合规检查、数量和通知；如果您同时负责多个产品线和项目经理，可以想象，不容易，可能导致不能关注产品本身，不能充分了解用户关注的重点。当然，这里最大的问题可能是团队分工，合理的分工和人员配置可以发挥最大的效率。3)过程过于形式化。每次发布需要交付的文件和相应的bug管理系统都有很多记录项目需要注册，需要严格按照标准执行；例如，计划和版本的命名不能错，否则将扣除KPI。我们的反应是在每次发布版本之前，偷偷用SQL语句检查是否符合标准(无奈冷漠的脸)。如果你能说一个句子，你自然是最好的。如果你不能把它转换成一个句子，你很容易踩到雷声，你必须强行记住它；一旦出现了新的过程或标准，就需要大量的学习成本，特别是对于新兵来说，这是致命的——过程太长，太难理解，不实际参与迭代很难消化。六、双周迭代交付的改进和实施确实带来了好处。如果发布节奏统一，各IT产品线的研究、供应、生产和销售节奏几乎相同；我们还将根据规定的发布时间点组织系统交互会议，以确保发布不会相互影响。此外，业务部门还认可一套完整的需求/缺陷收集、解决和发布方法，减少了不必要的沟通；每个流程节点都有可追溯性和可追溯性。PMO和质量人员也有数据作为统计数据。指标相对完善，管理更加方便。作者提到了实施双周迭代方法时面临的一些坑和问题，使工作人员不满意，工作结果不令人满意。不能说这是一种完全合适和有效的方法。通常解决问题的第一步是找到问题，然后在不断调整和探索的过程中找到最好的方法，忽视问题是最大的问题；有很多方法可以找到问题点，关键取决于组织和执行。作者提出的改进，[重点]基于以下两个方面：1。优化分工1）每次迭代必须明确负责人，负责人协调整个过程，可以是产品经理、技术经理或业务人员（最好了解IT项目过程）；否则，每一个过程都是独立行走的机器，最终的交付变成了孤儿，nobodycares，结果是每个人都不愿意流泪。2)尽量避免每个人都有多个角色。目前项目和产品没有明确的分工。一旦项目批准，就要走另一套复杂的流程，需要专业的项目经理带；同时，如果要处理日常流程复杂的双周迭代交付，工作量可想而知；当然这和部门人员的编制有关，也要看机会适当扩大人员。在当今疫情环境下，我们更加谨慎。3)产品设计和项目管理职责区分一般产品启动后，宣布项目结束，进入正常的产品线迭代升级期，可以采用双周迭代的形式推广。需要注意的是，不要经常以交付项目的思维交付产品。项目管理是过程管理，注重进度、成本和质量的平衡；产品功能的迭代应考虑运营部门和关键用户的需求。在产品规划、设计、框架设置和造型过程中，如果过于受项目管理思维的约束，产品通常不符合预期，不易使用，并为以下迭代埋下难以填补的深坑。2.简化当前流程，在有限的两周内，无疑过于冗长，可以适当减少；如使用PDCA法、ECRS法分析、设置价值点、分析过程节点的价值，无意义节点可视为无关紧要环节，直接去除，减少不必要的重复工作；另一方面，适当的分类，不是一刀切，简单，复杂。这个项目实施起来并不容易，因为需要从部门层面进行推广，近150人参与了这个过程，并不是说推就推。在制定过程中，如果不同的角色充分参与，工作就不会那么痛苦；当然，有些人即使被称为过去，也没有充分利用参与者的角色。因此，在部门层面启动和制定流程至少可以解决大多数人的痛点；更重要的是，很多经验不是一蹴而就的，更多的是从负面经验中获得更高的经验价值，这也是我写这篇文章的初衷。最后，思考是一切的起点。以上，欢迎留言讨论指正。

以上就是关于关于B端产品双周迭代交付的详细思考的相关介绍，更多关于B端产品双周迭代交付的详细思考相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对关于B端产品双周迭代交付的详细思考有更深的了解和认识。