如何做产品减法_程序员创业_非技术区_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 非技术区 > 程序员创业 > 如何做产品减法

如何做产品减法

 2011/8/7 11:48:54    纯银的日志  我要评论(0)
  • 摘要:文/纯银取这个标题我很惭愧……觉得自己好像江湖老骗子。“如何做产品减法”这种问题得根据具体的产品市场状况,公司人事环境来作判断,脱离了完整的生态环境,只能说一些糖稀屎样的空话,套话。平生最恨糖稀屎……不过最近对产品减法又有几条实战经验,不妨拿出来讲一讲。讲之前,想起曾在微博上见人说励志名言“不到最后关头,不要轻言放弃”,被火热转发无数次。又有某君出言讥讽,说&ldquo
  • 标签:减法

  文/纯银

  取这个标题我很惭愧……觉得自己好像江湖老骗子。“如何做产品减法”这种问题得根据具体的产品市场状况,公司人事环境来作判断,脱离了完整的生态环境,只能说一些糖稀屎样的空话,套话。

  平生最恨糖稀屎……

  不过最近对产品减法又有几条实战经验,不妨拿出来讲一讲。讲之前,想起曾在微博上见人说励志名言“不到最后关头,不要轻言放弃”,被火热转发无数次。又有某君出言讥讽,说“那何时才是[最后关头]呢?此话如同一屁!”大笑,想去跟某君亲切握手。产品减法也是这个道理。这个行业里的猪都知道减法好,要做减法,身在局中时,却哪里容易分清楚何谓多,何谓少,何谓加,何谓减。振臂高呼“产品减法好”,仿佛港片恶俗台词“人活着最重要的就是开心”。

  还是说正题吧。做产品减法的技巧因地制宜,见仁见智,但也有一些客观的手段来帮助你下刀。这样的手段,我找到了三个,恰好都不太难。

  第一个手段是制定少而精的阶段性目标。以1-3个月为周期,制定当前阶段与下一阶段的产品目标。每阶段最好只有一项核心目标,绝对不超过两项,粒度的大小则根据不同时间周期来定。

  定目标,也是个技术活。明确单一目标对于划分任务权重很有帮助,而制定下一阶段目标则有益于安排当前阶段的次要任务。

  第二个手段是制定严格的发布日程规划。我在Joel的《软件随想录》里看到这么一段话,深感共鸣,当即手打出来群发PM共赏。

  ————————————————————

  有效的日程规划有许多很大的好处,其中之一就是你会被迫删去一些功能。这为什么是好事?

  假定你想实现两个功能。其中一个非常有用,会使你的产品变成真正的优秀产品。另一个很容易实现,程序员迫不及待地想把它写出来(“快看!别眨眼睛!”),但是这个功能并非很有用。

  如果你不搞一个日程规划,程序员就会首先将容易的/有趣的功能做出来。然后,他们剩下的时间就不够了,你别无选择,只好推迟日程来开发有用的或重要的功能。

  如果你确实搞了一个日程规划,那么甚至在你开始工作之前,你就会意识到你必须砍掉一些东西。因此,你砍掉了容易的或是有趣的功能,全部精力投入开发有用的或重要的功能。正是这种迫使你砍掉某些功能的压力,使得你最终做出了一个更强大、更优秀的产品,它包括了更好的功能组合,而且能够在较早的日期完成。

  回想很久以前,我还在Excel5开发团队的时候,我们最初的功能清单十分庞大,完成日期远远落后于日程规划。“啊,老天!”我们心想,“这些全部都是超级重要的功能!如果没有一个宏编辑向导,我们还怎么活呀?”

  最后,事情很明显,我们没有第二条路,只能把许多功能都砍掉,砍到不能再砍的地步,“只剩下了骨架”,这样才能如期完工。所有人都为这件事感到非常不开心。为了让大家感觉好受一点,我们安慰自己说,被砍掉的功能并不是被抛弃了,而是仅仅被推迟到Excel6中实现了。

  当Excel5的开发工作接近尾声的时候,我和同事开始着手编写Excel6的设计规格说明书。我们坐下来,详细审阅从Excel5的日程规划中被刷下来,准备放进Excel6的功能清单。猜猜结果怎样?这份功能清单比你能想到的最糟糕的清单还要糟糕,上面没有一个功能是值得开发的。我想它们之中的每一个功能都从来没有过开发价值。为了赶上日程,我们砍掉了这些功能,现在看起来这是我们做过的最有价值的一件事情。如果我们当时没有这样做,那么Excel5的开发时间会延长一倍,然后做出来的产品中包含了50%无用的垃圾功能,并且未来我们还不得不维护这些功能,直到Excel生命的最后一天,都要让当前版本向后兼容这些功能。

  ————————————————————

  Joel的文章比我好太多了,不必狗尾续貂,接着讲第三个手段:尽可能快速发布你的第一个版本。快到什么程度呢?甚至在用户测试版面世之前,就在内部发布其预览版,我粗俗地称之为光杆子版本。只有基本可用的核心功能,搭配相当粗糙的界面与交互。

  在过去做产品的三年半里,我多次羞愧地意识到,设计一个产品原型,与你在真实数据环境里亲手使用它,总会有多多少少的差距。老实说,我没法在发布一个产品(模块)之前准确预知自己使用它的感受。这件事情可能令工程师大失所望,可即便是三鞠躬谢罪,我还得这么说,“设计情景”与“真实使用情景”总有差距。有时候设计方向本身是错的,可我们为之添加细腻的优化修饰;有时候方向没错,细节处理却南辕北辙。考虑到开发主干功能通常只占50%甚至更少的时间,最好能够在完善细节之前,先提供一个代入真实数据的光杆子版本,让团队早点“矫正感觉”,及时调整设计。至少比纸上谈兵更准确。

  以上这三个简单的手段,就是我今年来的心得总结。我没有足够的天才提前看清楚该减掉什么,坚持什么,只好制造一些外部的压力,通过压力来逼迫着自己作出选择。这包括制定阶段核心目标,方便你砍掉目标之外的任务;制定版本发布日程,方便你砍掉日程无法实现的任务;以及提前预览产品(或小规模敏捷迭代),快速感知真实体验。否则一列列都是得意设计,手心是肉,手背也是肉,如果缺乏压力,则容易放纵自己的想法,事后又追悔莫及。

发表评论
用户名: 匿名