人人都是产品经理——iamsujie

又到周五了，意味着大家又要开始憋周报了，从@纯银的一个段子开始——

公司有个技术牛人，某产品专员向他提单，牛人一看内容很扯，质问“你觉得这个需求有价值吗？”对方诚恳回答：“没价值，但是我总得写周报啊。”牛人想了一分钟，回答说好吧我帮你做，因为我也得写周报啊。

我想，看这个博客的人，基本上都要写周报吧，更有甚者估计要写日报，但多少人打心底里觉得写的周报没有意义？只是为了写而写？今天，不妨从两个方面，简单说说，如何让周报真正的有意义。

第一个话题：写什么内容。

这个万变不离其宗，其实和敏捷里的站立晨会是一样一样一样的。形式不重要，说清楚3件事即可。

本周做了什么：重点不在于做了什么，而是拿到了什么结果（有共识的）。举个例子，花了半天时间和谁谁开了个什么会不重要，重要的是会上做了什么决定，会后定了什么后续的行动方案。

下周要做什么：同样，重点在于希望拿到什么结果，推进什么事情。不要是“继续优化Q2的产品规划”这样虚的东西，而应该是“与某某老板讨论Q2产品规划，并达成共识，从而下下周可以启动某项目”。

碰到了什么问题：怎么去尝试解决，搞不定的需要什么资源，打算找谁，打算让老板或同事怎么帮你。

然后，针对你的工作内容，细化一下，比如分为“项目、日常需求、其他”几个模块，有的时候再加一点工作感悟，也挺好，比如我，就是从每周500字的感悟渐渐写出一本书的，：）

第二个话题：发给谁。

可能有人觉得这个没啥可讨论的，传统上，周报不就是汇报工作（说白点，方便老板汇总周报）么？发给自己的主管不就行了么，我觉得这是最傻的，这大大浪费了“写周报”这个及其费脑子的工作。

稍好一些，周报可以发给主管和团队同事，团队里的人互相了解都在做什么，可以便于工作展开。

更好的，周报应该发给主管、团队同事、下属、以及有干系的合作方（其他部门的人），并且酌情区分“To”和“CC”，这才是真正的信息流通，发挥最大价值。愿意把周报发给下属的主管是好主管，：）

这位说了，周报里有敏感的内容啊，不方便发这么多人……我说两句：第一，互联网的精神就是开放共享，再想想，你觉得敏感的内容，是不是真的敏感；第二，稍稍做点技术处理，很简单的，可以共享的内容发给所有人，实在敏感的内容，在邮件上再回复一下，补充给对应的收件人好了。

要不，改变从今天开始？

呵呵，又是大大的软文一篇，开始了啊~

各位帅哥美女，我是《人人都是产品经理》的作者苏杰，这份资料是我整理的产品经理的常用文档，也是书中提到的各种文档模板或实例，我会不断更新。

现有这几个下载链接，只有558k：新浪文档；探客网官方；可乐同学的Axure小站（给个小广告）；CSDN。

第一批14个，它们的名称及在书中出现的位置如下：

l 第2章提到的

n 人物角色（Persona）实例：2.1.2

n 用户访谈实例：2.2.1

n 调查问卷实例：2.2.2

n 单项需求卡片模板：2.2.5

n 商业需求文档（BRD）模板：2.4.1

n 简易需求管理模板：2.3&2.5

l 第3章提到的

n 项目组织结构模板：3.2

n 产品需求文档（PRD）模板：3.3.1

n 用例（UC）文档模板：3.3.1

n 项目日报周报模板：3.4

n 项目发布通知模板：3.4

l 第5章提到的

n 产品路标规划实例：5.3.1

n 会议记录模板：5.3.2

l 其他书中未出现的

n 个人日报周报模板

每一个文档本身，都会有一些说明，看了可以大致明白如何使用，更具体的说明，书里有最详细的讲解，所以也期待大家关注《人人都是产品经理》，豆瓣页面在此，预计4月20日左右开卖。

欢迎大家给我提需求，如下几种联系方式比较方便：

• 我的博客：http://iamsujie.com/

• 我的新浪围脖：http://t.sina.com.cn/iamsujie/

• 我的豆瓣：http://douban.com/people/iamsujie/

我基本每隔几个月就会整理一次团队的产品文档规范与模板，然后release一个非常轻量级的文档包，起个酷点的名字：PD_std_template_tool_kit.mmap，这次讲讲理好的mindmanager图：

====== 看不清猛击图片看大图 ======

Ø 需求管理类

n 用户调研模板，调研前、中、后都要做什么，调研问卷怎么设计。

n 功能列表极其管理方法，这里可以体会到团队协同工具的重要，我们用过office live的excel，比较简单。

n 产品的网站页面地图，这块让UE的同学帮忙这里更合适。

Ø 项目管理类

n 项目管理制度，原则性的东西，比如项目经理、开发经理、测试经理的权责利。

n 项目任务书，网上有很多模板，小项目可以灵活变通。

n 项目Kick Off的ppt，之前有说过这个话题。

n 项目组织结构，省时间的，以后每次填名字就可以了，没啥技术含量。

n 项目WBS，我用的是一个小软件“WBS Chart Pro”（奇怪我搜不到下载了，需要的可以问我要），只有几M，它做的图可以生成project文件，就是说项目计划也有了。（我不喜欢动不动就几百兆的软件，而对于几M就能实现大部分功能的小软件特别有好感，呵呵。）

n 项目日报，主要有今日要闻，明日看点，当前问题，所需支持，项目进展等几项。

n 项目发布通知，为了省时间而已。

Ø 流程管理类：小团队常用的有日常发布流程、紧急发布流程等。

Ø 商业需求类：BRD，参见4004。

Ø 产品需求类：PRD，参见3010。

Ø 需求规范类：

n 交互规范：控件规范，如列表的默认排序、列表中文字的对其方式，手头这个产品是“文本左对齐、时间居中、数字右对齐”；判断规则规范，包括字段的校验规范、系统反馈的规范等等。

n 视觉规范：整体的如页面大小、字体字号颜色编码。

n 文案规范：如语言风格、语法模板、常用操作的标准说法等。

Ø 日常工作类，暂时只整理了会议记录模板和日报周报模板。

另外还有很多文档，比如开发规范，会说一些代码的规矩，函数命名规则等等，PD接触的不多，我也太懂，就不扯了。

网上不少同行前辈讨论过产品文档、规范应该什么时候整理，我个人的感觉是产品1.0发布以后，2.0发布之前。一般互联网产品在1.0之前都是急行军，顾不上文档，而在做1.1、1.2的时候往往有一个设计工作的缓冲期（一方面是开发测试忙着应付扑面而来的线上故障、另一方面是PD需要收集反馈以确定下一步方向、团队也会做人员调整），所以这个时候做产品文档规范，总结第一代产品、第一代团队的工作，对提高后期的效率是最合适的。当然，这个工作也是应该采用迭代的方式进行的，无需也做不到一蹴而就。

今天看到一篇讲述产品设计中几种文档的文章（一个老外的blog，Michael on Product Management & Marketing），感觉很好，结合工作的实际整理一下。按照那篇文章的思路，从产品的抽象到具体主要产出的文档有BRD、MRD、PRD和FSD。

BRD：Business Requirements Document，商业需求文档。这是产品生命周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。

MRD：Market Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。

（iamsujie补：我们的模式下，上两种文档会合并成为BRD，参见“4004：资源战争与BRD”）

PRD：Product Requirements Document，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（参见下一篇：UC写作），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

FSD：Functional Specifications Document，功能详细说明。有一点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，比如表结构设计，要由架构师来编写了。

再往后，就到“详细设计”和编码了，就此打住。