一，拿到一个项目大体的策划书之后：
1，需求调研（时长、用户）；
（1），所在行业、市场的分析，当前发展情况及未来发展趋势；同类产品的发展情况；
（2），使用场景分析；需求层次的分析，表面分析，深入分析；
（3），竞品分析，分析竞品功能的出发点及主页业务，从而分析自身的一些需求，切记不要照抄；
（4），需求分级，根据产品不同周期区分什么是核心需求，什么是重要需求，什么是次要需求，然后根据需求的重要性，调整对此需求的开发投入。
二，调研结束知道大体的需求后：
2，产品策划，核心需求，架构分析，功能，交互、设计等，同时需要对竞品的产品需求、产品功能、用户定位、商业模式、运营思路、营销盈利等方面进行分析；具体如下：
前台（App或H5）：
（1），MVP(最简化可实行产品)原则和可用性测试就不用去做；
（2），设计原型，不要一开始就画需求。首先进行需求分析，分析明确了逻辑、流程、功能点再着手制作原型；
（3），项目需求文档(PRD)的书写，严格区分并且记录每次需要发布的版本；
首先，明确需求后，用Xmind画出项目架构，然后通过架构中的某个模块或者业务，进行拆分话出流程图。
对于某一个复杂或者具体的业务模块，用Xmind画出流程图，并且进行记录，在优化或升级的时候在其基础上进行重新保存，记录版本；
PRD文档中包含：原型的展示，数据元素，用例描述，复杂一些的模块还需包括流程图；
[1]，PRD文档可和设计原型并行完成，先在PRD文档中书写大纲，然后再具体的模块中进行设计原型并且完善PRD文档；
[2]，可以直接贴本功能的原型图；
[3]，本功能原型图中所有展示的数据列表及解释；
[4]，本功能中部分操作用例的操作方式及交互方式；
[5]，描述每个功能的互动设计和使用案例，用最简洁易懂的语言或者图形。
（4），每次升级或者优化的版本进行记录，以便后期能够直观的看出每个版本具体做了那些升级，最好做成excel以供检索；
（对每一个版本的需求进行分组，组下边有此版本的各个功能的增加、修改、优化条目，方便查找且留有历史记录）
（5），版本的冗余度不要太高，不要将某个版本的功能做的太过复杂，要进行发布迭代，先实现核心的需求，然后迭代次要需要。
（6），最重要 – 总结能力，各个功能和版本进行总结。
设计：
1，规范一些产品主题色值；字体大小，字体颜色，遮罩，透明度，圆角，一些常用文本的行数；
2，规范标准图标的大小。例如：iOS，Android的icon、封面展示图，wechat、新浪等第三方分享的封面展示图；
3，不要让设计人员因为美观而去修改产品的交互性和产品最初的理念；
4，设计人员的设计工作从外到内进行设计，设计出来一个页面就发布一个页面，禁忌全部设计完再发布，勿拖延开发人员时间。
后台（开发）：
[1]，规范一些需要保存的数据字段用以数据分析；例如：
IP、坐标、设备型号、设备ID、版本号、设备类型、token等公共信息。
[2]，规范一些接口中不得出现的字段及一些数据格式；
例如id，nil等不出现的字段或者值；
接口整体形式：
{ code , msg , data, attach}
[3]，后台系统的一些流程图，主要以功能图为主，从管理员登陆到base页展示，菜单栏操作等；
[4]，后台系统的一些实体关系图，例如用户权限的一些操作图，不仅用于记录，而且直观的让后台开发人员直观的看到权限等，对数据库的设计有所帮助；
[5]，后台原型图；
[6]，后台系统的PRD（原型，元素，用例）；
[7]，后台不要一股脑的返回所有的字段给前台，需要什么返回什么，缺什么加什么；
[8]，最重要 – 总结能力，各个功能和版本进行总结。
6，产品跟进和推动（项目管理）；
8，测试：熟悉项目功能、流程、交互、盈利模式等，需要全方位进行测试。
9，上线后的数据分析，从数据里发现优化点，从数据获得新的需求等进行迭代；通过数据分析，分析产品功能效果，找到产品迭代的重点，对症下药。
10，优化，改进，营销；
1，业务逻辑图；2，流程图；3，产品结构图；
业务逻辑图等同于流程图。
软实力
1，统领心，大局观；
2，逻辑性；
3，沟通能力，表达能力。
1，思考能力；
2，总结能力；
3，学习能力；
1，产品需求；
2，产品功能；
3，用户定位；
4，商业模式；
5，运营思路；
6，营销盈利。
一些规范：
1，文件命名： 公司名+产品名+PRD+v1.0 ，例如： 公司名-产品名-PRD-v1.0；
2， 修订控制页 ： 编号、文档版本、修订章节、修订原因(背景)、修订日期、修改人 ；
项目背景：人员组成、产品目标描述等
修改记录：每次的修改点和原因
信息架构：整体架构
核心流程：主要用户使用流程 交互分支1/2/3…：中高保真原型（功能和元素布局等）、详尽交互说明（空状态、错误提示、网络相关等等）
场景关联：应用外部的关联场景，硬件相关（低电使用、物理键操作等等），软件相关（通知打断、应用调用等等）
应用一致性梳理：弹框、toast、文案、设置列表、操作手势等等聚类梳理，主要是自我核查。（如有时间，会协助视觉同事把所有图标聚类梳理）
当然，文档撰写前有很多前期工作，例如用户研究、需求分析、沟通/评审/修改/确认、可用性测试等等。文档交付之后，还需要沟通/修改/补充/确认、开发核对、辅助测试等等。
一般而言，PRD文档是写给UI、研发、测试看的，那些市场分析、数据分析、产品需求、产品背景介绍等等前期准备工作还是通过MRD或者PPT来完成，针对PRD文档，针对的对象很简单，就是指导UI设计和开发团队研发和测试，既然如此，那么框架很简单：
1.目录（这个不用说）
2.修改记录（为了追踪整个产品形成的过程）
3.设计风格、要求（主要针对界面设计）
4.功能说明（便于了解产品架构）
5.操作说明（这里要重点说明，一定要详细写明，不同操作状态下的显示、提示、转场是什么样的，都要详细说明，不然留下的后果就是开发人员按照自己的程序语言来表达，导致啼笑皆非的事都有，后面你要优化个没完没了，还不如刚开始提交PRD文档时就面面俱到。
一些概念：
1、uv(unique visitor)，指访问某个站点或点击某条新闻的不同IP地址的人数。
在同一天内，uv只记录第一次进入网站的具有独立IP的访问者，在同一天内再次访问该网站则不计数。独立IP访问者提供了一定时间内不同观众数量的统计指标，而没有反应出网站的全面活动。
2、PV(page view)，即页面浏览量；用户每1次对网站中的每个网页访问均被记录1次。用户对同一页面的多次访问，访问量累计。
PV(page view)，即页面浏览量；用户每1次对网站中的每个网页访问均被记录1次。用户对同一页面的多次访问，访问量累计。
3、转化率；用户从某个指定的区域进入目标页面的次数；例如banner图点击进入某个商品详情后，记录一次banner的转化率；
给老板看的东西一般为：
市场分析、数据分析、产品需求、产品背景介绍等等前期准备工作还是通过MRD或者PPT来完成，然后通过演示给管理层进行评审。
功能性需求：登陆，注册，聊天等功能性的需求；
非功能性需求：产品客观意义上的一些需求，功能以外的一些需求，例如系统性能、可靠性、可维护性、可扩展性、兼容性、营销需求、运营需求、财务需求等。
1，是否需要国际化；
2，是否需要兼容暗黑模式；
3，是否需要删除缓存；