论迭代式的产品开发方法
2019-12-18
来源：互联网的那些事
是1和1后面的0的关系，没有1，则再多的0加起来也是0。
我讲过一个简单的理论：游戏的核心玩法是一款游戏的纵轴，而内容的增加是一款游戏的横轴，一个好的纵轴，可以支撑很广阔的横轴，就像弹弹堂或者疯狂的小鸟，基于自己的核心玩法，可以不断设计推出新的地图;而如果纵轴不够强大，横向的扩展越多，产品死亡的速度就会越快。这就像盖房子没有把房梁搭好就往上放砖，建的越快就塌陷越快。
所以，在游戏的初期，对于核心玩法和DEMO的反复修改不断锤炼，是决定了这个产品能走多远的基础和地基，打个比方你能设计出疯狂的小鸟或者植物大战僵尸的核心玩法规则，那接下来要做的无非是找一堆美术和关卡外包干活罢了。这在网页游戏和社交产品领域同样是成立的，就像傲视天地的推图和战斗系统，都应该是在早期就开始勾勒并且贯穿了整个产品开发始终的东西。
迭代式开发的核心思想与理念
好了，接下来，把艺术的感性收起来，我们要进入迭代式开发的阶段了。
何为迭代?盛大以前有一句很形象的形容，叫做小步快跑。
以下文本来自百度：迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。
其实中国还有一句老话，叫做走一步看一步。本质上，迭代式开发承认开发者当前对于用户需求的了解和把握是欠完备的，开发者并不追求对产品需求进行一次性、全局的理解和把握，而是针对每一个产品细节，收集用户行为和反馈，提出可能的解决方案，加以实现并验证是否解决了问题，然后再迈向下一步的一种循环。
可以这么说，迭代式开发的起点，是从一个版本的发布开始：版本发布，通过数据统计和分析，以及直接的用户调查和问询，得到用户行为的直接反馈;基于反馈分析原因并提出可能的解决方案及验证方法，开发完成这一解决方案，观察用户的行为是否有所改善。如果没有得到改善，那就去尝试另一个解决方案，重复这个循环;如果经过证实得以改善，那就继续接下来的开发流程。
一个典型的迭代式开发过程中，有三个关键原则：尽可能短的迭代周期、明确的效果验证方法、低成本的修正方案。
在不对用户和运营产生过大困扰的情况下，迭代周期越短越好。这就要求把一个比较大的版本规划切分成若干个小版本，分别针对某个特定的问题。本质上每一次的迭代循环，相当于开发人员与用户/市场之间的一个对话周期，而对话进行的越频繁，对市场的了解和把握就越深入。一对每年只通话一次的朋友，关系一定比不上每个礼拜都一起吃饭的朋友亲密，而开发者和市场之间关系越疏离，距离成功的道路就越遥远而不可见。
明确的效果验证方法。这是绝大多数产品开发过程中会犯的错，就是有意无意的省略了对效果的验证。发现产品中的一个问题，譬如某个高流失率环节，讨论，提出了某个改善方案，制作完成上线。然后……没了。
实际上我一直在强调，迭代式开发的潜台词就是承认我们对用户和市场的无知。只有经过了验证的方法，才能称为一种“经验”，而这种经验的积累，代表了游戏团队水平和竞争力的提升。仅仅满足于提出或者完成某种改善方案
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
