你只会推进产品上线？那你懂产品下线吗?

今天整理了下公司近几年的相关项目，差不多三四年的时间吧，尝试了大约五六十个业务项目（含合作平台对接），但几年下来，真正意义上还在正常运转的其实也就个位数，绝大多数项目最终都因为各种原因而停止了。在整理的过程中，写了点备注关于项目停止运营的原因，然后在回家的路上，突然心血来潮想着说点什么。

产品建档管理的优点

整理了五六十个产品项目，其中很多项目因为是早期的项目，只知道其名称，但整个项目的背景经历乃至现状几乎找不到任何资料可以查看。比较常见的是，时不时的，比如审计或者其他某些原因，可能需要这种老古董项目的信息，然后就会出现一种现象：一个一个的去询问猜测可能知道的人，最后可能也是毫无结果。

因此，在做产品的过程中，其实学会进行产品（或者项目）的建档管理其实很有必要，大致会有如下优点：

1. 产品具有完整的时间脉络，方便后期进行项目的回溯和查询。人的记忆和口头传达实际上永远不如文字记录的承载，（扯远点，所谓的诗书传家，难道也是因为古人知道自己某一天挂菜了，可能就要靠这些文字传播一下，让后辈子孙知道"子曾经曰过”？）尤其是在产品功能不断改版迭代，越来越复杂的情况下，有完整的书面记录才能复现一个产品的完整发展历程。当然，有完整的项目档案，也方便项目审计等；

2. 便于进行工作上的交流和沟通，提高效率，让其他人尽快了解业务。当公司的发展到一定规模的时候，跨部门跨BD的合作会越来越频繁，并且人员的流动也很频繁。我们可能需要给新入职的同学进行相关业务的介绍，可能需要在开展跨部门合作的时候，对合作方介绍相关的改动内容。如果没有完整的文字承载和建档，那么可能会一直陷入在重复性的沟通交流中，而如果有相关的材料，就可以先让不熟悉的人通过这些沉淀归档的业务进行快速了解；

3. 便于进行项目的复盘总结，并能够成为后续工作的经验借鉴。“以历为鉴，可以知兴替”，实际上这在一个公司的发展中一样存在着相同的知兴替的作用。我们如果认真记录每个项目上下线过程中的问题，去总结和回顾其成败的原因，那么就饿可以为后续进行深度的积累和准备，也可以让其他人以此为鉴，在后续新项目的开展过中，能够规避曾经遇到过的问题或者吸收其中的优点。

好是好，但实现难呀

既然建立完整的产品档案有这些优点，但实际上却很少有人这么做或者说做了但不够好。想了想，可能有如下原因：

1. 从公司或者部门层面，没有完整的流程指引或者规范。这种工作层面上的东西，如果从公司层面的角度以及从现实物质利益角度来看，其实没什么太大的作用，没有办法直观的看到可以量化的效果。虽然现在一般互联网采用协同办公的方式，基于wiki等进行文档的归纳管理，但在wiki的建立、维护和管理上，也是乱的一踏糊涂，基本上也就是作为日常的工作类文档。这类文档只在某一时刻有作用；

2. 事情变化发展太快，在追求效率和快速迭代试错的产品中，没有时间进行完整的文档建立和维护。这应该是最主要的原因，常见的比如产品需求文档，当文档完成后，在经历各种评审、以及开发过程中，对于原有的需求设定可能会经历各种变化和调整，但文档并没有及时更新，或者直接不写文档，直接就开发了。。。因此也就容易出现文档的断档。（吐槽下，这我觉得也没什么特别好的解决方法，因为我自己都有的时候懒得更新，所以难道是懒得原因？懒惰原罪啊！）

3. 缺少及时的正向反馈。因为文档的更新和维护，本质上其实不会太大特别直观的效果，而且估计大多产品或者开发想吐槽的，你写的东西给谁看?没人愿意看啊。。。久而久之，因为缺少积极正向的反馈，可能就不愿意把文档写的太详细或及时更新了。（在吐槽下，这就不为自己洗白了，现在我也懒得写文档，没办法。。。俗人一个。。。）经历过的最认证看相关产品需求文档的只有测试了，可怜的测试作为产品开发过程中的最后一环，背负了多少压力。。。

产品建档都需要啥？

结合日常工作以及今天的一些思考，大致想了下，一个完整的产品档案的建立，有这么一些不成熟的建议。

1. 项目相关背景，就是为什么要做，做这个是出于什么考虑，做了的话有哪些价值等，通常体现在MRD、BRD上。虽然工作上其实不怎么写这两个文档，但还是有必要简要说明，如果是外部合作类的业务，其实对于合作方的相关介绍，也是很有必要的；
2. 项目相关人员，这个实际上在项目出现问题，需要快速排查的时候就会发现很有作用，便于直接找到核心人员。原则上在项目的人员更替变动最后也有记录，最新的责任人，以及历史相关责任人等；
3. 相关需求文档及功能介绍。这个属于产品需求文档的一部分，本质上重点在于需求文档的管理，最主要的其实不是需求文档的编写，而是需求文档的变更维护，要保持与时俱进的更新。（这个好像没啥好说的。。。产品吃饭家伙。。。主要的问题就是尼玛线上实际运转的产品和你的文档永远是天上人家。。。）
4. 项目的复盘总结。这个属于产品上线完成后，需要定期的进行跟踪维护，并总结相关的数据，以及其中踩过的坑。作用其实很大，但说实话就没见过做的好的。。。复盘本身是一个大的命题，可能短期我们会进行产品效果跟踪，以及数据的回收分析，但却缺乏长期持续的跟踪和回顾。比较好的总结，理论（为啥是理论，因为臣妾也做不到啊）上是需要随着时间的延续，尤其是在长时间回顾后去验证的，就好比经济发展有其周期规律一样。比如A股，我们今天看，他莫名其妙的在2019年5月6号所有指数一篇绿油油，我们可能会认为是茅台引起的或者是因为股神巴菲特刚开完股东大会（瞎扯的。。。看新闻茅台今天市值蒸发854亿，开玩笑，A股第一股啊），但可能一年后来看，可能是经济发展周期中其他因素导致。
5. 项目的死亡证明。写到此处，我才发现我以上说的全是废话。。。今天我本来想聊的是关于产品下线的处理。。。哎，这才是本文重点，我决定给他个大标题！！！今天写文章就是这么任性，反正没人看，自己嗨就行！

如何给死亡产品办葬礼

这人出生的有出生证明，死了当然也有死亡证明。我们在项目中，产品上线通知基本都不会忘了写（尼玛，这可是功劳，现在是按劳分配的时代！），但对于产品停止运营下线了，基本都不会进行广而告之，尤其是不会写为什么下线？为什么下线？为什么下线？。所以我要说的是，作为产品，你懂怎么进行产品下线吗？你知道怎么给你负责的产品办葬礼吗？

每个产品都有其所存在的生命周期，有的可能是注定出生后就要夭折，有的可能是辉煌过后总需要陨落。但不论如何，实际上相对于推进产品上线而言，如何优雅的处理产品的丧葬事宜，我觉得更加重要。仔细想想这个葬礼应该这么办：

1. 准备好操办白事所需的一切材料。既然产品已经死了，我们就要为他办理身后事，需要进行相关的材料准备。产品在下线时，我们需要根据其状态，决定下线后的善后事宜。根据情况大致可以分为两个方面：

• 对于用户：停止新增用户，安置存量用户。如何处理保证不会有新增用户，准备停止运营的相关用户通过，引导存量用户的迁移等，确定最终停止运营的产品下线时间等；
• 对于公司关联部门：如何同步各关联方相关的下线事项，每个部门需要进行那些动作，如何培训客服部门进行解答等。以及相关的无用的代码、应用配置、服务器啥啥啥的是不是要进行处理；
  整体而言，下线相关的准备以及处理，最好能形成文字落库存档，以便于后续可以追述。不过貌似有一定用户量的产品停止运营，这部分大都会做的比较好。考虑的深入一些，还会思考以及规划如何将这部分存量用户进行留存以及向新的产品转移等。

2. 雕刻墓志铭，悼念其一生。这个产品已经寿终正寝了，那么我们需要回顾他光辉的一生，给他写墓志铭。X产品，生于x年x月x日，因xx原因于x年x月x日卒。比较感触的在于，很多历史项目其实是什么时候开始停止运营的，几乎都找不到任何的记录，尤其经常不知道为什么原因而停止。这本身需要和项目复盘相结合，每个产品停止运营的时候，其实最主要以及最有意义的一件事情，是开个”追悼会“，缅怀一下这个产品的一生，我们去分析这个产品为什么要下线，他取得了哪些瞩目的成就，以及又有什么遗憾没有完成。但事实是，很多项目都死的毫无价值。。。因为我们压根不去分析他为什么失败。回顾了下，我自己经历过的产品，大部分九死一生，但从没真正意义上去组织复盘思考会，去思考为什么会失败，这其中是哪些事情做错了。我觉得对于一个公司而言，真正有意义的，其实应该是对于公司内部失败的项目进行复盘整理，并能够作为培训材料（哎，感觉这就是商学院的案例分析啊，突然觉得每个成熟的互联网公司都该进行产品失败案例分析课程，这才是最大的资本啊）。

后记

最后，要不这篇文章就这样吧，感觉扯淡了一堆有的没的。核心感觉其实就一句话——对每个经历过的失败的项目组织复盘总结，分析整个项目的过程以及其失败的原因，是最大的财富。以及这个标题是我走路临机一动想的，感觉特别适合作为标题党骗点击！