商业软件工程——产出会计和约束理论

标签： 商业软件 工程会计 | 发表时间：2012-09-29 16:22 | 作者：

出处：http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

Steve Tendon在最近一篇博文“ 约束理论和软件工程”里解释了为什么在软件开发公司中产出会计要优于成本会计，同时他还给出了一个适用于软件工程的产出会计简单模型。

软件架构师除了负责架构设计之外，还需要关注商业因素。架构师在做架构决策时一定要考虑到商业因素，否则构造出来的系统可能没有很好的经济价值。 Steve Tendon是一名专注于软件工程管理的顾问，在这篇文章里他提议用产出来评估商业价值，而不是用成本。

为了阐述观点，Steve Tendon在博文中引用了约束理论（Theory of Constraints，简称TOC）里的“链子的强度是由最弱的连接点决定的”的观点：

TOC认为所有业务都是将输入转变为输出的系统，输入经过一系列工作步骤处理最终转化为输出。输出是商业客户定价和付款的产品或服务。

TOC的核心原则是：总会存在一个工作步骤限制了系统的输出能力。这一步骤被称为“能力约束资源”（Capacity Constrained Resource，简称CCR）。Steve Tendon认为CCR往往可以通过将过程流水化和细分任务来避免。在软件工程中，最小的任务单元可以是RUP里的用户用例，XP里的故事点或者是Scrum里的backlog。优化CCR的方法是称之为”5步聚焦法“的模型，如在维基百科中所提到的：

指出系统约束（阻碍组织在单位时间内达成更多目标）
决定如何利用系统约束（如何从系统约束中获益最多）
所有一切配合上述的决定（整个组织要支持上述决定）
升级该系统约束（为打破约束做必要的改变）
注意！如果前面的步骤已打破了某个约束，直接回到第一步。不要让惯性产生新的系统约束。

介绍完TOC模型后，Tendon 用三个公式解释了产出会计的概念：

产出T=收益-变动费用总和
净利润NP=产出-运营费用
投入回报ROI=净利润/投资额

如把这些概念用于软件工程的话，对应如下：

产出：指将工作中的代码发布到产品后的现金变现率，它通过将销售价格减去直接成本得到，直接成本包括：打包、发布、安装、培训、支持，以及网络系统。
投入：包括软件使用环境以及获取对客户有价值功能所消耗的金钱。包括软件开发工具以及需求采集。
营业费用：将概念需求转变为实际工作代码所涉及花费到的金钱。主要是软件工程师的人力成本，但也包括销售、综合成本和管理成本。

这个简单模型使得产出会计也能够被那些非会计专业出身的人（如软件架构师）所理解。很多公司在提高商业绩效过程中常常会把重点放在减少成本上，但产出会计提出了另外一个方案，正如Tendon 所提到的：

减少成本是有限度的，而提高产出则有可能是没有限度的。过度地减少成本会危害到交付的能力，从而反过来会引起产出降低等更严重的后果。

Tendon在文章里列举了3个运用了产出会计方法的例子：

减少产出会计里的营业费用的一种办法是：在实现前砍掉需求。减少每个故事点都能够降低营业费用，从而提高净利润。
利用开源软件减少投入，虽然这样做有可能提高营业费用，但通常会比新构造一个同样系统所耗费的费用少。
当处于小众市场环境时，软件公司可以通过满足这个市场特有需求来提高报价。

就像Tendon在文章里解释的，产出会计不仅仅是可用于软件工程的会计模型，而且是可以彻底替代传统的专注于减少成本的（如减少营业成本）成本会计。在文章的最后，Tendon解释了产出会计在其他商业通用流程中（如周转、招聘、项目计划方面的约束、预算、资源和范围）所起的作用。最后是他对产出会计的总结：

产出会计可对所有商业流程进行管理决策，包括周转，招聘，外包，选择方法等。方法很简单，做任何决策都要考虑到产出、营业费用和投入三因素，这样的决策才是明智且财政稳健的。

一部分读者对这个博文发表了自己的看法，Robert McGinley是一名支持TOC方法论的读者，他说：

自从我读了《The Goal》一书后，我就成为了TOC的坚定拥护者。我认为它对系统架构师是非常有意义的，这篇文章作了很多很好的解释。

Dave Nicolette 喜欢这篇文章，但不同意对故事点的处理：

我不同意将故事点与预估收入价值联系在一起。IME故事点是基于成果的而预估价值完全不是，我更倾向于用“挣值”来跟踪顾客价值交付。它适用于传统和非传统开发模式。我见过有人用同样的方法来追踪范围和价值，其实是有问题的。你的看法可能不同。

Tendon 回复Dave Nicolette说道：

是的，将故事点与收入价值联系在一起并不是最好的方法，用挣值来衡量会更好，但从我所处理过的案例里来看，这样做已经足够接近真实值了，而且它可以为开发人员估计与管理决策所需要数字间的鸿沟铺平道路。也就是说：它是个可以达到理想结果的实用性的方法。它是基于平均来考虑的。从平均来看，一个故事点可以被平均地认为一个收益价值。而且如果你对工作清单进行严格分类的话，这个平均还能很好反映清单里剩余的工作量。

Christian Beck喜欢这篇文章但认为约束并不一定总是坏的：

约束并不一定是总是坏的。在CDS（信用违约掉期）中，约束很大程度地决定了交付的范围（这在软件领域里是很难定义和衡量），而且还涉及了其他重要的交付指标如质量，结果是否新颖。甚至，约束还是系统设计的一部分（如在制品数量限制，时间限制等），变化的约束是影响（而不是控制）结果的重要工具。

Tendon回复Christian Beck道：

是的，约束必须结合着你自己的目标来看。一些约束实际上会帮你往正确的好的方向发展；而有些却相反。最好是能够分辨它们，而且也要知道怎样利用这些好或不好的约束来让你自己的目标受益。

查看英文原文： http://www.infoq.com/news/2012/08/tendon-toc-ta

感谢郭雪品对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至 [email protected]。也欢迎大家通过新浪微博（ @InfoQ）或者腾讯微博（ @InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

商业软件工程——产出会计和约束理论

相关厂商内容

相关赞助商

相关 [商业软件工程会计] 推荐：