转载

如何避免开发一款失败的产品（下篇）

本文编译自 Medium ，作者Rian van der Merwe 2005年到2009年间曾就职于eBay，现在在Jive Software担任产品设计主管。

在这篇文章中，作者提出打造一款成功的产品，必须在产品开发的始终关注着“用户需求”、“商业需求”以及“技术需求”。原文篇幅较长，这里拆分为3篇为大家阐释作者的看法。本文所讨论的是作者对于产品开发中“技术需求”以及3种需求之间平衡的看法。如果您还没有阅读前两部分，请移步：用户需求、商业需求

在讨论技术需求之前，需要先明确两个概念： “技术资产” 和 ”技术负债“ 。所谓“技术资产”就是产品所依赖的底层技术以及一些日常办公所用的系统（采购、财务、后勤）。相反，“技术负债”指的是限制产品开发的系统和代码（经常以bug的形式出现），技术负债如果长期得不到缓解会带来更加严重的问题。Construx公司的首席软件工程师Steve McConnell认为，技术负债主要可以分为两类：

无意的负债(unintentional debt)会出现在错误设计被实施时或者程序员写出了差劲的代码时。这种负债并不是刻意的，当然越少越好。
有意的负债(intentional debt)是指公司明知道某种情况并不理想，但是出于种种原因还是做出了妥协（通常是由于预算或时间限制）。尽管这类技术负债也并不是件好事，但是对任何组织来说，它都是不可避免的，我们需要做的就是将其影响最小化。

对于技术负债来说，我们需要尽可能地减少负面影响，不然就会遇到我们常说的“破窗效应”。

“破窗效应”是犯罪心理学中的术语。用来解释城市中秩序混乱和破坏公物的行为，其含义是：

城市管理中需要保持各种设施处于良好的状态，并随时监控，这样才能阻止进一步的公物破坏甚至升级成更严重的暴力犯罪。

如何避免开发一款失败的产品（下篇）

我们可以把软件比作城市的环境。如果有几扇窗户破了（软件中出现一些糟糕的代码），而破窗又没有尽快修好，那么很有可能会出现更多破碎的窗户（人们变得不再关心优质代码），继而环境进一步恶化：垃圾到处出现，擅自占用空房的人越来越多（代码标准普遍下降）。不久之后，所有的窗户都会破碎。

如果负债扩大到一定程度，公司最终花费在弥补这些漏洞上精力会比用在创造新价值上的还要多。常见的情况就是遗留的代码库往往需要耗费大量的精力去维护（也就是“还债”），留给开发系统新功能的时间就变少了。——Steve McConnell

在产品开发时需要竭尽全力去避免此类技术负债。如果遇到了，找时间来处理这些欠账的过程会非常艰难，经常看不到任何改变，团队内会有一些人不理解这么做的原因，很多人懒得去清理代码中的这些垃圾。然而，在开发过程中清理这些技术负债恰恰是一项非常重要的工作，如果做不好很可能会摧毁整个体系。

当然，需要注意的是，技术负债并不一定都是坏事，有时技术负债会催生一些强大的功能。总得来说，新出现的负债是没问题的，但是长期累积起来的旧账就不好了。Henrik Kniberg在他所写的《Good and Bad Technical Debt》一文中曾提出一个避免技术负债失控的好方法，那就是引入了债务上限的概念，当你的负债达到一定限额时需要采取措施以避免进一步失控：

当债务达到上限时，我们就宣布进入“负债紧急状态”，停止开发新项目，所有人都将注意力放在清理旧代码中的问题，直到回归到基准线。

如何避免开发一款失败的产品（下篇）