项目管理的一些知识总结

项目

项目是为提供某项独特产品、服务或成果所做的临时性努力
示例：

开发或购买一套新的系统
实施一种会全新的经营程序或流程
为某个社区建造供水系统
设计chenqionghe变身超级赛亚人计划

项目管理

项目管理就是把各种知识、技能、手段和技术应用于项目活动之中，以达到项目的要求
项目管理是通过应用和综合诸如启动、规划、实施、监视、监视与控制和结尾等项目管理过程进行。

具体来讲，项目管理就是把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内，完成项目的各项工作，对组织资源进行计划、引导和控制。

WBS

Work Breakdown Structure，工作分解，把项目工作按阶段可交付成果分解成较小的，更易于管理的组成部分的过程。

简单地说，就是把“大象放进冰箱”的过程

甘特图

甘特图（Gantt chart）又称为横道图、条状图(Bar chart)。其通过条状图来显示项目，进度，和其他时间相关的系统进展的内在关系随着时间进展的情况。以提出者亨利·劳伦斯·甘特（Henry Laurence Gantt）先生的名字命名。
甘特图以图示标明计划与实际完成情况的图表，通过活动列表和时间刻度表示出特定项目的顺序与持续时间

时间线图

时间线图，又叫时间轴图，能以历史进程为载体，将过往的重要事项或者里程碑，标注在轴线上，并加以说明。它的作用是能够可视化内容，以图文的形式呈现出来，帮助读者理解。
根据布局方式的不同，时间线图可以分为水平时间线、S型时间线和垂直时间线。

水平时间线
垂直时间线
S型时间线

风险管理

风险管理是指如何在项目或者企业一个肯定有风险的环境里把风险可能造成的不良影响减至最低的管理过程。

风险概率：每个具体风险发生的可能性
风险影响：风险对于进度、成本、范围、质量的影响
风险指数：风险概率 x 风险影响

示例：风险对主要项目目标的影响量表

示例：风险登记册

质量管理

项目质量管理是指为保障和提高项目质量，运用一整套质量管理体系、手段和方法进行的系统的管理活动。
项目质量管理把组织的质量政策应用于规划、管理、控制项目及产品质量要求，以满足相关方目标的各个过程。

规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程。

示例：质量保障手段列表

示例：需求到发布质量活动概览

示例：CICD发布流程

高效会议

断舍离，只开最有必要的会。
会议不在多，在于精，每个会议都要真正开出效果
坚持只开最有必要的会，开真正高效且产生决议的会，大家不但不会排斥，还会积极参与，会后还会有“这么短时间就达成一致”的满足感
会议不是目的，借助会议去做好群体沟通，让大家看到有效的进展，才是最重要的

启动会
三步走，why、what、how，清晰目标，明确授权。
充分理解项目背景、目的和意义，才能更好地唤起团队的参与热情
每日站会
站会满足的是团队自组织的需要，而不是leader的监控需求。
真正的自我管理的站会，团队成员不仅可以自己决定站会时间，还可以轮流当主持人
项目周会
对于10人以内的团队来说不太需要，每日站会已足够。
周会目的，解决整体计划层面，跨团队协同配合的问题，包括产品、运营、市场、研发等环节。

需求变更

常见流程

三个技巧

达成最小共识，记录历次变更影响
记录历次变更的影响，给团队带来的各项成本增加及引发的返工

细化具体流程

* 所有需求及所有变更必须有凭据，否则开发有权不接
* 需求变更必须经过变更委员会评估成本，变更成本较大的要提交项目经理更新时间计划，并告知全员
* 确认通过的变更产品人员要发送邮件告知全项目组人员

源头治理
来自在老板或大客户的无力抗拒的需求，经常是写死的上线时间，并且会多次评审且修改方案，这样的可以从源头开始治理，扁平化开发

* 产品、设计、开发一起关进小黑屋，及时沟通，及时发现问题
* 组建老板需求响应小分队，提高响应速度，轮流值班，尽可能隔离对团队进度的干扰，让老板快速试错，不合理的需求可以小范围灰度发布，并对比数据说话。

复盘流程

复盘原来是围棋用语，说的是在下完一盘棋后，把过程重新摆一遍，看哪里下得好，哪里下得不好，哪些地方有不同甚至更好的下法。

简单地说就是复习的意思，通常用于项目或活动结束后，对已经进行的项目进行回顾，对经验和教训进行总结。

高效复盘流程

现场回顾总结项目的整体概况。包括目标达成情况，进度计划及变更情况、需求变更情况、质量报告等项目历程记录
与会人员用便签纸写下项目过程中做得好和不好的3个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。
在白板前逐条review大家的意见，共同发现问题，并有针对性地展开讨论。
对大家总结出的好和不好的点，进行集体投票。
由项目上经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案。

报告分类

紧急报告
1. 事件描述。购物车改造功能高延期风险
2. 影响后果。由于此功能在项目的关键路径上，很有可能会造成项目整体延期两周
3. 跟进分析。本期购物车改造功能，有部分调整涉及到底层订单系统，里面有大量遗留代码，已经很久没有人维护了。之前对此风险的评估不够充分，改动风险很高，可能会影响全站订单系统的稳定性，具体影响仍需要详细分析
4. 响应措施。请和全力以赴做好技术评估，本周内给出详细任务评估时间表；与此同时，产品人员介入，调研规避老系统又能满足需求的可行性，本周内给出调研结论；
5. 所需支持。熟悉老系统的资深技术人员，以及红牛一箱。
常规汇报
项目整体进展状态如何？风险可控吗？目标达成有没有问题？
数据汇报
善用图表（JIRA中的项目仪表盘）

制定计划

好的计划能有效的避免延期，以下五个特点

具体
好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。
全面
识别关键资源和关键依赖，考虑研发之外其他环节。

准确
尽早定义完成标准，要不会出现开发不知道完成交付和开发完的概念

* 需求/设计确认
执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。
* 功能完成/提测
所有定义的功能已经完成（如冒烟测试通过率高于90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作bug处理。质量基础比较好的团队，可以把CI自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更具体的完成标准
* 里程碑完成
质量已经达到适当水平（如不存在P0及P1优先级的Bug），可以上线发布，或者可以开始下一个里程碑。