蜗牛派本文是一个系列文，主要是将我自己目前产品工作中踩过的坑和遇到的困难进行反思和总结，然后将其输出为一个工作规范。同时也因为我现在负责公司产品组管理的工作，制定相关的规范和准则，一来可以约束自己，形成良好的工作方式和流程；二来可以约束团队，方便新人工作和成长更加具有科学性和条理性。初步定的内容和模块大概有三个大模块，九个 小细项，希望我能坚持写完。
1、多需求、多项目管理
一般来说以单独的系统作为一个项目，每个产品可能或多或少会接触两个以上的系统，也就是要同时处理多个项目，对多个项目进行管理。
- 项目启动：为什么要做这个事情？动机是什么？目的是什么？需要准备什么内容？
- 项目规划：如何实施这个项目？这个问题包含了多个子问题？项目团队要做什么？需要什么样的资源？什么时候开始做？谁来做？什么地点做？等等……
- 项目执行与监控：执行之前的计划，根据分解的目标来进行逐步完成，对执行的情况进行控制，控制的过程就是围绕着质量，成本和时间来进行的。
- 项目收尾：最大限度的积累项目的经验，总结教训，为下一次的项目争取更多的资源并做好准备。
从项目管理的生命周期入手，产品在项目启动的环节要注意需求的收集与分析，需要给出足够的理由和证据去调动资源开发某个需求，此处要注意一些特殊化的定制需求，有时候往往是这类看似可拒绝，又不可拒绝的需求总是会让团队陷入一些困境。尽量从一些行业通用标准和一些用户信息反馈去落实，该不该做，哪怕是未来可能会翻篇也要做的就在项目启动前面注明未来的改动，让大家提前有一些心理准备和缓冲。
项目规划这一块尽量按照敏捷的思想去实践，往往很多时候项目延期并不直接是产品的问题，但是良好的规划和用户故事的拆解，会让团队对项目的进度和计划有更细致和具象的了解，有利于让大家了解具体要工作的内容和要花费的时间。此处除了要求严格用TAPD实行敏捷迭代的要求之外，也推荐大家去看看WBS相关的内容。
WBS是指将项目产出物（或项目目标）逐层细分为更小、更易管理的子项目或项目要素，直到分解出的要素非常详尽，能够支持下一步的项目活动分析与定义为止的一种方法。
项目的执行和监控就是日常提到的一些产品跟进和信息补充，这一块比较容易出问题的就是需求文档或者描述的调整没有及时同步和更新，导致开发做了新的东西（私下沟通的）但是需求文档中还是旧的描述，到时候测试进行验收的时候容易出现一些矛盾。所以要么就及时修改需求文档的东西，要么就是联合开发和测试一起讲一下变化的东西是什么，当然我依然是建议需要记录相关的变化。
除此之外，项目的跟进还可以体现在“产品亲自验收”，“每日站会”，“及时更新操作手册等文档”，“及时汇报项目风险和难点”，“广播相关进度和内容”等等。
项目的收尾主要就是下面讲到的一些产品发布和上线后要做的东西，在这里如果继续讲有点重复的味道。所以主要就是关注几个词：
- 复盘总结；
- 数据分析；
- 文档梳理；
其实总结下来就是：回顾和记录。回顾就是复盘，记录就是翻出文档，继续完善文档。
2、产品发布
a. 制定发布方案
由于公司采用敏捷开发的模式，产品版本的发布频率较常规的产品发布频率会高很多，但是由于B端业务的复杂性和关联性，建议“少发版本，多合迭代”。
一个迭代会有一些更新内容，可能重要也可能不太重要，但是一个迭代完成了之后都会形成一个提测版本交给测试，测试完成之后就可以对此迭代的需求做一个“已完成”的状态标识，但是却不一定要发正式生产版本。因为生产版本可能涉及或者影响的东西比较多，频繁上生产版本会耽误用户的使用，同时可能会造成一些配置或者数据的问题。
所以，我们合理地结合各方面因素，将几个迭代的内容或者诸多需求合并到一起然后再确认发布正式生产版本，其中的工作则可以概括为：制定发布方案。
制定发布方案并非是指临近要发版本了，然后去制定要怎么发，什么时间发这么简单，而是在需求收集设计过程中结合目前已经在开发的需求，综合考量去制定相关的计划。一般的，发布方案应该考虑或者包括以下内容：
1. 制定上线检查清单，主要是评估产品是否满足上线标准，以及是否有遗漏重要环节，包括以下内容 ：
- 回归测试：这部分一般测试团队会去做并且会给出测试报告，建议各位产品经理在产品自测阶段一定要自己对核心流程、核心功能充分回归测试，确认是否完整可用；
- 时间选择：上线时间的选择很重要，WMS需要考虑到会不会因为发布版本而对实际生产作业影响，一般会挑选仓库上班前或者下班后或者午休时间等发布。而其他系统的发布也要考量到是否会影响到用户的使用，最好制作一份时间表；
- 文案：所有文案是否明确无歧义，并且合规？比如一些词语“账户、帐户， 登录、登陆”的确认，如果有一些系统需要做多语言切换，则需要确认语言的翻译是否准确，是否到位等；
- 相关文档的准备：帮助文档、SOP文档是否完善，新功能的上线会增加用户的学习成本，好的SOP或者帮助文档可以尽快让客户熟悉系统，同时也能为后续岗位变动的同事提供相关的指导；
2. 通知与协作，主要是通知和培训相关干系人，公布相关系统新功能和特性，减少沟通不畅带来的损失。
- 运营团队：SOP文档制作、仓库作业人员的培训是否到位，一般由产品经理与运营团队培训，然后由运营同事进行SOP文档的完善和调整；
- 客服团队：新功能的用法，可能存在的异常情况，以及能解决什么相关的问题等；
- 技术团队：产品发布上线干系人确认，谁来发布版本，谁来验证版本发布是否完成，谁来对出现的意外情况负责，同时是否需要制定紧急应对方案等；
- 其他团队：其他团队如果需要了解系统的更新和内容可以与产品沟通，或者提前联系参与相关的培训即可；
3. 预案和整理，上线前的准备和上线后内容的整理。
产品上线过程存有不成功的风险，针对这种情况，要准备好相关的预案，比如：
- 发布失败怎么处理？
- 大量用户投诉该怎么办？
- 无法访问，导致业务受到影响要怎么办？
发布上线之后，还有这么几件事情需要抓紧去做整理，包括：
- 测试过程中，需求变更了，更新/补充需求文档；
- 针对本次版本未实现的需求、未解决bug的收集；
- 相关文档的整理归档，形成相关的资料库等；
b. 发布你的产品
产品发布环节主要是分为两个大类：一个是规划，一个是执行；规划其实在第一步的时候就讲到了，制定好完整的产品发布方案，有了方案就是有了规划，就可以对自己即将要做的事情进行统筹和管理。
执行则是实际作业中需要去坚决执行的操作，对于发布产品来说，产品经理要做的大概有以下内容：
- 制定好发布方案（前提条件）；
- 确认执行方案中的内容，如果有调整需要进行补充说明；
- 积极主动，跟进相关的进度；
这里以WMS的产品发布上线为例，讲解一下产品经理在发布产品的时候大概要做什么工作。
WMS版本发布上线职能图
WMS的产品使用者是仓库的人员，但是仓库人员往往并不在身边，需要由运营部代为了解系统的更新，所以和运营部沟通，将他们理解为用户。召开这种培训会议和产品版本上线更新的内容有关系，如果一个版本更新的内容较多，需要实际演示讲解才能让用户接受和理解，那么就需要召开这种培训会议；如果一个版本更新的内容较少，而且对基础流程和业务没有什么影响，那么可能只需要提前发邮件通知一下用户即可，无需召开会议。
召开培训会议之后，还需要对会议纪要进行记录和保管，以便公示给更多的人了解。而培训会议的内容可以直接演示，也可以用PPT配合演示，只需要能让受培训者快速知晓更新的内容即可。总结来说，WMS产品的发布，需要做以下几点：
- 确认是否要培训用户，如果要则召开培训会议，如果不要则直接邮件提前告知更新内容和要点；
- 将版本发布的时间，范围等报告出来，确认相关的干系人知晓此事；
- 将本次版本涉及到的更新和调整邮件的形式发送，如果之前进行了培训会议，则此更新和调整内容作为会议纪要一并发出；
- 提前通知开发、测试和运维同事准备相关的代码文件等，按制定的时间进行发布；
- 发布之后，及时通知测试同事进行验证，并且给出验证结果（一般没问题反馈就是没问题）；
其他系统的产品发布和WMS的也是大同小异，制定产品发布方案和计划是首要，其他的只是按流程办事罢了。
产品发布方案和计划主要可以理解为对上线发布做一个自查表清单，清单可以用Excel表的形式，每一次发布就是一个Sheet文件，然后可以截图记录在TAPD中进行归档。
WMS产品发布上线自查表
3、产品上线后
对于C端产品来说，产品上线之后一般会关注一些点击率，增长率还有成交率等等，但是对于B端产品，尤其是我们公司的产品来说，产品上线后的监控、验证，能做的其实并不多的。
如果需要对一些关键信息进行监控、收集及分析，则需要在上线前就制定相关的验收计划，直到上线之后就可以去验证计划是否达到了，否则没有规划和计划也无法做到什么有效的验收。
一般我们可能更多的是针对产品上线之后做一个用户访谈或者用户反馈。通过对几个典型用户的访谈，去了解上线了某个版本之后对Ta们工作的一些提升和改进有哪些，同时还有什么是不够的、还能继续优化。以此来与用户拉近关系，不仅能收集到一些有用的需求，同时还能增强用户对产品的好感，会让人觉得这是一个靠谱的产品经理做出来的靠谱的产品。
除了用户访谈之外，也可以多关注每周测试运维反馈的生产问题报告，看看上线之后，是否以前暴露的一些问题还会出现，同样的，测试运维的同事也可以经常性地做一些用户调查、访谈，因为Ta们也是对产品离得最近的人之一。
除了上述讲到关于产品迭代优化方面的内容，产品经理还要关注一些收尾的细节工作。
例如上线了某个新功能之后，操作手册是否有及时维护，背后的业务逻辑是否有文档记录，其中遗漏的点是否有记录然后规划到下一个迭代或者未来的需求池中，涉及到的改动和调整是否有及时广播和通知到位……
这些都是很琐碎但是却很重要的事情，因为产品从0到1的终点，并不是上线，真正来说，做产品是没有终点的，任何时候都处在过程中。
最后，我建议针对大版本的迭代上线之后，要让产品经理自己输出一个复盘记录，对其中的一些难点，收获，不足之处进行总结，然后与内部同事进行分享。这是快速提高自己产品能力的一个手段之一，同时还能让其他同事更加深入地了解到你所负责的产品是怎么样的，加强产品组内部沟通，也会让产品决策有更广、更全的依据。
复盘记录可以用文字，也可以用PPT，无论是总结能力，还是PPT能力，或者是演讲表达能力，都是需要在日常工作中进行积累的。
没有舞台，就给自己创造舞台；走的人多了，自然会有路；经历的项目多了，自然会成为一个好产品！
后记
这些内容是我之前在公司的WIKI中摘出来的，全部都是当时我自己在工作之余思考和沉淀下来的内容，大概过了一年之后再来看，有点感慨。
一年可以做成很多事，一年也可以做不成很多事。
很早的时候我对产品组管理充满斗志和热血，觉得克己复礼，以身作则就会带来很多积极或者很具有突破性的变革。但是现实似乎并没有想象中的轻松和自然，阻碍有很多，打击也会有很多，至于效果呢，也不能一厢情愿。
逐渐的我开始意识到，计划只是成功的负一楼，而执行也不过就是刚逃离底下看到点阳光，登顶是一次又一次的尝试和打磨，所以不会再为见到一点阳光就欣喜，上升一层就觉得快要触顶。
前路还有很长，晒出这些内容，只是对一年前的自己做一个回顾。现在回头看一下，还是很高兴，因为这条路似乎还没走歪，甚至也走得挺快的。
