这是Kevin的第 803 篇原创，
持续日更，做产品经理的创业斜杠青年。
一个ideal到最小化产品的实现落地过程中，我们喜欢叫做MVP版本产品。这个最小化产品实现中，前期的投入和预算总是非常谨慎的。所以起初要么是创业团队，要么是一个大厂下的小项目组。
市面上的小团队比不上大厂的项目组，在产品经理、开发、运营、测试人员资源数量、和职位等级上都不如大厂。
在大厂里，存在小项目是团队成员“兼职”方式加入，比如本身处于在A业务线，但却临时去支援某个项目。
和创业一样，在大厂的小团队里也面临着生死攸关的问题，但获得的风险也低许多。比如项目迟迟没有达到预期指标，项目就会下架直接原地解散，但这创业的小团队来说，这样的损失成本可谓是最低的。
当然了，如果成功了，所获的收益也是比不上创业团队的。
因为这类风险，小团队里每个人工作就有点特别了，基本上会身兼数职。比如产品经理还上要能够搞定商务、市场，下要搞定产品功能需求调研、同时还要扮演测试角色助力产品上线。
小团队在技术架构的选型、和研发流程上都和成熟产品十分不同。比如在架构设计上是选择快速的单应用、微服务、还是选择成本高的分布式服务？
小团队宁可选择单应用实现业务，后期重构，也不会早期做复杂的架构设计和投入。
对于一个产品经理来说，市面上所传播的各种需求文档规范不尽其数，但在工作一定要要按某一个模版来吗？
实际上不是的，同样需求文档也不是越复杂越好。
比如对于一个产品经理，可能一份标准的需求文档是下面这样
登录注册的需求文档
上面这个模版，包含了该页面的测试用例、交互、前置条件、后置条件、字段规范，但实际上这类PRD文档完成时间需要非常长的。对于每一个需求都这样，那产品经理估计有加不完的班了。
但或者至少也有这样的
简单的需求描述
对于小团队，速度、和快速验证是第一使命。产品经理的需求文档是可以更加应该在这小团队里简化的。上面2种文档是极其笨拙的，所需要的范围、撰写成本都高。
软件类互联网产品，小团队往往就是一个产品经理、前端开发、后端开发、UI设计师构成，如果还要再继续精简，那就是一个产品经理、一个后端开发、一个前端开发即可。
团队虽小，但是要做的事情却一个不能差，我们可以罗列出每个人会牵涉到的工作职能。
成员分工
麻雀虽小，五脏齐全。
在团队成员每个人都在多线程的工作状态下，产品经理显然要选择最简易的需求文档撰写方式，既可以减少需求输出时间、还能够达到快速研发的目的。
这种方式有一个前置条件：需要有至少3年以上的工作经验产品经理才能胜任
理由很简单：越是简单的需求文档撰写，就越需要只关注重要的部分；而不是花时间在其他无用的需求上。
简易需求文档撰写模版
我建议小团队（10人以内的研发团队），需求文档用简易方法撰写，注意下面模版不是以文档的结构开始的，而是列举了文档的必要部分
1.前置条件说明
说明了当前操作是需要依靠前置条件的，比如在Pmtalk下的活动报名H5页面，需要用户的账户完成注册，在微信授权登录-手机号绑定-信息填写后才能选择支付。
前置条件是非常重要的，比如IOSapp是否能提供游客身份、以及用户体系分层都是前置条件最常见描述的。
2.字段类型长度
字段类型长度其实需求文档出现的频率最高的，因为每个页面都会有字段。人数、时间、价格、产品名称、文章标题等，都需要一个规范定义。
3.计算规则
计算规则并不是业务逻辑，比如在下面的阿拉丁小程序榜单里涉及到了应用榜单排名。背后就是对应的算法规则
小程序排名
小程序排名计算规则
当然这类计算规则越到后期肯定是希望系统来完成，人工的参与度降低。所以在后面也会有对应的AI算法、数据修正。但在早期产品经理必须说明清楚
4.文案说明
文案并不是等于内容运营，而是指的是对应产品的按钮、页面、其他样式下的文案。尤其是做微信生态下的产品类型，这类文案和转化率、访问量、传播数据直接相关。
比如微信小程序的分享
比如H5的分享提示文案
3.图片尺寸和大小
图片无论是由后台上传还是前端展示，都需要给出对应的尺寸说明，否则就会造成用户阅读变形，体验极差。
当然还有简单粗暴的方法交给系统进行对应固定尺寸的裁剪和处理。
同样对视频、其他类型的文件也要说在需求文档中给出对应的格式、尺寸、大小，方便在系统进行存储、同时提供给用户展示。
这类一般需要有经验的前端开发或UI设计师进行问题处理，否则产品经理自己拍脑袋给出的尺寸很容易不适用。
4.操作交互
交互说明要区分终端设备和产品形态2个纬度。
比如终端设备可以分为PC端、移动端、还有穿戴设备等领域
在产品形态上可以分为客户端、小程序、web、H5形式类型。
上面小程序的hover、loading加载交互，提升了用户体验。
交互说明既要建立在终端设备上、还要建立在产品形态上。
比如在PMTalk里，我们最常在需求文档描述的是按钮的点击、条件判断2类状态样式。
当然了，如果团队里有资深的前端、客户端开发工程师，这类交互的描述即使没有，也能够带来非常细腻的用户体验。
毕竟做的多了，自然就知道好的产品需要什么。
5.需求背景
需求背景是为了同步给对应上下游同事，告诉当前需求的作用。不能简单认为给任务他们就应该做，让团队得参与感、荣誉感也是十分重要的。所以搞清楚需求背景，让大家清楚现在的问题和优先级
为什么做，当前需求解决了什么问题，预计阶段规划
6.版本号&更新时间
更新时间也是需求文档极为重要的一环节，版本号还是同理，表明了当前文档的有效性。在文档中写明需求更新时间，同时如果是线下文档还要标明文档的版本里
7.业务逻辑图
业务逻辑图是为了讲述需求背后的业务逻辑，只有团队成员清楚了业务逻辑，才能着手进行开发。毕竟需求文档里的文档描述，是不能保证100%描述齐全，同时还存在阅读者可能没有仔细看完。有时候还因为文档的排版问题，开发或设计直接遗漏了某部分需求，导致功能缺失。
业务逻辑
业务逻辑既可以让系统开发中保证串起来。
同时团队成员还能明确知道当前需求的定位。业务逻辑图可以用时序图、泳道图、UML图等表示。但要想实现简单需求文档的实现，最快的方法还是用时序图。
8.词汇表
和文案不同，词汇表收集了通用的功能名称、字段命名。比如PMTalk在早期有签约作者、专栏作者，但实际上背后是一个逻辑。所以为了避免~混淆，就统一更改为专栏作者。
好，今天的分享就在这。我的微信是574319420，欢迎添加我的微信进行交流
网友评论