B端产品双周迭代交付的思考.docVIP

B端产品双周迭代交付的思考 / 一、背景 笔者之前在职一家传统制造业公司做产品，负责的产品线可以划分至电商类B端产品，业务体量每周在几百万级别。 部门基于交付质量及交付周期的一系列考量，在一个风和日丽的日子，推行双周迭代。 有点类似敏捷，但实际不是；熟悉敏捷的人都知道，敏捷开发是轻流程轻文档的，其过程曲线是螺旋上升式的；我司施行的迭代实际就是小型的瀑布式项目，按照双周的节奏进行交付。 二、过去VS现在 简而言之，过去版本发布没有控制节奏，有需求、缺陷完工了就安排上线，视优先级安排发布；可能极端的情况是一天发几次，当然前提是不影响业务正常开展。 现在则是按照约定的节奏，只允许双周发布一次，遇到特殊情况则需申请走紧急发布。 三、过程执行 双周迭代的大前提下，要求严格按照瀑布式的流程来走，具体： 需求或缺陷需要从内部系统收集，并且确定承诺解决时间之后进入禅道系统，延期未解决的缺陷或者按照优先级排出的需求没上将扣项目KPI； 每一次双周迭代需要在禅道上维护计划，并关联相应的版本和需求，版本日期与常规发布的日期一致，命名需按照规范，否则同上视为不合规，扣合规性KPI； 所有需求需要拆解成为方案、开发、测试任务，由不同角色去创建，指派以及跟踪闭环；如果没有定义任务的起止日期也将被审计定义为不合格，扣合规性KPI；为每个需求建立测试用例，开发完毕提交测试需建测试单以及关联用例，缺陷则不需； 系统发布或者数据变更，需要走OA流程发起，并附相应的测试记录清单，流程审批完之后才能发布上线； 双周即小项目，该有的需求调研，解决方案设计、设计评审、开发、代码评审、集成测试、UAT测试、上线准备、发布、发布验证，一个都不能省。 看起来一整套的流程十分严谨，该有的都有了，该连接的都连接了，该监控的都监控了，我们也在短短双周内做了很多的事情；但实际过程中是总有各种各样的问题，我们的出发点是平衡需求和运维的完工占比，严控上线缺陷指标；同时在这两个大前提下控制版本发布的节奏，促使业务端养成提真正有价值的需求的习惯，把资源用在有价值的事情上。 四、问题显露 实行了约两个多月之后，我们遇到了很头疼的问题：总是在上线的前1天有问题遗留，无法按时解决；或者磕磕绊绊解决完，上线后质量堪忧，欠下技术债，又要在下个迭代预留时间来解决。 如果这个迭代延期了，无疑要占用下个迭代的时间，导致下个迭代延期，恶性循环；即使下个迭代从需求池砍掉需求了，团队还是感觉吃力，按预期上线似乎是一件很难达成的目标。 我们做过相应调整，但每到发布节点依旧如通魔咒扣在了头上，一方面焦虑不已，另一方面陷入发布还是不发布的两难境地；不发布意味着延期，发布意味着有bug，欠了技术债。 出来混不就是怕有人说你不靠谱，喊着要你还债么，团队情绪难免陷入负面，甚至有时候会抱怨相互之间协同不够积极，信息失真或沟通不到位；但好在每次大家都在面对并无逃避，一直在积极寻求改进切入点。 五、问题点分析 作为亲身经历者，做着对内较大体量的产品线发展、交付和维护的工作，也因为双周敏捷交付属于值得分析的交付方式。 此间种种背景和现状，激发了笔者的兴趣，就做了一些归纳和思考，抛出了几个问题： 1. 计划层面 1）需求和问题数量难以平衡：每迭代前评估需求进入数量，需求数+bug数的工作量=现有可用人天的工作量，但通常很常见的情况是——迭代中间有很多需求插入进来，比如某领导要求的，组织架构变化，搞活动等等；通常这种插入的需求，要不拆分迭代，要不加班完成；这两种处理方式都对原先制定的迭代计划产生或多或少的影响，越晚提出的影响越大，越难有效的控制执行效果。 2）排计划仅依赖开发人员个人经验，未记录历史迭代的工作情况数据进行参考；需求/bug的数量比例、人员分配未形成经验教训数据，开发人员绩效没有进行复盘分析，没有数据作为指导进行合理调整。 2. 执行层面 1）没有明确具体迭代责任人 组内多个产品线同时作业，每次发布计划开始由产品经理负责，方案或原型确定之后交由开发，中间的过程几乎是放养状态。 以致临近发布时间点，经常出现这样的画面： A：xx需求做完了吗？B：做完了。 A：赶紧发测试服啊，说了很多遍提前发啊。B：哦（老系统，发布挺麻烦）。 A：这个需求怎么这么多bug，您没有自测过吗？！有没有按照方案来啊。 A：xx需求可以测试了吗？B：兄弟，你的那个需求还没开始做呢，临时去修一个bug了，要找好几个组的人协调，不好弄啊（哭泣脸）。 A：（一脸惊恐）。 在设计与开发沟工作交替后，大家都各自专心忙着自己手头的事情，如果没被指明去管，一般当然是先做好自己的事情。 所以协同出现了问题，导致交付前发现失控；这个我把他归于管控层面，也就是小组需要一个去监控、统筹大家步调的人，当然这个人担子不轻。 2）一人身兼多职 产品要做商务谈判、项目管理、数据分