内容简介:项目管理是一门抽象的学问,实践证明,能把项目带向成功的并非固定招式,也不是放之四海而皆准的标准,在项目管理这条道路上,走过的弯路、踩过的坑都有可能成为非常宝贵的经验和教训。总结了三个项目管理的关键,分享给所有项目管理者或者想成为项目管理者的伙伴。风险,一直是令项目管理者头疼的问题,客户关系处理不好是风险,交付范围扩大是风险,需求变更是风险,团队合作是风险,有的时候诸多风险会一起到来,令项目管理如履薄冰,稍有不慎就会导致项目失败。在真实风险之外,也有许多项目折戟于“想象中的风险”。换言之,很多风险并非无法解决
项目管理是一门抽象的学问,实践证明,能把项目带向成功的并非固定招式,也不是放之四海而皆准的标准,在项目管理这条道路上,走过的弯路、踩过的坑都有可能成为非常宝贵的经验和教训。总结了三个项目管理的关键,分享给所有项目管理者或者想成为项目管理者的伙伴。
01 管理风险,基于事实而不是感觉
风险,一直是令项目管理者头疼的问题,客户关系处理不好是风险,交付范围扩大是风险,需求变更是风险,团队合作是风险,有的时候诸多风险会一起到来,令项目管理如履薄冰,稍有不慎就会导致项目失败。
在真实风险之外,也有许多项目折戟于“想象中的风险”。换言之,很多风险并非无法解决,而是我们认为自己无法解决。
我的上一个项目,客户负责算法,交付团队负责应用程序,就在离交付只有不到三周的时候,团队提出客户的算法有bug,会导致一些我们解决能力范围之外的问题,于是报出了高风险预警,并产生了悲观情绪,认为项目必然会失败。
后来,我们做了问题整理和原因分析,结果却大大出乎我们的预料,竟然发现大部分的问题是来自应用程序,应用程序解析外界输入太脆弱,而且没有良好的容错机制,应用程序读取算法时设置了错误的参数。
也就是说,团队掉进了自己为自己挖的坑。
我们还把所有基于感觉的问题做了梳理跟踪和记录,项目结束之后大家一起做了回顾,对所有人来讲,那是一次深刻的教育。
项目交付过程中,团队可能会面临各种各样的复杂度,有时候需要突击学习,有时候需要加班赶工期,这些挑战都有可能变成团队的压力,重压之下团队很有可能变得悲观,当一个人的悲观变成一群人的悲观,团队就失去了对风险的客观判断,这时候最需要的就是事实。
所以,项目管理的第一个关键: 面对风险,我们需要多做一些分析,管理风险,一定是基于事实。
02 管理客户,多一些沟通少一些猜测
很多项目管理者认为客户管理是项目管理中最有挑战的部分,而客户管理中最复杂的莫过于决策者的管理。
决策者通常来自客户的高层,有时候还是出资的那个人,他们有想法,有话语权,但其特殊的身份决定了他们一般都很忙,不是我们在项目中直接对接的那个人。
如果管理不好决策者,就经常有如下情景发生:
- 项目开发到一半了,决策者出现,推翻了大部分做好的功能;
- Showcase的时候决策者提出反馈,条条都是需求变更;
- 关键业务功能找他拍板的时候,约不到时间,找不到人。
- ……
这样的事情发生的多了,开发团队通常会这样猜测,重要的人物都很忙,我们的项目不是他的优先级,我们尽管非常需要他,但无能为力。
但当你问开发团队,决策者是否知道他很重要,是否知道他可能会是项目交付的风险和最大瓶颈,大多数时候,开发团队一脸茫然,因为很少会有人和决策者确认过这个猜测。
这是项目管理的第二个关键,有时候,我们对客户的认识基于我们的猜测,而不是事实。
我经历过一个决策者隐身的项目,也预料到他的缺席会是项目交付最大的风险,于是借助一次关键的showcase,我们暴露了所有的缺陷,也因此引起了决策者的关注,我们趁机和他做了沟通,原来他之所以和项目保持着若即若离的距离,是因为他一直以为项目一切顺利。
意识到参与的重要性之后,他和团队安排了一周两次的catch up,自那之后我们才真正将决策者引入开发的过程。
所以,在客户管理上,对客户产生正确的认识,让客户成为团队的一部分,多一些沟通,大部分的时候都会有收获。
03 管理目标,不断验证并强化目标的一致性
所有的项目都是有目标的。
这个目标的设定首先来自于客户,客户想通过一个系统或者数字化手段解决什么问题,带来什么价值,对这些价值都有什么描述,成功和失败的定义是什么,除了数字化手段还有什么其它辅助方案?
绝大多数项目经理,都会有意识去收集并澄清这些信息。
团队的目标是根据客户的目标制定的,团队如何帮助客户达到目标,实现期望的价值,团队内部如何合作,团队和客户如何沟通,如何界定开发范围,根据什么进行优先级决定,这些也通常会被项目管理者纳入工作的范围。
理想情况下一旦客户的目标明确,团队的目标也会变得非常清楚。
但现实往往是,每过一段时间就会有人质疑团队是否有目标,或者抛出一个对目标的错误认知,甚至认为团队不可能达到目标。
项目经理可能会疑惑,目标不是很明确吗?团队不是一起讨论过目标吗?而且所有人都达成了共识?项目经理甚至记得这种事情发生了什么地点什么时间,他自己或者有上下文的同事说过什么话,在白板上写过什么内容。
但是,这些都无济于事。
人的认知是个很奇怪的事情,信息被植入人的大脑,但随着时间的推移,它会被迭代很多次,于是不同的人就有了不同的认识。
此时,如果项目经理还是基于以前的假设,认为所有人都已经充分了解上下文并拥有一致的认识,那就大错特错了。如果不反复强化目标,并确认所有人拥有一致的认识,就会出现这样的一些情况:
- 团队花时间开发了无用的功能,造成浪费,但是要开发重要功能的时候却没有时间了;
- 系统出现了问题,有人认为应该修复,有人认为不需要,对优先级的认识不一致导致了很多无效的讨论;
- 客户也会对开发团队产生怀疑,认为团队自始至终是没有理解业务;
最终,在客户的资源耗尽之时,团队没有办法交付一个可以实现价值的可用的版本。
这也是项目管理的一个关键问题。
要解决这个问题,项目管理者需要不断验证假设,弄清楚团队是否都理解目标并且是否对目标达成一致,尤其去找中间加入项目的成员确认他们对目标的认识。
即使团队暂时性的对目标明确且达成了一致,项目管理者也需要不断的强化目标,这样才能尽可能的帮助团队统一方向,提高效率。
导致项目失败的原因有很多,遇到如上原因的话,有可能会使一个看起来成功概率很大的项目走向失败。
在《有效管理的5大兵法》中有这样一句话:解决问题,就是把可能让我们失败的因素清除了,让我们达成预期目标。
作为项目管理者,把项目带向成功,就是不断识别可能会导致项目失败的关键因素并解决问题的过程。
更多精彩洞见,请关注微信公众号:ThoughtWorks洞见
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 项目管理基础:什么是项目管理?
- 项目组合、项目集、项目管理实践经验及思考
- 项目管理:如何避免项目延期?
- 7 个支持敏捷的开源项目管理工具,更好地管理项目
- JEPM 正式发布:项目工时管理,让项目管理准时又高效!
- 敏捷项目中的项目管理如何做?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
程式之美-微軟技術面試心得
編程之美小 / 悅知文化 / 2008.06.20 / 490元
書內容分為以下幾個部分: ▓ 遊戲之樂:從遊戲和其他有趣問題出發,化繁為簡,分析總結。 ▓ 數字之魅:程式設計的過程實際上就是和數字及字元打交道的過程。這一部分收集了一些這方面的有趣探討。 ▓ 結構之法:彙集了常見的對字串、鏈表、佇列,以及樹進行操作的題目。 ▓ 數學之趣:列舉了一些不需要寫具體程式的數學問題,鍛煉讀者的抽象思考能力。 ▓ 書中絕大部分題目都提供了詳細......一起来看看 《程式之美-微軟技術面試心得》 这本书的介绍吧!