写给程序员看的项目管理入门
写给程序员看的项目管理入门
- 项目管理铁三角
- 定义任务范围
-
- 任务分解
- 进度计划
-
- 资源评估
- 任务排期
- 项目执行
-
- 提测阶段
-
- 冒烟周期长
- 代码bug
- 开发阶段
- 项目监控
- 项目回顾
- 附录
程序员从拿到一个需求到这个需求上线，除了写代码还有没有其他必须要做的事情？
初出茅庐的程序员
提交代码才是王道，被扯那些虚头八脑的玩意。
我们已经采取敏捷开发模式了，还需要项目管理？
我就开发一个普通的需求，一个星期就能写完代码，需要了解项目管理的知识吗？
计划赶不上变化，还计划个啥，干了再说。
从业三年的程序员
PD要我做个需求排期，就改几行代码的事情，为什么我总是评估时间少了，搞点buffer又被挑战，时间都去哪了？
为什么每天都有那么多杂事骚扰我，就不能让我专心写代码吗？
完蛋了，提测后才发现有个关联系统忘记改。
每到上线就通宵，需求总是无法按期上线，前面都干嘛去了？
关联系统接口总是调不通，有心无力。
项目管理铁三角
中高级软件工程师开始独立承担一些功能点的开发，在没有任何项目管理知识时，通常会成为“五拍”程序员。
- 需求排期：拍脑袋决定（所谓的经验）
- 追问进度：拍胸脯保证（毫无理由的自信）
- 遇到困难：拍桌子赶工（生死看淡，不服就干）
- 上线延期：拍大腿后悔（这个当时怎么就没想到）
- 反复失信：拍屁股走人（不是我不行，是这里的事太难干）
虽然我们日常功能开发并不需要使用完整的项目管理工具，但需求上线流程依然离不开项目管理的本质。一个独立的需求开发任务就是一个微缩版的项目计划，一样会包含项目管理的过程和要素。
项目管理的四个重要的方面，即：范围（需要做什么事）、时间（什么时间做完这些事）、成本（花多少钱做成这些事）、质量（这些事做到什么程度客户才满意）。
定义任务范围
专门立项的项目通常有项目工作说明书（Statement of Work，SOW），定位项目范围。日常开发任务范围通常由产品需求文档（Product Requirements Document,PRD）决定。没有明确的PRD就无法分析需求上线到底要如何实现业务需求，更加无法评估到底有多少工作量。
PRD并不完全等于开发任务，原因：
- PRD是对需求的整体描述，可能某部分功能现有系统已经实现，可能某部分功能不需要通过编码实现，可能某部分功能是在其他系统实现
- PRD只描述了最终上线需要达到的效果，不包括研发中的过程性工作，比如分析，沟通，测试，部署等等。
需求排期评估工作量时，需要对PRD进行分析后再做任务拆解，才能相对准确的评估工期。
任务分解
不管是瀑布式开发模式还是敏捷开发模式，软件开发都包含以下任务，差别只是任务的并行情况和任务的轻重。所以拿到需求以后第一个计划评估时可以直接按以下任务做第一步的任务分解和评估。
- 需求分析
- 详细设计
- 编码开发
- 开发联调
- 功能测试
- 部署上线
新手程序员做需求排期最常犯的一个错误是只评估了编码开发的时间，其他分析、联调时间统统没有预估。导致需求上线投入时间与计划严重偏差。
开发任务是逐步细化和完善的，接到需求后，第一步按软件研发生命周期完成任务拆分，对需求做一个大致的计划安排。在需求分析和详细设计过程中会进一步丰富和完善开发任务。
- 需求分析
需求分析过程中，我们会分析出那些功能点需要开发，那些功能需要关联系统支持，那些功能无法实现。这样我们可以分析出大的开发功能点，评估出详细设计的任务。 - 详细设计
详细设计过程我们给出详细的开发实现方案，从而可以评估编码变更影响点，代码改动量，开发人力需求，关联系统支持。
如果需求分析和详细设计完成质量较高，详细评审后通常开发任务和测试任务就已经非常明确，任务分解告一段落，基本不会产生太大的偏差。
大型软件特别是历史遗留系统，通常会发生只改几行代码，但分析定位要在哪里改代码需要花一两天的情况。这时详细设计就显得非常重要，并且在需求排期时需要预留详细设计的时间，否则经常会出现提测后甚至上线后才发现改漏了，项目基本无法按计划上线。
PS:
如果这个情况在某个项目中是个普遍现象，一般意味着这个项目坑非常的深。
形成这个问题的原因一般如下：
- 架构不合理，没有做到高内聚，低耦合。
- 核心开发人员不足，没有熟悉这一套代码的中高级软件工程师。
- 技术债太重，经手N代程序员，每代程序员都在填别人的坑，然后给后人挖坑。
ԅ(¯﹃¯ԅ)
赶紧找领导要求做新系统吧。
进度计划
资源评估
即使是一个人自己独立完成的开发需求，也需要做基本的资源评估，也许这个评估只是花几分钟想一下自己手头还有哪些工作，近期每天能够投入几个小时到这个需求，这个基本能够知道这个需求自己大概可以什么时候完成提测。
而稍微大一点的需求，需要多人合作开发，这是就需要评估任务可以拆给多少人，这些人是否有时间。在涉及关联系统配合改造时，尤其要评估关联系统是否有时间配合开发。这个时候一定要做好充分的事前沟通，得到资源确认后才能够真正做需求排期，否则指定的计划没有可执行性，无法按期完成。
任务排期
简单需求一般知道改什么后上手就开始撸代码了，但稍微复杂一点的需求涉及多个开发任务就需要对开发任务定一个优先级，确定各任务之间的依赖关系，评估每个任务的工期，发现关键任务，评估需求整体工期。
传统项目管理和敏捷研发流程在制定项目计划时会有些差异：
- 传统项目管理
强调资源和任务是固定的，通过任务和执行任务的资源评估项目什么时候完成。 - 敏捷研发流程
强调资源和时间窗口是固定的，通过资源和执行任务的时间评估哪些任务可以在时间窗口完成。
传统项目管理在制定项目计划时，会事先明确每个任务的开始时间，结束时间，资源依赖，任务依赖，每个任务按计划执行。而敏捷研发通常是一个任务做完再从任务池中领取下一个任务，所以事先不需要明确每个项目的开始时间和结束时间。但这样的方式通常无法面对需要高度协同的开发任务，比如大功能点无法拆分拆分提测上线，必须在一个版本由多个开发人员开发的需求；再有上下有接口联调依赖，需要关联系统排期的需求。这种情况下需要对这样的关键任务做明确的排期计划，而将一些离散的小功能需求作为buffer放在空闲时间点开发。
制定项目进度计划的技术和工具,其中一项是关键路径法(CPM).对于一个项目而言，只有项目网络中最长的或耗时最多的活动完成之后，项目才能结束，这条最长的活动路线就叫关键路径（Critical Path），组成关键路径的活动称为关键活动。其通常做法是：
1） 将项目中的各项活动视为有一个时间属性的结点，从项目起点到终点进行排列；
2） 用有方向的线段标出各结点的紧前活动和紧后活动的关系，使之成为一个有方向的网络图；
3） 用正推法和逆推法计算出各个活动的最早开始时间，最晚开始时间，最早完工时间和最迟完工时间，并计算出各个活动的时差；
4） 找出所有时差为零或者为负数的活动所组成的路线，即为关键路径；
5） 识别出准关键路径，为网络优化提供约束条件；
项目执行
编码开发是程序员在项目中最熟悉也是最喜欢的步骤。实际上需求分析、详细设计、测试支持、部署上线等等都属于项目执行的范畴。在任务执行过程中会循环迭代更新任务计划。为了观察开发阶段项目执行效果，我们可以从提测阶段反推需求分析、详细设计、编码开发阶段执行需要注意的问题。
提测阶段
当需求进入提测阶段后，原则上需求不应该再投入开发资源，开发人员应该开始分析开发新的需求。但在实际项目执行过程中，功能提测后开发人员通常无法立即开始新需求开发。如果功能提测后开发人员大量时间投入到测试环境支持，通常说明项目存在极大质量风险，测试周期可能会很长。这其中有客观原因，也有项目执行不到位的原因：
- 测试冒烟不通过，开发人员配合测试反复解决问题。
- 功能验证代码bug太多，开发人员全力在修复bug。
- 测试人员对提测功能不理解，反复咨询开发人员。
- 测试阶段增加功能点。
冒烟周期长
冒烟不通过一般有以下原因：
- 环境问题：中间件、网络、外部服务依赖资源不到位，
- 配置问题：除代码外，应用执行还依赖数据库、配置中心中的配置数据，
- 代码bug：开发人员没有自测，或者测试覆盖不够，
环境问题和配置问题统一都是部署发布问题，严谨的部署说明以及严格的部署流程完全可以规避掉这些问题。
- 环境问题
环境问题通常出现在部署逻辑图有变更或者关联系统有变更（包括需要关联系统变更但没有变更的情况），部署逻辑图变更在详细设计阶段就应该明确，比如增加了外部系统依赖，增加了数据库依赖，增加了MQ依赖，增加了redis依赖。这些依赖必须在部署说明中体现，并明确提供资源地址、账号密码。
关联系统变更在详细设计阶段也应该明确，并需要协调部署上线计划，明确系统发布顺序。 - 配置问题
所有的配置变更都应该提供配置文件，dml，ddl脚本以及部署说明。
代码bug
冒烟阶段发现的代码问题是极为恶劣的开发质量问题，反应了相关开发人员完全没有质量意识，也反应了相关需求负责人在开发阶段任务跟进上存在较大的问题。
开发阶段
开发阶段最有成就感的是写完了需求实现代码。但coding只占日常业务开发工作的一小部分，实际我们需要做更多其他事情：
- 业务场景梳理
谁、在什么情况下调用当前代码，输入参数是什么，需要得到什么效果，如果异常了怎么办。 - 单元测试编写和执行
针对业务场景编写单元测试代码，确保各个分支都测试到。 - 开发集成测试
确保按真实业务场景执行完全链路测试案例。 - 提测前冒烟回归
由于版本是多人持续开发，需要在提测前在开发环境重新回归测试案例，确保冒烟100%通过。 - 分支管理
很多项目都有多版本并行开发，当前面版本上线后要及时合并生产版本到当前开发版本，避免丢失功能。
项目监控
新手程序员在项目执行过程经常犯的错误是只顾埋头干活，没有抬头看路。具体包括
- 获取外部资源：确保需求排期时约定好的资源能够按时到位，通常在任务开启前要做二次确认，避免撸起袖子开始干时才发现被人放鸽子了。
- 管理沟通和相关方：让PD，测试，关联系统都知道我们要做什么，怎么做。交付设计文档，发起设计评审。让所有人知道关键节点的进度。
- 建设和管理团队：确保队友知道当前要做什么，做成什么样了，是否达到要求。
- 管理质量：确保是按需求保质保量的完成。
- 应对风险：如果出现问题要及时暴露风险，并给出处理方案。要对任务排期做定期review，评估进度风险。
项目回顾
温故而知新，可以为师矣。
普通程序员需求开完就完了，优秀的程序员会对刚刚做完的需求做一个复盘。做得好的给朋友传授一下经验，做得不好的找别人学习一下经验。
附录
软件项目常见名词
- 商业需求文档（BusinessRequirementDocument，BRD）
是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。 - 市场需求文档（Market Requirements Document，MRD）
市场需求文档的主要功能是描述什么样的功能和特定的产品可以在市场上取得成功，在BRD说服领导拿钱给你做某件事以后，MRD需要更细致描述该怎么做，以及这样做的好处。 - 产品需求文档（Product Requirements Document,PRD）
PRD用于向技术人员进行功能需求说明。 - 项目工作说明书（Statement of Work，SOW）
是对项目所要提供的产品或服务的叙述性的描述。对内部项目而言，项目发起者或投资人基于业务需求，或产品或服务的需求提出工作说明书。对外部项目而言，工作说明书作为投标文档的一部分从客户那里得到，如：邀标书，投标的信息，或作为合同的一部分得到。 - 工作分解结构（Work Breakdown Structure, WBS）
以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP考试中，工作分解结构（WBS）都是最重要的内容。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。 - 关键路径法(Critical Path Method,CPM)
关键路径是指网络终端元素的元素的序列，该序列具有最长的总工期并决定了整个项目的最短完成时间。关键路径的工期决定了整个项目的工期。任何关键路径上的终端元素的延迟将直接影响项目的预期完成时间（例如在关键路径上没有浮动时间）。 - 概念验证（Proof of concept，POC）
是对某些想法的一个不完整的实现，以证明其可行性，示范其原理，其目的是为了验证一些概念或理论。 - 完成的定义（The Definition of Done，DoD）