团队协作的五大障碍书籍 团队协作的五大障碍

团队协作的五大障碍(团队协作的五大障碍书籍)项目团队管理知识:怎样穿越团队协作的五重障碍
即使艺术、哲学和科学领域的一些非凡成就看起来是由杰出的个人独自完成的 , 我仍然怀疑他们是否也有他人的帮助 , 这些人是无私的、匿名的(也许是在幕后) , 作为一个团队一起工作 。 从大国勾心斗角、社会动荡、政治抗争、建立帝国、争取自由、建设国家、保卫边疆 , 到创造了金字塔、泰姬陵、艾菲尔铁塔、自由女神像、悉尼港湾大桥、伦敦眼摩天轮等诸多壮丽奇迹 , 一切都是靠团队合作而诞生和存在的 。 当然 , 团队合作的范畴并不排斥简单的 , 平凡的 , 日常的事务 。 虽然他们不能成为报纸的头条 , 但他们极其重要:普通人不能没有团队在田里耕作 , 安排野餐甚至家庭活动 。 既然团队合作在我们的日常生活中起着如此深远的作用 , 我们自然希望团队的产出直接受到协作质量的影响 。 可惜的是 , 团队合作不能只靠美好的愿望或者听天由命 , 很多时候根本就不可能发生!团队合作的质量受到很多因素的影响 , 比如团队成员的个体主动性、团队成员之间的信任、团队任务的明确性、对目标的统一认识、资源的缺乏、团队成员之间的沟通不畅等等 。 所以说团队一拍即合需要适当的投入也就不足为奇了 。 然而 , 尽管有最先进的流程和工具 , 团队的功能障碍经常严重影响团队的绩效 , 并危及其有效执行的能力 。 大多数软件经理缺乏感知这些深层社会学问题的信号的相关能力 , 因此他们无法处理它们的影响 。 对这些问题的任何敷衍的反应只会使它们更难处理 。 本文分析了帕特里克兰西奥尼在他精彩的寓言书《团队的五种机能障碍——领导力之寓言》中基于商业情境提出的团队功能障碍模式 。 在书中提到的模型中 , 他确定了影响团队绩效的五种功能障碍 。 这些功能障碍并不是完全独立的 , 而是相互关联的 , 上下叠加 , 如下图所示 。 换句话说 , 缺乏信任导致对冲突的恐惧 , 对冲突的恐惧导致承诺不足 , 如此等等 。 虽然Patrick在一个没有充分发挥潜力的业务团队的帮助下讨论了这个模型 , 但是我发现这些想法是通用的 , 适用于一个软件开发团队的情况 。 可能没有一个地方像软件开发这样能突出团队合作的有效性和重要性 。 软件开发是一项团队运动 , 有自己的公平竞争政策(“职业道德”) , 一整套游戏规则(“流程”) , 非常重视团队合作 。 软件开发过程 , 或管理开销(以过程或组织认为合适的任何类型和份额存在) , 或更简单的 , 如统一集成开发环境(IDE)、通用编码规范、配置管理工具.事实上 , 一切的存在都是为了同一个原因:让团队作为一个整体比其组成部分的集合更大 。 然而 , 我们也知道软件项目的失败率高得惊人 。 即使业内对“失败”的构成及其真实统计没有共识 , 但我们都知道 , 失败率总是高于应有的水平!即使偶尔有例外 , 考虑到软件行业雇佣的大多数员工都很优秀 , 如果项目失败的首要原因是技术低、粗心、愚蠢或故意破坏 , 我仍然会感到非常惊讶 。 那么 , 为什么会有那么多软件团队达不到预设的目标呢?我认为 , 在其他因素相同的情况下 , 没有得到足够重视的软件项目失败的一个主要原因是团队的功能失调 。 过程决定了“工作方式” , 对团队的有效性有很大的影响 。 在过去的十年中 , 敏捷方法变得流行和主流 。
维基百科将其定义为:“.敏捷方法广受推崇:鼓励频繁检查和调整的项目管理过程;鼓励团队合作、自我组织和责任的领导哲学;一套工程最佳实践 , 允许快速交付高质量的软件;将开发工作与客户需求和公司目标相匹配的商业方法 。 ”以上所带来的对团队和个人的赋能 , 达到了我们在软件行业所见过的最高水平 。 我认为这是流程改进的另一个重要进展 , 它将决策权从经理手中转移到授权的自我指导团队 , 从而使团队合作发挥比以前更重要的作用 。 然而 , 敏捷不是一个社会学的过程 , 而是软件开发中一种面向团队的哲学 。 虽然有团队社会学的痕迹 , 但如果武断地看待 , 很容易忽略这一点 。 考虑到敏捷原则正逐渐成为业界开发过程的事实标准 , 我分析了敏捷实践如何处理软件团队的五种故障 。 让我们从金字塔的底部开始 , 一个一个地扩展 。 缺乏信任“第一个障碍是团队成员之间缺乏信任 。 这本质上是因为他们不愿意在群体中被轻易攻击 。 除非团队成员对自己的错误和弱点真正开诚布公 , 否则他们无法奠定信任的基础 。 ”一个团队远不止一群乌合之众 , 无论个人有多能干 。 每个团队成员都提出了独特的、通常是互补的技能 , 这些技能的集合有助于团队实现目标 。 在一个由各种“分工”方式造就的传统团队中 , 成员之间有着强大的攀比压力 , 没有机会发展出“基于弱势的信任” 。 基于可持续的过去表现 , 团队成员被“信任” 。 然而 , 在现代工业中 , 不可能假设或期望任何人拥有所有必需的技能并在任何情况下取得成功 。 根据帕特里克的说法 , 相互信任团队的成员可以承认自己的弱点和错误 , 向他人寻求帮助 , 接受对其责任领域的问题和评论 , 在做出负面结论之前假设他人是无辜的 , 冒险提供反馈和帮助 , 欣赏和探索他人的技能和经验 , 将时间和精力集中在重要问题上而不是勾心斗角 , 毫不犹豫地提供和接受道歉 , 并期待会议和其他集体工作的机会 。 鼓励敏捷和自适应的软件开发 , 这在很大程度上依赖于过去性能的反馈来提高未来性能 。 鼓励敏捷——开发人员、业务人员、赞助商和客户——的所有利益相关者之间进行面对面的交流和互动 。 它还鼓励频繁的(通常一天一次)进展更新 , 并在迭代结束时反思过去的进展和未来的改进 。 这种定期的公开交流和反馈是非常有效的建立信任的活动 。 敏捷团队通常很小 , 团队成员拥有互补的技能和任务 , 而不是许多人同时拥有竞争的技能和任务 。


特别声明:本站内容均来自网友提供或互联网,仅供参考,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。