Linux 之父出席、干货分享、圆桌讨论,精彩尽在 OpenCloudOS 社区开放日,报名戳 了解详情
写点什么

“你们不是用敏捷了吗?那怎么项目还延期呢?”

  • 2020 年 4 月 17 日
  • 本文字数:1937 字

    阅读完需:约 6 分钟

“你们不是用敏捷了吗?那怎么项目还延期呢?”

上个月,我曾写过一篇 #在传统企业做互联网架构 # 的文章,与大家探讨在传统企业里,如果搞互联网架构会遭遇哪些问题,并结合自己的经历聊一下心得体会。


说来也怪,在互联网盛行的这十几年里,我见过很多认真学习互联网思维的传统企业,虽然从技术架构、组织结构,到工作模式,都学的有膜有样,绘声绘色,但基本都停留在 “四不像” 的阶段。


这种半吊子工程,不仅增加了内部矛盾,还降低了工作效率。


当然,导致这种现象的原因有很多,什么犹豫不决啊,什么错失时机啊,或者什么运营与营销手段过时等等,在外人看来,似乎都很有道理,但却没有命中核心。


在我看来,这和绝大多数的传统企业高管年龄偏大,且整体管理水平陈旧有关。


简单来说,很多传统企业老板平均年龄在 40 岁以上,高管起码在 35 岁以上,这些人在传统营销领域经验丰富,但随之而来的问题是对互联网不精通。他们大部分是业务好手,但整体现代化管理理念、管理技能与企业发展要求,还存在一定距离。


不仅如此,他们基本没有技术背景,对互联网架构的理解只局限于 “别出事”,对项目管理模式的理解只局限于 “快上线”。


记得在某次敏捷话题的分享中,在提问环节时,有位老板模样的大叔向我发问:“你们都鼓吹敏捷能提升研发效率,但为什么我们用了敏捷之后,项目周期该延误的还是照旧,成本也得不到有效的控制,真不明白为什么你们还整天瞎嚷嚷这个好,那个好,吹牛很好玩是吗?”


我脾气本来就爆,听完这番话的第一反应就想给他怼回去,或者干脆回他一句 “你不懂技术,没必要跟你解释。” 但我还是很礼貌的说了一番大道理,最终指着大屏幕违心的说了一句 “这是我的个人微信,今后可以多多交流。”


对方愣了几秒,面带微笑的点了点头,坐下了。但从他的表情上可以看出,对于这样的回答,他并不买账,估计心里早就用那三个字骂了千百遍了。


不过这也正常,在我的经验值里,如果自认为对研发与测试有着不少功底的话,那对项目管理模式就完全是门外汉了。有人说,门外汉还能站到台上去分享?这还多亏的这张伶俐嘴,和实践中积累了充分的案例,至少能在面对技术理科男的时候显得更加游刃有余,但在面对这种有备而来,并略带调侃的提问,的确显得有些措手不及。



进入好买以来,我逐渐养成了 “遭遇挫折或不满事件,必复盘” 的习惯,通过翻阅大量资料及与其他公司的交流,对这个问题进行了梳理和规整。


如果再遇到类似提问,我想我会这样回答:


敏捷,解决的不是速度的问题,而是灵活性的问题。


就好比在短跑比赛中,速度最快的人种基本是黑种人,为什么呢?因为目标是明确的,拼的是身体素质,黑种人相比白种人、黄种人,天生就具有这方面的优势,当然也最有可能成为冠军。


短跑比赛,相当于一个需求明确且不会发生变更的业务项目,而黑种人,相当于某个采用瀑布式开发模式的技术团队,中途没有障碍,大家都把眼睛瞪大,撒开腿跑,一口气跑到终点,成本与效率一定是最低的。


当今的互联网业务,更像是一场羽毛球比赛。


就算面对同一个对手,每一场比赛的节奏,每一次出球的线路,都是完全不同的。在应对策略上,经验越丰富的球员越是能够增大预判的准确性,合理分配自己的体能和发力点,该快的时候快,该慢的时候慢,使自己的优势发挥至最大,最终赢得比赛。


很显然,敏捷模式不是万能的。


如果你的产品需求相对稳定,目标明确且很少走回头路,产品与技术的 KPI 各自为战,重视过程和强调文档,那就用瀑布式吧。


如果你的产品需求不明确,产品与技术的目标同为 “客户最终受益” 为宗旨,试探性需求偏多,接受不断尝试,不断试错的价值观,那就用敏捷式吧。


有人说,你这样讲还是太理论化,在现实的敏捷实施中,还是有人困扰于 “版本快结束的时候,需求要进行大范围调整” ,你质问他为什么?他会理直气壮的告诉你,“敏捷不就支持不确定性变更吗?”


对,敏捷的确支持,增加一个迭代周期来解决就行了,但时间与成本肯定会提升。


再说了,从敏捷的视角来看,目标变了等同于重新设定了新版本,重新再来自然需要更多时间。在这种场景下,非要给 “敏捷并未解决项目延误的问题” 的罪名,好像并不合适。


另外,虽然敏捷具有 “保持灵活性以便满足用户需求” 的功效,但用户往往对这种灵活性期望过高了,从而导致团队在持续交付价值的时候举步维艰。


在很长一个阶段里,我很反对敏捷,因为我觉得这为 “反复无常是正常的” 找到了一种借口。


你看,敏捷允许用户甚至能够在大型项目的后期调整优先级,但很多产品并不理解 “交付能力是有上限的” 这个道理。他们并不能真正理解速度和时间的度量标准,但却总是期望可以随时添加新的需求而且能及时得到交付。


我想,这也正是 “你们不是用敏捷了吗?那怎么项目还延期呢?” 这句话的由来吧。


本文转载自头哥侃码公众号。


原文链接: https://mp.weixin.qq.com/s/x5Vg9-7kCcnU5MaHoDPa6Q


2020 年 4 月 17 日 16:00658

评论

发布
暂无评论
发现更多内容

GPU容器虚拟化:用户态和内核态的技术和实践详解

GPU容器虚拟化:用户态和内核态的技术和实践详解

“你们不是用敏捷了吗?那怎么项目还延期呢?”_语言 & 开发_头哥侃码_InfoQ精选文章