本文接《这些年做产品踩到的坑，和犯过的错（一）》，作者分享了自己在做产品过程中遇到问题后总结出的几点经验，希望对大家有所帮助。

四、尽量保证所有事情都有记录可寻

这个标题本身就很吓人，所有的事情都有记录可寻，人又不是机器，怎么能保证任何事情都会留痕呢？但实际工作当中，做到记录留痕真的非常重要。通常有以下6种常见情况，你会发现有迹可循、有文可查是非常有意义的：

1. 当你迭代产品需要对原来的功能、内容进行调整时；
2. 当你对你的工作进行总结、回顾以及输出方法论时；
3. 当你的交接者需要进行工作交接时；
4. 当你的合作者需要介入产品/项目的设计与研发时；
5. 当你与需求方进行沟通，构思业务逻辑与产品逻辑时；
6. 当团队协作时遇到某些问题或出现事故时；

我们对上述6种情况逐一简要的分析一下。

（1）我们设计产品，难免会对原来设计的功能进行调整或优化。很多新手产品经理在做这项工作时想当然的认为新的设计一定会比旧的设计更好，因此会大刀阔斧的直接对功能下手。我们在论语中学过一种学习方法叫做“温故而知新”，说的就是通过温习旧的知识来参悟新的知识。那么对于产品设计而言，这种温故知新法同样是有必要的。有一些旧的设计，虽然在现在的眼光里看来很low，但是当初这样设计很可能是有意而为之。比如受到了公司资源、研发实力、技术框架、运营手段等等各个方面的限制。如果这时，我们没有好好的记录下当初的设计为什么要这样做、为什么不那样做、受到了哪些限制、希望达到什么样的目的，那么在功能优化时，就会漏掉这些问题。导致无法进行研发或者上线后出现很多其他问题。

（2）有时我们会抱怨公司要求的日报、周报、季度总结、年度总结等等，但实际上这些汇报往往是你在年中或年底总结时的重要参考数据，也是和我们的奖金直接挂钩的内容。我尝尝因为懒而不去认真的记录日报，或是干脆忘记。直到当我要进行总结、为未来做计划时，才发现无从参考。

（3）工作交接是每一个人在工作中都会遇到的问题。无论是公司内部交接还是员工离职交接，每一个交接的人都希望拥有之前产品所记录的所有内容，以便于更好的了解产品、了解历史。无论是从交接者还是被交接者的角度思考，我们都应该负责任的去记录好应该记录的内容。

（4）与工作交接相类似，合作者的介入，也非常仰赖旧的文档以及沟通记录。因为我们不可能每次都要言传身教的去帮助别人更好的理解产品和项目，也不能玩完完整整的在脑海中记录每一个细节问题。

（5）与需求方沟通，通常需要我们提出自己的产品角度的建议与想法。这些建议和想法都是跟据历史经验得来的。你有没有遇到过一种情况：需求方提出一个你认为不可行的方案，但你又回想不起来当初到底为什么不这样做? 这时，如果你有据可查，那么就能够轻松的应对。

（6）团队协作，必然可能出现相互扯皮、出现事故的情况。大家站在各自的角度和利益面前，不可能非常理性的去分析和思考一些问题。那么这时，如果你需要有证据来尽可能证明问题不是出现在自己身上，那么一个好的记录会让你能够捍卫自己的权益。这并不是说让我们利用这些证据成为团队中甩锅的利器，而是为了团队更好的了解问题的根源，避免无休止的争论。

五、再小的设计也值得认真思考

在做产品设计时，尤其是一些有一定经验的产品经理，对于细节的处理和小的功能点会带有一种迷之自信。我曾经也看到过一些文章，探讨过产品经理是否需要过多的去关注细节问题。在这里我只谈我个人的感受，那就是：再小的设计，也值得认真的思考。

认真思考并不是我们要陷入某些产品细节之中，更何况真正工作的时候往往没有那么多时间去处理一些细节。认真思考的意思是说对于一些常见的功能，我们是否有认真的态度去思考过它该如何设计、为什么这样设计。

工作中，我发现很多人包括我自己，在设计一些常见功能（比如页面跳转、空值显示、筛选排序等）时，选择直接copy，或者不去过多地描述功能逻辑和异常处理逻辑。我们理所当然的认为说，研发和测试已经做过很多这样的东西，并不需要过多地去思考和描述这个需求。就是因为我们在思考上的懒惰，导致产品在研发时，我们会发现研发人员会提出各种各样的问题，甚至直到看到测试用例的时候，才发现自己当初的设计有多么愚蠢。

其实只要我们在设计的时候，多花点时间来思考，动手去描述，就能够避免大部分这类问题。我们常常会夸赞某个产品对于细节的把控非常到位，然而自己却对于小设计嗤之以鼻。

六、双人或多人合作时千万不要替对方做决定

在工作中，我们经常会遇到与其他产品同事进行合作来设计产品。比如一个网站，大家各自负责独立的版块，彼此的业务又常常会有交集。这个时候，我们也难免会碰到需求重叠、互斥、耦合等等情况。这个时候，我建议双方在合作时一定要明确分工、及时沟通、共同负责，于此之外，更重要的一点就是不要提对方做决定。

我曾遇到过两件事：

一件事是在某个产品设计中，我设计的某个功能与其他同事的设计有交集。当研发和测试人员咨询同事的设计时，问到了我的设计。由于同事并不了解我设计的初衷，但又碍于面子，强行按照自己的想法给研发和测试人员进行解释。就导致他的解释与我的设计初衷几乎违背。直到事后我发现问题，才避免了研发与测试人员的理解错误。

另一件事，是研发和测试咨询我某个其他产品经理设计的功能点的某个字段是否不合理需要去掉的时候，我并没有仔细核对，直接通过自己的判断告知其删掉。导致事后才了解到如果没有这个字段，会影响产品合规性要求。

因此我们在与他人进行合作设计时，千万不要凭自己的感觉去提对方做决定。即使在小的点，也要经过沟通确认再共同去对其他部门的同事进行宣导。

本次的分享就到这啦，如果您有什么建议或想法欢迎留言，我会继续梳理这个系列。

#相关阅读#

这些年做产品踩到的坑，和犯过的错（一）

本文由 @黑眼圈233 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议