转产品助理岗位有一段时间了，目前更侧重于后台产品设计，从产品愣头青到能独立负责项目，期间收获良多，想写一些经验与大家分享，也是对自己成长的总结。

• 工作流程

和客户开需求会议，了解业务需求

通常需要外出和客户沟通，了解客户的业务需求，更准确的理解客户想通过此项目达成的目标。一般是产品人员和项目经理一起去，项目经理进行技术评估，这样能够保证需求能够很好的实现。

需求的整理、分析转化，优先级排序

开完需求会议之后，需要将会议的内容做一个整理，将用户需求分析转化为产品需求，即要实现的功能点以及功能页面的元素。另外在资源有限的情况下还需要确定需求的优先级，明确此版本需要做的需求，优先实现用户最迫切的需求。

制定项目计划

我在工作中会用Excel制定项目计划表，把控项目的功能明细、模块负责人、计划时间等，这样可以清清楚楚的看到会有哪些任务，每个任务会消耗的时间。多数情况项目经理会把控开发阶段的时间节点，但作为一个产品人，明确自己需求的进度，做到心中有数，并且能够及时检验，是对产品负责的一个态度。

梳理流程

进行原型设计之前，需要先梳理流程，将流程梳理清楚才能保证原型图的正确，可以借助流程图、思维导图。一上来就撸起袖子画原型容易陷入繁杂的细节中而忽略业务流程上的重点，因小失大，并且因为各种逻辑梳理不清楚会造成效率低下。

原型设计

Web端产品大多用Axure 工具来画原型，Web端页面设计的规范是要了解一些的，此篇就不详细讲述了，后续会写一篇对页面设计规范总结的文章，敬请关注。

PRD文档

PRD文档是把之前整理分析转化的产品需求变为技术实现的研发需求，需要阐述清楚详细的细节以及方案实现过程中的各种问题。开发设计人员通过文档可以了解页面元素和相应规则，测试人员可以根据文档撰写测试用例。之前PRD文档一般用Word文档的形式，由于使用人员需要原型图、Word文档、流程图、思维导图等资料来回切换着看，很是繁杂，而且也不易整理和回溯。现多用于直接在Axure构建，总体框架如下图所示

1.项目概述

（1）项目简介

以模块的方式介绍项目的总体背景、主要建设内容、建设目标等，让PRD阅读用户快速了解项目概况信息。

（2）结构图表

补充系统相关的图表，包括架构图、流程图、功能点列表等，同时图表带日期版本，可以追溯历史版本。

（3）版本信息

主要填写该项目的版本迭代、更新记录，包括迭代的时间、版本号、实现主要功能等。

2.修订记录

产品需要把每次PRD文档调整的地方在这里清晰地写出来，方便文档读者观看，也方便自己记录。

3.全局说明

主要体现整个产品的公共设计规范，及一些页面通用的规则、系统公共的规则说明。

4.产品原型

需要体现产品原型页面和标注信息，要将页面所有的功能与跳转逻辑标注清楚；标注格式由编号和文本框组成，注释位置一般在要素上，为了界面美观，默认不展示注释详细内容，点击编号后展示。

需求评审

想强调一点，评审会上不要一上来就直接讲原型，最好能简要阐明会议内容，做这个项目的意义以及业务背景等让团队成员快速进入状态，对自己的工作有更清晰的认识，提高效率。

会议上对涉及的主要流程进行讲解，功能需求进行阐述，演示原型内容和交互，可能还会涉及技术实现方案的讨论以及评估工期时间。会议结束后需要总结整理会议上讨论的问题以及讨论结果，完善方案，更新产品文档及原型。

项目跟进

需求评审之后，则需要落实到具体的时间安排，开始项目跟进。这时开发、测试人员就会忙碌起来，开发、测试过程中也会暴露很多问题，可能是细节遗漏，也可能是设计不合理，甚至是客户临时调整需求……对于产品来说，此时需要做的就是尽力填坑，保证产品及时落地。另外产品人员在项目开发中，也要尽可能的去测试功能模块，确保落地的产品与预期的无误，在操作体验的过程中也能思考优化一些细节问题。

• 产品习惯

从产品的角度思考

作为产品，只有我们思考的更全面，后面开发测试中出现的“意外”才会越少。多考虑一些细节问题，比如页面的必填字段、是否需要分页、是否有字符限制、字符过多怎么显示......这些细节问题，当我们思考的多了以后，就会形成自己的一套思维模式。

从开发的角度实现

把自己当成开发，站在开发的角度来考虑实现需求，这样有助于在写PRD文档的时候，更详细地标注需求的条件说明。比如给出明确的规则，排序是升序还是降序；一周是自然周还是取7天的数据就可以？

从测试的角度体验

站在测试的角度来体验产品功能也极其重要，通常我们习惯性地考虑理想状态，而测试人员除了常规测试外，也经常“屌丝”的测试某些极端情况。比如边界值测试、特殊符号测试、网络中断测试等。极端情况发生的几率很低，但是对用户体验有着重大的影响。

• 产品提高

尝试着去理解你不能理解的上层决策。老板拍脑袋加需求是常有的事情，通常你又无法反驳，这个时候就不要独自在心里较劲了，站在老板的角度弄清楚为什么要添加这个需求，然后收集相关的资料信息，把最终思考的框架及结果展示给老板。

尽可能的多积累自己的知识、技能和经验。基础技术知识、UI设计规范甚至心理学等都是有必要学习一下的；平时遇到好的文章也可以收藏起来当做知识储备，以便后续参考；元件库、移动端设计模板、Web端设计模板可以收集汇总，形成自己的标准库。

学会沟通，勇于背锅。提高专业能力，把问题考虑全面能减少很多不必要的矛盾；开发、测试人员平时的压力也都是不小的，塑造良好的沟通氛围，以同理心站在他们的角度看问题，跟他们一起战斗，一起优化，一起完成。因为自己的失误而造成工作损失，理应自己负责任，承担后果。

以上内容大多都基于对自己的工作理解，可能存在一定的局限性，仅供参考。更多文章更新在微信公众号【产品小姐姐】，欢迎关注免费领取我购买或收集的产品学习视频、规范模板、元件库等资料，期待一起交流进步。

微信扫描关注