聊一聊产品经理害怕的那些事儿

有一次跟一个朋友A出去吃饭，席间A君一直在看手机，故问他，连吃饭都不走心，工作能走心么？A君回答，他们家的产品周末高峰期并发量会猛增，每周周末在瑟瑟发抖、心惊胆战中度过，吓得小编赶紧打开app看看，自家的产品是否还健在...

产品经理最害怕的假设，莫过于，如果有一天，你的软件挂了，这是一个友谊小船翻掉的好假设，你家软件才会挂[傲慢]！

为了让周末能安心地睡过去、打游戏、约妹子，该知道的套路还是得知道，下面小编要给大家介绍几个方法，解决用户无法访问软件、bug随处可见，Loading不出来等问题。

一、MVP-最小可行性产品

聊到这儿，大家可能就有看法了，产品需求用MVP来验证用户的使用、接受程度，你这聊的软件风险问题，跟这个有什么关系？当你在MVP的基础上增加附属功能，除了要清楚这个功能的必要性，还要知道增加的功能对软件性能的影响，比如新增加的功能是“兴奋型”需求（具体参考KANO模型），在没有验证基础需求是否满足的前提下，是难以说服领导和你的开发团队的；二来，新增加的功能如果较为复杂，需要引用第三方代码库，无意中增加了很多代码量，会让你的软件代码很臃肿，直接影响加载速度。

虽然这MVP功能不那么完美，但是稳定的功能比牺牲稳定性发布要好得多。当你添加额外功能时，要判断这些额外的功能是否有必要，以及对你产品的稳定性是否有影响。总之，稳定性>完整性。

二、评估团队的资源

大多数产品经理在定义需求时，往往“理想化”，特别是跟领导汇报时，会把“蓝图”描绘得十分生动，以获得领导的更多青睐，但其实是在给自己找坑。在实际设计、开发过程中，会经常出现设计资源不足，部分功能无法开发，被临时插入紧急bug等现象。导致原计划要做的事情，最后变得面目全非。举个生动的例子，现实中的开发场景，理想模型的小龙女是李若彤，设计模型是刘亦菲，实现模型很可能就是陈妍希版的小龙女（绝对没有黑的意思）

所以，在评估开发资源时，要考虑所有的可能性，可能出现的延期情况，团队能力，设计/开发/测试难度等；如果在给定的时间内无法完成，一定要学会砍需求，或者让你领导排需求的优先级。

三、敏捷开发

什么是敏捷开发？

采用迭代、循序渐进的方法进行软件开发，一个大的项目被拆分成多个子项目，各个子项目的成果都经过测试后才上线，这个过程软件一直处于可用的状态。

在敏捷开发中，每一个子项目都经过设计、开发、测试，每一次迭代的代码都经过测试。在测试阶段，比较高级的测试会写一些自动化测试脚本来跑程序，验证产品经理定义的所有用例，测试的自动化脚本覆盖率越高，效率就会越高，上线后风险越低。运用敏捷开发，交付功能不再只是产品经理的责任，而是整个团队的责任，只有互相配合，上线风险率才低。但是在初创团队，发布流程往往得不到重视；在初创公司做测试的同学经常抱怨，每次留给测试的时间非常有限，并且只测功能，根本没时间写测试脚本。

如果领导不够重视发布流程的话，建议你多跟领导谈一谈，最好谈之前做一些调查，告诉领导目前发布流程存在的问题，以及改进方法。

四、压力测试

产品崩溃对用户的影响，每个产品应该都清楚，但可能不清楚的可能是，到底软件能承受住多大的压力，就像运动员锻炼举杠铃一样，每个人承受的压力都不太一样，软件服务器也一样。

作为产品经理的你，应该能回答出来以下问题：

我们是有100个还是10000个并发用户？

哪个时刻是用户使用的峰值？

如果在高峰期，某个东西卖完了有替代方案吗？

...

了解可能出现的问题是第一步，但是更重要的是，你怎么测试和处理。性能测试必须在每个可能出现环节的真实环境中进行，在并发量少时，你可能觉得没有问题，但是并发量一上来，你的软件很可能就承受不住。比如，之前淘宝双十一在11.11凌晨并发量过亿，导致服务器崩溃；在12306上买票，在高峰抢票环节，经常出现404页面。

以上，就是小编总结的几个方法，大家觉得有用的，点个赞吧~