敏捷项目管理——响应变化高于遵循计划(采用敏捷项目管理方法,在控制进度过程中需要)

前言

敏捷项目管理——响应变化高于遵循计划(采用敏捷项目管理方法,在控制进度过程中需要)

响应变化高于遵循计划

“响应变化高于遵循计划”—敏捷宣言。

在当今变化莫测的时代,昨天5G刚刚兴起,今日6G已悄然开始布局。如何抓住时代的红利是每个产品或者项目管理者都要思考的事情。越早响应变化,就越早能够享受变革带来的红利,反之,一味的遵循计划只会被时代抛弃。

接下来老程与大家一起分享敏捷项目管理中的响应变化的知识,旨在让大家了解,敏捷并非是洪水猛兽那么可怕,相反,顺应时代的潮流,引领大家体验敏捷的奥妙!

请各位抓紧时间上车,坐好扶稳,老司机开始飙车了

let’s go


适应学

敏捷项目管理——响应变化高于遵循计划(采用敏捷项目管理方法,在控制进度过程中需要)

世界上最后能生存的生物,不是最强的;也不是智慧最高的,而是适应能力最强的

“世界上最后能生存的生物,不是最强的;也不是智慧最高的,而是适应能力最强的”—英国生物学家达尔文

传统的项目管理者注重按计划行事,尽量做到和计划没有出入;而敏捷项目领导者关注如何成功的去适应不可避免出现的变化《敏捷项目管理第二版》

传统的瀑布式项目管理,往往前期做了大量的计划,制定各项约束,详尽的文档。而敏捷项目管理者则更注重价值。

曾经有段时间,老程接收集团一个LMS(实验室系统)时,先收集需求(各部门及客户)勾画更重流程图,反复的讨论;在调研完毕后,关起门来,奋力书写几天,终于在抽了几包烟以及双眼熬成“国宝”项目需求说明书,项目计划书等等文稿出世了。

接下来信息慢慢,觉得这下子,改兄弟们大展拳脚了。一开始项目进展挺好,中期有一次和市场部门人员闲聊时,对方提了一个随意的问题;听闻他讲完,老程心中不禁大吃一惊。糟糕,这里没有想到,确实是客户需要的功能,但项目已经进行到中期,如果改动,意味着要打破计划,于是,心一横,对市场人员说,你的想法很好,第二个版本我会考虑加上。

就这么团队人员吭叽吭叽码了几个月代码,项目宣告完成,交于市场人员推向市场,获得反馈真是多,比各位粉丝的评论还要热烈,于是团队成员不得不再次修改项目,期间团队的气氛压抑到极点,好在最后经过无数次的抢救,项目被抢救过来了,市场反应相对小一些。

结果这一次项目,反思了一点,为何要制定详尽的计划?详尽的计划一定是对的吗?能不能,划分模块,相互独立的模块,由市场人员来确定优先级,做完一个阶段的功能后,让市场人员进行评审,并收集反馈,进行更高。

于是在第二个项目《XX旅游网》启动时,采用轻计划及规范。由客户参与,罗列出项目的愿景及价值。在一次周日,老程坐上游轮到香港的中环,在总部和客户进行一次交流,虽然那几个美女热情的讲解,但没听懂多少(对方讲英文,连蒙带猜,懂了50%左右);咳咳,一不小心跑题了。

书归正传

在第二个项目中,我们团队吸取上个项目的教训,决定采用迭代式交付。虽然也属于传统型项目管理,但比瀑布式要好的多。

通过小版本的迭代—评审–修复缺陷–发布,期间用到看板,这种项目管理流程,HK的客户MM们挺满意,期间特意从HK来公司进行深入交流,气氛异常融洽。

直到接触到敏捷后,才知道,原来是有一种项目管理方法是基于变化、实现客户价值为核心的方法,那就是敏捷。

适应性原则声明

《声明》:预测不确定性,并设法通过迭代、预防、适应来应对不确定性;

《声明》:通过使用根据具体情况而定的策略、流程和实践来提高效率和可靠性;

《宣言》:响应变化胜过遵循计划;

《宣言》:即使在产品研发后期,也乐于接受变化的需求,敏捷流程充分利用变化以增加客户竞争优势;

《宣言》:团队定期反省如何做到更有效,然后响应的调整团队的行为。

总结:

以客户价值和质量为目标,计划就是实现这些目标的方式而非目标的本身。计划中的约束依然重要,只是不是重点,重点变成了计划约束是指导项目完成的一种方法,在随着项目的深入,要对计划进行剪裁和更新,使一潭水由死变为活水。


敏捷项目管理——响应变化高于遵循计划(采用敏捷项目管理方法,在控制进度过程中需要)

敏捷项目管理之探索

探索

敏捷是为了在动荡的商业环境中创造利润而制造并响应变化的能力–《敏捷项目管理》

有响应变化的能力固然很好,但是如果能给竞争对手创造变化则更佳。创造变化就是向对手展开竞争攻势。想赢对手的变化,是防守。

变革是困难的,比如,老程一直想戒烟,无奈抽上容易,戒掉很难。要警惕那些固有的习惯,习惯有时会成为惰性,阻止我们作出变化。

尽管敏捷价值观告诉我们,响应变化比执行计划更重要;但往往研发团队习惯固有的计划,而不愿作出大胆的探索,因为探索带来的可能是颠覆性的重构。

探索式困难的,容易引发焦虑、恐惧。这是就需要敏捷项目管理者及时鼓励团队成员,鼓励试错、借鉴成功经验和错误经验,创造安全的环境,让大伙大胆地说出自己的想法。外部的鼓励和内部的鼓励可以帮助团队建立内部激励;

研发产品是需要被引导而不是被管理,我们容许团队成员有好的点子,有变革的激情。每个项目都有一只和未知的条件、有确定因素和不确定的因素,因此,如何在计划和变化中找到平衡点变得尤为重要。这就需要我们用各种方法去探索例如用户故事作坊、用户特性、用户角色、用户画像、用户故事、每日展会、评审会等等方法来帮助我们。


研发人员

在研发团队中,最重要的就是人员。如何点燃人员的激情,很重要。需要各种激励和惩罚手段来调动和约束人员。

人员的意愿也很重要,如果人员对敏捷项目管理或者对公司文化认同,不用打鸡血,人员会释放自己的激情,关于如何做,请参照老程的另一篇《敏捷项目管理-在敏捷环境中交付》一文。


敏捷项目管理——响应变化高于遵循计划(采用敏捷项目管理方法,在控制进度过程中需要)

障碍还是机会

障碍?机会?

老程经常有听到:“敏捷做法太耗时间、敏捷做法太昂贵了、敏捷流于形式”等等对敏捷的抱怨。这种做法往往是针对短期迭代、频繁更新、持续整合、测试等一系列其他的敏捷做法。

大多时候,人们感觉适应变化成本太高,是因为做事相率低下–没有抓住机会简化流程提高组织的适应能力。敏捷研发需要短期迭代,持续集成。很多公司在运用敏捷时,对WIP没有限制,一股脑的把probacklog中的所有事项集中到doit中,高速公路因为在制品的增多,不堵车才怪。可以参照我的另一篇文章《敏捷项目管理-精益产品开发》。

如何看待障碍和机会?我们在遇到困难或作出变革时,要经常问一句“这样做对我们有什么益处?”


结束

开发优质的产品需要探索,而不是遵循计划。探索和适应是创新的两个行为特质–拥有探索未知世界的勇气,拥有承认错误并适应形式的谦逊。

在敏捷中,我们运用一些列的方法“KANBAN、精益软件研发、Scrum、xp、sprint、站会、评审、回顾”等等方法,丰富软件研发的方法,为我们提供有依据的探索工具和方法,让我们在研发的探索之路上不迷路!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。