做技术的同学，90%的人都是从事业务开发。
业务开发同学，80%以上的工作量都是来自产品经理。正所谓知己知彼，百战百胜，咱就看看产品干啥的。
1 和业务/客户沟通，收集业务问题、诉求，形成原始需求
2 对原始需求进行分析设计，输出初步产品方案（原型、交互示意、流程）
3 确认可行性后，输出用例分析，详细prd
4 上线后验收，提供文档，回到步骤1循环。
5 部分产品经理，会兼任项目管理职责，规模比较大的项目，一般一个团队无法独立完成。主产品经理，联动架构师，完成需求模块拆解，确定边界，细分到具体执行团队，把控整体业务流程，核心业务数据相关场景，规则，词汇等。
1 聆听理解能力，快速抓住业务痛点，诉求
2 专业领域知识，不具备客户业务的专业领域知识，无法支撑问题理解，方案设计。
3 抽象，架构能力，从一个物理上，流程上的问题，转换为一个系统解决方案。
4 文档能力。正式的需求确认，无论是对客户，还是对内部，都需要通过文档，清晰规范的文档能降低沟通成本。
PS：汇报啥样，和项目做成啥样同等重要。
5 项目管控能力，一定级别以上干部适用。
一般来说，需求分析要经过业务建模，用例分析和系统建模三个阶段才能完成需求工作。
1、业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生。
业务建模阶段工作：
发现和定义涉众（干系人）
敲定业务边界（提供啥能力）
获取用例
绘制业务实体模型（领域模型）
编制词汇表2、用例分析是产品采用经验或者各种方法论来分析业务用例的过程，这个阶段就是建立概念模型。用例分析是一个过渡过程，但其非常重要，业务架构通常在这个阶段产生。（故也有部分架构师会参考或者加入该环节）
3、系统建模是将用户的业务需求转化为计算机实现的过程。系统范围，项目计划，系统架构通常在这个阶段形成雏形（在系统分析阶段确定）。
商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。复杂的表面下其实只是一个简单的规则，只要弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求。
产品决定做争取的事情，开发正确地把事情做完。
产品和开发意见分歧主要是一下集几种场景：
1 交付期望：客户可能会提出不太合理的进度预期，产品不一定能降低业务预期。
2 实现是开发完成，产品不一定能准确评估实现成本。
3 开发以产品视角review方案，尝试提出更低成本的替代方案
互联网的产品经理，比传统的需求分析人员，有更强的进度交付压力，也有更强的平台加成。高强的节奏，没办法像传统需求分析一样慢慢迭代。交付的prd，其实是介于原始需求，用例分析和系统实现用例之间的混合物。虽然做了一系列的精简，跳过，但需求分析设计的思考因素不变。
笔者一直认为，评判一个设计的好坏，只有一个标准，是否和业务匹配。恰如其分的设计，更需要对业务的深入理解，加行配置真不叫设计。不妨多问产品，方案背后的考量是什么？
总的来说，牛逼的产品，和牛逼的开发，都需要具备较强的抽象、逻辑、架构能力，都是项目交付上的一个轮子，互相理解，转得更快。