从设计到开发上线中，产品的一些基本原则

身在创业团队中工作，讨论与意见分歧是不可避免的，最近在进行复盘的时候，我发现讨论通常会分为两种：

• 一种是针对于模棱两可的问题进行进一步的明晰与界定，这种讨论往往是有积极意义的，会促使团队成员深度思考；
• 另一种是讨论往往是针对于产品细节可A或可B的意见分歧，这种讨论会浪费大量的时间，并且在很多时候是无意义的。

进一步分析第二种讨论，我发现原因是团队内部对于一些基本的产品原则模糊不清，每个人都会有不同的产品理解与产品原则，这也就不可避免的在很多次要问题上进行了过多的无意义讨论。为此，我专门总结了一下产品从设计到开发上线这个过程中的一些基本原则，然后把这些原则与公司各部门同事进行了沟通，以期就一些基本的产品原则达成共识，从而减少无意义的讨论。

这些原则中，有些是已有广泛应用的，有些是我自己的经验总结，欢迎同行们补充纠错，相互学习。

一. MVP产品原则

1. 该原则的含义

这个概念最早是由《精益创业》的作者Eric Ries提出来的，意思是指开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。MVP产品的重点并不是让产品如何美观、交互如何炫酷，而仅仅是为了验证产品的功能是否被用户所接受，人们的接受程度如何。

如果团队成员对这个原则没有清晰的认知，那么产品经理就会接到大量关于优化与细节体验上的需求，而且产品也会经常被内部成员吐槽。所以这个最基本的观念需要在团队内部达成充分的共识。

2. 该原则的意义

（1）MVP原则可以使创业团队在拥有较少资源的情况下，对用户的需求进行快速试错；

（2）MVP产品可以使团队大量减少因为开发错误功能而产生的成本与开支（时间成本、人员成本等）。

3. 注意的点：

（1）MVP产品是一个持续优化的过程，初期不要将眼光过多着眼于UI与体验层面；

（2）MVP需要产品团队将更多的精力花费用户意见反馈搜集及数据分析上，并以此为依据进行版本的持续更迭。

二. 需求冻结原则

1. 该原则的含义

这个原则是我自己总结的，是因为在创业团队里虽然也有开发节奏把控和版本控制，但是经常性的会被上级或者老板以一些有理或者无理的需求所强行打乱，逼得我变更需求，而开发团队又是敢怒不敢言。所以这个“需求冻结原则”就是针对于公司内部喜欢频繁变更需求所制定的。

需求冻结是指在需求评审会议结束之后直到产品新版本上线之前，对需求进行暂时性的冻结，不在此期间内接受新的需求。新提出的需求都需要统一延期到后续版本中去。

2. 该原则的意义

（1）对开发进行保护，避免因产品经理或其他人频繁变更需求而导致开发进度延期；

（2）提升团队开发效率、对需求提出方进行约束、避免过多的需求扰乱开发节奏。

3. 注意的点：

需求冻结在实际中很难做到百分之百，你总会有那么个别上级或老板喜欢在上线前强行插需求，但冻结率至少应控制在90%以上，否则会扰乱开发节奏、而且让开发感你的需求控制能力很差。

以下是提需求的过程中，可能需要注意的原则：

三. 数据导向原则

1. 该原则的含义

创业团队内的每个成员都有提需求的权力，但是很多人会根据个人的主观感觉提一些不重要或当前阶段并不需要的需求。而每当这时，我都还需要花费一定的时间解释这个需求为什么不重要、为什么不适合在当前版本做等等问题，时间长了还挺浪费我时间的。

所以我觉得团队内部在提需求的时候，应当有一个数据导向的原则，提需求并不是凭空构想的过程，而是需要有具体的数据分析依据，根据数据分析出来的需求、才有可能是核心需求。在各种需求依据当中、总体的排序如下：

数据分析>用户反馈>竞品情况>先前经验>个人构想

2. 该原则的意义

（1）这样做的核心目的是为了降低开发错误需求的概率；

（2）让全体成员都拥有数据意识，养成从数据角度看产品的习惯。

四. 需求统一管理原则

1. 该原则的含义

需求的管理其实并不是一件容易的事，因为需求的管理需要综合考虑需求的来源、优先级、影响的范围、带来的收益、可能带来的风险以及产品当前所处于的阶段等等方面。而很多人在提需求的时候（尤其是老板），总是认为自己的需求就是最重要的，而要求产品经理将自己所提出的需求进行插队。

需求统一管理原则其实就是让各个部门以及老板知道：既然你们现在有产品经理，那么你们所有人提出的需求都应该让产品经理进行统一管理，让他去排序优先级、决定做与不做，在这方面进行充分的授权。而非自以为是的要求产品经理按照你的要求一会做这个、一会做那个。

2. 该原则的意义

（1）给予产品人员更多的自主性与授权，提升产品人员对于产品的责任心与担当；

（2）只有维护产品人员的相对独立性，才有可能做出更好的产品。

3. 注意的点：

产品人员也同时需要承担需求错误、延期等问题以及所带来的责任。

以下是需求评审中的一些原则：

五. 可行性先行原则

1. 该原则的含义

需求评审过程中，如果技术人员针对于某个产品需求提出了更便捷的实现方式，原则上尊重技术人员的意见，按照可行性先行原则进行。

2. 该原则的意义

可行性先行原则有利于提升开发团队的效率，并且提升技术团队的参与感与责任感。这个原则也与MVP原则是内在统一的。

六. 责任人定夺原则

1. 该原则的含义

在产品设计与开发的过程中，经常会出现可A可B的时候，各方也经常会为了证明到底是A对还是B更正确进行非常多的讨论。这个时候如果没有具体的结论，应当遵循责任人定夺原则，比如宣传页面到底是蓝色好、还是红色好，这种问题发生争论的时候，最终应当交由设计师进行定夺。

比如交互方式到底是A好还是B好的时候，最终应当交由交互设计师去定夺。再比如一个需求到底做或者不做，最终也应当是产品经理发话。

2. 该原则的意义

（1）责任人定论的原则其实是对员工的一种授权与信任；

（2）责任人定夺的原则有利于让专业的人在其专业的领域发挥更大作用。

3. 注意的点：

责任人定夺原则需要责任承认其定夺错误带来的问题与责任，所以责任人定夺并非是乱授权、乱定夺。

以上就是我最近复盘所总结出来的产品从设计到开发上线中的一些基本原则，欢迎同行进行修正或补充。