在我们日常客户项目评估中,最常用到的衡量单位是:人天,代表项目执行所需要的人数和周期,通常这个单位能比较准确的反映项目执行的周期,项目执行过程中参与人员的角色和重要性,但是往往带来一个很难衡量的项目风险:执行中的难易度问题。

举个最简单的例子,我们在项目报价中通常会看到诸如:需求分析师 15人天 这样的描述,我们如何规避上述中提到的风险呢?增加人天数。那么客户往往就非常疑惑:为什么同样的一个需求,不同的公司或团队评估出来的人天数差异这么大,或者说报价差异非常大,甚者可能其中一方的报价超出另一方100%还多。

严格意义上,我们无法完全去用报价高低来区分两者的项目质量,通常会认为报价高的一方可能会带来更好的项目质量,报价低的一方带来的项目质量可能就差一些,但是在客户的可接受范围内去选择的话,必然会倾向于选择报价低的一方。但是我们要提出一个有意思的系数,这个系数其实是一只存在的,在越规范的团队里它的存在感会越强,但是它的体现方式是多种多样的,它就是:项目难易度系数。比如增加需求分析师和销售合作,从来未销售和客户有效降低项目难度系数,靠专业的人员来为复杂的项目护航,又比如在技术环节增加经验更丰富的工程师来为项目提供技术上的保障,从而有效规避项目中未知技术难题带来的交付风险。

但是通常都是不透明的,在规定了交付周期的时间里,客户是无法准确感知项目团队是否增加匹配了经验更丰富的测试工程师或者是技术工程师,因为客户界面往往还在项目经理或者销售这边。如何传达项目难度系数变化带来的成本增加,往往是销售或项目经理最头疼的问题。客户也通常是不乐意为额外的成本付费的。

所以我们可以尝试一种简单的办法,既可以提现项目的难度,又可以增强双方对于合作中产生的成本或风险的认可。办法就是把项目难度系数放到需求分析中。

假如项目的难度系数最大是10,最小是1,这里的最大最小不代表项目交付体量的大小,也不代表成本,只用于表达实现项目的技术难易度。

例如我们正在交付一个项目,其中需要用到工程师约10人,项目经理1人,需求分析师1人,测试工程师2-3人,项目根据实施的模块不同,区分不同难易度,那么可能同样的人员配置,在不同的实施模块中的工作配比就会不同,所以在甲乙双方的沟通上,提前确认这些难易度的系数,从模糊的「这一块比较难」「这里耗时会多」等字眼中抽离出来,用系数来进行标注,并且配比相应的工时和人员,这样大家都会有一个比较直观的概念。

在理解系数之前,我们还有一个很复杂的问题需要简单的理解一下,那就是人员能力的问题。通常我们可能会提出一个命题:我们都用高级的工程师,高级的项目经理,那么这样是不是就可以不用考虑难度的问题,毕竟都是专家。自然没错,但是往往一个项目中不可能人人都是专家,无论从任何一方的成本考量,这都是一个太过于理想的假设,如果有,往往也需要大量的不同层次的人员进行填充弥补,去做掉大量的基础工作。所以,难度系数仍然是一个比要的有效的办法。

如何定义难度系数

首先,我们应该正确理解难度系数并不是恒定的公式,它更像一种范畴定义。它的定义来自于项目所有参与者对产品或项目的理解深度,理解深度越深,难度系数其实越好定义。所以,如何有效的拆分项目模块和工作事项,直接决定难度系数。

其次,难度系数是参考量,并不是决定量。难度系数是工时定义基础上的参考量,取决于项目参与者的水平和项目的目标,如果目标过大,难度系数定义即使再精确,也会偏离项目目标。这就好比我们一直听到的:我们现在预算1W人民币,你们能抄一个淘宝出来么?能还是不能,难度系数的定义就全然不同。

所以,难度系数的正确定义应该是:

在充分理解项目背景和项目实施方案的前提下,以双方当前认可的技术方案为基准,针对不同模块进行实施难度定义的系数。