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

　　今天我们来聊一个尴尬的话题改设计。
　　在工作中，很多PM都可能会遇到这样一种情况：产品的文档已经交付了，产品也已经在开发了。可是，你突然发现有个功能设计有一点问题，需要做一些改动，这时你该怎么办？
　　这种“雷”对于几乎各种级别的产品经理都会遇到过，或大或小地都会经历一次这种生不如死的过程，有时感觉研发工程师恨不得拿刀剁了自己，可是本着对产品负责的态度又不得不提出来。这种结果往往导致团队士气低下，关系变差，产品延期，PM信任危机，等等。
　　那遇到这种问题究竟有没有解决方案呢，或者说有没有应对的方法论呢？
　　我们今天就简单来聊一聊，产品开发到一半，用什么姿势来思考“改设计”这个事。
　　区分真老虎和纸老虎
　　事情往往来得很突然。可能是和别人沟通中，可能是给技术讲解产品时，可能是自己突然领悟到，也可能是在读某篇文章时，你突然意识到，“我设计的产品功能有问题。”
　　此时，你的内心应该是Bi了狗了。接下来，你的内心活动可能是这样的一条路径：
　　产品功能有问题我得修改我怎么搞定我的技术我死定了
　　没错，你这样想就是死定了。因为这只是你的内心活动，而不是客观事实。
　　我们很多产品经理遇到问题时，都是自己把自己给吓死的。我们太容易把客观事实、迫切程度、迭代规划、内心感受、同伴关系等问题搅和在一起来考虑，你在做判断的时候就很痛苦，自以为事情很紧急很迫切，却不知道哪个是客观事实，哪个是你臆想出来的恐惧。
　　我们举一个例子：
　　比如某个数据产品经理，他在为一个新产品设计一个新的数据分析工具，大概有条件筛选、数据排序、数值计算、对比分析等一些基本工具，他在设计时考虑了数据分析的输入是什么，操作有哪些，输出有什么，从而设计出一个比较完整的数据分析工具，我们称之为v1。0。看来看去似乎并没有太大的问题，而且也比较简单，所以产品文档写好之后就交付了。突然某天，在和技术老大碰细节的时候，技术老大说，你怎么没考虑到数据如果太大处理不了怎么办？我们在流程上是不是要首先做数据过滤啊，不然数据存在数据库里，一口气几十万条数据都拿出来，岂不是乱套了！
　　这个问题真够唬人了，想想还真是个大麻烦事，如果一口气几十万条数据都被导出来，那岂不是把产品得搞挂了。看来得改设计了，可是开发已经进行到一半了，这怎么办？
　　此时最怕的是自乱阵脚。
　　这个产品经理需要好好分析一下，技术老大说的这种情况会在什么场景下出现。作为技术老大，他需要考虑的很多都是极端情况，这样才能确保产品在后续迭代中不会掉到坑里，他关心的并不是产品设计，而是技术设计。能够提出这样问题的技术老大是很有经验的，但另一方面也可能印证一件事，他提出来的问题并不是眼下最紧要的，可能是将来才会遇到的。
　　就拿这个例子来说，大量的数据过滤是建立在数据量已经足够大的基础上，对于一个新产品而言，如果忽略了这个功能，是不是致命，下一个版本能不能弥补，是在发现问题时需要立刻考虑的，这些就是我们前面提到的“客观事实”。这个功能缺失一定是个问题，但是不是要立刻修改又是另一个事情。
　　所以，产品经理千万要在问题出现的时候，把“客观事实”从所有复杂的信息里摘出来，认清楚这个客观事实是真老虎，还是眼下的纸老虎。
　　学会评估，是处理问题的第一步
　　当问题被抛出来的时候，立刻行动并不意味着立刻去改，而是立刻评估。
　　因为此时产品已经开发过半，返工和延期都是很影响研发进度的，而且还会影响到后续功能的设计。你需要学会评估一切因素，从而做出最合理的判断。
　　评估迫切程度：立马做，还是以后再做
　　如果这个修改是不得不改的，那么它才有返工的必要，否则就应该延后到下一个版本。
　　如何来判断迫切程度呢？我认为只有一点即可，这个功能如果不改，当前版本用户的使用是否会出现不可控制的断点和风险。
　　我们举个例子：
　　比如一个登录功能，如果是v1。0版本，你在设计的时候忘了加验证码。我们推演一下，因为是v1。0，可以假设此时的用户量并不大，大概也就多则几万，少则几千，此时即使没有验证码，也没有大问题，安全风险也相对较低。当版本迭代到v2。0，或者v3。0时，用户量已经比较大了，验证码就必须要有了，因为有安全风险。
　　再举一个例子，关于用户使用断点的例子：
　　比如一个聊天功能，如果在设计的时候，忘了设计本地缓存。此时我们再推演一下，如果是v1。0版本，用户数量不太大，每个人手里的聊天群平均下来都不太多，缓存的确可能会影响到一些网络不好的用户的体验，但是早期用户大多是奔着核心功能来的，缓存没有并不是最重要的断点，用户是可以勉强接受继续使用的，而且产品经理、运营是可以通过人力方式设法维系用户。但如果版本是v2。0，此时用户对于没有缓存的意见就比较大了，再不做缓存的话，聊天群如果比较多，则非常影响体验，立马形成了用户使用的断点，所以就很迫切。
　　所以，我们评估迫切程度是要和当前的版本相结合的，然后判断用户使用是否有断点和风险。根据经验，一般能够被评为迫切程度很高的修改是很少很少的，大部分功能都是可以延后再补救的。
　　评估研发难度：优化和分拆设计
　　如果很不凑巧，你就是赶上了一个被评估为迫切程度很高的设计改变，此时你要做的事不是立刻安排人去做，而是在完成新的设计之后，评估研发难度。
　　为什么要产品经理评估研发难度？这是为了帮助你更好地完成这次设计的修改。
　　我们一般在做产品设计的时候，第一个确定的方案往往不是最佳方案，这种方案会更多靠直觉推演。当我们深入到评估研发难度的时候，我们会发现最早的那个方案可能在研发难度上需要很长时间，或者需要多人参与，所以产品经理要学会重新评估，以及分拆设计。
　　我们可以将一个复杂的功能分拆成若干个简单的功能，当前只去开发最重要的那些，而不重要或者复杂的，如果迫切程度不高，我们可以把它们推迟到后续版本里。如此就可以极大地节约工期。
　　关系的维护是一定要做的工作
　　一切评估结束，我们看看怎么去和你的小伙伴们解释这个问题。（其实本不是特别想写这个部分，但是想想却又是绕不过去的坑）我简单罗列几个可供参考的方法。
　　勇于承担责任
　　产品经理是产品的CEO。
　　勇于承担责任是必须要有的勇气和担当，哪怕主要责任不在你，也需要站出来承担责任。一个好的PM首先是一个好的TeamLeader，否则不会有兄弟愿意和你一起卖命工作。错本身不可怕，怕的是甩锅怯懦的PM，这样的PM很容易失去同伴的信任。
　　明确分析原因
　　无论是通过一个小的会议，还是通过邮件，都需要明确分析产生这种修改的原因。
　　这种做法的目的不仅仅是将事情告知大家，而是要让所有人明白，这个是全团队的大事，通过正式的方式来通报所有参与者，显得正规合理得当。如果你只是私下里和大家说道说道，你的同伴会觉得你这个人相当不靠谱，也很不正规，他们在做这件事的时候也会不正规，最后可能又会带来新的问题，而锅还得你来背。
　　陈述新修改的影响
　　修改后带来的影响一定要提前讲清楚，这样所有人心里都有一个预期。
　　这里有一个小的Tips，你可以把你做优化以前的设计所带来的影响，和你优化之后所带来的影响进行对比，告诉大家我们产品经理通过努力，将影响降到了最低。这么做一方面让大家有个对比，比较容易接受，另一方面是大家会看到你这个产品经理在这个修改上很努力，很为大家着想。
　　好的沟通是确保未来长期良好合作的基础，千万不要充当一个只会分派工作，不会解释说明的产品执行者。
　　学会总结，不在同一个坑里跌倒第二次
　　当大家都接受了你的修改设计，并且已经开始工作之后，你一定要学会总结，以确保下次别再掉坑里了。
　　最好的成长来自于总结别人的错误，其次的成长便是来自于总结自己的错误。
　　总结一定要深刻，你需要分析你这次设计中缺失的环节，你手里的产品功能在后续的设计中还有哪些地方可能还有坑，而且还需要总结你这次处理的好不好，有没有后续的负面影响。总结并没有特别的方法论，具体问题需要具体对待。但是可以肯定的是，你总结的越细节，越能推演出前后的关系，你也就越能体会到成长。
　　祝愿各位年轻的PM们，在后续的工作中能够多总结，少犯错。