Welcome

首页 / 软件开发 / 数据结构与算法 / 为什么敏捷专家应该关心资本化

为什么敏捷专家应该关心资本化2013-11-17 infoq 译:赵震一在很多公司中,由于对敏捷软件开发的误解和错误报告,导致税负的增加,损益报告的不稳定,并需要对 程序员的工时进行人工跟踪。我敢断言,相比于大多数瀑布模型的实施者,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的职责。 必然的,你将可能成为软件资本化、资产折旧、资产减损这些主题的专家。欢迎来到财务的世界!