笔者在某知名通信公司从事技术写作五年有余，经手的项目有四五个。曾经历项目扩张期间的各种酸甜苦辣，多少累积了些文档项目管理方面的经验。
接下来，我就和大家聊一聊文档项目管理的那些事儿。希望抛砖引玉，一起学习和交流，共同成长，将文档项目管理得越来越好！
你选项目还是项目选你？
乍一看，你会很奇怪，我们技术文档工程师（Technical Writer，TW）还有得挑吗？不是老大让我跟啥项目我就跟啥嘛？其实我刚进入公司的前几年，因为TW很少，项目也少，入职后分到哪个项目就跟哪个项目，然后就一直在那干着着。直到项目close或发生重大变化，否则换项目的情况几乎不可能，自己也从没想过换项目。
可实际上每个TW的工作背景，教育背景，还有专业优势都不同，理论上所适合的项目应该也有所不同。如何因材施工，是个值得思考的问题。
首先TW要清楚自己的特长和兴趣，也要主动和老板传达自己的想法。其次上司也要多了解TW，结合当前的项目情况，尽量让每个TW都能接手自己相对喜欢和擅长的产品和项目。比如说我，对代码还有技术细节不是很感冒也不擅长，更喜欢与用户交互的产品，觉得可以直接参与到产品设计提高终端用户体验可以给我带来极大的成就感。所以就不适合那种技术性很强的给系统集成人员和开发人员使用的后台产品。而有些TW，之前从事测试或与开发相关的工作，技术理解能力较强也对技术感兴趣，可能对那种复杂的后台产品更感兴趣。如此，大家各得其所，对个人和公司都是一件好事。
但也有些人会说，我们就是要缺什么补什么，做个全才，不要做专才。可是，亲爱的，在资源和精力有限的情况下，让每个员工做自己擅长的事情，并将自己的专长发挥到极致，不是更高效吗？而且不擅长某件事情的背后大都是因为不感兴趣。做自己不感兴趣的事情，自然事倍功半。而做自己擅长和感兴趣的事情，自然事半功倍，你说是这个理吗？
怎么控制项目进度和风险？
我想说，不管是大项目还是小项目，做一个清晰的项目计划非常必要，而且能起到事半功倍的效果。我所在的公司采用的是敏捷（Agile）开发模式，以迭代为开发周期。我会针对每个Release创建一个文档项目计划表，以迭代为顺序，把所有会影响文档的需求和User Story （US）或backlog按照迭代划分。然后在每个迭代的Planning Game结束后，和产品经理与Scrummaster开个15分钟左右的短会，确认下这个迭代中文档的Impact scope。Scope确认后，在项目计划表里清晰地显示它们会影响哪篇文档的哪个章节，相关的开发人员，开发进度，以及文档状态（同行评审，技术评审，编辑评审）。如此，整个文档项目计划就非常明了。
接下来，参加每天的站会，熟悉各个US的开发进度，迭代的每一周自己都要去过一下文档的进度，确定是否滞后，然后去和相关的开发人员沟通，尽快要输入，尽量做到在每个迭代结束时，文档进度与开发进度差不多。
如此，一个迭代一个迭代下来，你的文档进度一直在可控范围之类，自然就不会出现Delay的风险了。
怎么要文档输入？
你现在已经有个非常清晰的项目计划表，对开发进度和文档进度也了然于胸。接下来就是在开发结束时，赶紧找开发人员要一套环境，研究下设计文档（如果有的话）和任务说明，做好功课。然后就可以理直气壮地向开发人员要文档输入了。下面是TW向开发人员要Input的情景对话：
TW：亲，你的这个US开发是不是结束了？我现在要准备写文档了。我自己先做了些功课，对它的背景和功能有个大概的了解。现在主要想跟你确认下这个US或task做了哪些改动。比如：用户行为是不是有变化？对安装升级等是否有影响？是否加了新的配置？或者配置是否有变化？bala bala ......
开发人员1：哦，好，我现在就给你演示下。（然后就打开系统一边演示一边bala bala ......；或拿起笔和本子，一边连写带画一边bala bala ......）
TW：太谢谢了，非常清晰。我们现在来一起看下我们的文档项目计划表，我之前和产品经理（PO）有大概确定文档的范围，现在我们一起来确定它的细节吧。（然后打开计划表，和开发人员一条一条地讨论，并做好记录，两人协商好哪些内容TW可以直接开写，哪些还需要开发人员的书面输入。然后整个过程视US复杂度而定，历时30分钟左右。最终大家对文档的修改和时间点达成共识，愉快地结束对话）
但有时也会遇到一些难搞的开发人员，比如：
开发人员2：不好意思，最近很忙，没时间给你文档输入。
TW：额，我之前已经在你给我的环境下大概操作了下。也看了设计文档和任务描述。我对文档的改动已经有大概的想法。你只需确认下主要的改动，我们再一起明确下文档的范围就好。之后我就可以开写，到时遇到不确认的，再一并向您请教。我写好后，你再帮忙review下给下comments就好。不会耽误你多少时间的，大概只需要10分钟左右时间。（然后一脸真诚地望向他，一般都不会拒绝你的。然后是不是真的就10分钟，就呵呵了）
如何做到文档发布零风险？
要做到文档发布零风险，那一定要严格按照项目计划表进行，以防在软件发布的最后几天还要忙于更新文档。另外，就是要准备一个文档发布的check list，包括在哪个时间点，哪些东西要ready。以笔者的项目为例，文档最终是发布到一个公司对外的公共平台，release之前有些准备工作，比如发邮件给相关人员创建release文件夹，要upload权限等。下面提供一个checklist范例供大家参考：
以上便是我认为在技术文档项目管理中最重要的几点，简要总结如下：
选对适合且擅长的产品和项目
制定清晰的文档项目计划表
做好功课，高效沟通
严格执行发布的check list
希望文中的观点对大家有所启发和帮助，欢迎同行拍砖。
