最近在反思这个问题,工业产品的质量管理大多都有标准。而我们的软件研发却只有少数情况能如期交付。更多的时候则像是一个人在以十公里的时速在丛林夜行。两眼黑,走到哪算哪。
我反思为何管理的项目有些能如期完成,有些则出现巨大的时间误差---差距大到应该说是错误(只有可理解范围内的偏差才能叫误差)。
//待续
我反对过于臃肿的工程管理方式--这中方式严重制约事情的进展,而且容易流于形式。严格化的软件工程产生的无数在其出生既被视为垃圾的文档绝对是每一个关系人的心头刺。但是亦坚定反对放羊风格的工程管理。
1、工程的周期管理问题
工程的周期延迟的或多或少都与下面的情况有关
-
反复的需求
-
错误的时间评估
-
执行者的执行能力
-
过渡设计与不设计
第一个原因我有深刻体会。
毕业工作的第一年,我在一个创业团队当小兵(很感谢)。团队是随着互联网泡沫一块成长起来的,团队人数从20多人在一年时间内膨胀到60人(两年时间膨胀到130人)。当时的一个手机游戏项目在做项目评审的时候,讨论预计周期是2个月左右。7月份开工9月份左右上线。然而不幸的是,这么简单的项目都出现了一倍的延迟。项目到十一月下旬才上线。
我现在回顾当时的原因,很简单:
反复变化的需求。拍脑袋就能提一个需求,而拍脑袋的人不是执行者,最关键的是,执行者还必须要实现拍脑袋的人的那个idea---因为他是老板。投资人和PM/PMP的角色错位交叉是灾难性的,这严重违背了专业分工的发展趋势。拍脑袋的需求多意味着没有系统化整理的需求,另外也意味着没有设计和工程管理。
第二、错误的时间评估
这条也可以说是第三条,或者第四条中的“不设计”原因造成的。关键还是看周期延迟的黑锅谁来背。如果撇开因为不设计和分析导致对项目的无知,无知评估产生的项目延期,负责人背黑锅则是良心的做派。
第三、执行者的执行水平
我们撇开执行者的(相同类型项目)背景经验不谈,相同的事情给两个人做肯定有快有慢。显而易见的表现是,那么多的招聘需求都有各种要求。阅历越丰富的人越能在复杂情况中理出头绪快速推进事情。如果说是这条原因导致的延期,我建议PM自己把黑锅扛下来,因为PM显然是对团队成员有一定程度的无知。
第四、过渡设计与不设计
这点不用看了,肯定是项目的技术负责人的问题。过渡设计实际上很少出现,纵使有些人可能忧虑的很多(整天担忧项目能不能满足性能和后期扩展需求,而且仅仅止步于担忧,而不具体落实设计执行,这类人肯定缺乏经验)。
2、绩效管理
一说到绩效,大家都能想到KPI。
为什么要绩效管理?绩效是管理者试图规范化度量团队的工作成绩。这个真的很难考量。特别是大部门制的公司,或者大型项目组。
我对此也有很多的困惑,如果绩效管理真能永葆一家企业的青春,则不会有那么多跨国巨头进入暮年,倒闭了。