敏捷转型之“挖坑”的艺术

进入一个团队,如何带领团队敏捷转型?有时候,或许需要一些放手,甚至一些“挖坑”。如何“挖坑”,这是一个很有讲究的活计。

在无数次X面试的时候,面试guān问:“如果你来做我们的敏捷教练,在一个没有敏捷基础的团队中,带敏捷转型你要怎么做?”

我说:我可能什么都不做,一定要做什么的话,那就做个被动者,用团队的错误,做正确的事。”

一、融入:别做团队的麻烦X者

“我最近进入了一个团队,发现了不少问题,要如何让他们听我的?”

“我学了Scrum觉得有用,可团队都不太感兴趣,要怎么办?”

这是我最近在参加完一场敏捷分享会后,收到几个X的提问。

团队的转型存在于各行各业中,近年来X行业为了应对市场的高速变化环境,敏捷转型成了一个热门词汇。那么,正如X的提问,初入一个需要转型的老团队到底要先要做些什么?

与从零开始建立团队不同,作为一个要打破团队xí惯的X者——初入团队时,既是X者,同时也是一个新人。

不同人有不同的性格,所产生的气质和团队形成的氛围也都不同,后续适合的转型之路也会有不一样的差异。路有千万条,千万别走麻烦X者这条。

什么是麻烦X者?

寻找问题、寻找差异是人的本能。无论什么岗位,为了快速体现个人价值,会用各种方式寻找团队中的问题再一条条列出,然后希望按照自己学到的知识在团队中进行大dāo阔斧的X,这就是常见的麻烦X者。

所谓的麻烦X者,往往为了找问题而提出问题,且不说目的是否正向纯粹。就X而言,当一个带着问题来的项目经理、敏捷教练,在实践过程中必然会有一股无形的阻力,这个阻力正好来自原本需要他的对象——团队。

为什么?

试想,在原本一个已经正常运行的团队中,如果因为你的出现而找出了一堆问题,那么对团队来说,显然这些问题唯一的源头是来自于你。当团队认为你就是问题的源头,那么产生的结果只有两种:“对抗”或“隐zàng”。

“对抗”或许比较容易化解,有很多方式可以解决对抗问题,哪怕是请客吃饭这样的“资本腐蚀”。

而“隐zàng”是可怕的,“隐zàng”指的是隐zàng问题。这表现为:表面上认同你,但内心中处于不认可或抵触的状态;不理解新的方fǎ同时也不表态,更不愿意告诉别人X的想fǎ;最终表现一片祥和,似乎什么问题也没有。

但看不见,问题难道就不存在么?

所以在敏捷X转型中最怕的不是一个有各种问题的团队,看似完好无缺没有任何问题的团队,往往是敏捷教练或X者最需要担心的。

二、形成:战斗前先X战线

从正面保护团队、建立信任

是转型的根基,也是敏捷教练的原则之一。

如X融入团队的初期避免出现“对抗”或“隐zàng”的情况呢?

在zhēn对团队A转型过程中,第一个月我只做了两件事情,观察与帮助:

  1. 观察团队中存在的问题,了解让成员们感觉到痛苦的事情;
  2. 在成员抱怨时,出现在身边去倾听和理解他们的抱怨,并且适度的X帮助。

七月中旬,笔者所在的研发团队经历了需qiú反应不及时、产品质量问题频发等X,受到了来自X方的压力。此时作为一个敏捷教练或是X者,无fǎ直接帮助参与实际研发工作,能做的便是保护团队。

如何保护团队?

在保护团队方面有很多方式:替团队挡住外部压力,消化X方、上下级之间沟通上的X情绪,为团队解决相关支持等。

总之,保护团队让团队有足够的安全感,便是建立信任关系的第一步。信任关系也无需太多huā哨的技巧,你用心且认真地保护团队,且为之努力,团队是能够感知到你的真诚,也能够真正的建立信任,战斗也就可以开始了。

三、X:挖坑是一门艺术

问题并不会因为你一开始的“不作为”而消失,也不会因为出现了“X”才存在问题。问题的X恰好证明它一直存在,只是凑巧被XX了出来。

在进入团队A的第一周时,我参加了包hán部门负责人(市场方面)、产品、研发团队的月计划X。

X中,产品按照市场提出的需qiú,洋洋洒洒列几十条,然后一条条解释需qiú,提出希望(必须)上线的时间。团队成员按照要qiú的时间点,一条条进行承诺。

最终X结束发现,一个月的时间要完成近两个月的开发量,总任务数的二分之一被列为最高优先级,预估达到月底上线的的任务也排在了最高优先级。

产品、运营、市场信心满满,开发团队一脸迷茫。

X全程,我没有做出任何发言,哪怕我感知到了这场X后存在的风险,有哪些问题,团队要经历哪些痛苦。

有些“坑”,必须让团队自己跳下去。

牛顿的第一定律说到:“一切物体在没有受到力的作用的时候,X状态不会发生改变”。

这一定律在人和团队身上同样适用,一切的改变背后都需要一个绝对的动能。

团队自己犯错,自己经历错误,再自己思考问题的一些过程,就是一个很好的动能;也是认识问题的必要过程。这个过程我称之为:挖坑(当然,所谓的“坑”要可控,在团队能够承受的范围内;明知道团队在XX,还在旁边抽烟围观是不可取的)。

延期是意料之内的事

经过一个月痛苦的研发过程,“坑”如期而至,月末统计:

  • 计划偏差:30%
  • 需qiú完成率:60%
  • 更新缺陷率:20% (注:每次更新出现BUG的概率)

到底是哪里出了问题,是什么导致了理想和现实的差距?每个人都陷入了反思:“是计划管理出现偏差?”“是研发效能偏差?”……

这里我们再回顾一下月初的计划会大家做了哪些事情:

  • 计划太过理想,月初就定好了整月、甚至下月的需qiú;
  • 研发团队估时不准确;
  • 优先级概念不清,一半的需qiú放到最高优先级。

四、转变:如何把“瓜”给扭“甜”了

人性的特点:在相同条件下,对一个事物的绝对值估算的误差,远大于具有参照物的相对估算。

在问题出现后,应团队主动的要qiú,我和团队来了一场全新的计划会。

1. 计划太理想

月初要做接下来一个整个月的规划,在面对时刻变化的市场需qiú下显然是不科学的,毕竟这不是盖房子。

那么我们就不做一个月的计划。开始建立需qiú池,市场提出的需qiú都收集下来,但我们只承诺第一周要做的任务。在开始第二周的工作前,需qiú池可由产品X变动(熟悉敏捷的同学可以看出,潜移默化中团队开始Scrum的迭代冲刺的模式)。

2. 无fǎ准确评估期限

原本团队评估模式是:事先安排好所有任务的负责人,再由负责人根据经验预估任务的工作量做出期限承诺。

“太美的承诺因为太年轻”。

曰常工作过程中,各种X、BUG、活动、甚至一次下午茶的打断,都会影响到任务的完成时间,而任何一个不能完成的任务估时,其实都是一种不负责的表现。

敏捷中关于任务评估有两种方式,X团队商议,这里我们用到了其中一种“故事点”以及“宽带德尔菲”技术:每个故事由产品讲解,所有开发人员各自进行估算后同时展示,差异部分进行讨论,最终得出所有人一致认可的估值。

同时,我们将需qiú由组长分配,改为成员认领,谁完成了自己的任务,可以立即X新的任务,这样可以有效消除任务等待的时间。

3. 优先级概念不清

现实环境中所有需qiú,在产品、市场单独来看,它都是重要的。其实在产品开发过程中一直存在80/20fǎ则(俗称二八定律),80%用户、价值存在于那20%的功能。

如何厘清全部优先级的时效性?可视化、X化的工作看板是一个选择。

团队A原本使用的是在线敏捷管理工具Teambition,在线工具有它一定的先进性,例如信息、数据的保存,以及异地办公的支持。但实际上仅有项管、研发团队内部使用,这其实是不足的。

正如我们执行的“早会三件事”,信息的可视化、X化是为了团队能够更好理解共同的进度、确保大家努力的方向是一致的。所以如果学xí工具成本过高,那么我们就化繁为简,用最原始的方fǎ——纸和笔。

就这样,我们开始使用了Srcum看板,把所有的任务按照:“需qiú明确度*市场价值/故事点=优先级”的方式进行排序。最高优先级的任务一定是:X、可估量、有价值、短小、可测试的(敏捷中的用户故事属性理论)。

将研发过程、进度、目标贴在最显眼公开的地方,新增需qiú、BUG再用不同的便签区分。无论是X总裁还是保洁阿姨都能看懂这个团队现在的工作情况——这便是“信息发射源”的最初用fǎ。

五、X:成功的标志是建立X

一个好的方fǎ,没有得到有效的执行,它就只是纸上的X。方fǎ在执行中走了样、贯彻不到位等都是团队转型过程中会遇到的常见问题。

如何有效执行?授人以鱼不如授人以渔。

X“挖坑”的X,方fǎ是团队主动和我共同约定而成的,所以在执行过程中,我唯一要做的就是X提醒与引导。或许初期会去帮忙团队做一些工作,但一定是在一个限度以内。以至于我经常和团队说一句话“哪天我一忙,这些事就要你们自己做了”。

X一定要X者开吗?决策一定要X者做吗?问题一定要X者发现吗?

其实有时候团队自己做的比你更好。

团队自我思考的养成,是X者的终极目标,没有任何一个方fǎ、模式是最好的,好的改进需要团队自我持续思考,这也是一个X建立成功的标志之一,故“以退为进”是在转型中可以适度使用的方式。

改变是一个长远而持续的过程,敏捷开发管理是一个不断迭代、优化产品来应对市场而提升最大价值的开发模式。而我们在帮助团队做转型时同样也是一个不断迭代、优化的过程。

不同的团队有着不同的特点、xí惯、问题甚至于价值观,所以在做转型过程中需要注意以下几点:

1)要根据团队实际遇到的问题和选择合适的方fǎ。现如今常用的工具和方fǎ如下:

  • 管理方fǎ:PMP(瀑布式开发)、CMMI、Scrum、XP等;
  • 工具方面:Teambition、Jira、TAPD、钉钉等;
  • 技术方面:特征驱动开发、测试驱动开发等。

在项目管理、团队管理中有着很多成熟的模型、工具,但切记没有任何一件东西是完美万能的,在团队转型过程中需要“逢山开路、遇水架桥”,裁剪和改进(如看板工作liú)已经成熟的理论、工具、方fǎ,这是一件很正常的事,正如我常说的:适合的才是最好的

2)保持倾听,最好最合适的方式往往来自于团队自我的思考与方式,很多时候管理者要做的只是点题,剩下的团队自己会告诉你。

3)理论知识不在于记、而在于用。如前面说到的用户故事、看板工作liú、敏捷迭代,都是在执行过程中实践反向印证了理论的合理性。

4)问题总是一点一点、一次一次浮现,团队无fǎ一次进行全方位的改变,也无fǎ一瞬间就把问题彻底改好。所以需要保持一些耐心,给团队适应的过程,只要持续进步,相信“all is well”(一切终会变好)。

写下这篇的初衷是为了记录,最终受到了“开源精神”所影响,后续将陆续写关于”产品与团队管理方面”的实战经验。

在实践过程中你和团队或许都会遇到无fǎ解决的问题,勿慌:“破万卷书,心中自有青竹”,路行千万里,共进之。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 敏捷转型之“挖坑”的艺术 https://www.xiongfawang.com/4409.html

常见问题

相关文章

敏捷转型之“挖坑”的艺术-海报

分享本文封面