减法开发哲学
我在大公司受过的完整训练跟经验是：大公司的那一套完整产品开发经验跟流程不适合套用在每一个公司，特别是新创公司(startup)。
Startup 本身的资源有限、人力有限，必须要思考如何把资源投注在最重要的项目上，才不致浪费时间在开发“只有 20% 需求的功能”上 – 没错，要取悦所有使用者很难，因此，当资源有限时，必须取舍。
先照顾大多数人的需求，确保绝大多数使用者是被满足的，然后行有馀力再来检视是否必要满足剩下的使用者需求 — 有的时候，维持使用者的“饥饿感”是必要之恶，因为，很多时候连我们自己都不确定是否是短暂的需求，抑或可能发展出长久的使用习惯 — 这个问题跟购物慾望很像，当我们很喜欢一件商品时，心里头可能会开始囤积慾望，不断的堆积自己必须购买的理由，说服自己“我需要”，进而促成实际的购物行动，但很可能一两个礼拜后，这件商品就被晾在一旁了。
我认为 Startup 适用的开发方法是“减法开发”。
什么是“减法开发”呢?
1. 尽量列出需求
首先，团队可以天马行空发想，依照产品的主要定位构思不同的功能，并列出详细的使用情境(use case)，假设总共列出了 100 个待开发的功能。在这个阶段，我们先不去构思其可行性或是开发的时间。
2. 去芜存菁
现在，我们提出一个实际的假设：“我们的资源有限，只能开发其中 50 个功能，哪 50 个功能是非得要优先开发的?”
留意到了吗?第二个阶段我们必须思考的问题是：当我们必须取舍时，哪些功能是真正使用者必要使用的。取决“必要”性的关键在于，哪些功能是可能“现在(或暂时)没有也没有差别”。
3. 专注在核心项目
第三个挑战来了。“我们只有一半个月时间，依照目前的人力与资源，算一算可能只有 10 – 20 个功能可以如期被开发完成。”
我们必须在 50 个我们在第二阶段觉得“一定要开发”的功能里，再筛选出“真正必要”的功能。团队只需要专注在把第三阶段列出的 10 – 20 个功能开发完成即可。
因为，新创公司往往没有太多的资源，必须要在很快的时间内“做实验”(interation)，知道实验的结果，然后不断的从实验结果及经验中快速修正，继续做下一个实验，花费太多时间在开发一个大型专案，很容易把仅有的有限资源不知不觉中就耗费掉了。
把使用者的抱怨与不满变成助力
这是一句老话，可是我们往往(或偶尔)会忘记。千万别一开始就把所有资源都抑注在一个超大型的专案，因为对很多 Internet 的使用者来说，早已习惯测试新的服务跟产品，并提供自己的使用经验回馈，别放过广大的 beta tester 群所能贡献给你的价值。
开发一个超大型专案所冒的风险不小，因为一个新功能或新产品，往往推出后三个月内就会决定生死：这是一桩一翻两瞪眼的生意，很快就会知道结果。
所以，如果所冒的风险是如此，我们是要选择要花一年时间开发一个超大型、超完美的专案，还是很快地在三个月内先推出简单的版本呢?我会选择后者。
曾经，有一个公司耗费了很多人力、资源，花了两年时间开发一个新的服务，结果在一年半时，市场窜出了新的同样的服务，并且快速地在市场空窗期满足了使用者需求，掳获了很多使用者的心，形成一股不小的“实力”，最后只得花大钱跟其他竞争公司竞标，买下这个新的服务。
“测水温”是 Internet 软体或服务的常态，使用者早已习以为常，对于“不完美”完全可以理解，也很乐于尝试，因此，先推出CYE核心的功能测水温，反应好再持续专注开发其他必要的周边功能来使得这个新服务变得更完善，反应不好，也不必冒着抑注了所有精力，花费很多时间开发一个大专案，却可能很快便知道不讨使用者欢心的结果的风险。
一次给一点，使用者最高兴
我承认这是我以前求学、工作时使用过的伎俩 – 使用者的期待是需要被管理的。
如果一次推出 100 项功能，大部分使用者不见得会觉得高兴，反而因为面临太多选择，亦或是在使用者遭遇到程度不等的问题，在这些功能里“迷航”了，他们心里头可能会觉得“不好用”。
其实，使用者接触一个新的服务都需要“学习”。每个使用者的学习曲线会依照他们的专业背景、接触网路的时间长短等而有所不同，这还不包括“适应”的问题。试想：100 项功能要花多久的时间才能上手，甚至“适应”(顺手)呢?
如果只推出 5 项功能，使用者可能会感到惊讶，很快地便可以上手，甚至可能到处广为宣传，使用者得到的成就感与满足感与前者有很大的不同。
你会选择哪一种方式呢?
想认识全国各地的创业者、创业专家，快来加入“中国创业圈”
|
