|
▍言职用户 @Stove SaaS产品经理 · 拉勾网 经历了将近半年几乎不写文档的小团队，对这方面稍微有点感触。分几个阶段分别来说吧： 一、文档无说明 项目初期整个团队会一起梳理和确定基本的逻辑和架构（就算是被动的也会参与，毕竟是从无到有的阶段，大意不得），所以对文档的依赖性还比较小，产品基本只输出原型，有问题也只是具体的功能问题，遇到随时问就好。 而在产品上线后的一段时间内，提需求一般也只输出原型，然后当面讲解需求。 个人感觉在项目初期，这种方式更敏捷。 不过如果团队中的后端不够强势或话语权不够大的话，建议产品在梳理基本逻辑和架构的时候主动叫上研发，并反复向对方讲解需求和未来的规划。 二、无文档有说明 没有文档，但在原型旁做需求说明。 这种方式在App上还比较流行，但由于SaaS产品的复杂性远高于App，因此从产品角度来说： 1、文字太多，书写的体验并不好 2、对厘清思路的帮助较小 而对研发来说，后端更关注逻辑，原型 说明不如单纯文档来的简洁，前端更关注视觉效果，把原型换成设计稿，需求说明仅保留和前端相关的，这样可读性会比较高。 顺便说下，这种方式是最快被放弃的，但如果有朝一日做C端App的话，我还是会继续尝试。 三、用例式文档 为了测试，项目进程中也曾花了2天时间给QA写Word文档，当时的思路完全是用例式的： 用户XXX，系统XXX。 当时的感受是： 1、 用例式的文档确实能够帮助产品本身厘清思路，但流程上还是后置于需求整理，甚至画原型 2、对研发来说，并没有比传统Word好多少 我自己分析下来，大概有2个原因： 1、Word的仪式感比较强，一打开Word整个人就好像被附体了，特别严谨特别装 2、 用例式的文档毫无疑问是面向QA的，但对研发来说，4个字：不说人话 不过面向QA输出PRD毫无疑问是有价值的：需求的实现质量能够得到保证。 而面向QA的弊端则是——不说人话只是结果，根本原因是——研发根本不喜欢看PRD，PRD一长串，写的人自己估计都不太想看，更不用说惜时如金的研发了。 那怎么办呢？ 如果你在大公司，或者已经比较成熟的项目，那么请继续面向QA输出需求。这并不是不考虑研发哥哥们的心情，而是面向QA是防止扯皮保证质量的最优方案。 研发实在看不懂咋办？发挥产品汪的本色，跪着讲需求吧。 但如果你在小项目，那么我这有一个好方法——用Outliner工具输出需求。 四、 Outliner文档 这是我最近一段时间在尝试的PRD风格。
Outliner的首要优势是，它不仅能够帮助产品本身厘清思路，而且在流程上平行于需求整理，前置于画原型。如此的好处是能让需求方想清楚了再开始画原型，而不是画到一半才发现问题。 最近我在构思需求时首先打开的都是Outliner，写下目标和制约，再随手记下任何想到的需求点、风险点，颗粒度大小、规范等都无所谓，输出需求时再统一整理。 这几乎完全解决了产品侧的问题：PRD和需求整理、画原型脱节；花费大量时间死磕文档，拖慢项目进程。
Outliner的魅力不仅如此，由于本身强结构化的特质，它还能帮助你根据研发的思路整理需求。 我的方法是借鉴OPP（面向对象编程）和状态机，在输出需求的时候将模块/页面按照：权限、数据、能力、状态4个部分来写（这4个是最基础的，每个Feature还需要根据自己的特性和业务场景单独补充）。 相比于用例式的陈述句，结构化的方式更便于研发理解需求。 这背后体现了产品和研发思维的差异性，产品的思维是从目标向下推导，逐渐落地——需求对产品经理而言，只是实现目标的手段。 而研发的思维则是从最底层的权限、数据存储逐渐向上，以匹配目标（需求）——既然需求是目标，那么产品变更需求就相当于在变更目标了。 综上，如果产品在思考需求的时候能更多从研发角度出发，研发自然能更方便地理解、产出需求。 毕竟作为产品汪，讨各方开心是一项必备技能啊。 ▍言职用户 @张欣 产品经理·中国移动 1、为啥要做这个需求； 2、需求在什么场景下会发生； 3、满足此需求需要新增什么功能； 4、功能的交互流程，图文描述； 5、功能的业务流程，图文描述； 6、功能有没有特殊的约束规则，例如需要用户实名认证； 7、流程中的异常情况描述，例如网络不佳时是否有提示； 8、需求文档也分为很多种，新增功能类、优化类； 9、需求文档存在的目的是让前端、视觉、后台、测试都可以围绕此文档展开工作； 10、对于前端，你的交互流程要清楚，对页面元素要精准到字段长度； 11、对视觉，页面重点元素要标注，产品风格要定好、扁平、清新、喜庆、拟物，不可用高端大气等形容词； 12、对后台、业务流程、异常处理、风控规则要描述清楚； 尽量让开发团队减少对业务和交互的思考，要让他们专注于技术的逻辑与实现。 好的文档能减少团队的无效沟通，也能避免产品乱改需求的现象。 ▍言职用户 @冯治文 产品经理·nubia 1、目的：满足什么需求（重要等级9）； 2、目标：如何验收（重要等级5）； 3、用户场景：用户用起来是什么样的（重要等级8）； 4、详细描述：first、逻辑图（重要等级8.5）； 层级1→功能点拆分； 层级2→二级功能点； 层级3→约束条件； 5、非功能性要求、与其它模块的关联（重要等级6）； 另外，需求文档不是一成不变的，核心目的在于描述清楚一个需求，所以在不同场景下可以用文档、卡片、列表都ok，只要达到目的。 ▍以上内容由拉勾网 言职社区 用户原创出品，转载请注明作者及来源 © 2017 拉勾网保留所有权利 - END - 拉勾网言职社区旨在分享有价值的知识干货和职场经历，及时获取互联网最新动态，更深度的了解一家互联网公司。希望你可以留下自己的观点，得到有价值的交流。 查看更多精彩互联网职场问答，欢迎来拉勾网言职社区。 |
|
|
