文档编号：ZD-190507-RMJC（1）
目录
Made by Miles.R
一、前言
本文档的编写主要用于对产品专员/助理及产品工作相关小伙伴入门时，对产品经理岗位进行了解，并牢记岗位相关背景、职责及技巧，较快上手相关工作，早日成为一名优秀的产品经理。
二、基础认识
1. 关于产品经理
产品经理(Product Manager)是一个特别宽泛的词汇，在不同的行业，产品经理的指代意义完全不同。比如旅游行业，产品经理往往指的是负责开发旅游线路。而在金融行业，产品经理的职能通常都是负责设计理财产品和投资类项目。
产品经理在互联网/IT行业，是一类人群的统称，细分下来，有所谓的：后台产品经理、数据产品经理、商业产品经理等不同领域，而且各个领域有着不同的侧重点与工作内容。主要是负责管理、规划、设计乃至于负责实施工作的一个岗位。
△ 产品经理站在商业、技术和用户体验三者的交点，发现有价值的、可用的、可行的产品
2. 认识岗位工作
中国传统的产品经理的工作情景是这样的：
• 没完没了的开会，根据会议中得出的需求开始制作方案
• 画流程图、画原型、写文档，方案完成后开评审会
• 和项目组的人侃大山，定下方案就开始项目沟通跟进
• 最终测试验收完成上线
真正有价值的产品经理应该是这样的：
1) 不做需求的执行者，而是需求的制定者。如果你现在只是被动接受需求，而不是主动提出需求，那么这就是差距。
2) 为项目负责，确保做的事情有意义，是正确的。项目做成怎么样、要做到什么样的程度、怎么样做才有效果都是产品经理要决定的。
3) 帮助项目取得成功。光做出一个项目还不行，你还要确保这个项目是成功的，成功的定义可以是你的项目广为所知、你的项目赚了很多钱、你的项目改变了人们的生活方式等等。
3. 你的协作团队
Made by Miles.R
三、工作内容
（一）基本流程
主要流程包含以下关键环节：
1. 需求预受理：需求采集、调研分析、整理汇总并归档需求池
2. 项目立项：制定项目方案、评估风险及可执行性、进行需求评审会议
3. 产品方案设计：原型制作、输出需求说明、进行产品方案评审会议
4. 产品研发：开发、测试
5. 项目上线：验收、部署上线
（二）详细流程
1) 产品团队通过向需求方采集及沟通业务需求，记录需求后整理汇总讨论分析，期间着重探讨业务需求的合理性、完整性和前瞻性，充分考虑各种流程、各个环节以及异常流程的处理，并保证正确理解需求。
2) 产品团队向需求方反馈预受理结果，受理结果包括转为正式受理和拒绝受理。拒绝受理的原因可能会很多，上边提到的需求受理原则是考虑的主要方面，拒绝受理必须提供原因，必要时可与需求方沟通改进业务需求以达到正式受理的结果。
1) 正式受理后，开始执行调研报告、数据报告等。早期需求分析，需要保证需求点是清晰的、明确的、有意义的、可测量的，并且存在技术可实现性，同时符合市场运作要求。
2) 需求分析后，调研人进行需求及评估文档的编写归档，文档需要反馈用户调研的结果报告及需求模型，以供技术评审讨论使用。
3) 邀请主要研发人员参与需求分析，初建立需求与技术实现之间的联系，确认需求的可实施性和难易程度。主要与研发人员确认需求中重要部分的可执行性，包括影响因素、实现关键因素、时间节点等，保证技术实现可在需求方预定的发布时间内研发完成并上线，避免对项目进度及需求方满意度的影响。
4) 如果确认技术可实施性，再组织产品会议讨论并输出解决需求的初步思路方案。
5) 邀请需求方进行初案审核，具体验证每一个需求的定义、实现方式等，保证方案每一点都经过需求方「批准的」。
6) 产品团队实时跟踪需求方需求变动，并对每次变更及时进行沟通确认。并反复上述规范流程，直到需求方案最终确认。
• 需求方案确认后，由我方指导需求方填写并提交项目立项说明书，最终由全部负责人签名确认工作任务后，项目方可启动。
• 项目立项说明书（或业务需求单）主要体现需求点可执行性、业务需求详细说明等，可附带附件、附图、附表等文档，需求描述的粒度应尽量细小，并说明业务需求的重要程度和紧急程度。
• 与需求方明确未提出的业务需求，在我方项目启动前可以提出需求补充，若已启动项目开发执行，后续产生的一切需求变动，可能导致的时间、人工等成本是随之变动，届时酌情商讨需求变动的具体执行方案，或纳入下一版本执行。
1) 根据需求方案，从需求实现的角度将业务需求拆分成系统功能点进行分析，并设计产品框架。（建议先与需求方沟通确认基础产品框架）
2) 制作并输出原型图（线框图），并与需求方沟通确认原型设计稿，根据立项说明书/业务需求单检查确保产品设计已对需求文档的所有需求都进行了设计。（可将需求点标记为“已设计”状态，方便需求设计管理）
3) 协调UI进行界面设计，并与需求方沟通确认界面设计稿，保证所有交互逻辑都是经过需求方「批准的」。
4) 撰写需求研发说明（产品设计说明），根据产品功能点、界面设计和逻辑实现，撰写研发说明，帮助研发人员更好的理解和执行所有工作细节。（文档形式自定）
• 根据原型图/界面图/设计说明，评审业务逻辑、交互逻辑等产品细节，提出异议并讨论解决方案，根据修改意见进行方案细节优化修订。
• 如遇重大逻辑问题驳回，则返工与需求方重新沟通讨论产品设计方案，并重新修订产品设计方案，重新制作输出相关需求设计说明等。
• 评审通过后，产品团队将所有需求文档提交研发团队，由研发团队进行任务拆分指派，确定相关负责人，并由各负责人对后续研发工作负责，包括统筹规划、协调沟通等。
• 与研发团队沟通并制定“功能计划”、“时间进度计划”等，其中包括开发、测试、上线的工作内容，项目计划要与需求方达成共识并签批同意执行。
• 研发团队要严格按照计划和需求文档进行研发工作，在出现问题时及时与产品团队沟通。
• 测试团队同时编写测试用例，并对存在疑问的地方及时与产品团队沟通确认。
• 完成后将每一个已研发完成的任务标记为“已完成”状态。
• 产品团队审核测试团队提交的测试用例，保证已满足所有需求场景并符合产品设计方案。
• 测试团队（质量保证组）测试产品研发工作并报告结果。
• 测试合格通过后将每一个需求点标记为“测试通过”状态。
• 当完成内部测试和用户测试并保证结果无误后，提供用户公开测试版本以供核收需求结果，核收无误后与需求方确认上线时间。
• 需求上线由我方运维人员统一部署到实际生产线，工作完成后通知产品团队和需求方最终验收，并由运维人员监控服务器稳定器，测试人员同时进行生产线最后检测。
• 上线前由产品团队编写好《产品使用说明手册》以供需求方学习使用。
• 必要时，由我方产品团队为需求方讲解项目实现情况和产品操作流程，具体视需求方要求，但不负责对需求方的客户进行培训等后续工作。
四、其他指导
（一）业务相关
任何业务需求都必须了解其业务出发点，特别在需求方跳过业务背景的描述，直接提出功能点时，尤其需要追溯根源诉求。通过了解业务背景，可以优化需求实现方式，甚至有可能改变功能点。在需求文档中可通过增加备注或描述业务背景章节帮助需求阅读人员更深入了解需求的产生过程。
需求方往往从局部角度提出需求，该需求可能没有联系其他模块进行推敲，甚至会有自相矛盾、漏洞百出的现象，我们在受理需求时可先通过询问问题来了解该需求是否准确、清晰，是否与其他功能点和主题有冲突等，如果需求方仍存在模棱两可的现象而导致无法清楚地阐述需求，我们可以不予受理。
• 重复现象：有些需求可能以前提出过，只是尚未解决，或者已经被否决，总之是重复需求，对于该类重复需求，可研究原有需求与新需求是否有差异，如果确认重复则不予受理。
• 杂糅现象：有些需求中包含了多个子需求，其中的某些子需求在其他需求中已经包括，即需求间存在交叉现象，这种情况下应梳理子需求，确保没有杂糅现象。
需求提出者有时可能只代表个人意见或一个小团队的意见，或者提出者可能并不是业务主管部门，因此业务需求的提出必须首先在该业务部门内部有权限人员得到认可后才能代表整个部门意见，否则为无效需求。
有些业务需求的提出可能涉及其他部门的业务操作流程，如果该需求的提出没有征得相关部门的同意，则在后期实现过程中会遇到阻碍，导致该需求无效，因此如果涉及多部门的需求，需求提出者应与其他部门沟通，在合理的解决方案下征得他们同意。
有些业务需求的提出是为了解决一些特殊情况的发生，即小概率事件，但该需求的实现却需要投入很大的工作量，该类需求可征求业务主管部门意见，必要时可让业务部门出具小概率事件发生频率报表，从投入产出比的角度谨慎受理需求。
（二）需求相关
针对原有需求中尚未完善的规则、表单、流程等进一步维护需求，此类维护不是需求变更，而是在前期需求分析过程中，需要等待业务部门提供的资料进行完善后，才能明确需求方案。这种情况下，应在需求研发进程中，与各方人员明确提出存在的地方，并尽快维护和更新需求方案。
在评审后的需求如果有变动，如果确认接受该变更，则应根据最新的需求要求重新修订研发说明，并记录变更历史。需求变更必须有一定的流程，并征得业务部门和技术部门的同意。关于需求变更，必须明确几个方面：变更原因、变更程度、变更解决方案。
• 因我方技术等原因发生滞后进度时，研发团队及时向产品团队提出，产品团队根据情况，制定解决方案及可行性计划，并向需求方提出需求变更申请，经需求方审批同意后，完成需求计划变更并同步文档更新。
• 因需求方在当期业务需求范围之外发生需求内容强制变更时，可通过向我方提出需求变更说明，详细填写项目问题、需求变更内容等信息，并由我方评估后，协商沟通项目时间及人工成本影响。双方一致通过后，由产品团队即时调整项目工作及同步文档更新。
• 明确双方提出业务需求变更时，应说明业务需求的重要程度和紧急程度。若为重大变化，则需要最高领导审批决定。
• 新增的需求必须是有效的、经过分析的并且划分了优先级，更新并签批需求确认书，在项目计划和产品交付期间反映需求变更状态，该需求的状态是“已批准”。
• 删除、放弃需求，需更新并签批需求确认书，并在项目计划和产品交付期间反映需求变更状态
• 该需求的状态保持为“已批准”，并在项目计划和产品交付期间反映需求延迟状态。
（三）项目相关
业务需求部门所需业务功能对整体业务系统影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。
• 非常重要：需求实现对整体业务系统影响非常大，如该需求为关键流程的关键环节说明等。
• 重要：需求实现对整体业务系统影响大。
• 一般：需求实现对整体业务系统影响一般，如页面显示文字、字体、颜色等。
可分为非常紧急、紧急和一般三个级别，非常紧急为最高级别。
• 非常紧急：关键业务流程不能被正确执行、且无可替代措施。
• 紧急：业务流程不能被正确执行，但存在可替代措施或方法。
• 一般：不会对业务流程存在较大影响。
有些需求的实现依赖于另一需求的实现情况，即业务需求是有顺序、按步骤进行的，在这种情况下我们建议需求可分期完成，如果在一期尚未完成的情况下就提出新需求，可称为“跳跃性需求”，此类需求我们建议等基础需求实现后再完善。
系统建设需制度先行，适当放宽要求也需制度并行，有些需求的提出是先行于制度，该类需求实现后的问题在于没有配套制度或岗位作为运行的保障，可能导致系统与制度脱节，反而影响业务的发展。在制度并行的情况下，需求提出者需给出制度下发的计划表，才能保证该需求的有效性。
不论是新需求还是需求变更，如果涉及层面比较广，可能影响到系统的上线时间，需谨慎受理，必须征得领导意见，给出可行的方案供领导决策选择，一般方案有三种：
Made by Miles.R
研发中心对业务需求以时间为基线实行版本化，并统一规范管理：
1) 定义文档命名、文档编号及版本号信息：
• 统一文档命名格式：日期+文档名+版本号，例190507产品设计研发说明V1；
• 统一文档编号格式：类型-日期-文档名缩写（版本数字），例ZD-190507-GZXX（1）；
• 统一文档版本号格式：V1、V2、V3…V10…V20，以此类推。
2) 定义软件系统版本号：
• 统一软件系统版本号格式：产品名_主版本号.次版本号.修订号.版本日期_希腊字母版本号，例iShuidi_1.0.0.190507_beta；
• 主版本号：当你做了不兼容的 API 修改；
• 次版本号：当你做了向下兼容的功能性新增；
• 修订号：当你做了向下兼容的问题修正；
• 希腊字母版本号：①Alpha版，Bug较多，需要继续修改；②Beta版，已经消除了严重的错误，存在部分缺陷，需要测试消除Bug；③RC版，不存在导致错误的Bug，与正式版相差无几；④Release版，“最终版本”、“上线版本”、“正式版本”、“标准版”，软件封面上取而代之的是符号(R)。
• 产品团队须维护文档时，需保证在项目所有人员手中版本一致性且为最新文档。
• 所有文档版本更新管理时，需明确记录“修订记录”和“签批记录”，方便追溯管理。
网友评论