背景
现今我们很多工程师在实际工作中，可能工作许多年都还未能感受到自己所在组织产品或项目的开发流程到底是怎样的，也不清楚自己在团队中为何存在，应该如何表现才能在团队中出类拔萃。
大部分原因就在于我们自己对于组织的结构和流程没有太多关注，自己没有明确的职业规划，或是没有意识到自己在团队中应如何努力才能得到领导的赏识和肯定。说到底就是我们的认知和觉醒力还不够，一个在于自己没有被开发，另一个在于当前国内的环境，特别是中小型公司更多是劳动力输出型，对于职业发展引导方面比较少。
本章将通过产品开发流程和研发过程中项目管理的基本内容带大家一起了解下，算是抛砖引玉，希望能给职业发展遇到瓶颈的你一些帮助。
产品开发流程
产品开发整体流程
以上流程基本上是绝大多数公司产品开发的流程了，不同组织结构的公司可能各个环节所执行的粗细粒度不一样而已，但大体方向应该不会有太大偏差。流程中“项目立项”-->...-->“部署运维”为项目管理过程
产品设计
产品设计，首选需求的来源，针对于自主研发的产品，需求可能来源与市场，或是目标用户以及与组织对于这个产品的对外能力所关系到的涉众对象；而对于一些定制项目，特别是外包项目，需求一般都来源与甲方(准确来说，来源与甲方以及甲方目标系统所涉及到的涉众群体)，甲方作为需求提供方，收集了所有涉众需求。这个过程中有个非常关键的动作就是将用户需求转换为产品需求，我们也可以将这个过程称为需求分析；需求分析：从用户提出的需求出发，挖掘用户内心真正的目标，并转为为产品需求的过程。
我们在做需求分析过程中，需要考虑如何将用户需求转化为产品需求，在这个过程中我们更多需要去研究任性，了解用户提出这个需求背后的真正目的是什么。
在本章主要介绍，在组织中实际进行产品开发产品设计的过程。如下图所示
如上图所示，在产品设计过程中，输入是MRD文档，也就是《市场需求文档》提前对用户需求，商业价值以及技术难度等做了提前的推算和分析。最后确定立项才正式进入项目开发环节，项目过程中即对产品进行原型设计，原型测试以及高保真等方面的设计，其目的在于能够更好的与用户或是需求方描述满足需求的产品方案。另一方面在于后期可以与研发团队有一个比较好的衔接，一般会形成PRD文档。在PRD文档中主要描述产品的整体功能框架，详细流程，以及各个功能模块的关联关系等内容，形成文案的方式，交付给研发团队，其目的是让研发团队指导产品想做什么。
以上流程看是比较正常，其实经过笔者多年的团队管理实践来看，这种模式未必是一种比较优越的方式，因为在这个过程中，开发团队接收到的是经过产品分析设计后的产品，很多时候，开发是比较难知道这个软件产品最终使用的客户到底是要解决什么问题，为何推演出来的这个产品设计。从而一定程度上会导致研发工程师偏离真实需求，照单干活的情况。
软件开发
在学校特别是学习《软件工程》专业的伙伴，一定是知道软件开发模型的，比如瀑布模型、演化模型、增量模型、螺旋模型、快速原型模型、喷泉模型、V模型等。
与开发模型一样，对应的开发方法也是很多，比如：迭代开发方法、快速应用开发方法、基于构建的开发方法、统一开发方法、敏捷开发方法、模型驱动开发方法、基于构建的开发方法等。
以上都是一些开发过程或方法。
项目管理
在项目管理圈，同行都有一句话，叫做凡事皆项目，无论是个人的事，还是公司的事都可以是项目。从早上起床要去上班这个事情，也可以当做一个项目来管理，为了不迟到，如何控制风险，如何做好计划，需要管理哪些干系人等等。
项目管理是一个相对专业的学科，建议无论以后你是否从事项目管理工作，都有必要系统的学习和了解项目管理。这里我搜集了一些关于专业项目管理方面的体系和方法，如下图:
如上图所示，纵向从个人到组织，横向如何做到做什么。
- 个人:
个人不涉及到团队，看上去是没什么管理可言，但是在这块需要自己有较强的学习能力，自控能力，自律能力。在开发圈中很多刚出道不就的伙伴，最开始一个人单兵独将，做事情都很快，自己想到什么立马就开动，直接开始写代码，玩的不亦乐乎，但是到了一些大型团队，就感觉做事情没以前顺溜了，其实这是一种比较正常的现状，因为个人管理和团队协作完全是两回事。
个人协作，对应的方法有 PSP，单核工作法，包括在CMMI体系中1级认证就是针对个人的。
- 团队
如上图所示，团队管理涉及到很多的专业方法和理论了，比如XP、Scrum、RUP、PMP等，一般建议是在3人以上20人以内的项目团队，推荐最佳的10人内比较合适，否则管理难度就比较复杂了。
- 组织：
组织级别的专业认证，主要有，敏捷方面的SAFe、LeSS，华为的IPD、CMMI等；这些都是比较大型，比较重量级的管理体系，落地有利于企业实施事业部或事业群的管理体系支撑。当然也要看我们各自实施的具体方式和方法。
接下来重点介绍两种目前比较主流的项目管理方法体系，目前业内比较主流的应该主要分传统和敏捷项目管理两类。传统项目管理以PMP体系为代表，敏捷项目管理以Scrum(认证体系为SCM)为代表
PMI-PMP体系
PMP指的是项目管理专业人士资格认证。它是由美国项目管理协会（Project Management Institute(简称PMI)）发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。
其目的是为了给项目管理人员提供统一的行业标准。目前，美国项目管理协会建立的认证考试有：PMP（项目管理师）和CAPM（项目管理助理师）已在全世界190多个国家和地区设立了认证考试机构。
根据PMBOK内容，其主要体系如下，五大过程组+10大知识领域，每个领域都有其对应点过程组
十大知识领域
敏捷项目管理
敏捷项目管理是近几年比较热的一个话题，无论是大公司还是都在实施敏捷，还有DevOps，这里说到敏捷，我们不得不提到敏捷宣言。
从敏捷宣言内容来看，更多是推崇团队协作，而不是传统的文档工具，合同和刻板的计划。对应敏捷的体系也演变出了不少的分支体系，其中Scrum是所有敏捷体系里面算是一个比较基础的框架了。LeSS、SAFe里面的最小单元也是基于Scrum的方式，可能在管理上稍微有些不同而已。
以下是Scrum对应的框架图
如上图，市场或终端用户将需求输入给PO(Product Owner)，PO根据产品的整体规划，梳理出产品的Product Backlog，对每个Backlog会标注上对应的客户价值分数，标识出哪些是对用户价值最大的点。在以Scrum Master为带领的项目团队，大家组织
- 计划会议(Sprint Planning Meeting): 在这个会议上主要做三件事: 1. 挑选即将计入下一个Sprint计划的用户故事；2. 将选定的用户故事进行故事点拆分，输出Sprint Backlog；3. 每个人主动认领任务(可以直接认领任务，也可以认领某几个故事点).
- 站立会(Daily Scrum Meeting):在站立会上每个人主要描述三件事:1. 昨天完成了哪些事情；2 今天计划做哪些事；3. 今天工作需要谁的协助。
- 可运行的软件(Potentially Shippable Product Increment); 每个Sprint结束都具备潜在可运行的软件
- 验收(Review) 每个迭代，都可以让客户对已完成工作进行验收，以便于及时发现问题确保输出物的正确性
- 反思会议(Retrospective),反思会议，主要是团队召开反思会议，回顾在这轮Sprint中大家做的好的部分和做的不好的部分；对做的好的部分由Scrum Master统一放入到团队优良传统榜，对于做的不好选取几个能执行的，讨论出对应点优化方案，在下一个迭代中去持续改进。
在整个Sprint过程中有个时间盒的概念，也就是说在正式Sprint过程中是不允许变更的，变更需求都在每个Sprint开始部分。
我们一个项目跑下来，就是经历无数Sprint不断的迭代，每个迭代的结束紧接着写一个迭代的开始。
传统项目与敏捷项目的对比
这里借鉴了网络上总结的，个人觉得比较到位，也就不用再单独总结了。如下
从管理关注的重要领域上看，可以参考如下图例
左边为传统项目，邮编为敏捷项目；传统项目中，范围，进度，成本就是一个铁三角。任何一边变更都会引起其他方面的变更，如果不然质量将无法得到有效保证。
敏捷项目实践
在笔者所在的公司推行过如下的敏捷实践，仅供参考。在实践过程中还是比较顺畅的。产品设计与产品开发交叠进行。有效保证了项目的有序推行。
总结
本章主要给大家介绍了产品开发的基本流程，以及项目管理的知识体系和比较主流的另种管理体系。同时也简单对比了传统项目与敏捷项目的差异点。最后结合笔者过往在团队中的实践，分享了敏捷实践模型。希望通过本章的分享能帮助大家建立产品开发流程的体系结构，同时了解当今主流的项目管理体系以及差异。为后期个人的职业发展和团队中定位更加清晰明确。
如果你在这方面有不同方面的见解，也欢迎在下方进行留言，一起讨论
想要了解更多信息，可关注本公众号(一起学开源)；或请长按以下二维码添加助手。将拉你加入社区进行更多交流
