论迭代式的产品开发方法
2019-12-18
来源：互联网的那些事
，这本身没有任何特别的意义。因为你压根不知道，这个改善方案到底是对的，还是错的?
我们往往以成本和工期为理由，用自己或者领导的想当然，来替代繁杂但却可靠的运营数据和用户行为分析，并且振振有词说这就是我的水平，其实这只导致了一个结果，就是曾经犯下的错误，必然在未来某个时间点重复再犯一次。工期越长、时间越久，这种差距就越来越大。就像同样是成立5年的公司，zynga真正比我们强悍的地方，其实在于每过一年，他们做一个新产品的时候所需要犯的错误就少一些，而我们5年前犯的错和今天做一个产品犯的错有可能是一样多的。
低成本的解决方案设计。这意味着当我们发现某个环节有待改善时，应当首先评估那些实施成本最低的方案。因为每一次方案的提出和实施都是一次风险投资，在目标明确的前提下，投入越少，性价比越高。低成本的方案往往也意味着更迅速的开发时间和更短的迭代周期。有趣的是，虽然理智上我们很容易支持这一点，但是许多时候这样的要求，和作为开发者本身的人性是相违背的。
作为产品的创造者，我们经常会在发现产品的种种不足之处时，提出一个“全新的、更好的、一揽子的”解决方案，并且认为那就是完美的答案。这可以称之为一种“创新冲动”，但也可以叫做“创新性的陷阱”。实践证明，这种看起来很完美的方案，经常只是因为其细节没有被考虑充分罢了。大多数时候，在现有的方案上稍加调整，就可以解决问题的90%，这时候优先选择的一定是成本更低的解决方式。
有人会问为什么不投入更大的精力，追求产品的完美?这经常是一种很有冲击性的提问方式，就好像我们是在裹着裹脚布走路的小老太太，被五四青年当街质问一般。
其实答案很简单，因为你我这一刻所认为的完美方案，往往一点都不完美。人经常陷入一个思维误区，就是对某个特定方式的非理性推崇和崇拜。进而认为所有不同意这个方式的人都是品味或者能力有问题。然而一两个礼拜之后，就发现其实全然不是如此这般。之前的完美方案之所以看起来如此诱人，只是因为我们只是一厢情愿的看到了其优点，而不愿意面对其不足。
当一个方案真的在各方面都远胜从前的时候，我们自然应当勇往直前将其付诸实施，据我的经验，这种情况一般来说只占十分之一的比例。一段时间的沉淀、替代方案的讨论以及广泛听取周围人的意见，有助于我们去判断哪些东西是真金，哪些东西是空包弹。
一句话：为解决问题而提出、并且经过了事实的验证被证明有用的创新，才是有效性的创新，而一系列有效性的创新的累加，就是一款成功的商业化产品。
所以总体上，当我们面对一堆版本反馈和数据的时候：1、首先要做的，是提取其中对产品的进一步改善有显著标示性的片段;2、针对这些片段，提出关于其原因的假设和潜在的修改方案;3、通过逻辑性和既往经验，去掉部分可能性和可实施性较低的方案;4、然后，针对剩下来的方案，设计对其调整的有效性的验证方法;5、在成本允许的情况下，尽可能尝试所有的方案，寻找效果最好的一种，固定下来。
相对于拍脑袋，这是个辛苦得多的过程。而这个辛苦的过程所带来的，就是我们和真正一流的研发公司之间的巨大鸿沟。
另外一个很现实的问题是，当一款产品还没有推出到市场上的时候，应当如何实现有效的需求迭代?目前来看，有几个方法可以参考：首先，尽量压短前期开发时长，让产品
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
