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

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

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

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

一、MVP-最小可行性产品

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

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

二、评估团队的资源

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

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

三、敏捷开发

什么是敏捷开发?

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

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

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

四、压力测试

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

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

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

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

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

...

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

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180611G06ZB100?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券