产品日常工作规范之项目管理篇

一般来说以单独的系统作为一个项目，每个产品可能或多或少会接触两个以上的系统，也就是要同时处理多个项目，对多个项目进行管理。

项目管理的生命周期可以分为项目启动，项目规划，项目执行，项目监控和项目收尾。

从项目管理的生命周期入手，产品在项目启动的环节要注意需求的收集与分析，需要给出足够的理由和证据去调动资源开发某个需求，此处要注意一些特殊化的定制需求，有时候往往是这类看似可拒绝，又不可拒绝的需求总是会让团队陷入一些困境。尽量从一些行业通用标准和一些用户信息反馈去落实，该不该做，哪怕是未来可能会翻篇也要做的就在项目启动前面注明未来的改动，让大家提前有一些心理准备和缓冲。

项目规划这一块尽量按照敏捷的思想去实践，往往很多时候项目延期并不直接是产品的问题，但是良好的规划和用户故事的拆解，会让团队对项目的进度和计划有更细致和具象的了解，有利于让大家了解具体要工作的内容和要花费的时间。此处除了要求严格用TAPD实行敏捷迭代的要求之外，也推荐大家去看看WBS相关的内容。

WBS是指将项目产出物（或项目目标）逐层细分为更小、更易管理的子项目或项目要素，直到分解出的要素非常详尽，能够支持下一步的项目活动分析与定义为止的一种方法。

项目的执行和监控就是日常提到的一些产品跟进和信息补充，这一块比较容易出问题的就是需求文档或者描述的调整没有及时同步和更新，导致开发做了新的东西（私下沟通的）但是需求文档中还是旧的描述，到时候测试进行验收的时候容易出现一些矛盾。所以要么就及时修改需求文档的东西，要么就是联合开发和测试一起讲一下变化的东西是什么，当然我依然是建议需要记录相关的变化。

除此之外，项目的跟进还可以体现在“产品亲自验收”，“每日站会”，“及时更新操作手册等文档”，“及时汇报项目风险和难点”，“广播相关进度和内容”等等。

项目的收尾主要就是下面讲到的一些产品发布和上线后要做的东西，在这里如果继续讲有点重复的味道。所以主要就是关注几个词：

其实总结下来就是：回顾和记录。回顾就是复盘，记录就是翻出文档，继续完善文档。

由于公司采用敏捷开发的模式，产品版本的发布频率较常规的产品发布频率会高很多，但是由于B端业务的复杂性和关联性，建议“少发版本，多合迭代”。

一个迭代会有一些更新内容，可能重要也可能不太重要，但是一个迭代完成了之后都会形成一个提测版本交给测试，测试完成之后就可以对此迭代的需求做一个“已完成”的状态标识，但是却不一定要发正式生产版本。因为生产版本可能涉及或者影响的东西比较多，频繁上生产版本会耽误用户的使用，同时可能会造成一些配置或者数据的问题。

所以，我们合理地结合各方面因素，将几个迭代的内容或者诸多需求合并到一起然后再确认发布正式生产版本，其中的工作则可以概括为：制定发布方案。

制定发布方案并非是指临近要发版本了，然后去制定要怎么发，什么时间发这么简单，而是在需求收集设计过程中结合目前已经在开发的需求，综合考量去制定相关的计划。一般的，发布方案应该考虑或者包括以下内容：

1. 制定上线检查清单，主要是评估产品是否满足上线标准，以及是否有遗漏重要环节，包括以下内容 ：

2. 通知与协作，主要是通知和培训相关干系人，公布相关系统新功能和特性，减少沟通不畅带来的损失。

3. 预案和整理，上线前的准备和上线后内容的整理。

产品上线过程存有不成功的风险，针对这种情况，要准备好相关的预案，比如：

发布上线之后，还有这么几件事情需要抓紧去做整理，包括：

产品发布环节主要是分为两个大类：一个是规划，一个是执行；规划其实在第一步的时候就讲到了，制定好完整的产品发布方案，有了方案就是有了规划，就可以对自己即将要做的事情进行统筹和管理。

执行则是实际作业中需要去坚决执行的操作，对于发布产品来说，产品经理要做的大概有以下内容：

这里以WMS的产品发布上线为例，讲解一下产品经理在发布产品的时候大概要做什么工作。

WMS的产品使用者是仓库的人员，但是仓库人员往往并不在身边，需要由运营部代为了解系统的更新，所以和运营部沟通，将他们理解为用户。召开这种培训会议和产品版本上线更新的内容有关系，如果一个版本更新的内容较多，需要实际演示讲解才能让用户接受和理解，那么就需要召开这种培训会议；如果一个版本更新的内容较少，而且对基础流程和业务没有什么影响，那么可能只需要提前发邮件通知一下用户即可，无需召开会议。

召开培训会议之后，还需要对会议纪要进行记录和保管，以便公示给更多的人了解。而培训会议的内容可以直接演示，也可以用PPT配合演示，只需要能让受培训者快速知晓更新的内容即可。总结来说，WMS产品的发布，需要做以下几点：

其他系统的产品发布和WMS的也是大同小异，制定产品发布方案和计划是首要，其他的只是按流程办事罢了。

产品发布方案和计划主要可以理解为对上线发布做一个自查表清单，清单可以用Excel表的形式，每一次发布就是一个Sheet文件，然后可以截图记录在TAPD中进行归档。

对于C端产品来说，产品上线之后一般会关注一些点击率，增长率还有成交率等等，但是对于B端产品，尤其是我们公司的产品来说，产品上线后的监控、验证，能做的其实并不多的。

如果需要对一些关键信息进行监控、收集及分析，则需要在上线前就制定相关的验收计划，直到上线之后就可以去验证计划是否达到了，否则没有规划和计划也无法做到什么有效的验收。

一般我们可能更多的是针对产品上线之后做一个用户访谈或者用户反馈。通过对几个典型用户的访谈，去了解上线了某个版本之后对Ta们工作的一些提升和改进有哪些，同时还有什么是不够的、还能继续优化。以此来与用户拉近关系，不仅能收集到一些有用的需求，同时还能增强用户对产品的好感，会让人觉得这是一个靠谱的产品经理做出来的靠谱的产品。

除了用户访谈之外，也可以多关注每周测试运维反馈的生产问题报告，看看上线之后，是否以前暴露的一些问题还会出现，同样的，测试运维的同事也可以经常性地做一些用户调查、访谈，因为Ta们也是对产品离得最近的人之一。

除了上述讲到关于产品迭代优化方面的内容，产品经理还要关注一些收尾的细节工作。

例如上线了某个新功能之后，操作手册是否有及时维护，背后的业务逻辑是否有文档记录，其中遗漏的点是否有记录然后规划到下一个迭代或者未来的需求池中，涉及到的改动和调整是否有及时广播和通知到位……

这些都是很琐碎但是却很重要的事情，因为产品从0到1的终点，并不是上线，真正来说，做产品是没有终点的，任何时候都处在过程中。

最后，我建议针对大版本的迭代上线之后，要让产品经理自己输出一个复盘记录，对其中的一些难点，收获，不足之处进行总结，然后与内部同事进行分享。这是快速提高自己产品能力的一个手段之一，同时还能让其他同事更加深入地了解到你所负责的产品是怎么样的，加强产品组内部沟通，也会让产品决策有更广、更全的依据。

复盘记录可以用文字，也可以用PPT，无论是总结能力，还是PPT能力，或者是演讲表达能力，都是需要在日常工作中进行积累的。

没有舞台，就给自己创造舞台；走的人多了，自然会有路；经历的项目多了，自然会成为一个好产品！