第六章 产品死了,如何安葬？.pdf

产品死了 ，如何安葬 ？ 互联网的真正力量在于网络技术的开源特性。任何有兴 的人都可以搭建网站 ，任何有创意的人都 可以创造出下一个 Faceboo k。技术无关性别、无关信仰、无关种族 ，但技术的延续是依靠代码编 写以及创作热情支撑的。 这伟大的力量促使人们产生了了无限的热情 ， 「下一个伟大的网站或应用」可能就在你身边的任何 一个人的脑海里。但是在这前赴后继的热情背后 ，是海量产品不断失败的残酷现实。所以你可曾 想过 ，如果你的产品失败了 ，你该做什么 ？你该怎样将自己的产品体面地下线 ，给你和你的用户留 下最后的美好时光 ？ 这篇文章将会列举出下线一个产品的关键步骤 ，并将大致阐述 ，如何告诉用户 ：我们即将下线。 （ 需要注意的是此文提及的仅仅是下线某个产品或服务 ，很多情况下这是缘于公司的倒闭 ，但这里不 会就此展开。 ） 我不怕失败 ！ 商业社会里 ，下线一个产品通常是没有惯例可循的。从 《时代杂志》到 《哈佛商业观察》都在不断 提醒我们 ：不断评估风险与失败的可能性对于建立团队和设计产品是至关重要的。但他们很少置喙 下线产品的行为代价为几何 ，该考虑什么 ，如何处理反馈。 我们中的大多数都会在职业生涯的某个时候服务于某个即将失败的产品 （这令人悲伤 ）。其中有一 些产品确实是陷入了几无用户的残酷境况 ，但仍有一些产品需要你主动站出来承认我们难以为继 ， 并同时开始采取措施。 产品为何会失败是一个已经被讨论过千百万遍的老话题 ，但只要这个产品成为了你的负担 ，你就会 想要让他后台运转或者直接停掉。 在这里列举一下 ，如果某产品在以下几个方面使你负担沉重 ，你可能就应该考虑关掉它 ： 财务压力 你的产品正在盈利吗 ？所有产品在开发和维护时都有开销。即使你的开销只是一台服务器 ，也是笔 不小的支出。如果产品入不敷出 ，毫无疑问是一个经济负担。 资源压力 你是否有优秀的员工来保证良好的用户体验 ？用户会不停提问、反馈、寻求技术支持 ，这些都需要 消耗资源。大部分资源以通过客服支撑用户的形式存在 ，同时仍然可能会消耗一部分开发力量。如 果一个公司没有维持良好的用户支持服务的人力以及资源 ，那么产品的负担便体现在资源短缺上。 技术压力 保证产品的在任何时候都稳定有效需要付出什么代价 ？大漏洞以及兼容性维护将会迫使你们通过排 期来解决问题。但如果你的团队无法顶住技术水平有限 ，只能任由一些漏洞延续若干个大版本 ，技 术压力就显得尤为棘手。 老化压力 你的产品是否影响了你的其他业务 ？不同的产品经常会共享一些底层代码。如果一个产品的存在给 其他产品制造了大量额外的工作量 ，那这个产品就是一个拖后腿的存在。 让产品在后台静默地运行下去 ，还是果断关掉 ？这一类的决定总是会带有一些个人色彩和主观倾向 。 所以我就可以让产品自己运行着咯 ？ 对 ，这是一种比较吸引人的做法 ，你可以停止开发和资源支持却保持产品运行。但这种方法只适用 于用户量比较大的产品或者公司本身被收购的情况。 当 A do be 宣布他们将不再更新 Firewo rks 的时候 ，它在通告里明确指出 A do be 公司将会在可能的 情况下保持最低程度的对 Firwo rks 的支持。 W hile we are not planning f urt her f eat ure develo pment f o r Firewo rks ，… we w ill provide securit y updat es as necessary and may provide bug f ixes。 We plan t o updat e Firewo rks t o suppo rt t he next majo r releases of bot h Mac O X and W indows。 A s mo re specif ic det ails o n t he next versio n of W indows and Mac O X are made available ， we may adjust t hese plans。 （请注意 ，他们只是说“可能”会提供漏洞修复而不是保证会这么做。 ） 这样的做法看起来令人心安理得并且简单易行。你只需要告诉用户你们不再更新了 ，然后让产品静 默运行。你默默祈祷用户不会因此找上麻烦 （因为他们还在用啊 ），你甚至让自己可以免于解释为 什么要停掉产品 （多聪明啊 ）。 对于关注度比较高的明星产品来说 ，这确实是最容易被想到的方案。但关键是这个方案到底能不能 解决问题 ，