17年十一过后突然接到大boss的任务，要在年前对现在的前后台产品进行整体重构。大boss只是在战略层面上给了2个大方向和1个deadline，就让我们产品着手开始干了。因为这次重构涉及到前后台所有的产品线，而且时间紧任务重，所以几乎整个部门所有人都参与进来了。之前没有经历过这么大的产品项目，过程中遇到了很多问题同时也学到了很多东西。在这里跟大家分享下，希望能给到大家一些帮助。
一、宣讲产品目标
提到产品目标，大家可能都觉得太虚，大部分产品都更加喜欢上来之后就说产品功能，例如我们这次要做一个问答的功能需要有问答频道、问答列表、提问弹窗等等，感觉这样可能更接地气。然而我认为整个产品规划的第一步应该是向项目组成员宣讲产品目标。
首先跟大家同步下 我理解的产品目标是能为公司带来的价值及为项目组成员带来的价值。例如我们这次的产品重构，从公司角度上来说其实是公司业务转型的一次重要尝试，将决定公司接下来5年的发展甚至有可能改变整个行业。这样让大家觉得我们是在做一件有意义的事情，精神层面会有成就感。从个人角度来说，这是一次难得的机会，可以从头开始参与一个全新产品的设计，而且业务还是如此复杂，过程当中能学到很多东西。不论是在公司内部的发展还是未来换新工作，这都是一张非常漂亮的成绩单。大家可能还是会觉得前面提到的有点鸡汤，所以最后要来点接地气的，比如项目经费是多少，成功上线之后大家的能分到多少奖金。毕竟大家出来工作大部分都是为了赚钱，先把奖金抛出来会更有动力。
二、明确团队角色及分工
1、决策者
很多人认为老板才是产品的决策者，老板具有最高话语权。然而产品设计过程中有很多的东西需要确定。如果所有的问题都需要老板决定，项目进度肯定会有影响。同时老板并不是专业做产品的，很多细节的问题让他来决定并不靠谱。而且如果产品设计过程中，成员没有一点决定权，势必会打击大家的积极性。所以需要基于重要程度来分别设定不同的决策者。
例如产品对应的商业方案肯定是需要老板决策的，然后核心页面需要产品总监决策，之外的其他二级页面、三级页面，产品总监如果有时间可以给点调整意见，但是尽可能放开手让大家去做。
2、项目经理
大部分互联网公司内部都没有设立专门的项目经理岗位，很多时候都是产品经理担任了。但是一旦涉及到多产品同时协作的大项目时，就一定要设立这样的一个岗位。
项目经理需要负责控制整个产品范围、制定及监控项目进度、组织沟通会议、协调安排项目成员等工作。如果说决策者是对产品负责，那项目经理就应该是对项目负责，需要从范围、进度、人员、成本等多方位考虑，以保障项目的成功。
3、会议记录及整理员
产品规划阶段，会频繁的开会沟通，很多想法都是在会上碰撞产生的。但是碰撞的过程大部分都是非常凌乱的，所以为了保证好的想法能最终被记录下来，每一场会议都必须安排一个会议记录及整理员。
注意我说的不是单纯的会议记录员，而是记录整理员。如果只是把所有会议上的沟通点记录下来没有任何意义，因为大家没有时间把所有记录的内容看一遍 再找有用的点。所以记录完需要整理，最终出来的文档里必须要明确的记录下：会议决议及对应的执行分工、待决议事项及对应的处理方法。
建议每场会议分别由项目组不同的成员来担任会议记录及整理员，毕竟这是一份相对琐碎的工作长期安排一个人做，不利于他的成长也不利于团队和谐。
4、资料整理员
这是一个项目前期我们忽略的角色，但是到了后期UE设计的时候才发现少了这个角色，严重影响了项目进度。因为需要设计的页面特别多，时间很紧，所以基本上是每个人负责几个页面的设计，对应的UE也都是在自己手里。当其中一个成员请假后，就会发现他的东西没人能接手。再就是 因为调整版本太多，大家每个人的文档整理习惯都不一样，想要把方案整合到一起特别困难。所以项目执行到一半，增加了资料整理员的角色。
资料整理员的工作就是——
每天晚上负责把大家当前手头最新的产品方案UE、流程图等 收集上来；
按照项目文档的命名规范 整合在一起；
将整合完毕的资料上传到项目组的共享空间。
5、产品设计人员
最后就是我们产品经理的本质角色——产品设计人员。这里没什么需要多说的，只不过作为团队负责人，在分配产品设计任务时 除了考虑项目的进度和质量问题，如果可以尽可能多考虑下人员的成长。例如后台的产品经理，如果想尝试前台的产品设计，请尽可能给予机会。
三、建立规范的沟通机制
对于这一点之前跟很多朋友聊到的时候，他们都特别不屑。认为在前期产品规划阶段，就是天马行空的碰撞才会有好的想法，不需要搞什么规范的沟通机制，随时想到了就随时组会讨论就行了。我认可在产品规划阶段，确实不需要设置太多限制。但是这并不意味着不需要规范的沟通机制。
我曾经就经历过这种所谓自由开放的项目，领导随时想到一个点就拉着大家一起去开会沟通，然后大家七嘴八舌 开始发表自己的想法，整个会议氛围特别火热有激情。然后会议开了2个多月，产品却没有一个基本的雏形，各种各样的想法，今儿想到了 明儿就忘了或者是明儿就被推翻了。结果可想而知搞了3个多月，最后一个月不得不上线了，只能找各种相似的产品 东抄一点西拼一块 凑成了新产品推到了线上。
我所谓的规范的沟通机制，并非限制大家的思维发散，而是有目的 有方法的去沟通，尽可能减少无效的沟通。接下来跟大家分享下，我梳理的沟通机制。
1、建立会议机制
日会：每天召开一次，建议早上开。会议目的是 回顾昨天的工作情况，明确当天的工作计划。
周会：每周一次。会议目的是 穿透项目整体进度，梳理下周重点工作。
临时会议：不定期召开。会议目的不固定，但是会议前必须明确目的。
2、明确会议目标
无论什么会议，会议前必须明确会议的目标，拒绝无意义的瞎聊。也许在前期这个目标比较大，但是也必须要有，否则大家聊得过程中没有一个中心点，会无边发散，最后没有结果。
3、提前做好准备工作
与会人员应该提前做好相关的准备工作，尽可能不要在会上临时去找资料。例如当前整个问答模块进行重构，需要开会讨论下重构的方向。参会前需要提前了解到 当前的问答功能的逻辑、本次重构的目的、当前问答模块的PVUV等数据、竞品的研究等等。
4、做好过程中的会议记录
好的想法极难出现，然而在高强度的脑暴过程中又极容易被忘记。所以过程中会议的记录员需要记录下过程中的所有相关点，以备后续深入扩展。
5、必须有明确的会议产出及后续的工作安排
争取每一次的会议 至少产出一个明确的决议以及对应的后续工作安排，以此来保证每一次的会议都是有意义有结果同时可落地执行的。
四、建立文档格式、命名规范、修订规则及存档方式
提到这一点就异常难受，因为前期没有梳理，项目过程中导致了大量的时间浪费。例如在设计UE过程中，有的人习惯用Axure，有的人习惯omnigraffle ,然后有些公共的模块，就无法复用，需要重复做几遍。后期在跟UI对接的过程中，我们这边UE的页面是叫【圈子详情页】，然后到了UI那边就是 叫 【圈子01 】。整套产品大小页面差不多 200多个，命名一乱，不仅是要用的时候找不到，平时大家交流过程中也很痛苦，经常驴头不对马嘴。
所以前期一定要建立文档命名规范、修订规则及存档方式。每个项目都不一样，所以我这套方式仅供大家参考。
1、文档格式
会议纪要：所有会议纪要统一用 思维脑图 记录。我们都是统一用的百度脑图，因为可在线共享。
AI信息架构：思维脑图
产品需求清单：Excel表格，表格中注明 对应的页面、需求描述、优先级、提出人、当前进度等等
产品UE：Axure
产品UI：PS
产品PRD：统一维护到confluence里，然后PRD统一编写的格式，我们这边是之前梳理过PRD模板，所以相对来说比较清晰。当然有很多时候项目比较近，可能来不及写非常细节的PRD，但是建议复杂的逻辑还是最好写在PRD里，方便后续测试也为了后来人能更好的了解产品。
2、文档命名
会议纪要：项目编号-会议议题(会议时间)，例如 KPFS-PC前台操作权限沟通会(17.10.24)
AI信息架构：项目编号-信息架构（编制时间），例如 KPFS-PC前台信息架构(17.10.24)
产品需求清单：项目编号-需求清单（编制时间），例如 KPFS-需求清单(17.10.24)
产品UE：
注：一个产品线统一一个UE文件（包含产品所有的页面），尽可能不要拆分出多个文件。如果是多人协作，可以分别单纯出UE，但是每天都需要汇总到一起。如果是页面实在太多，整合在一起之后文件太大，可以考虑按功能模块划分是几个大类，每个分类下的页面放在一起文件里。
整个UE文件：项目编号-产品名称（最新修订时间），例如 KPFS-PC前台UE(17.10.24)
UE内页面：序号-页面名称（最新修订时间），例如 01 注册登录页（10.23），下图我习惯的UE页面划分方式。
产品UI：与UE页面的名称保持一致即可
产品PRD：统一维护到confluence里，然后PRD统一编写的格式，我们这边是之前梳理过PRD模板，所以相对来说比较清晰。当然有很多时候项目比较近，可能来不及写非常细节的PRD，但是建议复杂的逻辑还是最好写在PRD里，方便后续测试也为了后来人能更好的了解产品。
3、修订规范
A 如果是小范围的修订，则将原内容用删除线注释掉，然后将后面写上新内容。同时在文档顶部修订记录内写明本次修订的内容、时间、修订人以及修订原因。例如PRD里的需求调整，可以参考下图：
B 如果是大范围的调整，将原内容保留但是要注明已失效，重新编写一份文档。
所有修订的内容，一定要第一时间告知项目组所有人，避免因为信息不对等导致大量无效的工作。
4、存档方式
存档方式可以因项目不同随时调整，我一般习惯的是 按文档类型先做一级分类，例如UE、UI、会议纪要这是大类，然后每个一级分类下 再按时间做二级分类。因为前面每个文件的命名规则已经订好，所以直接按对应分类进行存档就可以了。下图我个人比较喜欢的存档方式：
项目过程中产生的所有文档，一定要记住存档。千万不要以为这版内容已经被推翻了就直接删掉，因为大boss很有可能看完了5版产品UI，后来觉得还是第一版最好。而且每一版内容都是大家花心思琢磨出来的，即使在这个项目没有用了，未来也有可能会用到。
五、制作标准元件库
很多产品需求梳理明白后就开始着手画具体页面的UE。经常画着画着 想起来这个模块 之前画过，然后就回去找之前的UE打开然后复制过来。而如果是多人协作的情况下，其他人不知道之前有过这个页面，又会重新画一遍。这样不仅浪费时间，还会导致同一模块出现不同的效果。
为了避免这种情况发生，建议大家在UE设计、UI设计、前端开发、接口开发等协作过程中，提前梳理出通用的标准元件库供大家使用。
六、搭建信息共享体系
这里其实就是想跟大家分享我常用的一些共享软件，便于大家信息共享。
百度脑图：我们所有脑暴过程中的会议纪要都是记录在百度脑图上，然后共享给项目组所有人。
Processon：一个在线协作绘图平台,支持在线创作流程图、思维导图、BPMN、UML图、UI界面原型设计、iOS界面原型设计等。我一般习惯用来画流程图，因为Mac没法装VISIO，使用还挺方便，同样也可以直接共享出去。
一起写：云端基础办公软件,支持多人协作编辑文档、表格。这个特别好用，例如每周汇总大家每个人的工作进度时，直接把周报模板丢上去，大家在线维护下各自的内容就OK了。我把这个介绍给部门小助理后，她使用后说至少减少了她原来10%的工作量。例如年底为了给大家父母寄新年礼物，需要统计大家的家庭住址。之前都是每个人单独给她一份，然后她再汇总为EXCEl。用了一起写，只需要把人员名单导进去，大家每个人在自己的那一行写下地址就可以了。
奇妙清单：一款todolist软件，比较适合小范围的项目管理，例如产品团队的任务分配及定时提醒。使用特别方便，随时想到随时就可以记录下来，再也不用担心遗漏需求点了。
confluence：这个不多说了，非常好用的一款产品PRD在线编辑软件。强烈推荐大家使用
JIRA：和confluence是同一家公司的产品，用于开发测试过程中的任务管理。同样强烈推荐使用
无论用什么共享软件，也不能代替人与人之间的直接沟通。所以多团队协作过程中，大家一定要记得多问多交流。
