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