在很多公司中，由于对敏捷软件开发的误解和错误报告，导致税负的增加，损益报告的不稳定，并需要对程序员的工时进行人工跟踪。我敢断言，相比于大多数瀑布模型的实施者，Scrum团队创造的生产成本数据更具有可检验性，并且记录得更好，也与已知的客户价值更为密切。更为出色的报表将意味着可观的税负节约并且能激发更大的投资者兴趣。敏捷公司应该对财务报表这一实践进行改良，从而彰显出Scrum的优势。这可能并不容易，但是我做到了。

Scrum的生产实验框架（production experiment framework）与财务报表的原则完全相符。

在对拥有900人的整个软件公司进行Scrum转型期间，我根据这些原则对软件资本化进行了调整，我们让审计师满怀欣喜，更多的去了解了上层的管理，并且提高用以雇佣开发者的内部资金。通过使用Scrum Product Backlog条目得到了更为精准的文档，并对我们的软件工作进行了资本化，从而使我们在税负开支上得到了数百万的节约。

我希望传达给你这些视角和资源，以此来为敏捷资本化创造会计学论据，从而潜在的减少你所在公司的税负开支，增加工程师们的可用资金，也能让你的审计师欢呼雀跃。

软件是资本投资

软件开发是一项针对长远未来的投资。我们预先为工程师的薪水买单，然后（希望）在不久之后的将来通过节约开支或得到收入来获取利润。如果我们投资得明智——将现金（一种类型的资产）转化成软件（另一种类型的资产）——公司的价值将得到提升。税务机构和投资者们是依靠财务报表来理解一个公司的价值的。我们该如何报告开发费用事项呢。

首先，让我们明确资本化（capitalization）和费用化（expensing）。“资本化”的意思是投资费用（有时也称为资本投资或资本费用）需要跨越一个长期资产（a long-term asset）的生命周期才能得到回报的价值。资本化常被用于税务申报和财务报表（比如损益报告）。资本投资成为了公司公开资产的一部分。“费用化”意味着成本即时受到了“影响”，作为“运营费用”在短期内获得了回报或没有价值。一个将所有软件开发进行费用化的公司，将很难澄清它的软件是长期价值的一部分。

某些软件开发项目并不是长期的投资；这取决于该软件是否仍然是一件资产。举个例子，一个软件外包服务商开发和销售定制软件，没有保留对软件持续的拥有权，这种项目将不能进行资本化。（但是采购该软件的公司是可以对其进行资本化的）

当对软件成本进行分类时很容易犯下致命的错误。一些公司错误地将所有软件投资视为运营费用，隐藏其真实的价值。尽管这个错误可以为某些不正当的行为提供机会，但是将软件投资归类为运营费用通常会导致公司承担更多的税负以及公司的价值被低估，从而压低了公司的股价并削弱了公司的借贷能力。

敏捷专家应该理解资本化

如果财务人员对Scrum产品开发处理的不够恰当，那么他们制订的政策将会成为一个隐患，从而削弱公司对Scrum的支持力度。敏捷会让一些财务专家感到困惑。由于其频繁的发布节奏，他们会认定敏捷软件是某种“临时的”存在。

敏捷专家应该学会适度的资本化并传授给他的同仁们。在如何跟踪和报告敏捷项目成本这个问题上存在的误解，会让很多公司多耗费几百万元美金的不当税负。不完善的资本化规则将为敏捷公司带来剧烈波动的收益表，让这些公司看上去显得管理不善。所谓“保守”的瀑布流程难以跟踪设计工作、管理任务与所产生出的功能特性之间的对应关系，但是敏捷方法却可以。然而，会计师们一般都无法理解如何合适地跟踪和汇报敏捷项目中的劳动情况。

当一些公司对软件开发进行资本化时，通常可以节约税负，雇佣更多的开发者并更快速的创造价值。如果他们资本化的工作做得合理，他们将可以对投资者和监督者更负责任地汇报公司的财务状况。对于合理的资本化来说，我们必须准确采集资产创造过程中的劳动成本，并将这些成本合理的归类到“资本化的”或“费用化的”。

Product Backlog条目说明了交付给利益相关者的价值，可以很容易的进行归类。但是瀑布模型——其无穷尽的设计周期和令人困惑的各个阶段（查看下某个RUP的阶段图，你将看到到处都是混乱不堪的景象）——很难跟踪哪些设计工作或项目管理任务导致了哪些功能特性。有人因此就会觉得财务人员和税务机构是会喜欢上敏捷实践的。

但是大部分的财务专家和专业会计师对敏捷实践都没有深刻的理解。比如在会计准则中使用瀑布模型的例子来解释资本化原理，而误用瀑布模型这种语言将导致人们对软件开发的错误归类。除非团队的敏捷传家可以帮助财务部门对敏捷软件开发进行合理的资本化，否则公司将承受过度的税负责任，对工程人员进行变相裁员，以及审计异常发现及随后重新修订报告的风险。

对于敏捷资本化原理的误解将导致显著的裁员。最近，Pat Reed（另一个敏捷企业顾问）和我一起在一家大型的工程公司中和一个经理讨论资本化。该经理告诉我们，他的财务部门可以正常地对瀑布模型开发进行资本化，但是却将敏捷开发视为“运营费用”，因为财务（错误地）认为所有Sprint实际上都是“预备项目阶段”工作。我问道，“这会限制你的人员编制吗？”他承认道，“是的，任何部门选择使用敏捷实践时都期望将人员编制减半”

从积极的一面看，理解资本化的ScrumMaster和敏捷开发主导者可以修正这个问题。因为好的敏捷实践可以使得资本化更具有可验证性，均摊到整段时间上的投资成本通常也可以降低整体的税负，并且有助于利用早期资金来雇佣更多的工程师。以下是ScrumMaster为何具备这个能力的原因：

ScrumMaster是在公司里最能够正确区分某项工作是一项长期投资还是短期费用的人，并且通常都拥有确保这些工作被财务人员和外聘审计师正确归类的关键数据。
 
ScrumMaster会推动流程从而调整团队的行为使其与既定目标更加可靠一致。Scrum技术中有一个自适应统计基础，并由实验来进行支持，这在传统的项目管理技术中是没有的。根据我的经验，相对于基于瀑布模型的“实际数字”，审计师可以更加信任基于敏捷的报表。

作为一个ScrumMaster，如果你想抓住这个机会，劳动分类将可能成为你和公司其他ScrumMaster的职责。必然的，你将可能成为软件资本化、资产折旧、资产减损这些主题的专家。欢迎来到财务的世界！

适当的分类将缔造一个光明的未来

税务机构和投资者使用运营费用和资本费用这些概念来帮助他们做出更好的决策。他们通常希望公司们进行长期投资，这样他们便可以让公司将投资成本均摊到整个时间段，从而略微的抵消部分应税收入，伴随着投资一起挣钱。

软件工作可以提供短期的价值（所有ROI在一年之内）或长期的价值（ROI跨越多年）。举个短期的例子：一个合约型软件公司可能为某个客户创建了一个网站，它在获得报酬后没有保留对该网站的所有权。在这个例子中，我们认为开发成本是一项“运营费用”。

上市公司通常需要向股东和税务机构报告年度和季度的利润。计算利润的公式非常简单：

利润 = 收入 – 费用

举个长期的例子：一个玩具零售商创建了一个网站来出售它的玩具。在创建完这个网站的若干年后，这个很久前完成的工作持续的产生着收入。在这个例子中，我们认为开发是一种“资本费用”，是一项长期的投资。计算总利润时需要追溯到很多年前，得到以下公式：

总利润 = 第一年的收入 + … + 第n年的收入 – 投资费用

股东和税务机构每年都会期待财务报表：我们去年的利润有多少？如果我们有一个长期的软件项目，并且在第一年是没有收益的。如果我们将它视为运营费用，我们可能将出现亏损。而不淡定的股东也许会因此卖掉我们公司的股份！也许我们不需要在这一年支付税负，那真是太好了！但是下一年我们也许没有开发费用，而我们的玩具零售网站却得到了大量的收入，在某些行政辖区将面临全额征税。如果我们这样处理开发计划，将会使我们消极的看待长期投资。

明智的做法是，税务机构和审计小组让我们把系统中的资本费用均摊到整个时间段，这种做法称为“折旧”。大多数的折旧计划会将资本费用均摊到整个软件的预期生命周期上，所以如果我们开发的玩具零售网站预期将被使用5年，我们将在开发后的第一年花费20%的开发成本，然后每年花费20%直到第5年。联系一个会计师以获取关于折旧计划的更多信息，这很大程度上取决于一件资产的预期生命周期。

一项投资可能未必马上可用。由于我们并不是立即从该投资获取收入，我们通常可以延迟折旧直到它开始被使用。会计学将开发之前的这段时间简称为“资本化时期”。（顺便说一句，资本化收益将在折旧开始后继续）如果我们从我们的网站软件上移除功能或彻底地停止使用它（很可能是我们替换了它），不管是在开发之前还是之后，我们“减损”了我们的前期投资，那么我们需要立即将剩余成本进行费用化。

通过对软件开发进行资本化，公司可以取得一定的税负优势：他们通常通过延迟成本从而抵消应税收入，并可以获得更多的利息收入。各部门也将会取得一定的雇佣优势：当一个部门可以延迟软件投资成本时，通常可以将这些被延迟的成本花费在员工薪资上（雇佣更多的人，提供加薪，等等）。

使用折旧和未使用折旧的利润与亏损对比(点击图像放大)

该图描述了利润和亏损（损益表）是如何受折旧所影响的。这些数字的展示单位是“千美元”。作为软件项目的一个典型性，主要成本（开发成本）发生在项目开始：2012年花费了200万美元和2013年花费了200万美元。在2014年及以后，成本是20万美元一年，主要是花费在向软件增加功能特性的成本。该项目在2014年被部署之前始终没有盈利或带来成本节约，直到该时间点之后才开始带来每年120万的收入。

如果项目成本没有被折旧，而是马上被费用化了，蓝色的线条讲述了损益的故事：在开始的两年存在巨大亏损，而在接下来的几年内出现了巨大的盈利。

当成本被折旧时，绿色的线条讲述了一个截然不同的损益故事。从损益表中可以看到在软件被投入使用之前没有成本花费。当软件就位投入使用时，我们通过一个五年的时间窗口对成本进行折旧以计算我们的利润

为什么这很重要？政府通常只对总数为正数金额的利润进行征税，所以很难通过负数金额来减少未来每年的应税利润（除非你通过折旧来进行调整）。

财务人员通常会因为将所有软件费用视为运营费用而造成过度花费，并声称这是某种程度的保守行为。而事实上并不是这样，如果你正在进行一项长期投资，将软件投资划分到短期费用一类将使你的公司看上去很不稳定——这对你的股东来说是很不负责任的。这将带来更高的税负义务，这也是对你公司的不负责任，同时违背了你们国家对于希望你们进行长期投资的原本目的。

一家具有高额利润的公司能够抵消一个产品开发部门的生产损耗。这样可以避免税负问题，但是却无法避免糟糕的计划。根据我的经验，高管们会把注意力放在部门的利润和亏损上，并据此来决定人员的编制。我们中间谁没见过大型软件问题中关于人事雇佣和解雇的兴衰循环？在某种程度上，人员编制的波动的可能原因是由于未能适当的将软件识别为一项投资。

最后，如果敏捷软件项目被费用化而瀑布模型项目却没有，这本质上相当于对任何长期在企业中采用敏捷实践的方式判了死刑。如果瀑布模型项目可以雇佣更多的员工，而敏捷项目却不可以，你认为经理们还会选择推动哪种方法论？

继续关注：忽略敏捷而推荐的会计实践