半年没有更新简书，复盘这半年时间，公司因为经营问题外加疫情原因，成为了压死骆驼的最后一根稻草，加入了倒闭潮。随之而来的就是失业、找工作、再就业。相对幸运的是，我在年前就开始准备面试，年后约好复试，因为疫情原因在家电话面试后，成功入职新公司。入职后一路开启忙忙忙模式（也是因为自己比较懒），直到最近做的几个项目基本结束比较悠闲，可以静下心来写写小作文。

    在写小作文之前做过大大小小的项目，从最开始的蒙着头就做，到现在先清晰目的背景后在进行前期准备最后开始做。中间也经历了很多小门槛经常被绊倒。此文章的主要目的，一是为了对之前做的产品复盘，二是把自身的总结方法写出来，锻炼自己的写作归档能力。如果有幸被我的产品好朋友们看到，也希望再给我一些意见或建议，方便后期再遇到小门槛可以轻松跨过。

    产品前期准备工作至关重要，准备的是否足够充分，可能会影响整个产品的走向。作为一个产品人要做的就是打好地基。地基如何开始打，怎么打，接下来就进入正题开始聊聊（偏B端）。

1、了解项目背景

    通常情况下，我接到项目都是领导告知，“有个***系统，你了解一下” 。而我需要做的就是了解要做的产品是什么，带着大致的了解和用户（甲方）进行沟通，挖掘用户的深层次需求，清楚用户做此产品的目的是什么，需要解决哪些问题，以及用户期望的需求点有哪些。此过程更重要的是清楚用户的痛点、需要和期望的需求，弄清楚后才可以带着这个点更深的了解产品具体功能。

2、了解同类竞品

    通过与用户的初次沟通，其实对产品已经有了一个概念性的了解，带着目的，寻找一些具有代表性的同类产品进行分析。通过竞品分析来增加对要做的产品及需求的熟悉度，主要入手几个方面

1）产品使用场景：了解产品的第一步，就是需要清楚用户会在什么样的场景下使用这个产品。使用场景有哪些。

2）产品适用群体：谁来使用产品，及使用产品的目是什么。

3）产品核心模块及详细功能：市场上同类产品有太多了，但每个产品的核心功能都不尽然相同，这一阶段就需要静下心来去使用、体验每个产品，清晰各功能模块的耦合关系，及业务流转。有时间的话可以写出每个产品的大概模块及功能点。

4）产品运营方式：产品通过哪些方式进行拉新留存，方法有哪些。

5）产品市场占有率：了解各竞品的市场份额、所占比例。

6）产品的优劣势：清楚每个产品优劣点，吸取能提升效率，增加用户体验的点，完善不是很满意的功能。

7）竞品的功能比对：列出综合产品功能清单，标识各产品有无功能。

    此阶段主要是为了加深对自身要做产品的认知，可以根据实际情况考虑是否需要编写产品分析报告。就我个人及现公司而言，没有更多时间产出完整竞品分析报告，所以在产品开始前期，有一个竞品功能比对即可。

3、整理功能清单

    根据1和2，整理自身产品功能清单，俗称搭产品框架，也就是把需要做的模块、功能以及功能详细介绍整理到功能清单中。好处是能对产品的整体架构有一个比较清晰明了的思路，方便在产出需求、画原型的时候有一个框架对照。同时需求过程中，遇到需要增删改的功能，可以直接在功能清单中进行标注。当然，出了功能外，还可以包含模块进度和各模块需求的开始结束日期。这个主要对自身产出需求时的工作把控，让自己的工作条理清晰，不至于一团糟，不知道自己进度如何。

4、确认需求

    功能清单是对产品人整个产品框架的把握，有的功能可能会和用户想要的需求不完全匹配，所以罗列功能清单后，需要和用户进行再次确认。此阶段基本不可能会一次通过，需要多次和用户进行沟通，根据用户需求修改功能清单。直到双方共同确认无误，可以进入需求产出阶段。

5、原型设计及需求编写

    流程类产品，原型设计前最好有一个流程图大概的流程图，根据流程图思路进行原型设计。非流程类产品，可以根据功能清单进行原型设计。

    因所在公司从不要求高保真并要求不允许原型中有很多色彩，所以需要有一份通用规则。此规则中包含按钮大小颜色、列表的长宽及展示字段自适应、新增编辑需要弹框还是新开页面、列表页展示数据条数、系统兼容、页面是否需要自适应等。通用规则前期一定要写好，避免开发过程中或开发结束后研发一直在修改，耽误研发进度。

    原型设计没什么好说的，铺页面即可。主要在于规则编写。我经历的公司，有严格要prd的，也有不需要prd文档，规则需要写在原型旁边的。其实不管哪种方式，只要规则写的完整，逻辑清晰即可。包含输入型规则（字段类型限制、是否需要获取数据，从何处获取，获取的什么类型数据等）、展示型规则（数据来源、数据是否需要多表查询展示，展示什么类型的数据、需要获取数据的增删改对展示数据的影响等）、编辑规则（哪些可以进行编辑、编辑后生效时间、编辑对上下游数据的影响等）、导入导出规则（导入模版、导入格式限制、导入内容处理）、查询规则（是否支持模糊查询、是否支持组合查询等）、其他规则（增删改查对上下游数据的影响，如何处置）

6、需求评审

    可能会经历多次需求评审，没有什么可以一次性通过的产品。主要是产品内部评审（可邀请部门同事一起提出意见反馈）和项目组评审，我之前遇到的项目组评审，都是产品讲需求，研发测试听完后就进入开发阶段，开发过程中遇到各种的问题，再回头问产品，这个过程可以说多方难受。所以现在要求评审的时候研发测试必须提出自己的意见，积极讨论，减少开发过程中因需求不确定而产生多余的工作量。

7、交付研发、二期需求整理

    需求评审通过项目进入研发阶段，一期功能暂时告一段落，通常情况产品可以轻松几天，但不要懈怠，需要立马投入精力考虑一期功能未完善需要优化的需求及二期需求梳理。

    以上，就是对产品前期准备工作的方法总结，文中阐述的观点是自己在工作中总结出来的方法，不说一定正确，但实际可行。如果文中有考虑不全的点，或有更好的方法，希望朋友们可以分享出来。

    第二次写这种小作文，互相学习、共同进步！