关于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人参与了这个过程，并不是说推就推。在制定过程中，如果不同的角色充分参与，工作就不会那么痛苦；当然，有些人即使被称为过去，也没有充分利用参与者的角色。因此，在部门层面启动和制定流程至少可以解决大多数人的痛点；更重要的是，很多经验不是一蹴而就的，更多的是从负面经验中获得更高的经验价值，这也是我写这篇文章的初衷。最后，思考是一切的起点。以上，欢迎留言讨论指正。