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