为什么项目经理需要放手

软件驱动的项目很少是可预测的——所以项目经理应该放松并变得更敏捷。
3 位读者喜欢这篇文章。
open source button on keyboard

Opensource.com

对项目的规划、执行和交付负责是需要付出很多努力的。 管理人员、促进沟通、解决冲突和降低风险都是按计划并在商定的预算内完成的前提。 加上这些因素通常是不可预测的,难怪项目经理会感到责任重大。

适合担任此类角色的人非常清楚这一点,并且他们很乐意承担。 他们认为项目经理的角色是守护者,负责监督项目以保护项目免于失败。 他们是最后一道防线,愿意在出现问题时承担责任。 这是他们寻求采取的令人钦佩的领导地位,但与之相关的责任即使对于最有经验的从业者来说也可能会变得不堪重负。

这就是为什么我认为他们需要放手。

追逐瀑布

软件驱动的项目很少是可预测的。 初始需求可能难以实现,或者,经过反思,证明是错误的方法。 人们也容易犯错误,并且会在压力下表现出不理智的行为。 那些未能认识到这些促成因素并为此做出让步的项目经理只是在与自然规律作斗争,而这些自然规律最终会使许多项目脱轨。

事实上,在项目的许多阶段,失败都非常有可能发生,因此,当项目经理感到最终责任时,他们倾向于实施避免失败的策略似乎是很自然的。 他们很容易相信,事情越可预测和有序,他们的项目失败的可能性就越小。 因此,为完成项目所需的工作准备详细且规范的计划似乎是一个不错的起点。

更传统和预测性的瀑布模型是管理者多年来使用的安全网之一,因为他们寻求更高程度的安全性。 这是一种历史悠久的方法,对于参与软件开发的项目经理来说,这是一个特别常见的课题。

面对满足截止日期和在限制性采购规则范围内工作的商业压力,项目经理也不喜欢改变。 他们寻求可预测性,并生成诸如甘特图、界面设计和技术规范之类的项目产出,以努力精确定义项目结果。 他们将其视为成功的蓝图,并将其用作对抗可能威胁它的任何事物的武器。

但是,项目经理越寻求确定性,他们就越努力控制可能影响它的因素。 那些受到最多关注的往往是他们周围的人员,即负责产生项目所需产出的人员。 突然,严格的界限限制了项目团队,并且管理者鼓励该团队避免偏差。 他们指导团队的所有努力来安抚期望预定义结果的利益相关者。

虽然这些行为可能是对项目施加压力的可以理解的产物,但项目经理创造了一种将变更视为高度破坏性事件的环境。 因此,对据称精确的规范进行重新设计以及固定时间表的延迟是不可接受的。 原始计划变得不灵活,并且项目团队会受到密切审查,以确保总体上符合它。

更好的选择是采取更敏捷、协作的方法——责任分散,不惧怕失败,并且认识到变化是常态。 这是一种更常识性的方法,可以更好地适应强烈影响项目成功或失败的人为因素。

从文化开始

然而,不习惯(甚至不知道)这种替代方案的项目经理需要在心态上发生根本性的转变。 克服对规范性方法的渴望并非易事。 许多人被困在沉闷的商业环境中,传统决定了实践,而对变革的渴望很低。

幸运的是,越来越多的管理者认识到敏捷项目管理方法的吸引力。 并且他们正在大力推动这些方法在整个商业领域中的应用,同时政府的采用也在加强。 人们认为敏捷方法是增加价值、培养与用户更高程度的参与度、生产更好的产品和服务以及提高生产它们的团队福祉的好方法。

对于希望转向更敏捷实践的项目经理来说,这种趋势本身就是一个很好的杠杆作用。 即使是很小的措施也能使他们的项目受益。 他们应该更好地利用他们的领导能力来影响关键利益相关者和管理者。 如果可能,他们还应该争取更多地参与采购过程,并在项目的早期阶段协商一种更敏捷的方法。

对于寻求变革的项目经理来说,关键信息是,您需要努力为自己和周围的人培养正确的心态。 促进更多协作,授权个人承担更多责任,并鼓励您的团队变得更加自主。 不要再沉迷于计划或流程,而是领导您的项目,而不是试图控制它们。

您甚至可能会发现您的团队将您的下一个项目庆祝为令人愉快的事情——而不仅仅是已经结束的事情。

我将在 2016 年 9 月 27 日在都柏林举行的 DrupalCon 上,在我的会议控制狂的自白:放手指南中谈论此事。

User profile image.
Jason Coghlan 拥有超过 15 年的领导数字项目和管理基于技术的业务的经验,专注于 Web 应用程序和产品开发。

3 条评论

“幸运的是,越来越多的管理者认识到敏捷项目管理方法的吸引力。” 很高兴他们赶上认识到敏捷,而世界其他地方已经开始转向持续迭代、集成和部署。

Dana R.
http://codespark.ca/

过去几年我与项目经理遇到的一个大问题是,他们优化流程是为了他们自己,而不是为了整个项目或公司。 作为系统管理员,这通常意味着我需要进行更多手动操作,这更容易出错。

此外,在高度孤立的组织中,项目经理经常将自己插入流程的所有步骤中,这导致了我在之前的工作中遇到的新 WM 需要 6 周的交付时间之类的事情。 需要 5 个或更多组织对新的系统构建采取行动简直就是崩溃。

有趣的是,这篇文章让我找到了自己以前的一条评论:https://open-source.net.cn/business/11/2/open-source-management-approach-re…。 我经常看到管理者在认为他们的控制开始消失时开始“微观管理”他们的团队。 这时,大多数最好的工程师决定离开。 微观管理表明缺乏信任。 过度控制和控制不足之间存在微妙的平衡……

Creative Commons License本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。
© . All rights reserved.