关于项目质量
最近做了一个项目,质量说实话堪忧。
项目开始的时候还是规划的很好的。预算不说充足至少是够用,所以人员配备也不错,项目计划按正常出。一切看起来都很美好。
计划阶段开始出现问题。首先是客户承诺交付的需求和设计无法交付,只能给一个非常粗略的框架图。然后是项目时间计划,由于项目的采购阶段延误,但是验收时间不愿意延迟,导致项目要分阶段上线。在最开始的阶段需要上线MVP,剩下的功能,由于其中一部分需求不成熟,要再分两期上线。整个项目上线时间变成三次。
最近做了一个项目,质量说实话堪忧。
项目开始的时候还是规划的很好的。预算不说充足至少是够用,所以人员配备也不错,项目计划按正常出。一切看起来都很美好。
计划阶段开始出现问题。首先是客户承诺交付的需求和设计无法交付,只能给一个非常粗略的框架图。然后是项目时间计划,由于项目的采购阶段延误,但是验收时间不愿意延迟,导致项目要分阶段上线。在最开始的阶段需要上线MVP,剩下的功能,由于其中一部分需求不成熟,要再分两期上线。整个项目上线时间变成三次。
作为服务提供商,应对不好对付的客户,大概是项目经理的日常。我们常常抱怨,也常常听到各种别人的故事。每个人做项目,都想有水平高的交付团队,专业且合理的客户,足够的预算,充足的时间。然而现实总是很骨感,不完美的客户是我们很多时候逃不了也逃不掉的现实。
如果有人问你,项目经理最重要的工作是什么?
你大概会脱口而出,沟通。90%的时间用于沟通。
但是如果是一个内向的人怎么办,不愿意太多跟人沟通,参加没完没了的会,不愿意晨昏定省,不愿意实时报备,不愿意三不五时的溜达过去只是闲聊几句。
怎么办?
很遗憾,最根本的答案可能是,内向的人不是很适合做项目经理。
上篇提到了两个教训跟理所当然的假设有关。我们可以很笼统的把他们归结为沟通不到位。但哪怕很主动沟通的项目经理也经常会问,我需要沟通什么?假设的验证就是一个很重要的内容。
项目中的假设是什么?按定义,假设是那些你认为是真实的事情:那些你认为以后会发生但还没有发生的事情,你觉得是真实的业务事实尽管你并没有证据。然而记住,我们不把这个叫拍脑袋,我们管这个叫Educted Guesses。
今天聊一聊项目管理中的容易踩的大坑,那些看得见的、看不见的、认为是理所当然的假设。
这个话题分两篇,第一篇先给大家分享两个让我印象深刻的经验教训。
第一个是之前有一个项目,系统需要与一个其他系统进行对接,需要对方系统给我们开几个API接口。
在项目初期,对于这个数据交换需求与那个系统的技术同事做过初步对接和可行性评估,评估的结果是大概开几个接口,技术也可实现。于是项目就愉快的推进了。
在网上看到一个数据,只有15%的项目经理一次只需要负责一个项目,其他的项目经理都需要同时负责多个项目,甚至有15%的项目经理一次需要负责10个以上的项目。
我在工作中,也只有很少很少的时间里,是一次性只负责一个项目。
同时负责很多个项目会产生一些需要克服的困难,比如最明显的如何在不同的项目中分配自己的时间和精力,如何同时满足不同客户的不同需求,如何在不同项目之间分配资源,等等。
摘要:本文取材于PMI《The Benefits of Tailoring》关于如何对于项目管理方法论进行裁剪。解决大家日常工作中经常听到“裁剪”这个词却不知道如何动手的困惑。
原文信息:
Whitaker, S. (2014). The Benefits of Tailoring: Making a Project Management Methodology Fit. PMI White Paper.
https://www.pmi.org/learning/library/tailoring-benefits-project-management-methodology-11133
本文是PRINCE2 第7章,计划主题的学习笔记。本章主要介绍项目计划,项目计划的构成,项目计划的编制。具体介绍了一步一步的项目计划编制方法。
PRINCE2与PMP的计划编制内容大同小异,区别在于PRINCE2强调用以产品为基础的计划编制,PMP是以WBS为基础的计划编制。核心都是将整个项目的交付物进行分解,然后通过自下而上的估算,计算出每个活动所需要的资源、时间、成本,再构成项目的总体计划、成本。
项目管理的关键链法是关键路径法的一个延伸。其主要目的是避免糟糕的多任务制,“帕金森法则”和“学生综合症”。
那么关键路径法是什么,又是怎样实施的呢?
关键路径,就是完成项目所需要的最长路径和最短时间。很拗口,举个例子。一个项目,首先做WBS,分解出6个工作包。如下图:
画出它的关键路径
可以看到,关键路径是上面那条,时间为21天。
用MS Project的Gantt图表示:
项目时长 = 关键路径 = 21天
注意,其中有一天的时间作为buffer,在task3后面。
那关键路径法有什么弊端呢?
首先,关键路径要求项目的变化很少。一旦有变化,关键路径上的task时间延长,整个项目时间延长。
第二,这样简单的做关键路径规划,没有考虑资源的使用。比如上面的R2就同时在做Task2和Task5,这也很可能不能按期交付。
第三,buffer时间的使用并不效率。比如驾驶Task1实际使用了4天就完成,但是Task2仍然在第6天开始这种情况。还有就是最开始说的“帕金森法则”(Parkinson’s Law) 和
“学生综合症”(Student Syndrome)
如今的软件行业已经越来越往敏捷的方向发展。我们在工作中常常遇到,其实PMP这一套并不怎么实用。曾经有一次面试,面试官问我是如何将PMP中学到的知识运用到现实的工作中的。我瞬间懵了一下,努力回想自己平常工作中的运用。然而这个问题答的也不是很好。
偶尔看到这本书,发现这便是可借鉴的标准答案,PMI是如何将它的项目管理方法论运用到软件行业的呢?
首先看书的框架。见下图:
从框架上看,与PMBOK的第五版并没有什么不同。都是首先总体介绍,然后讲项目生命周期和项目管理流程,最后讲几大知识域。
继续翻看,从生命周期看,PMI将结合了软件行业不同的生命周期类型来匹配了自己的项目管理流程。
如瀑布式:
迭代式:
Scrum理念的
从PMI的角度来看,软件行业可以选择不同的生命周期,但每个生命周期都必须经历的项目管理过程组是一定的。瀑布式的项目更是在每个阶段都会经历一次完整的项目管理周期。这也是PMI一直强调的产品生命周期与项目管理生命周期的区别。
其后的每个知识域,这本书都突出写明在软件行业的特定条件下,项目应该怎么管。大多数的输入输出都直接指到了PMBOK 第五版。我们在阅读的时候可以着重看一下,书中写的特殊活动。比如在整合项目管理中,就写到了项目经理在管理适应性项目中应该做的活动;软件项目信息披露应该包括哪些部分。甚至写到了项目组中需要有一个大的显示装置——纸质的或电子的——让团队成员可以一眼看出项目现在的状态,这也的良好做法。
在软件项目管理中,我们有太多新式的管理方法论。PMI这样的庞杂的系统往往看似冗余。但是这本书对于软件项目经理平常翻看也有一定的参考意义。