书摘《人人都是产品经理》——4年产品经理的思维书4

UML：时序图、活动图及其他

时序图：sequence diagram描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间、多个角色之间

活动图：activity diagram比较接近流程图，描述各个动作如何引起系统变化，善于表达用到较多、分枝较多的情况。

协作图：collaboration diagram 表达不同对象之间是如何相互影响的，用的不多。

DEMO

纸面demo

线框图

视觉效果图

BUG级别

BUG状态流传图：

发布阶段的工作内容：发布审评——》预发布——》发布——》线上验证

反流发布、灰度发布：让一部分用户先用，然后手机反馈再决定大面积发布的时机。

*发布标准：

SQL已经经过DBA确认无问题（别问我DBA是什么，听着特别熟就是想不起来，跟数据应该有关），DBA确认后，邮件通知到测试人员，抄送给某经理。

搜索引擎通关相关人员确认无问题。

QC重的bug全部closed或deferred

因技术或时间原因造成无法修改的bug，有测试、需求、开发三方一起研究能否接受，如果有争议上报上级主管

测试过程中，如果因为技术造成的需求变动，PD需要第一时间发送邮件到全组，让所有人都知道，同时修改相应的UC

*发布过程：

测试人员在确认晚发布标准重的各项之后，会发出邮件通知统一发布，发布人员在没有收到通知钱，不能自行发布。

测试人员在发布后，将做一轮生产环境的回归测试，测试完成后发出一封邮件通知生产环境已验证完成，发布成功。之后收到该邮件后，发布相关成语才能撤离现场。

项目发布公告：小项目的公告会比较形式化，大项目的公告会写的煽情。

发布之后写项目小结：小结一下做这个项目的心得体会，碰到了那些问题原因是什么怎么解决如何避免，项目资源评估是否合理，收获了那些经验，如何提高准确度，根据数据监控的反馈分析出了什么结果，项目的商业目标是否达到等。

你们最关心的来了PD常用文档模板：

千金不换的sujie产品经理模板：  https://pan.baidu.com/s/1o6FOAt8  此处划重点！！！！

玩转office：

记事本：几句话几段用记事本

word：文档用word，打开word先设置页面、格式、样式、标题级别等

excel：结构化文档。也就是当你写word时总是要写123条的时候就要考虑是不是要专用excel了。基本功能条件格式、筛选、单元格有效性、单元格锁定、隐藏。一些基本函数应用可以让我们处理表格、简单统计、数据计算与可视化过程更加流畅，如果会VBA当然更好。（这个有点难度啊，会的都是大神。）EXCEL学习教程https://pan.baidu.com/s/1i5t3S7j      你看你们是不是很爱我

PPT：PPT是辅助工具更重要的是思路啊。PPT中应该减少文字，最好只有图片和超大的数字，但我们经常又要满足“受众拿到PPT就可以了解内容”的需求，非常幸运的是有个功能叫单击此处添加备注的地方，可以把所有想说的东西都附加在这里，在严实的时候双拼（怎么双屏http://jingyan.baidu.com/article/0a52e3f4195d0dbf62ed72bb.html），自己电脑显示演示者模式，防止忘词还不会干扰听众，同时没来的人看ppt也能看懂。很重要的一点是让每张PPT上想说的观点一条一条地出现，并且突出当前在讲的这一条，这样做是为了让受众的注意力聚焦，从而更好的理解我们想要传达的观点。

mindmap：用来整理思路，经常在某项任务的早期产生常见软件mindmanager，freemind，xmind等

那么多评审，可以省么？！

产品会议：必须有，决定做不做，做多少，实在太重要了方向错了太可怕。即使没有多个产品之间的资源争夺，同一个产品的不同需求也必须争夺，可以吧确定需求商业价值的需求讨论会，初评工作量等工作都放在一起作为产品会议。参与者至少包含产品团队、开发、测试、销售、服务等各个部门的头或者有话语权的接口人。

KICK OFF会议：最好开一下，鼓舞士气的，磨刀不误砍柴工，可以考虑与需求评审合并，安排在最开始的15分钟，因为他们的参加人员差不多。这个会议项目干系人都应该到场有的人可以在kick off结束后离开，不参加需求评审。

需求评审：如果kick off之后只做一次评审的话，那就是需求评审。具体的PRD/UC/DEMO评审，我们也很少分为三次，看项目情况，任意两个都有可能合并，甚至三个合并。

设计评审：表面看起来经常在时间紧的情况下省略，实际上是在开发人员实力很强的情况下省略，而在开发弱、新人多、业务不熟的团队，则必须进行设计评审，否则是给自己找不自在。

TC评审：仅次于需求评审，这是在项目KO以后第二重要的评审，敏捷方法很看重测试，实在要省也可以，那么PD会更辛苦一些，需要做更细致的验收测试。与设计评审类似，TC评审也属于纯技术评审，商业团队一般就不参加了。

功能评审：这其实也是必须的，而且需要项目干系人都参加，但之所以没有和需求评审同等重要是因为功能评审经常采取线下的方式进行，比如在邮件里告诉大家产品的测试环境地址，然后大家自己去看。对于重要的项目建议开一个产品演示会。

发布评审：可以让开发经理决定是否需要。