负责的产品线可以划分至电商类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）一人身兼多职

产品要做商务谈判、项目管理、数据分析、测试等一系列工作，甚至做一些开发相关的工作（极少）。

重点是，还要每周应付各类合规性的检查、取数和通报；如果同时负责多个产品线和担任正式项目的项目经理，可想而知了，绝不轻松，可能导致的情况是无法专注产品本身，无法对用户使用关心的重点了解不够充分。

当然，这里最大的问题可能在于团队分工，合理的分工和人员配置才能发挥最大的效率。

3）流程过于形式化

每次发布需要交付的文档及需登记相应的bug管理系统记录条目较多，且需要严格按照标准执行；比如计划、版本的命名不能错，否则扣KPI。

我们应对的措施是每次发版本前，偷偷用SQL语句去检验下是否符合标准（无奈冷漠脸）。

能语句话的话自然最好，不能转换成语句的就容易踩雷，得靠自己强行记忆了；一旦有新的流程或者标准出来，都需要不小的学习成本，尤其是对新兵蛋子来说很要命——流程太长太难理解，不实际参与迭代很难消化。

六、关于改进

推行双周迭代交付确实给带来了好处。如发布的节奏统一了，研供产销各个IT产品线的节奏几乎一致；大家也会根据规定的发布时间点组织系统交互会议，保证发布不会相互影响。

另外业务部门也认可一整套的需求/缺陷收集、解决、发布的方式，减少了不必要的沟通；各个流程节点有据可循、有迹可查，PMO和质量人员也都有数据作为统计，指标相对已经很完善，管理层面方便不少。

笔者上面提到的是双周迭代办法执行时面临的一些坑和问题，让工作的人不爽，工作的结果差强人意，不能说它是一个完全适合、高效的办法。

通常解决问题的第一步是找到问题，而后在不断调整摸索的过程中找到最佳的方法，无视问题才是最大的问题；找到问题点了，方法有很多种，关键看组织力和执行力。

笔者提出的改进，【重点】基于以下两个方面：

1. 优化分工