关于导致项目失败的程序的讨论

SCNA_logo

最初的问题

上周,在SCNA(北美2010软件技术大会)的一个专题小组讨论会上,Chad Fowler (@chadfowler)问道,“有多少项目是因为程序的原因失败的?”。按当时的情形,我想他的观点是,项目的失败归咎于业务问题,而非程序。会议室里很安静。可以看出,全体成员认为他说的是有道理的。我相信大家是都同意Chad的观点的。项目的失败,罪不在于程序,在于业务问题。

后续调查

Uncle Bob (@unclebobmartin)后来做了一次简单的微博调查,我和其他很多人都参与了。调查的结果是,赞成项目失败的责任主要归咎于业务问题、而非技术问题的占了绝大多数。Bob感到这么多人选择这样的观点表明了从长远角度看,程序不是那么的重要,因此,技术人员也一样显的不那么重要。Bob认真了提出了一些很好的论据来说明为什么程序很重要,来说明事实上,程序不仅能使项目失败,而且会使整个公司倒闭。我在这里不做更多的复述,我强烈推荐你们去读一下Bob的这篇文章, “The Cost of Code?” (外刊IT评论网提供了这篇文章的中文全文翻译),Bob在这篇文章里的大部分观点我都赞同。程序的成本很大。但我不认为所有的项目的失败都归咎于程序,但他用来说明这个观点的例子都很有价值。

原因和责任

证据确凿

一个人死了,一颗子弹击中了他的胸膛。一个项目失败了,只剩下一堆没有的程序码。对于我们来说也许事实很清楚,一颗子弹杀死了这个人。对于我们来说也许事实很清楚,糟糕的程序杀死了这个项目。在没有举出其它可能的论证、在现有缺少证据的情况下,我承认这两种认定。人被一颗子弹杀死,项目被糟糕的程序害死。

是的,从技术上讲,项目的失败归咎于程序。

扣动扳机的人

我们的悲剧并没有结束。我们不能够用消灭子弹来阻止谋杀,我们更不能用禁止对程序代码的依赖来挽救项目。虽然子弹和程序是原因,但它们都只是表象。

是有人扣动了扳机。

在大型项目中,要想找到一个受谴责的对象,你不能不提及那些自以为是的人。在大型项目中,通常都是众多的人为因素要对失败负责。如果我们要对大多数失败的项目进行考古发掘,我可以自信的说,我们会发现失败的原因都在人身上。我可以自信的说,我们会发现这些都是交流不畅的失败。这不是一种失败,是成百上千种的,大的或小的失败。缺乏远见,缺乏透明度。由于缺乏远见和透明度而导致的缺乏凝聚力。缺乏清楚的预期。责任不清。当不同意时缄口不言。以非建设性的方式发表反对。讨论起来像打仗。用煽动性的语言制造分裂。避而不谈失误。用发邮件来替代打电话。用打电话来代替面对面交流。过度强调交货日期。对时间和速度的认识截然相反。不重视周边工作。没热情 … 这个清单还有很多。

对于软件项目,程序是关键。你不可能制作一个没有代码的软件项目。程序代码越糟,项目的风险越大。当糟到一定程度,项目就会失败。更严重的是,公司也可能会因为这个项目而倒闭。

但我不会忘记,是我们写了这些程序。

是我们扣动了扳机。

[英文原文:Code as a Cause of Project Failure ]
分享这篇文章:

One Response to 关于导致项目失败的程序的讨论

  1. lfsfxy9 says:

    “如果我们要对大多数失败的项目进行考古发掘,我可以自信的说,我们会发现失败的原因都在人身上。我可以自信的说,我们会发现这些都是交流不畅的失败。这不是一种失败,是成百上千种的,大的或小的失败。缺乏远见,缺乏透明度。由于缺乏远见和透明度而导致的缺乏凝聚力。缺乏清楚的预期。责任不清。当不同意时缄口不言。以非建设性的方式发表反对。讨论起来像打仗。用煽动性的语言制造分裂。避而不谈失误。用发邮件来替代打电话。用打电话来代替面对面交流。过度强调交货日期。对时间和速度的认识截然相反。不重视周边工作。没热情 … ”

    的确,这是很严重的问题。处理不好开发小组员之间的关系,大家就会离散,没有凝聚力和创造力。

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据