探索外包开发的极限：一个精品App诞生的全过程(15)

六、成本控制：虚拟迭代

「the App」曾经开发过1.0版本，虽然我对它的操作体验下足了功夫，但是体验只是给你产品加分的东西，它掩盖不了一个产品的致命伤。如下图，当时的设计是这样的：

1.0版本的“微博”设计

假设一个想要写下一条人生方向，例如：“我最致命的缺点是过分思考却不行动”，这条人生方向就形成了一篇“微博”，而每当这个人有了关于对“过分思考却不行动”的新看法，在生活中对它有了新的体验，或是看到一篇文章讲的也是这个话题，他都可以附带上新的观点来“转发”这条微博。

当他每天打开某个文件夹，例如这篇文章所在的“行动的巨人”文件夹，他就看到了一个完整的微博小站。这些微博默认按照时间流来排序，他可以看到他最近转发了什么，原创了什么。而当他切换到另一种排序方法的时候，「the App」只向他展示原创的微博，而且那些转发次数最多的将会排在最前面，提醒他最重视的人生信念是什么。

上线前我对这套逻辑信心满满，然而上线后才使用了两周，我就发现了其中的大问题。其一，越是转发次数越多的微博，我就对原文越不满意，因为我的思考一直在往前走；其二，当我灵感一现，想要掏出「the App」来写东西的时候，我往往会愣住，因为我不记得我有没有写过类似的“原创”，如果有，我也很难第一时间找到它来转发。于是，我往往都是写去写一篇新的原创，这套转发机制逐渐成了摆设；其三，转发次数最多的微博，并不一定是我最应该去坚持的人生信念，有时候，它反而代表一个我走过很多弯路的错误信念。

从这件事情之后，我决定「the App」以后每个版本在开发之前，都要经历足够多的“虚拟迭代”。这个名词是智超后来帮我总结出来的，它的含义是：在产品真正投入开发之前，尽最大努力在内心去虚拟这个产品上线之后真正的样子，不断地“使用”这个产品，从这个“使用”过程中提前发现产品的问题，不经过开发，直接进行下个版本的迭代。

如果一个产品原先要开发10个版本才能成功，通过虚拟迭代，你可能用3个版本就能达到同样的效果。由于「the App」是外包开发，所以我这边“虚拟迭代”的时候，外包公司的人力费用并不需要我承担，所以你可能会说，我的情况并不能适用在一个需要每天养活开发团队的公司里。

但是反过来讲，为了让设计组、程序组不空转，就强行赶鸭子让产品组草率地设计一个版本出来，其中很多问题都没有仔细验证，上线之后立刻就改需求，一个想法接着一个想法，源代码被弄得千疮百孔，产品实际要解决的问题却还没找到关键的门路，随时面临打倒重来的危险，这样难道就是有效率的企业运作方式？

PM一个人再厉害也有很多情况是考虑不周的。当产品设计在不断“虚拟迭代”时，设计和开发组不必那么快就进入正式开发的工作，设计组可以趁这个时间多做一些概念图，跟PM一起把产品视觉确定下来，一起跟前端工程师去探讨每个细节的可行性。而开发组则可以提前梳理产品需要的模块和技术，提前攻破某些技术难点，跟PM一起讨论每个产品模块的性价比：哪些该做，哪些该寻找替代方案……所有人坐在一起讨论产品未来可能的走向，以便提前设计好一个拓展性最强的框架，减少未来迭代的成本——最好的产品一定是这个团队所有人作为一个整体来完成的，强行划分成策划、UI、开发的步骤，或是强行说：“你是UI设计师，你不要参与功能设计”、“我不管你们怎么设计，我等你的文档出来然后写代码”，这跟工厂流水线生产罐头又有什么区别呢？

把产品设计在脑海里具象化

（编辑：ASP站长网）