免费下载!由 O’Reilly 出版的《NGINX 完全指南》中文版已正式上线 了解详情
写点什么

公司为了敏捷而犯下的十大错误

  • 2022-08-19
    北京
  • 本文字数:2389 字

    阅读完需:约 8 分钟

公司为了敏捷而犯下的十大错误

敏捷(Agile)无处不在,似乎所有人都想变得敏捷,而如果你现在还没有自己的敏捷团队,那你得是上古恐龙级别的老古董。但是,一个组织并不会简单地就变得敏捷,本文中将列举组织为了敏捷而犯下的十类错误。 


第十、从上而下地实施敏捷


作者所了解的一些从上而下的敏捷实施中,组织的管理层会通知团队要采用敏捷的方式开展工作,并列出了具体的时间和方式。但敏捷实际的意义在于团队通过自我规划来创建有价值的产品。


管理层传达敏捷目标这一点没有问题,但为达到最佳效果,团队和管理层都应参与到具体实施中,一起踏上敏捷之旅。团队各不相同,产品也各有千秋,是时候让团队自己决定什么才是真正行得通的了。


第九、“实施”变革


和上一点类似,组织试图通过指导手册或者是凭空创建的工作流程来简单粗暴地“实施”敏捷的文化变革。


这是不行的。组织的文化是在每一名团队成员的参与下,经过长年累月的积累而形成的。文化是无法轻易改变的。如要改变,管理层应以身作则,自觉遵守文化指导手册(最好是由员工协作编写的),展示预期行为,并对其他成员的模范行为给予鼓励,同时还需要保持耐心。


第八、聚焦输出


许多公司的敏捷团队完全将工作的重心放在了创造与交付产品上。他们关注上市时间和测试自动化,关注CI/CD,以做到更快的交付。但这种把重心放在输出的做法是反敏捷的。


如果你所交付的应用并不是客户需要的,那么交付再快也都没了意义。很多新功能都因为派不上用场而从没有人使用过。真正重要的是我们通过输出所能达成的效果。


第七、忽视客户和用户


很多敏捷团队对用户画像或客户需求只有模糊的概念。他们从不和这些关键的利害关系人接触,即使有定期演示或评审,也只是面向内部的利益关系人。而他们只要见到销量增长就会欢呼成功。但销量只是指标,它们不代表客户。


团队创造的产品是为客户和用户服务的,我们需要让客户和用户参与进来。敏捷的意义就在于定期与你的用户一起验证产品。没有这层验证,你的敏捷之旅就是毫无根基的。


第六、敏捷仅面向 IT


人人常常误以为敏捷只适用于 IT,只有 IT 需要敏捷,组织的其他部分完全无需改动。这是忽略了团队内除了 IT 之外其他成员为提供用户体验而做出的贡献。没有大家共同的努力,客户不会得到满意的结果。


IT 只是产品体验的一部分,而产品体验也是客户体验的一部分。客户对产品的体验还包含了销售、售后、政策法规以及第三方。在不断变化的环境中,最大化产品价值是所有人的共同目标。我们需要团队协作以及快速的反馈循环,我们都需要变得敏捷。


第五、敏捷只限于团队层面


敏捷的一大错觉是其只需应用于创造产品的团队。只要这些团队是敏捷的,那么一切就都不会有问题。

但这是行不通的。团队在组织中工作,并会不断被组织所影响。当组织展现出反敏捷的行为时,只会给团队帮倒忙,甚至会给创造价值的团队带来潜在伤害。


管理层、领导者、人力资源以及其他的成员都应鼓励团队,帮助他们成为更高效的敏捷团队。对于如何以敏捷的方式创建产品体验及达成目标方面,整个组织应该有统一的认识。

第四、敏捷只为更快的交付


“我们需要变得敏捷并更快地交付”。大型公司的顶层管理者也曾做出过这种言论,清晰地展示了他们对自己在说什么完全没有丝毫的认知。


敏捷不是为了更快的交付。敏捷是意识到我们无法提前预知一切,所以便通过增量构建来和用户进行确认。敏捷是更快的反馈,是更好地了解下一步要做什么,是通过与用户的协作,更及时地了解什么会得到认可,什么不会。


将注意力集中在更快的交付并无视反馈循环只会让你成为一个功能工厂,你在创建输出上非常在行,但你也只会创造出人们并不想要的结果。


第三、用瀑布式管理实施敏捷


敏捷不是通过漫长的研究、长期规划的阶段性工作流达成的。敏捷的工作方式是从传统“瀑布式管理”思考模式的一种明显的转变。团队不再会过度分析工作内容,而是会从产品的升级换代中学习。他们会更快地认识到到产品的价值,并找到更好的合作工作模式。


在敏捷之旅的开始,你会为团队设定目标,并找到达成目标的最佳途径。你会从你所完成的工作中学到什么可行,什么是不可行的。你会和团队一起协作奋进。


第二、应用不变的流程及工具


最痛苦的一种变得敏捷的方式之一就是直接应用别人的东西。想象一下,团队如果按指示使用 Scrum,用预先配置好的工具比如 Jira,在固定时长的 Sprint 周期里以预设好的速度交付。这样的灾难场景在 SAFe 里就发生了,并且还扩大了规模,成了组织内部自上而下的敏捷实施。


拿来主义并不适合 Scrum 和其他的敏捷方式。每个团队都是不同的,每个产品的应用场景也不尽相同。直接应用标准流程只会给团队套上枷锁。团队或许还会发展提升的空间,但如果没办法采取改进措施,那么他们的效率只会越发低下。


敏捷方法的引入只是真正旅程的开始,通过这一步,我们应放开对团队的限制,并期望他们可以自行寻求进步。这才是敏捷真正的含义所在。不断的变化,不断的提升,挑战将会是新的日常。尽管这段路程看起来非常吓人。


第一、想要变得敏捷


组织常犯的第一大错误便是对变得敏捷的渴望。敏捷不应是目标,没有人会因为你是敏捷的而选择你的产品。对市场和你的股东而言,敏捷没有任何意义,这只是一个词语。非要说的话,敏捷还可能是有害的。因为你会暴露出自己已经落伍了,已经过时了,即使是起步最晚的,多数也早在五年前就到达了你所在的阶段。


与其设法变得敏捷,组织应当将重点放在他们所希望造成的影响上,并设定达成预期影响所需要的目标。你应确保组织中的所有人都目标一致,应让人们都愿意为了这个目标拼尽全力。你还应帮助人们消灭前行道路上的障碍,无论是竖井、过于繁琐的过程还是任何其他形式的累赘。


无论你想怎么称呼它都不重要, 因为你的用户和股东不会因为你称自己为敏捷就会高看你一等,他们只会根据你所造成的影响和你所带来的利润评价你的工作。

 

感谢 Matt DiBerardino 及 Erik de Bos。

英文原文:


Top 10 Mistakes Organizations Make to Become Agile

2022-08-19 14:148232

评论 2 条评论

发布
用户头像
"敏捷不应是目标,没有人会因为你是敏捷的而选择你的产品。"一个总是做烂产品的团队, 只通过改变做事方式是很难马上就能生产好的产品, 必要的时候要敢于换人.
2023-05-02 11:31 · 广东
回复
用户头像
说的好,道出了一些伪敏捷的做法。
2022-08-19 16:09 · 广东
回复
没有更多了
发现更多内容

A tour of gRPC:03 - proto序列化/反序列化

BUG侦探

gRPC RPC protocolBuffer

Sator推出Web3游戏“Satorspace” ,并上线Huobi

EOSdreamer111

如何在软件研发阶段落地安全实践

华为云开发者联盟

云计算 后端 软件开发 安全发布

行业案例|数字化经营底座助力寿险行业转型

Kyligence

数字化转型 Kyligence

一文读懂数仓中的pg_stat

华为云开发者联盟

数据库 后端

你真的理解粘包与半包吗?3分钟搞懂它

C++后台开发

网络编程 网络协议 TCP/IP 后端开发 C++开发

DataSimba推出微信小程序,DataNuza接受全场景考验? | StartDT Hackathon

奇点云

数据中台

“未来办公”三大新趋势:分布式、移动、人工智能辅助

WorkPlus

Python 入门指南之数据结构

海拥(haiyong.site)

Python 7月月更

低代码助力企业数字化转型会让程序员失业?

行云创新

程序员 云原生 软件开发 低代码 数字化转型

Pisa-Proxy SQL 解析之 Lex & Yacc

SphereEx

数据库 sql SphereEx

当AI对话系统像自动驾驶一样分级,谁能率先跑出L5?

硬科技星球

人工智能 AI人机对话

MRS离线数据分析:通过Flink作业处理OBS数据

华为云开发者联盟

大数据 后端

Sator推出Web3游戏“Satorspace” ,并上线Huobi

股市老人

99%的人都不知道|私有化部署还永久免费的即时通讯软件!

WorkPlus

企业即时通讯软件是什么?它有哪些优势呢?

WorkPlus

HTML5网页3D场景制作之Three.js初体验-制作3D字体

迷彩

前端 3D three.js 7月月更

智慧物流平台:让海外仓更聪明

WorkPlus

dapp丨defi丨nft丨lp单双币流动性挖矿系统开发详细说明及源码

开发微hkkf5566

Kubernetes DevOps CD工具对比选型

行云创新

Docker DevOps 云原生 k8s pod

公司为了敏捷而犯下的十大错误_架构_Willem-Jan Ageling_InfoQ精选文章