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

本文编译自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》 一文中曾提出一个避免技术负债失控的好方法，那就是引入了债务上限的概念，当你的负债达到一定限额时需要采取措施以避免进一步失控：当债务达到上限时，我们就宣布进入“负债紧急状态”，停止开发新项目，所有人都将注意力放在清理旧代码中的问题，直到回归到基准线。

理论上在每个开发周期中你都会遇到技术负债，但是当负债达到上限时，就需要及时调整，以免事态恶化。权衡三方面需求收集用户需求、商业需求和技术需求只是产品开发中一部分工作，更重要的是如何处理这些信息，平衡三方面需求。这时我们应该主要考虑以下三个要素：产品在生命周期中所处的阶段。这是一款全新的产品，还是已经问世一段时间的产品？
用户获取情况。你们在努力吸引用户的阶段，还是用户会自己找上门来使用你们的产品？
公司的财务状况。你们是在想方设法挣钱的阶段，还是已经有了稳定的收入？
这三个要素的组合不同，你关注的重点应该也不一样。如果是一款正在努力获取用户的新产品，那么你就需要十分关注用户需求；如果公司在寻求大规模良性的增长，那你就需要把重点放在盈利上。

最后，需要强调的是：如果不理解产品的核心用户的需求以及商业上、技术上的需求，那你的产品就是建立在虚无之上的。一款产品可能在一段时间如日中天，但最终肯定会有新的产品出现。所以不要把你的产品建立在危险的假设之上，开发产品时做到深思熟虑，努力开发出可持续的产品。[本文编译自：medium.com]