技术项目的失败,屡见不鲜。不论你运营的是一个持续跟进一些项目的软件公司,还是一个需要顾问来为提供系统集成的非技术公司,都有可能遭遇这个问题。进度延期、预算疯涨、直至最后完全失败,这在软件世界非常普遍。
错误一:采用平庸的开发团队
软件设计是有难度的,而且不幸的是,很多自称程序员的人确实不能胜任软件设计。尽管这是项目失败的首要原因,你也不曾从官方的失败报告中得知。在所有的行业,软件业,物流业,或者客服业,人们对同事的无能都太过宽容。你从来都不会听到有人说“我们团队没有足够的智慧来完成这件事”。为什么要这样伤人的心呢?显而易见的,如果这队分得了任务的人员并不擅长这份工作,他们的工作会日复一日,日复一日……等等……但软件却没有做出来。你也不用太担心HR会阻挠你招聘一班废物。在大多数的案例里,我向你保证,HR对此毫无建树。
错误二:按周来定目标
假设你想改造你的厨房。你请来的师傅已经搞过很多厨房,而且不作详细蓝图就能估算出这项工作的成本。但软件开发者是在制造前所未有的东西。如果前所已有,他卖张拷贝的光盘给你就行了。因此,粗略的估计是不可能的。他们需要在写代码之前做好详尽的计划。无论你是客户还是开发经理,你的责任就是确保开发人员带着详尽计划来开展工作。当你向开发人员询问计划时,他们大多数人可能只会给你一份把进度按周来划分的时间表。这看似非常合理,但其实不然。如果你让软件团队提交一份大粒度的时间表(大是指需要两天以上的工作),那么你可以认定他们没有考虑到所有需要实现的细节,而这些细节将会积累,导致延期。
错误三:为截止时间而谈判
还有什么比按周划分软件项目更糟糕?就是要求团队承诺大大地提早完成工作。大多数开发者都会乐观地接受你的暗示并参与讨价还价。然后你会得到一份友好的协定时间表,但却无法按时执行。
错误四:均分任务
这里有一个破坏项目的好方法。列出人们需要做的所有工作,然后给重新均分给各人。这听起来完全合理,使得你不会被质疑。但时间一长肯定会出现问题。那是因为当一个开发者去替代另一个时,有理由假设效率降为十分之一。将会花费无数小时去搞清楚其实已经熟悉的那部分代码。
错误五:工作到深夜
假设有个项目要每周工作40小时,连续六个月才能完成。如果所有人每周工作60小时,那么持续四个月就能完全搞定。软件团队可能甚至会接受这个挑战,因为这使他们看上去像英雄。有一部完整的文献论述了“加班不会使软件更快产出”。
软件开发者花费大量的脑力劳动。即使是最好的程序员,也很少有能坚持几小时以上的高强度脑力劳动。另外,他们还需要休息一下大脑。这就是为什么你好像总能撞到他们在上网或玩游戏。
强迫他们投入更长时间坐在电脑前,并不会转化为更多的产出——即使会,那都将是劣质的产品。当软件开发者的大脑完全发烧,他们几乎做错多过做对,写出无法使用的代码,或者引入大量的bug。而如果你真的禁止他们上网,玩多人游戏,强迫他们在正常的睡眠时间继续写代码。死亡行军不是造成项目延期和预算爆炸的唯一条件,但绝对是充分条件。
----威海软件开发----