各位大大中秋节快乐，我是在软件业工作的PM，
之前有分享过我跟伙伴们一起写的PM工作与职涯相关文章～
这次的分享是关于PM该如何撰写产品需求与规格文件，
这也算是我跟工程师合作上的一个痛（之前写太烂、工程师都懒得看），
好在跟我合作的工程师们人很好，给了我满多回馈，
在这几年工作中也得到一些心得，希望可以跟大家交流！
如何撰写产品需求与规格文件？问题、心法与实作小撇步！
有图有排版完整版：
http://pesc.pw/LQBAD
什么是产品需求文件？
我在【PM伙伴攻略】如何跟工程师合作？中曾经写到 PRD（Product Requirements Document 产品需求规划书）这个文件类型，有时也叫做产品规格书（Product/Feature Spec），更小型的功能修改则可能只是一张票（Ticket）。PRD 内容通常包含：
【目标＆问题】
- 产品目标、预期产出
- 问题、指标、假设
- 使用者分群＆使用情境
【解决方案】
- 使用者故事（User Story — As a … user, I want to …, so that …）
- 使用流程与设计（User Flow / Wireframe / Mockup，PM、设计师负责）
- 产品规格细节、系统逻辑、极端使用情境（PM、工程师、QA 负责）
【其他注意事项】
- 功能范畴（Phase 1, Phase 2 …）、功能相依性（Dependencies）
- 功能上线策略规划、市场沟通策略
- 未来扩充可能、后续规划（上线后的下一步是什么？）
- 其他参考资料：使用者研究、竞品研究、会议记录
每天写这些文件都快堆得比人还高，为何 PM 苦口婆心用心良苦归心似箭地产出详细而精美的文件，有时却会被诟病，甚至最让人困扰的，工程师不看文件、不照着规格开发？
问题：为什么！为什么工程师就是不能好好用心仔细地看看产品需求文件？
因为从他的角度，这份产品需求文件无法达成有效的沟通。
让我试着从工程师的角度来思考一下他们遇到的问题：
1. 文件太长，根本不知道重点在哪里。
这一段是写给我看的吗？怎么感觉是写给老板或 PM 主管看的？杂七杂八到底要我看哪部分？
2. 文件内的需求、规格细节写的不清楚。
这文件真的写完了吗？还是又要我通灵？发文不附图，此风不可长。
3. 文件总是都一直改、或没更新。
实在无法信任我看到的任何一个版本。敏捷起来，连我自己都会怕。
这些问题导致工程师觉得看了文件也没用、懒得看，不如直接抓 PM 本人讲个清楚，或是先照自己的想法做，等到测试时看 QA 或需求单位最后提什么问题再来修。这之中的来来回回不但造成时间与精神成本的浪费，也显示出文件本身并没有有效达成他的目标。
其实不只是在与工程师用文件沟通时会遇到这些问题，产品规划涉及很多不同的单位，例如商业端（客服、业务、老板）、设计师、工程师、QA、其他 PM 以及主管，我也遇过丢出文件后却没人回应、没人提意见、没人看的状况，可能的原因就是我写的内容没有正中要点，或是我根本选错沟通方法。与其用文件，很多时候当面沟通完再用文字记录下来会是更有效率的做法。（只用口头开需求也是会被电爆的，请自重！）
解法：先确认目的与对象，再来有目的的撰写
写产品文件就跟做产品一样（跟这世上的万事万物都一样），要先确认使用的对象是谁、我想要达成的目的是什么，了解他们到底想要/需要看什么后，再来设计这份文件的内容，有目的的写文件以确保观看者可以得到他想要的资讯，来达到实际而有效的沟通。
【目的】
・我为什么要写这份文件？
・我希望它达成的目标与结果是什么？
・这是一份主要文件、还是参考文件？
・若是主要文件，哪些参考可以直接附上，避免重工？
【对象】
・谁会看这份文件？
・他将如何使用这份文件？
・他预期在这份文件得到哪些资讯？
・他习惯的文件格式是什么样子？
回到上面那份落落长的 PRD 来看，对于工程师来说，了解目标、使用者研究、使用情境也许重要，但这些都是次要资讯，仅需要在专案一开始时确认没有问题就行；而最重要的其实是产品要如何修改、功能细节的规划，这些跟工程直接相关的实作细节。
举一个各司其职、效率极大化的例子，在产品需求文件中 PM（你、团队、主管）想了解价值（outcome）、QA 想直接看到产出（output）长怎样、工程师则需要知道实际要做哪些改动（changes），一份文件的确可以满足所有人“想看到相对应资讯”的需求，但单单一份统一的文件可能无法达成“有效率的传递资讯”的目标。
流程：在对的时间，用对的方式沟通对的内容
而尽管是跟同一个对象，可能会因为不同目的在不同的时间点沟通，这时沟通方式、文件的内容也会不太一样。以这个流程举例：
1. 确认产品目标、商业问题 / PM 主管、商业端团队
2. 讨论目标、问题、指标、假设 / PM 团队、设计师、资料团队、工程团队
3. 讨论使用情境、发想不同解法、确认解法 / PM 团队、设计师
4. 设计使用流程、功能接口、研究与测试 / PM、设计师
5. 确认使用流程、功能接口、规格细节 / PM、设计师、工程师
6. 回去修改，再来确认修改过后的 PRD / PM、设计师、工程师、QA
7. 讨论开发实作（切 Phase、切 Story、资源时程） / PM、工程师
8. 与商业端确认改动与上线规划 / PM 主管、商业端团队
9. 将以上所有讨论内容的最终结论写下，PRD 最终版本定案！
口头沟通还是很重要
以上每个阶段，主要都还是仰赖口头沟通（当面、视讯），再以不同阶段、不同完整度的 PRD 作为辅助文件。产品开发是团队合作，同一份 PRD 会随着团队的讨论而慢慢变完整，就算 PRD 最终版本已经定案（希望是真的 final 版本），在正式开发前、中、后，还是需要大量的口头沟通！
PRD 作为最完整的文件之一，最主要还是 PM 自己要看的，当要 brief 给工程师或其他成员时、当忘记某个讨论过的细节时、当要分享给其他团队作为参考时，它就会是个很棒的资料来源。
阶段性沟通完成后，持续调整文件类型与内容
当要开始实作时，在一开始用完整的 PRD 跟团队成员 brief 完产品需求与确认规格后，可以直接将拆分的 Stories 开到专案管理工具里面，每张 Ticket 只写上那个任务需要完成的工程实作细节、产品画面，并将 PRD 反作为参考资料，让工程师在开发的时候可以专心在实作上。
原先的 PRD 可能随着你们释出一些 Stories 、得到一些回馈后需要修改、变换方向，或甚至是建立一份新的 PRD 开新的需求，那也代表又进入一个新的阶段，文件类型和内容又需要重新调整了。
实作小撇步
1. 沟通前先说明目的并画重点
传递文件与沟通时，明确告诉对方目的、预期结果，并帮对方撷取出重点。不要期待他会把整篇 PRD 完整看完，很多人看到落落长的文件会想说晚点再看，然后就没有然后了。因地制宜、设身处地为对方着想，主动让他知道哪边是最重要的部分，其他则是次要的参考资料。
更清楚一点，文件中待确认的部分也可以用红色标记大大的 TBD（To Be Discussed）让对方一眼看出要讨论的部分！
2. 视觉化、图像化
图像永远比文字表达得更清楚，讨论时可以沟通细节，实作时确保所有人认知一致，附上流程图、Wireframe、Mockup 是基础中的基础，就算只是手画的都好！
3. 条列目录
最核心的问题是“我如何写一份架构逻辑完整的文件？”但是这部分会因人而异，PM 与工程师思考的顺序、逻辑、对每个段落的重要性看法不同，因此为了让事情更明朗，至少在比较大篇幅的文件中放个简单的目录吧！也别忘了用锚点超连结，让使用者可以一键到达他想看的部分。
大部分线上协作文件的软件都内建有这个功能（Google Doc, Confluence, Dropbox Paper），只要确保自己有设定对、使用者也会使用就行了！
4. 从看文件的使用者身上蒐集回馈
其实上述使用目录的建议，就是我在跟工程师讨论为何他觉得我写的文件很难看懂后，我们想出的其中一个修正方法。
举例来说，我写 PRD 的逻辑是按照我的思考顺序写下来，并把所有参考资料放在文件开头；但他在阅读 PRD 时认为应该要把最重要的、他需要知道的资讯放在最开头，随着重要程度递减，将参考资料放在文件最尾端。
修改写 PRD 的顺序对我来说并不理想，况且这份文件也会给其他人看，每个人肯定会有不同的看法，因此我们讨论了一些在不需要修改文件顺序与架构的情况下可以改善的解法：
- 条列目录 + 锚点超连结
- 用不同颜色的标题来区分不同目的的区块（例如：商业相关、使用者相关、工程实作）
- 传递文件给特定对象时，在文件中收合（隐藏）某些区块，使用者想看再自己打开
每个团队、每个工程师喜欢的工作方法不同，这也是为何我会在文章一开始提到，文件怎么写、格式怎么设定、要写多细，这些都是“看情况”。有些公司就是一个步骤一个步骤严谨的走下来，不会有太密集的讨论，有些公司则是随时都在找不同的人开会讨论、做新的决策，他们会需要的文件和沟通方式就绝对不同，因此从一起工作的伙伴身上得到回馈是最快的修正方式！
文件只是一个沟通的工具
说到底文件就只是一个沟通的工具——跟自己沟通、跟正在一起工作的团队沟通、跟未来不认识的交接同事沟通。
文件能作为良好沟通工具的原因，在于它具有稳定性与可传递性，在穿越时间（历经多个月的专案）与空间（跨国团队）的情况下，能够让所有人得到一致的讯息，如同英文所说的 ”on the same page”。
放到近代的话，线上文件工具不但可以让多人同时协作，也可以看到历史变更纪录，方便团队回去考察在过去时间点做的决策与变更，让整个沟通的过程能够轻易的摊在观看者面前，同时确保公司与团队能够有组织性的维护共同知识，持续做经验的累积与传承。
除此之外，我私心认为写文件也是一个与自己沟通的工具，在下笔的过程中更透彻地思考整个专案，大至目标、小至细节，反复雕琢进而让问题的形状更清晰。
所以说何时该写产品文件？要写多细？
既然是沟通的工具，就应该只在“使用文件沟通是最有效率”的情况下使用它。重点不在于文件，而在于它是否能让沟通更顺畅，别让文件的产出与维护成本超出了它所能带来的价值。
尽管这篇文章主要在分享 PRD 的实作，但广义来说，我认为所有为了沟通“产品”相关资讯而存在的文件，都算是产品文件。包含了：
- 产品路线图（Product Roadmap）
- 产品需求规划书（PRD）、产品规格（Product/Feature Spec）
- GitHub / JIRA / Trello Ticket
- 产品使用说明
- 产品会议记录
在修修改改了好多不同版本的 PRD 格式后，我发现其实也不用拘泥于格式（网络上可以查到的格式真是千奇百样），不用每次都像填表单般把每个字段空隙填满，只要能够达成有效沟通的，都会是一份好文件！
毕竟如果一张 JIRA Ticket 就可以讲完的事情，就用不着在 Confluence 写一篇落落长的需求文件。
PRD 是你的产出，但不是你的产品，产品上线后产生的影响力才是 PM 真正重要的工作，因此善用产品文件来说服利害关系者、跟实作者沟通细节，进而推动产品影响力才是真正重要的事！