调查：软件开发过程中工作量（成本）都是如何分布的？

就著名的《人月神话》（含《没有银弹》）中有关软件生产率的问题，最近有意整理一篇相关的文字。在这里跟大家做一个调查。 每一个项目经理，都会关注项目的成本。 我这里所指的成本，只是指软件生产过程中的成本（工作量）。 至于其他的成本，例如销售、采购等等的费用都不算。

人月神话中是这么说的：

引用

所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。

引用

我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多数系统中的概念错误相比，它们是微不足道的。

为了验证一下真的如《人月神话》中的结论，我想请大家根据自己的实际经验头一下票，验证一下。

以我的理解，将软件生产过程拆成 调研咨询，需求，设计，开发，测试（QA）。 要特别提一下，我这里的设计，自然包含了详细设计，即使你在没有任何设计的前提下去写代码，事实上你也肯定要去考虑设计的。

我把软件生产过程中的全部工作分为2个部分，合计为100%。 打造概念结构的工作属于A类，表达这个概念结构属于B类。
调研咨询，需求，设计近似属于A类，而开发则属于B类。
测试（QA）是对前面两方面的验证，用来测试概念化思维工作的成分你计算为A类，还是用来测试构造工作的作为B类。（如果你的项目里对于测试时会明确区分问题发生的原因是设计原因引起还是编码引起还是需求引起的话，就很好区分）

投票时如下：
A类： 50%
B类： 50%

如果大家对具体工作所属类别的划分有意见，或者对于该书的论点有意见，请在投票的同时写下你的观点和分析。热烈欢迎就这个问题交换意见。

评论

29 楼 丁丁豆 2009-08-03  

不错，有功就成，[e-mail]  有时间加我msn 一块聊天

28 楼 donald 2009-07-09  

为什么能力强的要当救火队员？我始终想不明白，我想尽办法都好象走不出救火队员这个角色。
A 60%
B 40%

27 楼 tiannet 2009-07-07  

编码只是软件的冰山一角（尤其对于企业应用软件），不过很多程序员没意识到这个问题。
A 70%
B 30%

26 楼 phpxer 2009-06-30  

xiaohan.sun 写道

在《人月神话》中作者提到了自己的经验法则是：
1/3计划、1/6编码、1/4构建测试和早期系统测试、1/4系统测试。

工作量分布情况需要视实际项目而定，新项目所需要的设计时间总是要高于比较熟悉的项目的设计时间，但总的说来还是要保证有充足的设计时间，否则越到后续环节，问题的爆发越会成指数级别增长。
项目的时间管理中有叫做PSP和TSP的东西，它们可以帮助进行项目时间管理分析和经验积累，我觉得经验这个东西还是从自己做的项目中来得实在，LZ不妨可以使用这个看看，也许不久之后，这些数据就可以回答你的问题了。

chenlixun 写道

计划、调研、分析、设计、编码、测试都是生产过程中的环节，成本应该包括过程中的所有环节产生的成本，而产出物应该包括各个环节的产出物，具体成本分布率须根据不同的项目（新/旧、熟悉/不熟悉等因素）、不同的软件开发过程而定。

个人认为<<人月神话>>等文中提到的分布率，只是个参考依据罢了。

上面是一点点不成熟的意见，不知当讲否！

看来目前大家都没有特别去收集数据.... 给个经验值吧？

我也没有特意去收集数据，但是总感觉我们花在编码之外的时间其实很多的，但是又经常跟编码掺和在一起，跟维护掺和在一起。

25 楼 chenlixun 2009-06-30  

计划、调研、分析、设计、编码、测试都是生产过程中的环节，成本应该包括过程中的所有环节产生的成本，而产出物应该包括各个环节的产出物，具体成本分布率须根据不同的项目（新/旧、熟悉/不熟悉等因素）、不同的软件开发过程而定。

个人认为<<人月神话>>等文中提到的分布率，只是个参考依据罢了。

上面是一点点不成熟的意见，不知当讲否！

24 楼 xiaohan.sun 2009-06-28  

在《人月神话》中作者提到了自己的经验法则是：
1/3计划、1/6编码、1/4构建测试和早期系统测试、1/4系统测试。

工作量分布情况需要视实际项目而定，新项目所需要的设计时间总是要高于比较熟悉的项目的设计时间，但总的说来还是要保证有充足的设计时间，否则越到后续环节，问题的爆发越会成指数级别增长。
项目的时间管理中有叫做PSP和TSP的东西，它们可以帮助进行项目时间管理分析和经验积累，我觉得经验这个东西还是从自己做的项目中来得实在，LZ不妨可以使用这个看看，也许不久之后，这些数据就可以回答你的问题了。

23 楼 phpxer 2009-06-27  

taelons 写道

软件的生命周期并非到生产结束系统上线后就结束了，所以生产成本只是所有成本的一部分，软件上线后期的维护成本是相当惊人的，遗憾的是大部分PM和客户都没有意识到这一点。他们关注的是软件生产过程中业务功能的实现，而忽视非功能性需求和服务质量的需求。
非功能性需求和服务质量需求事关软件的运维成本，占到整个成本的50%以上，直接影响到客户满意度和客户关系的维系。太多的项目在上线后两年内被替换，因为人们发现，用了xxx系统后，每天都像热锅上的蚂蚁。一个业务需求的变更，哪怕是微小的局部变东，如果在生产阶段没有前瞻性，没有良好的设计，后期的运维将是非常痛苦的，琐碎的小改动，日积月累，加上人员的变动，使系统无法维系下去。
这体现在PM和客户在“战略和战术”两方面的欠缺，欠缺前瞻性的眼光，欠缺过硬的技术。当然，他们也有共识，项目当政绩来做，上线后向上邀功，拿到大部门项目款完事

说得好，所以在软件研发过程中对于质量和可扩展性、对需求变化的响应能力的要求是很高的。不过事实上很多项目对现在的需求都不满足，一上线以后直接出现问题或者用不起来。这是我们现在面对的严重问题。

PM本人，事实上不只是只对某个项目的某次生产过程负责，大部分情况下，只要还在公司做的话，基本上以前所负责的项目其责任仍然会沿袭下来，后面的维护和服务都会产生费用，成为项目成本的一部分。不过某些情况下，这一部分费用被转换到了服务费用中去了。发生这些情况，项目是部分失败的。

总之，在前期进行足够的调研/需求/设计，完全是有必要的。我所了解的项目中，很少有真正成功满意的项目，可能正因为很多时间放在了具体实现上，而不是构建这个概念思维系统上。

我估算一下我们目前的情况：
A 30%
B 70%

也许我们期待的应该是
A 50%
B 50%
?

22 楼 taelons 2009-06-27  

软件的生命周期并非到生产结束系统上线后就结束了，所以生产成本只是所有成本的一部分，软件上线后期的维护成本是相当惊人的，遗憾的是大部分PM和客户都没有意识到这一点。他们关注的是软件生产过程中业务功能的实现，而忽视非功能性需求和服务质量的需求。
非功能性需求和服务质量需求事关软件的运维成本，占到整个成本的50%以上，直接影响到客户满意度和客户关系的维系。太多的项目在上线后两年内被替换，因为人们发现，用了xxx系统后，每天都像热锅上的蚂蚁。一个业务需求的变更，哪怕是微小的局部变东，如果在生产阶段没有前瞻性，没有良好的设计，后期的运维将是非常痛苦的，琐碎的小改动，日积月累，加上人员的变动，使系统无法维系下去。
这体现在PM和客户在“战略和战术”两方面的欠缺，欠缺前瞻性的眼光，欠缺过硬的技术。当然，他们也有共识，项目当政绩来做，上线后向上邀功，拿到大部门项目款完事

21 楼 phpxer 2009-06-26  

yecllsl 写道

看了此贴，想起一句话“屁股决定脑袋”

呵呵，讨论得越来越偏题了... 希望更多有PM经验的朋友们来投投票...

20 楼 yecllsl 2009-06-26  

看了此贴，想起一句话“屁股决定脑袋”

19 楼 RCFans 2009-06-26  

fuwang 写道

软件项目对老板来说就是做生意，就是要用来赚钱的，从这个角度来看，架构师和工程管理者也是砖工(随时可以换掉)。
至于技术，当然是可有可无的东西，项目能赚到钱就行。

说的对。但做生意也有做生意的门道，尤其是想做点技术生意。因为不懂这个门道，所以绝大多数的软件项目就是赚不了钱。

18 楼 phpxer 2009-06-26  

fuwang 写道

phpxer 写道

RCFans 写道

这是一个视角问题，关键在于你如何看待软件开发这件事。如果你是一个醉心于编程本身的开发人员，有所侧重是应该的，但是你应该且必须接受一个观点就是，哪怕是很小的组织，都存在不同的工作视角，从不同的切入点来关注、解决问题。
仅仅作为一个开发人员的视角去考虑问题，无法做出成功的项目——哪怕成功的产品都不行。牢记开发只是一项应用技术，管理是一门科学。实践出真知，不做无真相。

所言极是。 管理是一门科学，开发仅仅是一种工具。 软件产品的开发是由开发人员来完成，他们的工作当然十分重要。但是大部分价值是由开发者之外的人去保证或者完成的。 对这点的感受越来越多。

建筑的隐喻十分合理， 架构师和工程管理者是最重要的，而开发仅仅是砖工（高级砖工）。

（如果读者你从业以来一直在作坊式工厂里，暂时理解不了情有可原）

软件项目对老板来说就是做生意，就是要用来赚钱的，从这个角度来看，架构师和工程管理者也是砖工(随时可以换掉)。
至于技术，当然是可有可无的东西，项目能赚到钱就行。

从老板的角度看，的确如此，研发只是他要关注的众多问题之一。

不过，作为一个软件研发和项目管理者，我们的角度是站在软件研发和项目管理的角度。

17 楼 fuwang 2009-06-26  

phpxer 写道

RCFans 写道

这是一个视角问题，关键在于你如何看待软件开发这件事。如果你是一个醉心于编程本身的开发人员，有所侧重是应该的，但是你应该且必须接受一个观点就是，哪怕是很小的组织，都存在不同的工作视角，从不同的切入点来关注、解决问题。
仅仅作为一个开发人员的视角去考虑问题，无法做出成功的项目——哪怕成功的产品都不行。牢记开发只是一项应用技术，管理是一门科学。实践出真知，不做无真相。

所言极是。 管理是一门科学，开发仅仅是一种工具。 软件产品的开发是由开发人员来完成，他们的工作当然十分重要。但是大部分价值是由开发者之外的人去保证或者完成的。 对这点的感受越来越多。

建筑的隐喻十分合理， 架构师和工程管理者是最重要的，而开发仅仅是砖工（高级砖工）。

（如果读者你从业以来一直在作坊式工厂里，暂时理解不了情有可原）

软件项目对老板来说就是做生意，就是要用来赚钱的，从这个角度来看，架构师和工程管理者也是砖工(随时可以换掉)。
至于技术，当然是可有可无的东西，项目能赚到钱就行。

16 楼 phpxer 2009-06-26  

抛出异常的爱 写道

60%
10%
我怎么认为少了些东西呢?
例如:
一个缓存
6天开发一个版本
一个半月准备期

准备阶段主要做的是调研和设计

15 楼 RCFans 2009-06-26  

welllove53 写道

国内80%的项目都技术都不是问题，
所以我说A 80%, B 20%

很多本来开发做得很好的项目，却因为交付的文档没做好，失败个彻彻底底。
轻则被小骂一顿，重则造成用户数据丢失

14 楼 抛出异常的爱 2009-06-26  

60%
10%
我怎么认为少了些东西呢?
例如:
一个缓存
6天开发一个版本
一个半月准备期

13 楼 welllove53 2009-06-26  

国内80%的项目都技术都不是问题，
所以我说A 80%, B 20%

12 楼 phpxer 2009-06-26  

mock1234 写道

这是一个A、B随时重构的不断循环过程，每一个循环周期只有十分钟（编成程序需要十分钟，而口头表达时我会在10秒钟内就开始对A、B重构）。当经院化地死抠它作为两个静态概念，所以必须分个比例或者全部实现A再实现B或者相互没有多少牵扯、重构的时候，我只能对这种适合学术上忽悠出论文而不适合工程实际的过于通俗的口号一笑置之。

我希望你能够站在工程观点上来对我的讨论做一个评价... 敏捷实践当然是很好的，但是即使敏捷实践也不排斥工程方法，敏捷实践也需要组织起来。 Scrum / lean 即是如此。

11 楼 phpxer 2009-06-26  

RCFans 写道

这是一个视角问题，关键在于你如何看待软件开发这件事。如果你是一个醉心于编程本身的开发人员，有所侧重是应该的，但是你应该且必须接受一个观点就是，哪怕是很小的组织，都存在不同的工作视角，从不同的切入点来关注、解决问题。
仅仅作为一个开发人员的视角去考虑问题，无法做出成功的项目——哪怕成功的产品都不行。牢记开发只是一项应用技术，管理是一门科学。实践出真知，不做无真相。

所言极是。 管理是一门科学，开发仅仅是一种工具。 软件产品的开发是由开发人员来完成，他们的工作当然十分重要。但是大部分价值是由开发者之外的人去保证或者完成的。 对这点的感受越来越多。

建筑的隐喻十分合理， 架构师和工程管理者是最重要的，而开发仅仅是砖工（高级砖工）。

（如果读者你从业以来一直在作坊式工厂里，暂时理解不了情有可原）

10 楼 phpxer 2009-06-26  

发错了，请见下个回复..