产品经理-一份标准需求文档的8个模块(14)
一份标准优秀的产品需求文档包括：
❑ 封面；
❑ 文档修订记录表；
❑ 目录；
❑ 引言；
❑ 产品概述：产品结构图
❑ 详细需求说明：产品逻辑图、功能与特性简述列表、交互/视觉设计、需求详细描述；
❑ 统计需求：指标定义、统计逻辑、数据报表；
❑ 客服文档：用户常见问题
需求详细说明
在完成产品概述之后，面对已经拆解到最末一级的各个功能点，我们需要进行详细的功能需求说明。
数据统计需求
数据是衡量一个产品需求效果的最佳指标，所以在产品需求文档中，我们需要明确该需求统计监控哪些指标，以便开发人员进行数据统计埋点。
层次清晰，先大后小
首先按照需求覆盖端（PC、H5、ANDROID、iOS）进行一级拆解，然后按照用户身份（未登录、登录（是会员、不是会员））进行二级拆解，这样就保证了在信息层级逐渐下沉的过程中信息的完整性。
在需求文档的功能描述环节，适当的搭配图片或表格可以起到“一图胜千言”的作用
一些常见的异常情况供大家参考。
❑ 网络错误：中断、无法联系、服务器繁忙。
❑ 产品兼容：新老版本兼容、跨操作系统兼容、国内国际版本兼容
❑ 按钮状态：正常状态、不可用状态、悬浮状态、按下状态、焦点状态。
❑ 极端情况：高频次访问、多用户访问、机器人挂机、多进程同时操作。
❑ 权限控制：管理员、超级管理员、普通用户、未登录用户。
❑ 后台配置：灰度测试、后台推送。
❑ 按钮状态：正常状态、不可用状态、悬浮状态、按下状态、焦点状态。
❑ 极端情况：高频次访问、多用户访问、机器人挂机、多进程同时操作。
❑ 权限控制：管理员、超级管理员、普通用户、未登录用户。
❑ 后台配置：灰度测试、后台推送。
理清用户及产品需求、撰写了需求文档、画好了交互图后，下一步就是研发的过程了。
在研发过程中，产品经理梳理的那么多需求，是怎么安排进一个一个版本的？
版本规划应该如何来设计？
互联网时代大家都说敏捷迭代，那什么是敏捷迭代？
和我们一般生活中看到的传统产品在研发过程中有什么不同？在敏捷迭代的过程中产品经理又担当一个什么角色？
瀑布模型
第一，解决了多人协作的问题，单一产品生产能聚集为之生产的人变多，使得几十，甚至成百上千的人们能够聚集在一起共同为一款产品的生产贡献劳力
第二，有了分工，不同的人在流水线上面有了明确的分工，每个人只负责生产环节的某一个部分，这样每个人都可以被培训成熟手的时间被大大缩短，也最大化地提升了生产效率；
第三，有了明确的流程和质量把控，每个环节丝丝相扣，甚至每个环节的时间也被严格要求，不超过1分钟甚至更短，而且拆分到每个环节，质量把控也变得更加容易和清晰。
瀑布模型是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈
随着市场变化趋势越来越强，而后在瀑布模型的基础上面演化出了迭代模型，敏捷迭代开发以用户的需求进化为核心
采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试
具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
互联网产品不是在产品研发前就被“设计”好的，而是在研发的过程中慢慢完善，甚至是在产品上线后根据用户的使用反馈不断成熟起来的
小步快跑，快速迭代”的迭代思维构
成了互联网产品研发的核心思维。这也是为什么我们看到很多互联网产品刚出来的时候会有Beta版本的编号，说明他们还在不断测试和完善中。
敏捷迭代的优势
敏捷迭代和传统研发模式相比，更适合互联网的原因是
1）速度更快：互联网的市场更讲究速度，敏捷迭代可以把特性拆小，把之前半年才能完成的产品提前到两三个月推出第一个测试版本，能够提
前抢占市场；
2）便于验证：互联网的用户更讲究体验，通过迭代可以更早地接触用户，通过用户使用中的反馈不断磨练改善，逐步推出更优的产品体验。
敏捷迭代的研发流程
研发团队的组织架构
在开始说清楚迭代流程之前我们先说下互联网研发团队的组织结构，因为一个研发团队的产品迭代流程和沟通方式往往和团队的组织架构息息相关
适用：规模较小，以技术为重点的内部项目，不适用于时间限制性强或对变化快速响应的项目
为什么职能型组织架构容易造成以下结果。
1）不能真正关注客户需求（“我们按照市场部提出的要求开发产品”）；
2）各人自扫门前雪（“你们的事情，而不是我们的事情”）
）签字审批手续繁杂，决策缓慢，没完没了地转来转去；
4）协调沟通困难，各执己见（每个部门都认为自己是正确的）
5）关注所谓的部门利益，而不是公司的整体表现（在部门中表现好的人不一定对产品或公司好）。
项目型组织架构
优点：项目经理全权负责，成员全职，发挥团队
精神，决策反应速度快，以市场/客户为导向。
缺点：资源配置重复，规章制度执行不一致，横向沟通少，员工职业发展存在困难
适用：包括多个相似项目的单位或组织以及长期的、大型的、重要的和复杂的项目，不适用于规模小的企业
从团队演进来讲，当是小团队且项目不多时，由于人手较少，一般采用职能型的团队结构，但当团队逐渐壮大，而项目分支也越来越多时
会改为第二种项目型组织架构以减少各团队间的沟通成本，提升项目速度。当然也有两者兼有的组合型架构，
如产品、研发这种相对专注的岗位使用项目型，而测试、设计这种可复用资源的岗位则采用职能型，以保证资源得到最大化利用
需求文档是用来提供需求信息的,方便代码工程师,业务逻辑的实现，具备一定的指导作用,做什么东西,都需要有依据,不能拍脑袋,做事,指哪,打哪,那肯定是不行的
所有成功的互联网公司,令人使用尖叫的产品,都有自己的一套研发流程
产品经理-关于需求文档详解（13）
2024-07-11
产品经理-一些交互设计原则和技巧（12）
2024-07-10
产品经理-交互设计动手实践(11)
2024-07-09
产品经理-需具备的能力- 辨别用户的真需求与伪需求（10）
2024-07-08
产品经理-的职业发展(9)
2024-07-07
(拓展人脉圈子)