产品研发流程-启示录

合理规范的产品研发流程能使研发过程中少走很多弯路，本文是我阅读《启示录》后，根据自己的理解梳理出来的一套研发流程，不足之处还望指正！

1. 确定产品评审团

产品评审团主要负责决定产品战略方向、监督产品研发流程、合理配置资源，制定更及时和可靠的产品决策；主要成员在十人以内，涉及产品、市场、设计、技术、财务、总经理等多个部门。
主要评审内容：

评审产品战略和产品路线图，启动产品机会评估，选择值得投入精力的产品；
根据产品机会评估结果，决定是否开始定义产品解决方案；
评审产品原型、用户测试结果、成本估算明细，决定是否开始开发产品；
评审最终产品，产品品质、发布计划、社会效益等，决定是否发布产品。

2. 评估产品机会

一般由创始人、领导或产品经理提出一个idea，然后根据该idea，进行相关的产品机会评估；
具体评估内容包括：

解决了什么问题？为谁解决了这个问题？
目前行业是否有同类成熟产品，该类产品发展情况如何（竞争格局）
目标市场的需求度以及需求紧迫度如何（现在是否为市场时机、市场规模如何）
自身有什么优势，想做成功需要投入什么（为什么我们最适合做这个？）
我们如何将此产品推向市场？（进入市场的策略）
我们如何衡量该产品的成功？（什么指标？收入？战略？）
成功后会带来什么，与公司主线是否一致，是否值得投入相应精力与资源
失败后会带来什么，是否影响公司现有产品线，风险能否承担
哪些因素对成功来说至关重要？
鉴于以上情况，建议是什么，做不做？

3. 探索产品定义

在初步评估完成后，确定去实现这个idea时，需要围绕以下几点完成产品定义的探索：

产品面向的核心客户群是？
产品的核心功能点是？
产品最佳的表现形式是？为什么？
最后应该形成一份可行性的解决方案初稿

4. 确定产品原则

产品原则是后期流程中主要决策的依据和理由，是明确的产品核心原则，以免后期出现需求杂乱、功能偏离主线等情况；思考产品原则主要围绕以下几点展开：

产品的核心业务功能，我们想成为什么？
产品最重要的用户群，我们要对谁负责？
我们一定不能做什么？

5. 寻找特约用户

在项目开始阶段，产品经理需要深入洞察用户的需求，大量用户直接沟通的可能性较低，因此就很有必要挑选一批特约用户，B端产品特约用户在6~ 10人即可，C端产品特约用户最好在10~15人左右，产品经理需要了解每一位特约用户，跟他们成为伙伴，积极的听取他们的建议，发布产品前尽量确保每个人都满意，这样他们也会主动的帮忙把产品推荐出去。【注意区别特约用户与产品尝鲜者，尝鲜者往往能容忍产品的不足和缺陷，他们不是准确的目标用户，他们对产品解决的问题并不是特别在意，因此如果错误的听取了尝鲜者的建议那么产品的发展方向就令人担忧了。】

6. 市场调研

合理使用市场调研工具及方法，找到以下问题的答案：

谁是目标用户？
用户会怎样使用产品？
用户能想明白怎样使用产品吗？障碍是什么？
用户为什么选用你的产品？
用户喜欢产品的哪些特点？
用户希望如何改进产品，增加或调整哪些功能？
以上市场调研仍有局限性，针对探索产品定义时，我门需回答以下问题：
采用什么技术来更好的解决产品要解决的问题？
设计什么样的用户体验？

7. 定义产品人物角色（用户画像）

根据用户调研分析结果，确定谁是目标用户，也要清楚谁不是目标用户，两者同样重要，面面俱到的产品往往一无是处；

人物角色可以用来筛选哪些是产品重要的功能；
可以避免产品团队把自己的需求当成用户需求；
有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的地方；
可以方便地向团队描述产品的目标用户是谁，他们怎样使用产品，他们关心产品的哪些方面；
可以帮助团队在解决问题时，迅速达成共识。

8. 确定基本产品（最基础功能，最小单元产品、MVP）

包含最重要功能，只满足基本需求的，不可删减的最小单元产品定义。

具备实现商业目标的最基本功能要求，以及浪花的用户体验和吸引力，把复杂度降到最低，把开发时间减到最少【小步快跑】；
邀请主程序员或架构师一起参与设计，估算各功能的直接与间接成本，指出设计上的误区并分析评估尚不确定是否可行的功能，最终各方都是透明的，开发团队心里也有底了；
开发前，必须请真实用户验证，验证通过后不能再随意修改设计。

9. 产品说明文档（功能定义）

理想的产品说明文档应该满足以下要求：

应该完整的描述用户体验而不仅是用户需求，还包括交互设计和视觉设计（用户需求和用户体验是密不可分的）；
必须准确地描述软件的行为；
必须以直观的方式把产品信息和产品行为告诉所有产品说明文档的受众（开发、测试、客服、市场营销、运维、销售、管理层、客户等）；
产品说明文档的形式应该是可以修改的（难免有意想不到的问题出现）；
主体清晰，并带有需求优先级列表、线框图、实体模型等；
因此符合以上要求的产品说明文档就应该是高保真产品原型，当然仅仅有原型还不够，用例可以作为有效的补充用来描述重要的产品行为，另外一些补充说明文档可以注释在原型上或者放在wiki等公司内网上。

10. 用户体验设计(高保真原型+UI）

我们的目标是打造有价值的、可用的、可行的产品；
为了保证开发过程不频繁变更产品功能，UI设计应该在产品开发前完成，用户体验需要全面地、连贯地看待，深刻考虑以往的用户使用习惯，以确保用户不会因为软件使用困难而放弃；
为了确保产品的可行性，在需求调研和产品设计时至少应该邀请几位开发人员参与产品设计的可行性及成本评估。

11. 产品验证、原型测试

产品验证能极大提升产品研发上线后市场的认可度，原型测试让更多一线用户直面产品，通过观察发现目前存在的问题并及时优化，再次验证，确保产品原型的符合用户需求及使用习惯；

可行性测试：让开发人员寻找产品设计里难以克服的障碍，提前解决这些问题；
可用性测试：务必请真实用户进行测试，为了让测试体验更真实可以模拟复杂的后台处理过程，根据用户反馈，最好规划多次迭代测试，确保实现最佳用户体验效果，让不同类型的用户都能明白如何使用；
价值测试：可以和可用性测试同时进行，使用原型也是一样的，不过可用性测试重点观察用户如何设法完成必要的操作，而价值测试重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式。

12. 产品研发落地

确定最终产品说明文档、原型图之后，根据实际情况，与开发人员一起合理排出研发计划表，运用敏捷开发以及瀑布式开发方法【持续改进法、里程碑式开发方法】，确保产品高效完成，并制定高效的测试计划，在规划时间内完成产品所有功能的测试工作，改进明确性bug问题，记录可优化改进的细节问题。

13. 优化改进现有问题

在开发完成后，产品团队以及公测部分用户使用后，会发现有一些可优化改进的问题，针对此类问题，需思考以下几点：

不要一味地添加功能，很多情况下随意添加功能会使产品性能变得更糟糕；
优化前，要明确目标，以提升具体有意义价值的关键指标为准；
分析改进细节时，充分利用用户的反馈数据，还可以进行网站分析，请用户参与测试，利用数据模型更准确的发现问题。

14. 产品版本管理、需求管理（迭代）

除非达到了产品经理的要求，否则不要轻易发布新版本，产品经理必须确保交给用户的产品能正常运行，频繁更新版本会让用户感到不安；
每次迭代完成后，产品经理应向团队展示产品现状，以及下次迭代的产品原型，让大家看到工作成果，同时加深大家对产品的理解，增强团队对这种开发方式的信心；
迭代后的需求管理，注意优先级，时刻以产品目标为依据，结合用户数据，排列需求的重要紧急程度，规划具体实现版本。

15. 平滑布署

很多用户对突然或频繁的版本更新非常反感，如果新版本存在使用隐患，影响会更加糟糕，为了将版本更新发布带来的负面影响降到最低，可以采取以下几种措施：

通过公告、群发短信、推送消息、新版本教程等方式提前通知用户，由于很多用户对该类信息都置若旁闻，所以这个方法效果有限；
加倍做好测试工作，最大程度避免新版本出现使用隐患，比如可靠性问题、扩展性问题、性能问题等，确保将来不会出现不得不降到旧版本的情况，给用户带来不必要的麻烦；
新版本如果影响用户规模较大的话，可以采取并行部署或增量部署、区域性逐步部署的方式来降低风险。
切记不要轻易试探用户的耐心，用户的信任和好感是非常珍贵的，要小心保护。