为什么我们说产品上线，总那么难？

产品立项之前，产品经理会要求研发团队进行需求评估，拆解开发、设计任务，预估一个上线时间，这个时间我们就称之为：上线时间。

很多时候，上线时间是在上级任务与开发工作量一起沟通的结果。但为什么我们每次在倒计时上线时间后，我们发现时间却不够了？

今天以我的产品案例来聊聊，上线延期出现的原因......

上线时间另外因公司的业务类型，会有区别。

如：公司做外包类服务，甲方的上线时间就基本无法变更的。除了整个项目的价格外，上线时间成了合同的deadline。

如：公司业务自身类的产品，上线时间因热点事件、竞品竞争、政策原因等，要求都会更加具体类似10月1号等，但这样通常给予产品经理的时间却少了，因为产品经理做需求的时间必须要考虑产品本身迭代需求和上面列举的需求。

结果：产品经理只能依据具体的项目任务时间，倒退需求的实现方案。

比如：主功能实现、关联性功能设计、交互设计、用户体验的完整度

上图中，左边为主功能弹窗，右边为主功能弹窗下的功能介绍+页面链接。既满足了主功能弹窗的选择，也增强了业务的关联性。

BUG的回归测试

产品上线前，正规的产品研发流程要求产品模块测试工作会在测试环境进行。但我认为产品经理在产品工作中，会遇到这样的场景：

测试环境没有出现的BUG，在线上环境却出现了。

类似这样的数据加载页面，我们在测试环境中打开是如下是可以正常加载和使用的。

但上线后，页面加载后却出现了这样的问题：

测试环境中显示正常，但在线上环境后用户打开页面却出现了无数据的问题。

所以，我建议产品经理就要协助测试人员，进行BUG回归测试。

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

回归测试的难点在于问题的迁移变化。和代码结构导致的关联性问题并发。

需求的变动

这里的需求变动在我负责的产品团队中，常出现2种情况

• 需求不清晰，导致最后开发自己YY做

  
  

• 需求被上级或甲方调整，导致开发任务增加

上述两种情况，产品经理应尽可能的避免第一种。尽可能的把需求的场景、需求的细节描述、需求的交互说明都列举清楚。

这里告诉一个方法：用户路径法

如上图，每个页面都有入口。入口之间形成了路径，而用户的入口点击就成了“用户路径”

以用户路径，对当前每个入口、页面的场景进行需求描述

what\how\where\when\why

以5W需求拆解法对入口需求描述，养成这样的习惯后，产品经理需求的描述功底会逐渐扎实起来

产品经理的工作本来就需要依靠以案例经验、业务或行业熟悉程度来落地的工作。

如果你仍然在担心自己的需求描述不够详细，除了反问上面几个问题，其次就是吸收几次产品设计中的问题，就会越来越好了

上面的方法也是我一路走来，最常用的方法。

需求的变动导致项目进度推迟，也是导致产品上线不能准时上线最常见的问题

正常都会浮动几天

曾经我在一个项目团队，因为上线定在周五。但就出现了上面说的两个问题，第一个是BUG回归、第二个是需求的问题

上线最终熬了一个通宵也没有成功。可想而知，团队的斗志瞬然变得十分低落，毕竟一个通宵一个周末，到第二个周一发现版本竟然没上去。

“这个产品设计就有问题”“这个产品估计很难做好”“这个公司靠谱吗”.....

上面这些言论因为产品上线不成功，让团队产生负面能量，显然是不可取的。

但不管我们要求的时间多么具体，自己要认识到互联网产品上线通常都会浮动几天。好的情况是提前2-3天坏的情况是推迟3-4天。

最后，我建议产品经理应该知道：

不要为了产品上线，而发版。要保证每一次发的版本给用户或给公司，带来的都是能够解决之前问题的新版本。一个无效、或没有解决问题甚至有更多问题的版本，可以选择延期上线。

好啦，今天的原创案例就在这里，预祝大家中秋节快乐～

推荐我的原创内容：

坚持一年，招募100个产品经理

我的第一本书，给你们

Kevin的10G资料包

2018年，让我们继续前进！