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. 优化分工

1)每个迭代须有负责人

明确了责任人之后,该责任人对整个过程进行统筹,可以是产品经理、技术经理,也可以是业务人员(懂IT项目过程的最好);否则每个流程都是独立行走的机器,最后的交付变成了孤儿,nobody cares,结果就是所有人不甘的泪水。

2)尽量避免每个人身兼多个角色

当前对于项目和产品没有做明确的分工,金额较大的项目,一旦立项,就得走另外一套复杂的流程,需专业的项目经理带;同时如果又要应对日常流程复杂的双周迭代交付,工作量可想而知;当然这个跟部门的人员编制有关,也要看机缘去适当扩充人员,如今疫情大环境下,更慎重了。

3)产品设计与项目管理职责区分

一般产品的一期上线之后,宣告本期项目结束,就进入正常的产品线迭代升级期,可以使用双周迭代的形式推进。

需要注意的是,切忌常以交付项目的思维交付产品,项目管理是过程管理,讲究进度、成本、质量的平衡;而产品功能的迭代,更多的要考虑运营部门、关键用户的需求。

在产品规划、设计、定框架、定型的环节,如果过多被项目管理的思维束缚,做出来的产品通常会不符合预期、不好用,给下后面的迭代埋下难以填补的深坑。

2. 简化流程

当前的流程,在有限的双周时间内,无疑是过于冗长的,可适当进行缩减;例如使用PDCA法、ECRS法分析,设置价值点,分析流程节点的价值,没有存在的意义的节点即可认为是无关紧要的环节,直接去掉,减少无谓的重复工作;另一方面,进行适当分门别类,不搞一刀切,该简的简,该繁的繁。

该项实施起来并不容易,因为需要从部门层面去推动,近150号人参与其中的流程,不是说推就推的。

在制定流程过程中,但凡不同的角色充分参与了,也不至于干起活来这么痛苦;当然有的人就是即使被叫过去了,也没有利用好参与者的角色。

所以部门层面去发动、制定流程,相对而言,至少能解决大部分人的痛点;更重要的是很多经验不是一蹴而就的,更多的是从负面的经历获取的经验值更高,这也是激发我写这篇文章的初衷。

最后,思考是一切的起点。

以上,欢迎留言讨论指正。

 

本文作者 @Daylight

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部