前面3.2至3.4节，从项目kick off到小结，完整讲述了项目的过程。3.5节叫“山寨级项目管理”，是从互联网和软件项目自身的特点出发，讨论项目管理中的几个关键问题——文档管理、流程管理、敏捷方法。

---

这节题目叫“山寨级项目管理”，主要是因为互联网和软件项目和传统项目相比，没有系统的管理理论，没有成熟的文档与流程体系，甚至本身就不是一个完整的项目，一般没有采购、成本预算的事情。但只要牢记目标是为了把产品做好，作为产品经理来管项目，山寨没关系，工具不重要，“文档只是手段”，“流程也是手段”，“敏捷更是手段”。

文档只是手段

文档不是目的，知识更好做事的手段。作者先分享了自己几年来简历的PD常用文档规范，然后谈了各种文档模板的本质作用，接下来是文档的多人管理与版本管理，最后分享了对文档写作工具的体会。

建立自己的文档规范

PD常用的文档模板

上图就是本节内容的提纲了，其中的文档基本能覆盖PD日常的绝大多数工作，从BRD开始，按顺时针顺序介绍一下各个文档。

商业需求文档：很重要的BRD，第2章里已经讨论过，详见读后感7（https://www.jianshu.com/p/3b7ea6f63d70）。

产品需求文档：同样重要的PRD，前文已有详细阐述，详见读后感12（https://www.jianshu.com/p/d9cdfe80326f）。

需求规范类：

（1）PD做什么：对产品和团队的PD工作内容的一份总结，可以让新人快速了解自己的工作职责。

（2）用户体验规范：又细分为如下几个部分，这部分最好让负责用户体验的同事编写。

           交互规范：页面上各种控件的规范，如列表的默认排序、列表翻页空间的样式等；各种判断规则的规范，包括字段的校验规范、出错信息反馈的规范等。

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

            文案规范：如语言风格、语法模板、常用操作的标准说法等，最常见的问题是，一个产品中同时出现“新增”、“新建”、“创建”多种同义词。

（3）通用原则：待补充，大家可以看到这份文档也是需要不断优化的。

需求管理类：这部分内容第2章中都有涉及。

（1）用户调研：这份模板说明了典型的用户调研前、中、后都要做什么，调查问卷、用户访谈提纲怎么设计，有哪几块内容。

（2）产品需求列表（含需求管理流程）：产品需求列表的模板，需求管理文档的模板，需求状态变化的流程图等。

（3）产品信息架构：待补充，用来描述产品的页面或功能之间的关系，比如网站地图、导航结构等，可以和负责用户体验的同学一起制作。

流程管理类：只列出了小团队常用的。

（1）日常发布流程：在第3.3.2节的“再看需求的生老病死”中已经提到。

（2）变更事件流程：如紧急发布流程、需求变更流程、需求搭车流程等，本书不做详细讲述。

项目管理类：

（1）项目管理制度：原则性的东西，比如产品会议制度，项目经理、开发经理、测试经理的权责利，这里沿用了公司统一的制度。

（2）项目任务书：网上有很多模板，小项目可以灵活变通，用BRD代替。

（3）Kick Off的PPT：之前已经说过。

（4）项目组织结构：这个模板每次填几个名字就可以了，没啥技术含量。

（5）项目WBS（可生成进度）：作者用的一个叫“WBS Chart Pro”的小软件画的WBS图，可以直接生成Project文件，就是说项目计划也有了。

（6）项目日报周报：主要有今日/本周要闻、明日/下周看点、当前问题、所需支持、项目进展等几项，在第3.4节的“以终为始，项目小结”中给大家分享的本书项目周报，用的就是这个模板。

（7）项目发布预告与公告：大量的重复内容模板化，为了省时间而已。

日常工作类：

（1）会议记录：这份文档多少能逼着每次会议都产出一些内容，比如会议决议、遗留问题与行动方案等。

（2）个人日报周报：用于团队分享每个人的工作情况。

另外还有很多文档，比如编码规范，包含一些编写代码的规矩、函数命名规则等，对开发工作非常重要，但PD使用不多，也就不含在内。

文档规范是在为公司、为团队、为产品做，更是在为自己做。试想一下，把这份文档去除公司的烙印，融入自己的理解，随身带着走，今后不管在哪里工作，只要做的还是产品相关的事情，这份文档规范都是一笔独特的财富，也是自己的核心竞争力之一。

模板的本质作用

（1）让经常看同类文档的人提高效率：当开发工程师看惯一种UC文档以后，如果突然换成一种哪怕更好的写法，他们也会很不适应。

（2）让写文档的新人可以尽快上手：新人可以根据模板，快速写出和团队里“老人”差距不大的文档。

（3）让写作者不会漏考虑某些内容：比如PRD文档的整体说明部分，有7项内容，如果每次都从零开始写，难免漏掉一两项。

在一个长期合作的团队中（包括自己公司的团队和与其它公司合作组成的团队），方法的统一真的非常必要，注意，“统一”并没有强调要一定要用“某种格式”。

各种模板、规范并不是与生俱来的，在团队刚成立、产品刚成型的时候强推，或者在团队、产品都已经很成熟的时候弥补，都是不合适的。模板与规范应该在需要的时候自然生成，逐步从简单到全面，不断迭代优化，无须也做不到一蹴而就。最适合开始做这件事的时机，就是产品1.0版本发布，进入1.1、1.2版的升级阶段，但尚未开始研发2.0的时间当口；或者说创业团队开始膨胀，不断加入新人的阶段。这是因为1.0发布之前常常是急行军，顾不上文档之类的事情；刚发布后的一段日子团队会有一个休整期，PD收集反馈以确定下一步方向；开发和测试的同学也要为扑面而来的线上故障忙一阵子；团队人员也会做相应的调整。所以这时候，我们应该总结第一代产品、第一代团队的得失，取精华去糟粕；并把优良传统传递下去，提高今后的效率，而模板和规范是很实用的形式。

文档版本管理

产生文档版本管理的本质需求是多人合作，协同办公。

作者谈了他的团队开始进行文档版本管理的经历，从Windows系统的共享文件夹（问题：有人打开文档的时候，其他人就无法编辑了）、Google Docs（问题：用惯了微软的Office，Google的总觉得不顺手）、微软的Office live（问题：网速慢），到SVN（对权限的控制比较精细，有几次保密项目用得挺顺）、VSS（只在和微软合作的项目中用过，感觉更复杂一点），后面又尝试Wiki，Wiki主要有两种方式，一种是把任务做比较精细的切割，每个PD各自维护自己负责的文档并保持最新，上传到Wiki汇总整理，如有多人共同编辑的文档，养成随时去Wiki下载、及时上传最新版的习惯；另一种就更先进了，完全抛弃了Word、Excel等软件，直接把常见的PRD、产品需求列表等写在Wiki上，完美解决了多人合作的问题，团队其他成员直接上Wiki阅读随时看到的都是最新的版本。此外，Wiki的优势还在于可以有一份“随时更新的整个产品的PRD”，基于产品的PRD把文档像代码一样管理起来，Wiki可以直接在网页上编写，而且可以采用类似SVN使用的版本管理模式，项目启动后先把要更新的需求描述从产品PRD里分离出来，项目完成后再将最新需求并入整个产品的PRD中，而且Wiki里做超链接也非常方便，可以在各个功能的说明之间来回跳转。

这些版本管理方法，本质都是把“版本更新通知”的任务从文档维护者手中分散到每个人的手中，并通过相应的工具来降低这个过程的成本，不过工具总是不能完全解决问题，所以团队成员的积极主动也是此机制顺利运行的重要因素。

最后建议大家都养成用版本号管理文档的好习惯，并分享了他的命名规则：第一次给别人看是0.5，以后每次自己的修改，改小数点后第二位，比如到0.51、0.52，有过集体讨论后的较大修改，会改小数点后第一位，比如变成0.6，直到第一次正式对外发布，改为1.0。

聊聊更常用的office

其实上面说了那么多，我们能玩转Office就足够了。

Word：做结构稍微复杂点的文档时才用，简单的几段话一般用记事本搞定，打开Word绝对不是一开始就码字，而是要先设置一堆东西，比如页面、格式、样式、标题级别等，充分利用Word的自动功能。

Excel：在写结构化文档的时候很好用，当你用Word写作时发现老是写1、2、3……条的时候，就要考虑是不是应该转用Excel了。它的几个基本功能：条件格式、筛选、单元格有效性、单元格锁定、隐藏，可以让你的表格看起来更专业。一些基本函数的应用，可以让我们处理表格、简单统计、数据计算与可视化的过程更加流畅，如果会VBA更好。

PowerPoint：PPT只能是演示者的辅助工具，更重要的是思路。PPT中应该尽量减少文字，最好只有图片和超大的数字，所有想说的东西都附加在备注里，演示的时候用“演示者模式”。另外注意，让每张PPT上想说的观点一条一条地出现，并且突出当前在讲的这一条，这样做是为了让受众的注意力聚焦，从而更好地理解我们想传达的观点。

以上是Office三步曲，又是一次“字→表→图”的进化，越往后越高级，平时我们做文档的时候也多想想，尽量用高级的工具，让读者看着更轻松。顺便提一下另一种平时经常写的文档——Mindmap，思维导图，它用来整理思路特别合适，经常在某项任务的早期产生，常见的生成软件有MindManager、FreeMind、XMind等。

下面三款软件就稍稍专业一点。

Visio：这个真的很强大，绝大多数能想到的图，Visio都能画。刚提到的思维导图；业务逻辑图；产品Demo（当然专业点比较流行用Axure）；简单的UML图，如用例图、活动图、时序图；团队组织结构；项目管理的甘特图；甚至家里装修布置都可以用。

OutLook：当邮件多到必须选择看一部分，无视另一部分的时候，OutLook才能发挥真正的作用。对于能够每封邮件必看的人，其实E-mail并没有达到需要管理的程度。不过，创建自己的收件夹结构、邮件规则、邮件标记、会议邀请几点真的有必要好好研究一下，其对提高工作效率很有用。

Project：开发经理和测试经理在安排详细的开发计划和测试计划时用得更多一些。Project对于复杂项目的安排，特别是牵扯到超多任务、多种资源，互相之间又有复杂的依赖关系时，非常实用的。

Office的其他产品，如有不少人用OneNote作自己的时间管理工具；Access可以当作简单的数据库管理工具（在数据量大到Excel打不开的时候很管用）；另外还有Publisher、Infopath等，适合一些比较专业的应用。