产品开发到一半，你想改个设计，怎么办？

作者：帅帅的帅

全文共 2912 字，阅读需要 8 分钟

—— BEGIN ——

今天我们来聊一个尴尬的话题——改设计。

在工作中，很多PM都可能会遇到这样一种情况：

“产品的文档已经交付了，产品也已经在开发了。可是，你突然发现有个功能设计有一点问题，需要做一些改动，这时你该怎么办？”

这种“雷”对于几乎各种级别的产品经理都会遇到过，或大或小地都会经历一次这种生不如死的过程，有时感觉研发工程师恨不得拿刀剁了自己，可是本着对产品负责的态度又不得不提出来。这种结果往往导致团队士气低下，关系变差，产品延期，PM信任危机，等等。

那遇到这种问题究竟有没有解决方案呢，或者说有没有应对的方法论呢？

我们今天就简单来聊一聊，产品开发到一半，用什么姿势来思考“改设计”这个事。

事情往往来得很突然。可能是和别人沟通中，可能是给技术讲解产品时，可能是自己突然领悟到，也可能是在读某篇文章时，你突然意识到，“我设计的产品功能有问题。”

此时，你的内心应该是Bi了狗了。接下来，你的内心活动可能是这样的一条路径：

没错，你这样想就是死定了。因为这只是你的内心活动，而不是客观事实。

我们很多产品经理遇到问题时，都是自己把自己给吓死的。我们太容易把客观事实、迫切程度、迭代规划、内心感受、同伴关系等问题搅和在一起来考虑，你在做判断的时候就很痛苦，自以为事情很紧急很迫切，却不知道哪个是客观事实，哪个是你臆想出来的恐惧。

▐ 我们举一个例子：

此时最怕的是自乱阵脚。

这个产品经理需要好好分析一下，技术老大说的这种情况会在什么场景下出现。作为技术老大，他需要考虑的很多都是极端情况，这样才能确保产品在后续迭代中不会掉到坑里，他关心的并不是产品设计，而是技术设计。能够提出这样问题的技术老大是很有经验的，但另一方面也可能印证一件事，他提出来的问题并不是眼下最紧要的，可能是将来才会遇到的。

就拿这个例子来说，大量的数据过滤是建立在数据量已经足够大的基础上，对于一个新产品而言，如果忽略了这个功能，是不是致命，下一个版本能不能弥补，是在发现问题时需要立刻考虑的，这些就是我们前面提到的“客观事实”。这个功能缺失一定是个问题，但是不是要立刻修改又是另一个事情。

所以，产品经理千万要在问题出现的时候，把“客观事实”从所有复杂的信息里摘出来，认清楚这个客观事实是真老虎，还是眼下的纸老虎。

当问题被抛出来的时候，立刻行动并不意味着立刻去改，而是立刻评估。

因为此时产品已经开发过半，返工和延期都是很影响研发进度的，而且还会影响到后续功能的设计。你需要学会评估一切因素，从而做出最合理的判断。

▐ 评估迫切程度：立马做，还是以后再做

如果这个修改是不得不改的，那么它才有返工的必要，否则就应该延后到下一个版本。

如何来判断迫切程度呢？我认为只有一点即可，这个功能如果不改，当前版本用户的使用是否会出现不可控制的断点和风险。

如果很不凑巧，你就是赶上了一个被评估为迫切程度很高的设计改变，此时你要做的事不是立刻安排人去做，而是在完成新的设计之后，评估研发难度。

为什么要产品经理评估研发难度？这是为了帮助你更好地完成这次设计的修改。

我们一般在做产品设计的时候，第一个确定的方案往往不是最佳方案，这种方案会更多靠直觉推演。当我们深入到评估研发难度的时候，我们会发现最早的那个方案可能在研发难度上需要很长时间，或者需要多人参与，所以产品经理要学会重新评估，以及分拆设计。

我们可以将一个复杂的功能分拆成若干个简单的功能，当前只去开发最重要的那些，而不重要或者复杂的，如果迫切程度不高，我们可以把它们推迟到后续版本里。如此就可以极大地节约工期。

一切评估结束，我们看看怎么去和你的小伙伴们解释这个问题。（其实本不是特别想写这个部分，但是想想却又是绕不过去的坑）我简单罗列几个可供参考的方法。

▐ 勇于承担责任

产品经理是产品的CEO。

勇于承担责任是必须要有的勇气和担当，哪怕主要责任不在你，也需要站出来承担责任。一个好的PM首先是一个好的Team Leader，否则不会有兄弟愿意和你一起卖命工作。错本身不可怕，怕的是甩锅怯懦的PM，这样的PM很容易失去同伴的信任。

▐ 明确分析原因

无论是通过一个小的会议，还是通过邮件，都需要明确分析产生这种修改的原因。

这种做法的目的不仅仅是将事情告知大家，而是要让所有人明白，这个是全团队的大事，通过正式的方式来通报所有参与者，显得正规合理得当。如果你只是私下里和大家说道说道，你的同伴会觉得你这个人相当不靠谱，也很不正规，他们在做这件事的时候也会不正规，最后可能又会带来新的问题，而锅还得你来背。

▐ 陈述新修改的影响

修改后带来的影响一定要提前讲清楚，这样所有人心里都有一个预期。

这里有一个小的Tips，你可以把你做优化以前的设计所带来的影响，和你优化之后所带来的影响进行对比，告诉大家我们产品经理通过努力，将影响降到了最低。这么做一方面让大家有个对比，比较容易接受，另一方面是大家会看到你这个产品经理在这个修改上很努力，很为大家着想。

好的沟通是确保未来长期良好合作的基础，千万不要充当一个只会分派工作，不会解释说明的产品执行者。

▐ 学会总结，不在同一个坑里跌倒第二次

当大家都接受了你的修改设计，并且已经开始工作之后，你一定要学会总结，以确保下次别再掉坑里了。

最好的成长来自于总结别人的错误，其次的成长便是来自于总结自己的错误。

总结一定要深刻，你需要分析你这次设计中缺失的环节，你手里的产品功能在后续的设计中还有哪些地方可能还有坑，而且还需要总结你这次处理的好不好，有没有后续的负面影响。总结并没有特别的方法论，具体问题需要具体对待。但是可以肯定的是，你总结的越细节，越能推演出前后的关系，你也就越能体会到成长。

祝愿各位年轻的PM们，在后续的工作中能够多总结，少犯错。

—— END ——

本文原创发布于人人都是产品经理，未经许可，不得转载。