今天我想聊一聊在产品需求进入正式的开发流程前我们需要做些什么？
起因是最近项目组公测「指的是功能已通过测试，服务端已发布线上生产环境，App端暂未提交应用市场，仅在公司小范围内进行正式的体验」了新的App版本，这次的发布让我感到非常尴尬。
关联发布项未提前沟通
发布前，测试确认了当前版本迭代的内容在预发和测试环境是测试通过的，准备发布线上生产环境，这时候项目遇到了第一个严重问题：优惠券要如何生成？这个版本需要发布邀请活动，但是由于一些历史原因，邀请活动的优惠券需要在其他平台上生成，并关联至代码中，才可以保障邀请活动的正常运行。
最后是在紧急联系了运营人员后，确认了优惠券规则，然后找对应平台产品新建了这次活动所需的优惠券，才解决这个问题。
配置项临时沟通并进行配置
这个版本涉及到多项运营配置项，需要相关人员配置以后才可以在前台有比较好的体验。公测版本服务端发布至线上后大约3小时后，产品经理才在沟通群里和相关运营沟通需要配置的项以及配置的要求，最终完成配置时间距离公测服务端发布已超过24小时，大大延后了公测的时间。
新增需求项
公测版本发布后，主要以该项目组为核心，在产品技术组内进行产品体验，体验过程中发现一些明显不合理的界面或逻辑问题，而这些问题理应在项目进入正式的开发流程前就应该被提出来就行修正。
需求无法被实现，临时变更需求
数据埋点的需求开发工作安排在公测至发布市场阶段完成，公测版本发布后，项目进入埋点需求开发，开发过程中发现部分埋点需求无法在当前需求基础上完成。由于相关功能已按照现有需求开发完成，所以只能在现有功能上根据可行性调整数据埋点需求，无法同预期一样完成数据的收集。
以上这些问题反映出在产品需求进入正式的开发流程前并没有做好产品上线相关准备工作。
那可能有人就会问了，产品上线的准备工作，为什么要在进入正式开发流程前就确定呢？不是产品上线前做好准备就可以了吗？
这里要区分一下具体的概念，产品上线前的准备工作包括两部分：清单&执行。
产品上线前的准备工作执行动作完全可以安排在上线前进行，但是清单需要在进入正式的开发流程前就准备完毕。
这样做的好处是什么呢？
保证需求的完整性和合理性
有种说法是，产品经理和程序员是天生的宿敌。这其中最主要的原因往往是产品经理交付的需求在逻辑上不够自恰，合理性和完整性层面上容易经受程序员全方位的挑战。
如果在进入正式的开发流程前，我们可以先想好这个版本我们的目标是什么，那么就可以以终为始，根据确定的目标，再梳理要达成目标，我们需要什么样的资源，经过怎样的努力，才可以达到目标。
这有点像做菜，一般情况下，我们在烧菜前，首先都会想好，我们想要吃什么菜，然后根据这个菜谱，再去准备相应食材，这样，我们才能烧出我们想吃的菜。
当达成目标的资源和行动项都可以被拆解到清单可落地项时，基本上需求也就想清楚，想明白了。这个时候产品经理交付的需求产物在需求的完整性和合理性上都有极大保障，即便在具体实施细节上因为某种原因无法实现，开发团队也可以根据目标给出相应的技术方案去实现目标。
降低需求变更可能性
需求变更主要由2种场景引起：业务变更引起的变更；需求未想全面就进入开发流程引起的变更。
日常工作中，大多数变更来自于需求未想全面引起的变更。
如果在进入正式开发流程前，我们就已经想清楚，想全面了需求的方方面面，那么将极大降低由想法不全面引起的需求变更可能性。
有序的项目管理
产品上线准备工作的清单整理出来后，我们就可以对这个版本有明确的认知：目标是什么？要实现目标我们要怎么做？etc.
结合开发团队给出的项目计划，我们就可以整理出上线清单，包含以下内容：
- 非开发资源什么时间准备到位？
- 相关人员什么时间进入验收阶段？
- 相关人员什么时间执行上线配置操作？
- etc.
有了上线清单，我们就可以对版本内所有事情做到了如指掌，在项目执行过程中就会比较容易把控进度和质量，做到有序的项目管理。
在产品需求进入正式的开发流程前，我们应尝试以终为始，依照最终的目标反向推导达成目标所需的资源和执行项，补充完善产品需求，整理上线清单，推进项目有序、效率完成。
