“1人100个月完成的项目，不是100个人1个月就可以完成。”

    项目管理是让项目活动中相互竞争的各类制约因素：质量、进度、资源、风险等取得平衡的艺术，同时也是平衡项目干系人的各种需要、关注和期望，带领不同的人朝着相同目标迈进的领导艺术。

    成功的项目管理可以简单理解为：按时、在预算内+满足产品需求+满足质量需求 地完成项目。

    以下是我对项目管理的一点体会记录。

     ――――――――――――――――――――――――――――――――――――――――――-

    需求等级

    如果在前期产品需求文档中没有明确定义每个需求的优先等级，或者说项目成员对需求的优先等级没有明确的意识，可能类似的争论会时常发生在项目成员之间，每个人会基于自己对产品目标的理解来考虑这个需求是否要做，什么时候做，做到什么程度而产生分歧，因而增加项目推进的阻力。

    所以在前期产品需求文档中，必须明确定义出每个需求的优先等级，需求的粒度可细化到每个大功能下的子功能需求，如：图片分享功能的转发链接分享、邮件形式分享这样的子功能需求。等级的划分依赖于前期的用户需求调研、产品的预定目标、开发成本、运营计划等；

    一般的需求等级划分：

    每个需求的优先等级确定之后，产品经理根据产品预定目标、开发成本、运营计划等来定义一个等级分界线，高于或等于这个等级分界线的需求在本期开发，部分根据成本、运营计划等因素调整到下期开发，而低于这个等级分界线的需求则只会在下期开发，这样让全体项目成员对本期要做的需求达成共识。

    需求等级的实际应用：

    ――――――――――――――――――――――――――――――――――――――――――-

    WBS

    项目各成员对自己需要负责的任务粒度细分不到位，每个任务的交付时间点不够明确，对任务之间的依赖关系也不够清晰，造成项目推进中的协作成本提高，项目时间预估准确率不高，项目控制的风险增加；

    因此在产品需求文档确认之后，必须做工作分解 WBS(Work Breakdown Structure)，即把需求分解成较小的、易于管理的工作包。一般的工作包是最小的“可交付成果”。工作包必须详细到可以对该工作包进行估算(成本和工时)、安排进度、分配负责人员或组织。

    项目经理、项目成员和所有参与项目的职能主管都应该参与WBS工作，根据项目规模情况，可以由项目经理或各模块主策划来组织。组织方负责召集有关人员，集体讨论所有项目工作，确定项目工作分解的方式后，各职能方提交各自的WBS，汇总后画出WBS的层次结构图。结构图中应包括每个工作包名称(内容定义)、指派人员名称、所需工时、可能的依赖关系等；

    WBS的工作包，最终以任务形式录入到QA中进行跟踪管理。

    QA可视化项目管理

    … …

    不管是前期开发的工作包还是后期的测试bug，均以任务的形式录入在QA里，然后对这个任务的一些基本属性做设置，如：属于哪个milestone、哪个模块等，然后由各个阶段的Triage的负责人按照需求等级标准来对任务作分类定级，并确定是否做，是否现在做；所有的任务都必须经过Triage并approve通过，才能开始工作。Triage的决策需要多个层面的知识(结合产品、技术、进度等多方因素)，特别是在大项目中，Triage往往是一项群体工作，以功能小组(feature team)或产品决策组的方式来进行。在项目的不同阶段，可以由不同的角色来主导Triage流程。

    在任务approve后，各职能方leader将任务指派给相应具体执行的人员。执行人员，也就是任务的owner，必须设置任务的Status date，如：Status任务状态是Working(进行中)；Status date即完成日期点，Status date应真实反映实际工作计划，并应契合项目时间表。

    在执行人员完成任务时，QA会通知各职能方leader去关闭这个任务，关闭的意义在于通知任务的相关跟踪者，可以着手下一部分的工作，如某功能代码任务关闭，即相关测试人员就知道可以开始这个功能点的测试工作；

    通过任务在QA系统里的记录和跟踪，以及任务状态的实时更新，最终会汇总生成各种可视化的图表，项目进展直观，且可度量，能够很好的把握整个项目推进的节奏，对项目中各项问题和风险定位更容易，并可在周会上对项目的所有成员公开进度信息，便于协调一致；

    其中最重要的图表：glide path任务走势图：

    “实际任务走势”与“计划任务走势”的对比，可以衡量出计划与实际的偏差。

    ――――――――――――――――――――――――――――――――――――――――――-

    每日构建

    … …

    每日构建(daily build)是指每天对整个项目做一次完整的自动构建，生成可执行文件的过程，对Web类产品，每日构建通常要伴随自动部署的过程，将这些可执行文件部署至测试环境，并按照一定的规则对这个安装包或测试环境做版本编号，是一种Public build的管理方式。

    每日构建的好处：

建议继续学习：

1. 神马？用excel来做项目管理？    (阅读：42236)
2. 多些时间能少写些代码    (阅读：3521)
3. 一页纸项目管理表格学习笔记    (阅读：3400)
4. 线下项目工作流程(归纳篇）    (阅读：1856)
5. 项目管理中怎么做资源平衡    (阅读：1855)
6. 线下项目工作流程（分析篇）    (阅读：1722)
7. 产品设计体会:一个只有七天的项目    (阅读：1650)
8. 挣值分析    (阅读：1646)
9. 隐性KPI：对项目管理的合理追求    (阅读：1627)