平生最恨糖稀屎……
不过最近对产品减法又有几条实战经验，不妨拿出来讲一讲。讲之前，想起曾在微博上见人说励志名言“不到最后关头，不要轻言放弃”，被火热转发无数次。又有某君出言讥讽，说“那何时才是[最后关头]呢？此话如同一屁！”大笑，想去跟某君亲切握手。产品减法也是这个道理。这个行业里的猪都知道减法好，要做减法，身在局中时，却哪里容易分清楚何谓多，何谓少，何谓加，何谓减。振臂高呼“产品减法好”，仿佛港片恶俗台词“人活着最重要的就是开心”。
还是说正题吧。做产品减法的技巧因地制宜，见仁见智，但也有一些客观的手段来帮助你下刀。这样的手段，我找到了三个，恰好都不太难。
第一个手段是制定少而精的阶段性目标。以1-3个月为周期，制定当前阶段与下一阶段的产品目标。每阶段最好只有一项核心目标，绝对不超过两项，粒度的大小则根据不同时间周期来定。
定目标，也是个技术活。明确单一目标对于划分任务权重很有帮助，而制定下一阶段目标则有益于安排当前阶段的次要任务。
第二个手段是制定严格的发布日程规划。我在Joel的《软件随想录》里看到这么一段话，深感共鸣，当即手打出来群发PM共赏。
――――――――――――――――――――
有效的日程规划有许多很大的好处，其中之一就是你会被迫删去一些功能。这为什么是好事？
假定你想实现两个功能。其中一个非常有用，会使你的产品变成真正的优秀产品。另一个很容易实现，程序员迫不及待地想把它写出来(“快看！别眨眼睛！”)，但是这个功能并非很有用。
如果你不搞一个日程规划，程序员就会首先将容易的/有趣的功能做出来。然后，他们剩下的时间就不够了，你别无选择，只好推迟日程来开发有用的或重要的功能。
如果你确实搞了一个日程规划，那么甚至在你开始工作之前，你就会意识到你必须砍掉一些东西。因此，你砍掉了容易的或是有趣的功能，全部精力投入开发有用的或重要的功能。正是这种迫使你砍掉某些功能的压力，使得你最终做出了一个更强大、更优秀的产品，它包括了更好的功能组合，而且能够在较早的日期完成。
回想很久以前，我还在Excel5开发团队的时候，我们最初的功能清单十分庞大，完成日期远远落后于日程规划。“啊，老天！”我们心想，“这些全部都是超级重要的功能！如果没有一个宏编辑向导，我们还怎么活呀？”
最后，事情很明显，我们没有第二条路，只能把许多功能都砍掉，砍到不能再砍的地步，“只剩下了骨架”，这样才能如期完工。所有人都为这件事感到非常不开心。为了让大家感觉好受一点，我们安慰自己说，被砍掉的功能并不是被抛弃了，而是仅仅被推迟到Excel6中实现了。
当Excel5的开发工作接近尾声的时候，我和同事开始着手编写Excel6的设计规格说明书。我们坐下来，详细审阅从Excel5的日程规划中被刷下来，准备放进Excel6的功能清单。猜猜结果怎样？这份功能清单比你能想到的最糟糕的清单还要糟糕，上面没有一个功能是值得开发的。我想它们之中的每一个功能都从来没有过开发价值。为了赶上日程，我们砍掉了这些功能，现在看起来这是我们做过的最有价值的一件事情。如果我们当时没有这样做，那么Excel5的开发时间会延长一倍，然后做出来的产品中包含了50%无用的垃圾功能，并且未来我们还不得不维护这些功能，直到Excel生命的最后一天，都要让当前版本向后兼容这些功能。
――――――――――――――――――――
Joel的文章比我好太多了，不必狗尾续貂，接着讲第三个手段：尽可能快速发布你的第一个版本。快到什么程度呢？甚至在用户测试版面世之前，就在内部发布其预览版，我粗俗地称之为光杆子版本。只有基本可用的核心功能，搭配相当粗糙的界面与交互。
在过去做产品的三年半里，我多次羞愧地意识到，设计一个产品原型，与你在真实数据环境里亲手使用它，总会有多多少少的差距。老实说，我没法在发布一个产品(模块)之前准确预知自己使用它的感受。这件事情可能令工程师大失所望，可即便是三鞠躬谢罪，我还得这么说，“设计情景”与“真实使用情景”总有差距。有时候设计方向本身是错的，可我们为之添加细腻的优化修饰；有时候方向没错，细节处理却南辕北辙。考虑到开发主干功能通常只占50%甚至更少的时间，最好能够在完善细节之前，先提供一个代入真实数据的光杆子版本，让团队早点“矫正感觉”，及时调整设计。至少比纸上谈兵更准确。
以上这三个简单的手段，就是我今年来的心得总结。我没有足够的天才提前看清楚该减掉什么，坚持什么，只好制造一些外部的压力，通过压力来逼迫着自己作出选择。这包括制定阶段核心目标，方便你砍掉目标之外的任务；制定版本发布日程，方便你砍掉日程无法实现的任务；以及提前预览产品(或小规模敏捷迭代)，快速感知真实体验。否则一列列都是得意设计，手心是肉，手背也是肉，如果缺乏压力，则容易放纵自己的想法，事后又追悔莫及。