【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

在敏捷实施中寻求帮助

  • 2014-04-21
  • 本文字数:2399 字

    阅读完需:约 8 分钟

培训和指导可以帮助组织实施敏捷。但只有在人们对帮助持开放态度时,它们才能发挥作用。是什么使得人们有时候不允许教练帮助他们?组织可以做些什么来鼓励帮助行为呢?

Bob Galen 写了一篇博文《敏捷项目经理——拜托,可以帮我一下吗?》。文中,他分享了几个人们不愿意从教练那里寻求帮助的故事。一个例子是,一个组织,在接受培训六个月之后,已经准备好继续他们的敏捷之旅,他们用一种命令和控制的管理方式使用敏捷:

管理人员对冲刺进行微观管理,并调整团队的预算和计划。团队缺乏信任、不透明,误导了他们的管理。团队中几乎没有诚信和开放式协作——也没有信任。

在这六个月里,人们没有寻求任何帮助,也不允许教练帮助他们:

他们的敏捷教练已经问过许多次,他们是否需要帮助,得到的答案总是“不——事情进展得很顺利”。只有当他们连续十次冲刺失败,团队成员开始反抗,负责人才会向他们的教练寻求帮助。敏捷教练回来,在一个相对较短的时间内就将团队带回了“基本面”,并帮助他们恢复平衡、信任、协作及承诺敏捷交付。后来,每个人都在问:“为什么花了这么长时间——我们为什么没有更早地寻求帮助?”

在该博文中,Bob 提到人们有时候不寻求帮助的几个原因:

我注意到,在专业人士中间,他们确实不愿意寻求帮助。是自负?是害羞?是信任?是观念?我认为所有这些都是原因,而且还有更多。(……)我在组织的所有层面都看到了这点——这是我试图举例说明的。它发生在高级管理层、管理层和团队层。通常,它与人的经验没有关系。事实上,似乎有这样一种关系存在,一个人经验越是丰富,就越不愿意承认他不知道什么,或者需要别人帮助他规划下一步的工作。

关于该话题的第二篇博文中,Bob 解释道,不寻求帮助关系到对团队合作在敏捷中的重要性的认识:

至少,从敏捷团队和项目的角度来看,这跟个人无关。这跟团队有关。寻求帮助是承认你的团队大于各部分之和,你们有责任找出挑战并作为一个团队来面对。如果你们不愿意尽早且经常地把它们提出来,那是你们没有看到团队朝着共同的目标协同工作的大局。

Bob 写道,帮助是多向的,寻求帮助和提供帮助彼此呼应:

我认为,你主动提供帮助和协作的程度将提高你自己从团队成员那里寻求和接受帮助的能力。“变得更好”的一个简单方式是帮助你自己的团队成员——围绕团队的挑战问一些寻根究底的问题,围绕完成工作做真正的交流。

在博文《世界上三个最强大的词》中,Mike Edwards 探讨了承认不知道的事如何才能打开寻求帮助和助人成长的通道。他从他的教练经历举了一个例子:

一位 ScrumMaster 拒绝寻求帮助,或者直面它的 Scrum 知识。他的项目管理背景使情况更糟糕。打破旧的管理习惯很困难,而且如果不承认需要帮助,就更困难了。这造成这样一个环境,新的 Scrum 团队挣扎其中,产品经理并不十分紧张,而项目注定得到类似瀑布式模型的结果。如果情况不改变,那么团队注定要回到旧时的安逸状态。

Mike 建议,通过帮助人们了解他们知道什么及不知道什么并在这个问题上变得开放来处理这种情况:

在采访的时候,我问一些问题,试着找出一个人知识的界限。我想看到人们愿意承认他们不确定的事情。如果当他们觉得不舒服时还愿意这样做,那么作为团队成员,当他们觉得舒服时,他们就更可能说出来。这意味着团队可以快速处理知识差距并向前发展。

在哈佛商业评论上一篇题为《 IDEO 的帮助文化》的文章中,作者 Teresa Amabile、Colin M. Fisher 和 Julianna Pillemer 探讨了组织可以做些什么来鼓励帮助行为。在文章开头,他们解释了为什么他们认为这点需要注意:

组织必须积极鼓励乐于助人的精神,因为无论如何它都不会自动地出现在同事之间。社会群体中的个体经历着相互矛盾的冲动:作为潜在的助人者,他们也可能倾向于参与竞争。作为潜在的求助者,他们也可能以单打独斗为荣,或者不信任那些他们可以使用的帮助。在双方看来,帮助需要为不确定的回报投入时间,而且看上去麻烦比价值更大。不过,通过他们的组织结构和激励机制,组织可以在不知不觉中消除提供或寻求帮助的不情愿。

本文描述了 IDEO 为创造一种人们寻求和提供帮助的文化所做的事:

在每个项目的开始,鼓励设计人员假设他们将会需要帮助。如果项目团队有一个非常苛刻的客户,那么它应该认识到,如果不请求一位对那个客户非常有经验的同事来审查其工作,是不负责任的。在整个项目中,团队成员都可能会要求那位同事提供帮助,在任何地方持续 15 分钟到半天的对话中。在 IDEO,寻求帮助并不可耻,而且这种心理安全感在许多层面都得到了体现:比如,人们欣然接受频繁的全办公室的电子邮件群发,类似“有人有西班牙语广播经验吗?”或“谁尝试过新的快速减肥饮食?”

IDEO 面向整个办公室人群做了一项调查,研究人们如何相互帮助。一个结论是,要使同事有帮助,最重要的是信任和可用性:

(……)与排名第五位的帮助者相比,人们更信任排名更高的帮助者,而对两者的信任都超过没有对他们提供帮助的人。(……)寻求帮助至少会涉及某一弱点,所以顺理成章,人们会向他们信任的、可以交托他们的想法与感受的帮助者求助。

可用性是指有时间、愿意且能够提供帮助。(……)当团队没能获得帮助,通常是因为需要的人根本没有时间——他或她不在办公室,无法用电子邮件取得联系,或者太忙了根本抽不出时间。(……)通常,对于团队而言,最好的帮助者是在项目开始的时候就已经确认不会出现上述情况的人。

Len Lagestee最喜欢的教练技术是使用非正式场合:

在午餐时间,我会尽可能经常地坐在休息室的桌子旁。目前,我工作的组织每一层楼都有小型休息室,所以我会找最近的坐下来,只是等待。我会补发电子邮件,或者做一点点事,但我会确保不表现得过忙或者摆出一副“不要打扰我”的样子。

可用且可见更容易使人们开诚布公地谈论他们关于团队和组织的经验,这为教练在日常工作中帮助他们创造了机会。

为了鼓励人们寻求帮助,您做了什么?

查看英文原文:**** Asking for Help in Agile Adoption

2014-04-21 04:25917
用户头像

发布了 256 篇内容, 共 81.2 次阅读, 收获喜欢 11 次。

关注

评论

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

【Java 多线程 1】CountDownLatch

Java 程序员 后端

公有云是什么意思?其存在的意义是什么?

行云管家

云计算 公有云 私有云 混合云

《Spring实战》读书笔记-第4章 面向切面的Spring(1)

Java 程序员 后端

《重学Java高并发》Disruptor使用实战

Java 程序员 后端

【C 语言小游戏】手打贪吃蛇1

Java 程序员 后端

ZK(ZooKeeper)分布式锁实现

Java 程序员 后端

【Java 集合框架】Stack、Queue 和 Deque 的使用

Java 程序员 后端

【Java每日面试题】大厂是如何设计秒杀系统的?

Java 程序员 后端

【Java从0到架构师】SQL 多表查询

Java 程序员 后端

过等保选择云堡垒机还是硬件堡垒机比较好?

行云管家

网络安全 云服务 堡垒机 等级保护

【Java面经】阿里三面被挂!幸获内推,历经5轮终于拿到口碑offer

Java 程序员 后端

全面通透深入剖析工厂方法模式

Tom弹架构

Java 架构 设计模式

《代码重构》之方法到底多长算“长”

Java 程序员 后端

《菜菜的机器学习sklearn课堂》降维算法PCA和SVD

Java 程序员 后端

[译] 微服务的设计模式

Java 程序员 后端

「并发原理专题」AQS的技术体系之CLH、MCS锁的原理及实现

Java 程序员 后端

《吃透MQ系列》核心基础全在这里了,一文啃透!

Java 程序员 后端

【Java 基础语法】万字解析 Java 的多态、抽象类和接口

Java 程序员 后端

【Java设计模式实战系列】好的单例模式是怎样的?

Java 程序员 后端

“抽象类”到底抽不抽象?实例对比一看便知!

Java 程序员 后端

《JVM系列》 第六章 -- 对象的实例化与内存布局(1)

Java 程序员 后端

《Spring实战》读书笔记-第4章 面向切面的Spring

Java 程序员 后端

【Java知识点详解 7】装箱和拆箱

Java 程序员 后端

ZooKeeper分布式配置——看这篇就够了

Java 程序员 后端

Zookeeper(从7个方面来了解Zookeeper基础概念)

Java 程序员 后端

《JVM系列》 第六章 -- 对象的实例化与内存布局

Java 程序员 后端

大数据中必须要掌握的 Flink SQL 详细剖析

五分钟学大数据

flink 11月日更

【Java面经】阿里三面被挂!幸获内推,历经5轮终于拿到口碑offer(1)

Java 程序员 后端

【Java从0到架构师】Maven

Java 程序员 后端

【Java核心面试宝典】Day3、图解HashMap高频面试及底层实现架构!

Java 程序员 后端

【Java设计模式系列】装饰器模式(Decorator Pattern)

Java 程序员 后端

在敏捷实施中寻求帮助_文化 & 方法_Ben Linders_InfoQ精选文章