国企敏捷大冒险! | 第7期

2023-02-09 11:01:55
践行者
原创
99
摘要:让我们与资深项目管理专家王抒音老师一起聊聊她的国企敏捷之旅!


在国企内引入敏捷是怎样的感受?我们应如何使用敏捷思维为传统项目管理赋能?本期《践行者》,让我们与资深项目管理专家王抒音老师一起聊聊她的国企敏捷之旅!

一、国企敏捷大冒险


针对敏捷转型这一话题,王抒音老师认为不论是Scrum、XP还是LeSS,本质都是在解决项目中的某一问题时衍生出来的最佳实践。因此当自己进入国企的项目中时,首先要解决文档产出速度慢以及文档产出质量低的问题。在解决这个问题时,王老师开始在文档交付中引入迭代的实践,通过规划文档交付计划、固定的迭代周期以及设定文档的“DoD”、文档规范,来保证文档输出质量。

也正是在敏捷化文档输出流程的同时,王老师开始在国企内部、管理层中引入敏捷项目管理的概念,并进行了相关培训。事实上,当大部分的企业开始转型敏捷的时候,未必需要在最初就将所有框架、实践套进来,而是可以从一个小的问题点入手,通过实际效果突显敏捷的真正价值。

接下来到了第二阶段:在国企内引入敏捷。在这个过程中也相继出现了很多问题:


  • 敏捷项目所强调的快速迭代、快速交付和传统式项目所制定的里程碑相冲突怎样解决?
  • 在转向快速迭代的过程中,原有项目团队的协作问题如何解决?
  • 如何获得领导层的支持?
  • 如何获得团队成员的支持?
  • 如何在团队中引入敏捷文化?
  • ……
以上是敏捷转型过程中经常遇到的问题,在此次直播中,王抒音老师将上述问题的答案融进了自身的敏捷实践故事中,绝对满满干货!想了解国企内部实践敏捷的更多分享,欢迎大家扫描上方二维码观看直播回放~

二、问答实录


此次话题毫不意外地引发了大家激烈的讨论,在这一过程中,王抒音老师也对大家的问题进行了回答,和我们一起回顾一下吧:

Q1:国企有部门墙吗?需怎么解决?


A: 任何企业或公司都会有部门墙,需要去持续打破、持续解决。

作为员工来讲,要保障企业盈利,因为企业如果不盈利,我们自然而然就拿不到薪水,除非你换一家企业。当我们跟自己的领导或兄弟部门有一些摩擦时,尽可能要站在他们的角度上考虑,他们这个角色有这样的决策,最终的诉求到底能不能达到我们最终的目的,也就是实现企业利益呢?大家还是要本着帮助企业去解决问题,帮助企业去创收,更低成本地去交付项目,这个才是打破部门墙的一个很重要的原则。就像大河没有水,小河自然也就干了。

Q2:为什么要强依赖文档,是因为人员能力不足?


A: 首先对于大型项目来讲,文档的留存是非常必要的,我们不能简单粗暴地认为人员能力不足,其实更多的是项目本身的需要。

国企或这种大型的传统企业,他们的系统很复杂,背后涉及的审批流程、涉及到的合同金额,都是不允许出错的。这类企业在做一个项目,投入的成本会比较高,周期也会比较长,这期间难免会有人员的更替。文档其实是减少人员更替成本的一个方面,同时这样做也可以有效规避项目中的一些风险。在这样的项目背景之下,还是更多地依赖文档的。

当然,更多时候,我们可以根据项目的实际情况去看是否需要强依赖文档,比如我们能够用简单的用户故事把需求讲清楚时,文档可能就会变得更轻量级。

Q3:在敏捷中如何拆分较大、关联性较强的需求?


A: 需求拆分需要因项目而异,有的项目可以分模块,有的项目可以分流程,有的项目可以分业务,需要具体问题具体分析。当我们开始一个比较大的项目,如果它的需求关联性比较强,并且同时使用敏捷,在这两个因素都要存在的情况下,这时,我们首先要看它的关联性。如何保障某一个流程的关联性,保证它完整的基础之上,再去拆分需求。

关于更多需求拆分方法,欢迎大家登录融·软件项目管理实践库RRPL查看。RRPL中有很多种需求拆分的方法,大家可以在RRPL里找到相应的实践学习、参考。

Q4:在敏捷转型初期,如何获得团队包括老板的真心支持?在开发任务中,有什么好方法能让团队看到敏捷的收益?


A: 在敏捷转型开始前,我们需要问自己和问老板一个问题:我们为什么要做敏捷转型?是老板想做敏捷转型,还是我们自己想做敏捷转型,要先把这个要区分开。如果老板想做敏捷转型,我们需要跟老板沟通,明确为什么要做这件事,挖掘背后的原因和动机,再去做敏捷转型。这样会更多地得到老板真心的支持,因为他知道敏捷转型在帮助企业解决问题。

在我们做敏捷转型的过程中,我们也要让老板更多地参与进来,共同去推动这件事,通过这样的方式在公司上下达成共识,大家一起去推动敏捷转型。

Q5:敏捷中的角色和会议是否需要严格执行,在研发中需要特别注意的点有哪些?


A: 敏捷中几大角色与会议要根据项目的实际情况执行,虽然 Scrum Guide说,如果你没有全部执行,那就不能说是在做Scrum,但不做Scrum又能怎样?把Scrum中所有的框架和实践全部拿过来严格执行,就能真的敏捷吗?效果真的会好吗?不一定。也不要去纠结到底是不是在严格做Scrum,因为这只是表面上的遵守,倒不如把Scrum中的元素尝试做到位,真正理解Scrum的精髓,效果会更好一点吧。

研发中特别需要注意的,比如DoD(完成的定义)是非常重要的,因为很多团队还没有养成做DoD的习惯,而且DoD其实不是只给研发做的,需要研发、测试、产品同学大家一块去达成共识,这点需要特别注意。另外,研发同学是不是真的理解需求,这点也非常重要。

Q6:研发经理觉得拆分任务费时间,不愿意在系统上拆分任务,也不愿意用Excel维护怎么办?


A: 第一:我们要多跟研发经理沟通。对于研发经理来讲,做好任务拆分能够给他的团队带来哪些价值。

第二:我们需要深入了解研发经理不愿意拆分任务的根本原因,再针对这些原因去制定具体的解决方案。比如我们通过让项目经理去帮助研发经理共同去做需求拆分,尝试先帮他做,再让他自己做。

Q7:兼职如何平衡开发角色和敏捷角色的工作时间呢?


A: 首先,我在团队里遇到一种情况是:研发Leader和产品Leader会充当Scrum Master的角色。

找Scrum Master的时候,也通常会找那些开发能力比较强的,比如开发leader这种身份,他们其实是有余力去做这些事情的。

Scrum Master的职能是分阶段进行的。项目初期,可能会把主要的时间放到Scrum Master角色里边去;项目中后期遇到一些疑难问题的时候,也会花一定时间去帮助一线开发同学解决问题;项目后期,Scrum Master的角色又会多一点,因为要组织团队去做复盘,找到团队当中有哪些可以再去做提升的部分。不同的项目阶段,Scrum Master所投入的时间是不一样的,这样去分配会更合适一些。

Q8:国企敏捷能动得了绩效考核吗?


A: 这个需要我们先去了解国企的考核体系和绩效考核内容;领导是否重视并支持敏捷愿意将敏捷纳入到考核体系中去。由于不同国企的绩效考核体系算法复杂且各不相同,所以我们需要具体问题具体分析。

Q9:脚本是什么样子?


A: 脚本可以理解为一个简单的用户手册。首先是要分角色的,比如我作为一名招聘人员或者作为一名运营人员,我应该怎么做?能够看到什么东西?其次,脚本根据每一个企业的特性可以自定义。它的目的就是让不同产线的人能通过简单的脚本把系统使用起来。

Q10:敏捷对技术工程实践,如单元测试、自动化测试、重构是不是有强依赖或者高要求?


A: 这要根据团队的实际情况来定,重要的点是在于我们对敏捷的定义。敏捷的定义大家都清楚,可敏捷落到团队中就需要大家能达成共识的。

比如Scrum3355的角色划分,会引申出另外一个话题——敏捷的成熟度。当我们确定团队角色时,我们就认为敏捷的第一阶段的工作完成了。《敏捷宣言》联合创始人Dave Thomas讲过,敏捷最麻烦的事情就是想当然把敏捷当作名词了,但它应该是形容词。所以敏捷并不是一定要单元测试、自动化测试到什么程度,也许增加一个迭代,就已经比较敏捷了。

Q11:关于敏捷需求颗粒度,业内有没有最佳实践?


A: 敏捷需求的颗粒度,我们通常会按照两周一个迭代走,但是两周一个迭代,我们是定义为上线还是做到可供上线?这是要企业内部自己定义的。关于最佳实践,我理解敏捷需求的颗粒度两周可以完成,并且能够上线,交付到用户手中,我觉得这就算一个敏捷的最佳实践。

Q12:能否分享一个DoD的具体样例呀?


A: 举一个简单的例子:拿今天的直播来说,今天的直播成功与否要怎样定义呢?

可以有以下标准:
  1. 嘉宾准时到场;
  2. 直播间的网络顺畅;
  3. 小伙伴的每一道问题都能够回答且能得到大家的认可;
  4. 这次分享是否能给小伙伴解决问题和疑惑。
以上就是这次直播成功与否的DoD。同时,这些DoD并非始终不变,而是需要随着时间的推移不断地进行补充的。当然,DoD也是我们回顾会的一部分,可以在回顾会上来看DoD有没有需要修改的地方。

同时,当我们做产品的DoD时,这个产品是需要潜在可交付的。DoD说明了潜在可交付的产品增量需要满足什么样的要求,也是对最终产品的质量要求。

Q13:b端业务怎样做敏捷比较好?


A: 这要看敏捷实践帮助b端业务解决了哪些问题,只要是帮助b端业务解决实际问题的,就算敏捷落地。

敏捷它是一个形容词,并不是一个名词,我们应该更多地关注敏捷方法能不能帮我们有效地解决问题,一切从解决问题的角度去考虑比较好。

Q14:产品经理也是项目经理,怎么平衡两种角色?


A: 在很多公司中,并不会严格区分产品经理和项目经理,往往都是一个角色。根据以往的经验来看,通常是用项目管理的方式做产品经理,会让事情的推进能够事半功倍。

Q15:怎样确保研发成员对敏捷的拥护使用呢?

先想清楚,为什么要推进敏捷,然后思考敏捷了之后给研发团队带来的价值,或者给研发个人带来的价值。改变大家的工作习惯很难,需要潜移默化,找到敏捷给研发成员带来的好处,逐个队员突破,找到能帮你站台的那个研发成员,一点点在团队推进。

    发表评论
    通过审核后显示您的意见