艾伟也谈项目管理,动起来再调整 - 向项目经理推荐敏捷

简介:   要成为一个好的项目经理需要学会逆水行舟。虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方。  “虽然很有道理,但我认为现实不允许,很多项目都有规定的期限。中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的。

  要成为一个好的项目经理需要学会逆水行舟。虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方。

  “虽然很有道理,但我认为现实不允许,很多项目都有规定的期限。中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的。”

  “写得不错,但是有些建议过于理想化了。毕竟说得很有道理,但实际中具体做起来又不是那么一回事了。”

  这是两位网友对《软件项目经理新手上路》的评论。这话很有道理,也是在现实生活中碰钉子碰出来的。在项目中确实存在很多限制,我们应该顺应限制,顺水推舟,否则会很难看。但如果这些限制间存在矛盾的话,如何能够做到顺水推舟呢?例如,项目资源限制与最后期限限制的矛盾。

  1. 向项目经理推荐迭代

  例1:项目经理张三到了一个新公司带一个项目。客户、产品、团队、流程、制度、环境、领导,一切的一切对于张三都是全新的。

  例2:开发人员张三因为优异的工作表现被提拔成项目经理。虽然张三对于项目中的业务、技术、产品和团队成员都比较熟悉。但是项目经理是一个全新的视角,张三需要从一个全新的角度去看待和处理问题。

  公司领导找到张三谈话,明确提出了项目的最后期限,希望张三能够给出一个计划。张三应该怎么办呢?

  虽然上述两个案例比较极端一点,但是在接手项目的时候存在几种未知情况是很常见的事情。在前面的建议中我们谈到了项目经理要承认有所不知,同时尽可能在公司内寻找一位项目经理导师。但这还不够,在应对项目的实际情况时,推荐采用迭代。

  迭代的时间一般是一到三周比较好。即使你的项目只有两周,也推荐分为一周的两个迭代。应该在项目经理导师的指导下,将需求划分到迭代中。每个迭代都应该像一个真实的项目,包含从需求到测试再到发布的全过程。

  2. 迭代的优点和注意事项

  麻雀虽小,五脏俱全,子项目也是一个完整的项目。以半年的项目为例,三周一次迭代,就能变成八个子项目,两周一次迭代,就是十二个子项目。

  无论你是新手项目经理,还是对项目本身情况不够了解的项目经理,你都可以从迭代中获得如下好处。

  2.1 好处:咱输得起

  分成迭代的第一大好处就是咱输得起。如果一个项目只有一次实施机会,如果完成的不好,就只有完蛋。而换成迭代后,一个迭代完成的不好,咱输得起,下个迭代想办法追回来。

  2.2 好处:先动起来

  相比以前漫长的计划协调、需求调研、可行性分析等等过程,迭代让你能够快速启动项目。专注于第一个迭代的目标,从而很快就能有产出。

  2.3 好处:暴露问题

  对一个项目而言,其实很难完全预测问题会出现在哪里。是团队人际关系、设计开发能力、刁钻的客户、资源不足,还是其他问题?要预测全部问题并给出完美的答案解决是几乎不可能的。而迭代能够帮助暴露这些问题,不需要老是拍脑袋,投入资源去处理可能根本就不会发生的风险。

  咱输得起,毕竟只是一个迭代嘛。项目的大问题就这样变成了迭代中的小问题,而项目经理经常处理这些小问题,经验就积累起来了三。

  2.4 好处:快速积累经验

  相比以前漫长的项目周期,迭代可以帮助你快速积累项目管理经验。除了通过解决问题积累经验外,还可以多做尝试。既然咱输得起,咱就敢在合适的情况下不断尝试项目管理的想法和做法,而不像以前必须对公司的标准做法生搬硬套,以便在项目失败后少被挑刺。

  2.5 好处:辅助沟通

  领导愿意在有产出的项目上继续投入,却不愿在项目早期花太多时间给你磨嘴皮讨价还价。第一个迭代的产出可以帮你大忙。领导你看,我们的产出是这些,但是还有些困难,是不是帮解决下呢?这个时候领导也会变得好说话些。客户也一样。人皆如此,要创造锦上添花的机会,别老是叫别人雪中送炭,很辛苦的说。(至于给领导的计划,就告诉他在用敏捷,然后给一个分迭代的计划就好。)

  2.6 好处:持续成长

  每一个迭代都会有收获、有产出,而下一个迭代会建立在上一个迭代的基础上。在这个过程中,你、团队、技术、业务、流程等都可以持续成长。

  2.7 注意事项

  全讲好处了,你心动了没?要使用迭代还是有些注意事项的。迭代需要改变一次性完成的设计和开发方式,并且在后期回归测试的工作量会明显增加。需要在项目经理导师的指导下,引入对应的实践逐步解决。(话说不用迭代,采用老方法,一样有注意事项。)

  3. 继续演化

  在确定了使用迭代后,需要从原有的整体需求中取出一块作为迭代的需求;需要在迭代前召开会议,和团队一起了解迭代需求,并制定迭代的开发计划;每天早上和项目团队一起开个会了解下有没有问题,进展是否顺利;在迭代结束时需要检查迭代需求是否切实完成(通过测试并发布);在迭代结束后,举行回顾会议,和团队一起巩固做得比较好的部分,对发现的问题需提出改进方案。

  也需要自己进行一下回顾,看下自己在这个迭代中哪些地方做得好,哪些地方还可以提高;哪些方法有用,哪些方法效果不佳,下次迭代采用什么方法;项目中还有什么问题,领导和客户的反馈怎么样;需要采取哪些措施,需要进行哪些沟通。

  这么一步步来,好像敏捷就不远了。这不,除了角色和燃尽图外,Scrum的其它要素就齐了。C项目就是这么一步步走过来的,虽然由于组织原因,C项目的敏捷实施并不完美。

  你是不是也想试试呢?(尝试有风险,请在你的导师指导下进行,呵呵。)

目录
相关文章
|
测试技术 项目管理
艾伟也谈项目管理,对项目管理的几点认识
自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目。中国有句古话叫“旁观者清”,同一个问题站的角度不同,可能会形成不同的结论。下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正。
945 0
|
项目管理
艾伟也谈项目管理,IT项目管理的六种错误思维
  错误一:错误的需求调研阶段,导致很多项目永远无法结束!       在软件行业,在界面设计没有正式展现给客户之前,所有的工作都处于需求调研阶段。其实建筑行业已经给我们做好了先例:客户买房子之前是先要看看样板房和模型的,什么都看不到,这房子你敢买么?除非你不是自己住!而在我们所学的软件工程概念模型中,这是三个阶段:需求调研、需求分析、概要设计。
1249 0
|
项目管理
艾伟也谈项目管理,项目管理 – 人员外购利弊谈
  昨天与同行进行案例讨论时得知,前2个月还被列为正面经典案例的项目到这次讨论时居然变成了反面典型,真可谓成也萧何败也萧何啊。   该项目是一个软件外包项目,发包方是非中国大陆的客户,项目规模在500人月左右,团队人数峰值为50人,实施周期为12个月。
1036 0
|
测试技术 项目管理
艾伟也谈项目管理,项目管理 – 人员外购利弊谈(续)
接上一篇文章“项目管理 – 人员外购利弊谈”。   以上方案只是初步分析,其缺点都是有相应解决办法的。  该公司对以上情况并没有使用DAR(决策分析解决方案)方法进行正式和认真的分析,仅仅从能快速启动和项目利润两个方面考虑来选择了最终的解决方案:项目经理由公司的技术和业务都掌握的人员担当;各小组的组长和测试组长采用人员外购的方式;项目组成员1/3由公司员工组成,1/3由实习人员组成,1/3采用外购方式。
1054 0
|
项目管理 C#
艾伟也谈项目管理,切勿过早优化
  Donald Knuth说“过早优化是万恶之源”(premature optimization is the root of all evil)。这话也许有些夸张,但“过早优化”的危害我觉得不能忽视。
1226 0
|
程序员 项目管理
艾伟也谈项目管理,较大型项目的产品工作心得
  最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。   立项前   1、统一元素设计需考虑周全   也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。
1294 0
|
项目管理
艾伟也谈项目管理,话里话外:流程管理,其实可以做的更多
  在为企业做流程管理项目的时候,我们经常会反复的给企业流程经理灌输这样的一种思想:流程管理,并不仅仅是把流程图画出来,装订成册就结束了,流程管理其实可以做的更多。流程管理实际上是一种建立在流程基础上的管理体系,是从流程入手,借助流程这个平台将各种管理方法结合在一起的管理模式。
926 0
|
测试技术 项目管理
艾伟也谈项目管理,敏捷个人:内容框架之执行力
  执行力是敏捷个人需要学习的一个内容,本篇主要介绍执行力相关的内容,大家在读后可以采用介绍的一些指南开始行动。 执行力的三个层面 按照命令和规则做事的过程,简单讲就是能够听话照做 按照预定的计划行为的过程,简单讲就是做事章法 将想法变成现实的过程,简单讲就是规划实现   对第一个层面来说,要做的事情是片段的、非连贯的,但对第二个层面来说是连续的、整体的。
1012 0
|
测试技术 项目管理
艾伟也谈项目管理,关于项目管理的一点体会
  这段时间,一直在负责一个项目的管理与开发。在时间短、任务紧,而团队人员又大部分是没有经验的菜鸟的恶劣情况下,我带领接近40人的团队,终于在客户规定的时间范围内如期交付产品。这其中,经历了需求变更、人员变动(因为其它任务,先后有近10人离开团队)等诸多问题,项目仍然取得成功了,不能不说有几分侥幸,但此外也有一些经验与教训可以与大家分享。
990 0
|
测试技术 项目管理
艾伟也谈项目管理,只有好代码的项目能成功吗?
  Simon Brown,集开发者、架构师及作家于一身,他认为成功的项目需要的不仅仅是好代码。在他的演讲《好代码是不够的》中,Brown讨论了项目成功所需的所有元素,从前期设计到操作文档。   Brown认为好代码是一个好的开始,但要取得成功,人们需要知道要构建什么、要发布什么以及它可以运作起来。
941 0
下一篇
无影云桌面