登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 专题 > 敏捷项目管理 > 敏捷项目管理的关键是在哪里

敏捷项目管理的关键是在哪里

返回>

2018年03月16日    作者:佚名    来源:敏捷视界

A-A+

  敏捷头脑的负责人会预见项目执行中的不确定性变化,并灵活应对,而不是固守原来的计划。实践中,他们深知预估性判断的局限性,因而更信赖自己的变通能力,即根据变化对项目的步骤和做法进行调整。

  

  首先,看一下企业对“成功”是如何定义的。长期对软件项目进行“成功(或失败)”评级的斯坦希集团(Standish Group)认为,如果一个项目能够“在计划的时间、预算内完成,并达到所有计划之内的预期特征和功能”,便称之为成功。但是,这个定义不是以创造价值为基础的,而是以各种条条框框为基础的。按照这样的定义,项目经理们就只能紧遵计划执行,而不会去应对任何突发的变化。


  相反,如果把客户价值和质量作为最终目标,那么计划就成了实现这些目标的手段,而非目标本身。计划设定的条条框框依然重要,依然指导着项目的执行,但是我们也应该清楚,计划并非圣旨那样尊不可违,而是具有一定的灵活性的;计划应该成为行动的指南,而不是紧箍咒。


  传统的项目负责人也罢,敏捷的项目负责人也罢,都会制定计划,而且会为之投入相当的时间。但是他们对待计划的态度截然不同。虽然他们都把计划当作底线,但是传统的项目负责人会按照这个底线,时不时对实际的结果试图“纠正”。在敏捷项目管理中,我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。


  在关于敏捷处理原则的文件中——包括敏捷宣言(Agile Manifesto, AM)和相互依赖宣言(Declaration of Interdependence, DOI)——有对怎样随机调整做出的五条主要说明 :


  > 预见项目执行中可能发生的不确定性,并且通过试点、预估性判断和随机调整来管控这些不确定性。(DOI)


  > 通过采取符合具体情况的策略、步骤和做法,提高项目的效率和可靠性。(DOI)


  > 面对突发性变化,应该调整计划予以应对,而非继续执行原计划。(AM)


  > 哪怕项目已临近收尾,也要对客户在项目要求上提出的变化持欢迎态度。敏捷的项目过程能够控制并利用这些变化,来保证客户的竞争优势。(AM)


  > 对于如何更好地提高效率,团队要定期反思,然后根据总结出的经验,对团队行为进行调整或改善。(AM)


  以上原则可以归纳为两点:


  知晓变化(即不确定因素)可能随时发生,面对突发的变化,要进行相应的调整,而不能继续按原计划执行。


  必要时,对项目的过程和实施办法做出随机调整。


  这种应对变化调整的能力,能够激发团队的竞争优势。想像一下,如果能够每周发布一款新的产品,会为团队带来什么样的机遇 (而不是问题);如果能够整合性能,为客户提供个性化软件服务 (并保持很低的维护成本),又会给团队带来怎样的竞争优势!


  因此团队必须灵活调整,但调整的同时,也应保证项目的既定目标始终不变。此外,无论是做出调整,还是进行预估性判断,都要问下面的四个问题,来对项目的进展做出时时评估:


  (1) 最终的产品是否能够体现(客户/团队的)价值?


  (2) 产品的质量目标——可靠性和兼容性——是否达成?


  (3)在可接受的限制条件下,项目进展是否令人满意?


  (4) 当管理、客户以及技术等发生变化时,团队能否做出有效的调整和应对?

  

调节项目中的已知和未知


  每一个项目都有其已知的条件和未知的因素,有其确定的一面以及不确定的一面,因此每一个项目都必须在计划和随机调整之间取得平衡。这种平衡是必须的,因为项目可以是生产性的,也可以是开发性的,还可以是介于两者之间的。生产性的项目不确定性很低,而开发性的项目却是高度不确定的。开发性项目强调预见性,项目执行的过程,就是朝着预见的方向探索前进的过程,而不是制定出严密周详的计划,然后严格实施的过程。也就是说,计划或调整,不能说孰对孰错,管理者应根据项目自身的具体情况、具体条件,作出最恰当的选择。


  影响选择的另一个因素是试点成本,即做实验的成本问题。尽管对创新非常渴求,但如果试点成本过高,也会限制管理者,从而加大对项目进行预估性判断。而如果像之前提到的,试点工作成本较低的话,就有利于管理者作出随机调整的管理选择。这样一来,项目的计划、构架和设计等,就随着产品的开发进度,同步前进,同时变化。


  随机调整的幅度取决于三点:产品、步骤和人。首先团队成员应该团结敏捷,面对变化应该持有正确的态度。其次,采取的项目步骤和实施办法,要有利于团队在遇到突发变化时进行随机调整。最后还要有能够进行自动测试的高品质产品编程。你当然可以用陈旧的产品编程,也可以选择不敏捷的团队,但这样一来想要调整就非常困难。因此,如果团队想做到敏捷和随机应变,以上三点缺一不可。

  

驾驭风险,抓住机遇


  人们不想采取敏捷的做法时,往往会找各种借口、理由,甚至抱怨:“这样做太费时间了”,或者“这样做成本太高”等等。所以无论是短期试点,更新数据,随时整合,自动检测,还是其他的各种变通性做法,总是会遇到这样的托辞。更有甚者,很多公司简直像是患上了“新玩意”痴迷症——把所有的精力重心都放在开发新的东西上,而忽略了整合企业的传统编码程序。这样以来,传统编程变得散乱不堪,也成了管理者们拒绝做出调整的借口,甚至障碍。有的调整的确是成本高昂,而大多数调整,根本没有人们嘴上说的那么可怕,那么难。经验丰富的敏捷管理大师们,会把这些困难和障碍变为机会。他们会这样想:“如果真的这样做了,会带来什么好处?”


  数年前,我们曾与一家大企业合作,在一个很大的、超过500人的超大型项目团队里工作 (多个项目,下辖在同一个整合式产品套装之内)。当时我们要求对方在做完每一组试点后,必须进行完整的跨项目的编程整合。但对方却说:“我们办不到,这需要很多人手,而且要占用好几周时间,太影响项目进展。”原来这个团队以前习惯于临近产品发布环节才进行编程整合,所以之前他们的产品,老是在临发布前出现严重的问题。于是我们这样问他们,“要是编程整合没有你说的那么浪费时间、浪费成本的话,会给我们带来什么好处?”并且我们告诉他们说,“你们别无选择。要想为自己赢得敏捷便捷的余地,就必须尽早而且要经常对全套产品的编程进行整合。”


  他们虽然极不情愿,但仍然第一次认认真真的对产品进行了全面整合,结果发现用的时间远远少于预期。经过三、四轮的全面整合之后,他们也有了经验,可以在三两天内、用很少的人手,就完成全套产品的整合。这种时时整合的做法非常重要,帮他们的团队提前发现并解决了很多问题;而在以前,这些问题都往往是积压到产品发布之前,才集中暴露出来的。


  多数情况下,虽不尽然,找种种借口拒绝调整,往往会直接导致效率低下,因为它让企业失去了精简流程、提高随机应对的机会。培养团队的敏捷性,必须进行小型的试点;而小型试点的目的就是找到方法,让重复的工作环节能够低成本地快速完成。而快速且低成本的工作习惯,又能促使团队面对变化,另辟蹊径。快速低成本的解决办法,还能够鼓励团队勇于创新,从而锻炼团队的创新精神。而这种创新又会影响到企业的其他部门,产生涟漪效应。这样一来,降低成本应对变化,就会促使企业重新思考它的商业模式。

 

采取可靠而非可重复的步骤


  必须指出“可重复的”并不意味着敏捷。虽然实施可重复的步骤,已经成为许多企业的管理目标,但在产品开发的过程中,追求可重复的目标却不仅是错误的,而且会极大的遏制产品的开发。


  可重复意味着用同样的方式,做同样的事情,产出同样的结果。而可靠性却指的是无论遇到什么困难障碍都要实现既定的目标——也就意味着不断的作出调整,应对各种变化,实现定好的目标。


  可重复的步骤,通过制定标准和对流程的不断改进,来减少产品的质量变化。这是一个源于制造业的词。因为在生产制造中,产出什么样的产品,是已经定义好的。那么可重复性就意味在生产过程中,只要连续输入,就可以产出预期的结果。


  可以重复意味着从输入到产出的转换过程是可以复制的,而无需任何变化。它还意味着生产的过程不会有任何新情况发生,因为所有信息都全部预先知道,来保证最终的精准产出。


  但是,可重复的步骤在产品开发中毫无用处,因为首先很难精准地判断出最终的结果;其次项目不同,项目的投入也大不相同;第三,开发不同产品,从输入到产出的转换过程本身更是大相径庭。


  可靠的步骤过程关注的是产出,而不是投入。哪怕是投入完全不同,通过采取可靠的步骤,项目成员也能够想出各种办法,不断向既定的目标靠拢。也正因为投入的差异,他们决不会把一个项目所采用的步骤或做法,亦或是试点,复制到另一个项目中。可靠性是受结果驱动的;而可复制性是受输入驱动的。如果把项目的步骤固定下来,那么项目本身就会因为投入和转化的巨大差异,而变得极其危险。


  即便是那些声称采用了固定步骤且获得成功的企业,他们的成功并非来固定的、可重复的过程本身,而是来自企业员工在实施这些步骤时,进行的敏捷调整。


  此外,这里面还有一个项目规模问题。在生产型项目中,尤其是那些适合采用重复性步骤的生产型项目,既定的生产要求就是项目的规模范围。但是在产品开发时,生产要求会随着项目的周期发生更改,因此根本无法在一开始时就准确界定一个项目规模。


  因此,对于开发产品这种本身就比较敏捷的项目,要想准确估计项目的规模,不能只看生产要求,而要看项目的远景规划—即可以发布的产品。


  产品经理们也许会拿不准具体的要求,但行政主管们会对产品进行整体考虑—那就是最终产品能不能够满足客户的期许?所以再次听到这个耳能详熟的问题 “项目是不是达到了既定的规模、方案和成本目标?”我应该首先对项目的远景规划、价值和整体的表现能力进行衡量,然后再做出回答。


  也就是说,对成功的衡量,可以包含在这个问题中:“有没有做出可以发布的成熟产品?”而不是看项目的种种计划指标是否都已经达成。

责任编辑:王兴钊

标签:项目管理
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
官方新浪微博
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3
PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设