需求分析、产品设计到部署交付各阶段图解 下面用一张图来表示产品设计到部署交付阶段： 研发流程各环节： 需求分析 产品设计 UI设计 开发和测试 部署交付 团队划分 按职能划分团队 产品团队 后端开发团队 UI 设计团队 前端开发团队 运维和测试团队 移动开发团队 按职能来划分团队，每个团队有一个团队
下面用一张图来表示产品设计到部署交付阶段：
研发流程各环节：
组织结构如下图：
跨职能团队一般是基于某个产品、项目 或功能特性来组织一个团队，在这个团队内，就可以完成需求、开发、并交付成果，然后进行下一个产品特性开发。
这样的团队成员组成由 产品、UI、后端开发、运维测试、交付等组成一个跨职能的全功能开发团队。
在稍微大一点公司里，可能还有一些公共技术团队，比如架构师团队，这个团队基本职责是负责公司的项目的技术架构设计、攻坚技术难题，还可能负责公司技术基础设施建设。
开发人数较少的公司可能没有架构师团队，那怎么办？一般由技术经理来兼任架构师的职责。
有的公司可能按照职能职责组成一个一个的委员会，来解决公司内遇到的各种技术、沟通、协调等问题。
比如说技术委员会，公司最高技术决策组织，里面成员有 CTO 、各技术组长、架构师，他们通过沟通、讨论和解决公司里遇到的各种技术难题。
产品与设计委员会，成员由CTO、产品经理、设计师、架构师、业务员等组成，评审产品项目、各种需求等，解决公司产品相关问题。
什么是需求？在经济学中
需求
是消费者愿意并且能够在给定时间段内以不同价格购买的商品数量。
在产品中，需求又是什么？
从问题角度来理解，在某个场景下，用户为了解决某个问题。
从心里角度来理解，在某个场景下，为了实现用户内心的某种欲望。
需求 = 用户 + 场景 + 问题
首先需要洞察用户需求，将洞察到的用户需求收集起来，然后进行分析 - 需求分析。分析真需求和伪需求，然后形成一份需求文档。
等等一些需求洞察的方法。
（需求收集分析）步骤图
比如用户年龄、学历、兴趣爱好等进行分析，确定哪些用户是目标用户，然后可以进行需求分析。
需求分析步骤：
需求过滤 -> 需求审核（审核需求真伪） -> 需求分类 -> 需求排序（优先级）
后面是需求实现，需求交付和验证。
一种需求分析模型，KANO模型介绍：
KANO模型是由东京理工大学教授狩野纪昭（Noriaki Kano）和他的同事 Fumio Takahashi 联合建立的用户对产品功能满意度模型。在需求分析中一般用来进行需求分类和优先级排序的工具。
KANO 模型可用于定性分析用户对新功能的接受度。
该模型核心理念：
用户对产品或服务的满意度并不是简单地随着功能的增加而成正比例提升，而是呈现出更为复杂的非线性关系。
KANO模型图：
KANO模型需求分类：
必备型需求（属性 ） （一定要有）：有的也译作基本型需求（属性）。用户认为理所应当、必须要有的需求，这些需求必须被满足。当这些需求不被满足时，也就是不提供这些需求，用户满意度会大幅降低；当这些需求被满足时，用户满意度不会得到提升。例如：手机打电话、发短信。
期望型需求（属性） ：满足此需求时，用户满意度会提升；不满足此需求时，用户满意度会降低。
魅力型需求（属性） ：用户对这种需求没有太大期望，需要产品经理对用户有深刻的洞察才能挖掘到此隐性需求，属于给用户惊喜的需求。不满足此需求，用户满意度不会降低；满足此需求，用户满意度会急剧提升。有时是产品很 有竞争力的体现。
无差异需求（属性） ：无论是否满足此需求，对用户满意度都不会产生影响。
反向型需求（属性） ：有无此类需求，用户根本不在意。若满足此需求，用户满意度反而会下降。
它们的优先级排序为：
必备型需求 > 期望型需求 > 魅力型需求 > 无差异需求
KANO模型的分析步骤包括：问卷收集→数据清洗→属性归属分析→Better-Worse系数计算。
比如用户年龄、学历、兴趣爱好等进行分析，搞清楚用户画像，确定哪些用户是目标用户，然后进一步进行用户需求分析。
业务分析中的一些概念：
业务目标，业务流程分析，关键业务流程是什么，业务场景有哪些，业务对象有哪些，业务对象之间关系是什么？业务活动有哪些，业务规则是什么，相关角色有哪些？抽象出业务模型。
图解业务，比如用 UML 绘图，绘制出业务各步骤、用例图、业务流程图 等。
用户和业务需求 -> 产品定义 -> 产品解决方案 -> 详细设计
上面把用户需求和业务需求分析完成后，就要进行产品定义 。
总体解决方案，产品架构设计，子系统设计，业务模块设计等等。
产品经理可以输出一份产品 PRD 文档，这份文档是面向后端开发、前端开发、交互设计、QA测试的一份文档。
PRD 文档组成：
这里很重要的产品原型图，画出了产品的界面、功能、操作、规则等。
产品原型设计工具有Axure、蓝湖、Figma等工具软件。
最后，PRD文档的评审工作。
根据产品经理画出的原型图，设计产品 UI、交互设计。
到这一步，就是产品的真正实现了。
架构设计，一般可分为：业务架构、产品架构、应用架构、数据架构、技术架构。
业务架构可以是对业务整体分析完成后，业务可以由哪些业务系统组成。
产品架构对应着业务架构，一种产品的实现是对业务的一种实现，所以往往业务架构和产品架构图有很多相似处。
应用架构对应着产品架构，开发的应用系统有哪些组成。
数据架构是关于数据设计、数据管理、数据分析等。
技术架涉及到具体技术系统架构、应用技术架构等。
应用架构、数据架构、技术架构 这 3 种架构相对来说，是技术层面的架构。
根据上面的产品架构文档，PRD 文档来设计应用系统。
系统设计：
- 需要设计成多个应用系统吗？按照产品生命周期的 4 个周期，在第一个周期里，从 0 开发的产品不需要划分多个应用系统。单个应用系统就可以。
- 子系统和模块：如果应用系统不复杂，也不需要划分子系统。直接把单应用系统进行模块划分。
架构选型：单体架构足矣。
最后可以画出一份应用系统架构图。
上面的设计都可以产出对应的技术文档。
数据架构：数据管理，数据分析
可以采取敏捷开发的方法，迭代的方式进行产品功能开发。每一个开发周期实现一个产品目标。
Scrum 敏捷开发方法：
- 产品负责人负责产品待办事项（Product Backlog），并进行优先级排序。
- 敏捷负责人负责迭代计划（Sprint Planning）。每一个迭代周期（通常为1-4周）从迭代计划里筛选出冲刺的任务进行开发，然后交付增量迭代成果。
- 开发团队成员每天进行简短的站立会议，分享进度、计划以及遇到的问题。
- 每一个迭代周期完成后，要进行评审会议，展示交付的成果，并收集相关反馈。
- 每一个迭代周期完成后，进行回顾会议，复盘哪些做得好，哪些做得不好，并制定改进措施。
完成冲刺后，源代码提交到 Gitlab 代码存储库中，然后触发构建，完成代码覆盖率、单元测试等成功后，完成构建，构建结果可以存储在 artifactory 中，然后部署到测试环境中。
QA 测试团队进行 QA 测试，性能测试 和回归测试。QA 团队测试通过，则部署到 UAT（User Acceptance Test 用户验收测试） 环境中。如果 UAT 测试通过，则成为部署到生产环境的候选版本。
如果上面的测试全部通过，测试部门同意上线，则建立相应的 tag 版本，准备上线。
运维团队建立好上线的时间，上线的版本号，评估上线后的影响范围。
