《阿里巴巴网站项目管理手册.doc》由会员分享，可在线阅读，更多相关《阿里巴巴网站项目管理手册.doc（6页珍藏版）》请在三一办公上搜索。
1、阿里巴巴网站 项目管理手册 出品网站技术部PMO 时间2009-11 1目 录 序言.4 项目计划.5 制定计划的意义.5 制定计划的原则.5 阿里巴巴实际的项目涉及的计划.7 制定计划的方法论.9 计划常见的误区.11 工具介绍.12 进度控制.14 进度定义.14 进度收集.14 进度评估分析.15 进度的控制.16 变更控制.18 项目变更和项目变更控制.18 正确认识项目变更.18 项目变更控制的目标.20 项目变更的处理.20 项目变更的流程.21 沟通管理.22 沟通基础.22 软件项目管理中的沟通管理.27 风险管理.33 什么是风险.33 风险管理.33 风险识别.33 风险评
2、估.33 风险应对.33 风险监控.34 软件项目典型风险.34 接手项目时进行分析.35 阿里巴巴项目典型风险及应对措施.36 1. 项目阶段 -Kick off前.36 2. 计划跟踪:.37 3. 需求管理:.37 4. 设计开发:.38 5. 测试 :.38 6. 发布.39 7. 过程.39 8. 资源.39 2团队建设.41 何为高效团队.41 如何进行团队建设.41 团队形成过程.42 阿里团队管理案例.42 质量管理.46 目标.46 质量是什么.46 产品质量.46 过程质量.46 质量管理是什么.47 质量管理的原则.47 质量管理的阿里巴巴实践.48 会议管理.49 会议
3、管理概述.49 项目会议知多少.50 项目KickOff会议.50 项目总结会.50 项目周例会.51 问题讨论解决会.51 FRD确认会.52 UC评审会.52 设计评审会.53 TC确认会议.53 发布计划评审会.54 3序言 2009年1月21日“阿里巴巴网站技术部”正式成立PMO当时我们PMO给自己设定的一个重要目标就是“项目管理实践和专家知识的整理”。所以就有了今天这份文档。我们给这份文档规定了一个原则那就是这份文档要区别于现在普遍的项目管理的书籍它应该更具有阿里巴巴特色更具有实践指导意义。我们网站PMO有这么多优秀的项目经理他们有着非常丰富的项目管理经验和体会。我们有责任、有能力贡
4、献出一份项目经理的工作指导手册并分享给所有有兴趣或者正在带项目的同学们。 以下是本文档各个部分的主要撰稿人。其中每个主题都经过了PMO集体的讨论和确认如果你发现其中问题PMO负有主要责任请告诉我们。 主题 负责人 项目计划 陈剑苏德祥 进度控制 谢黎文张聪 变更控制 王超陈波 沟通管理 章显洲岑欣伟 风险管理 欧猛杨震 团队建设 叶静俊谢飞 质量管理 杨争钱超 会议管理 马小龙傅茂建 感谢质量保证部的王宁一直参与PMO的工作你给了我们很多工作上的建议和帮助。 感谢网站技术部各位主管对我们工作的大力支持。 最后感谢曹行当初你给了我们PMO足够的空间让我们做我们想做的事情。感谢郑林网站技术部虽然分
5、为几个独立的技术部但你仍然支持着我们的工作向前推进。 这次项目管理手册的整理给我们一些启示。 1、项目经理其实不是一个岗位他更多的是一种能力所以这个手册不仅仅是适用于项目经理它也具有普遍指导意义。 2、项目管理的成败不在于流程、制度而在于人在于你。项目经理请珍惜我们身上肩负的责任。 网站PMO全体人员 2009-11-24 中国杭州阿里巴巴滨江园区 4项目计划 制定计划的意义 软件项目计划是一个软件项目进入系统实施的启动阶段它是软件开发工作的第一步。 项目计划的目标是为项目负责人提供一个框架 使之能合理地估算软件项目开发所需的资源 、经费和开发进度并控制软件项目开发过程按此计划进行。 在做计划
6、时必须就需要的人力、项目持续时间及成本作出估算。 简单地说项目计划可以起到如下作用 1、 确定完成项目目标所需的各项任务范围落实责任制定各项任务的时间表明确各项任务所需的人力、物力、财力 2、 确定项目的工作规范遵循的标准成为项目实施的依据和指南 3、 明确项目组各成员及其工作责任范围以及相应的职权使项目组成员明确自己的工作目标、工作方法、工作途径、工作期限要求 4、 保证项目进行过程中项目组成员和项目干系人之间的交流、沟通与协作使得项目各项工作协调一致增加客户满意度 5、 为项目的跟踪控制提供基础。 6、 项目计划在项目中起到承上启下的作用计划批准后应当作为项目的工作指南。 制定计划的原则
7、一、 制定计划时的粒度考虑。 首先以大的里程碑制定出大的计划。这个计划的粒度非常大线条很粗但能反映整个项目的进程。比如什么时候需求分析结束、什么时候详细设计开始、什么时候出开发的DEMO版本等等。很清晰地定义出了整个项目的轨迹。 其 次将大的计划分给具体的小组进行小粒度的细化。这个环节上首先制定出本环节的粗粒度的计划比如我们要求是制定出每个周的小里程碑然后在每周开始 的时候细化出本周的具体工作计划这个粒度非常细可以具体到每个人、每天的工作任务。依次类推下去会根据上周完成情况与经验对下周计划做出调整和细 化。 二、 计划的可操作性考虑。 计划不是给客户和老板看的是应该切实地指导我们的工作的。通过
8、计划的指定尤其是必须在某个时间点完成某个特定任务、在项目结束时间上不允许有折扣的项目中非常地重要通过细排计划资源的分配应该及时找出资源的不足及时向公司提出补充资源。资源包括人力资源、财力以及物资资源。 三、 计划的可考量性。 5 制定计划首先要明白做什么事在什么时间完成由谁完成这是必须的。但我们始终不要忘记计划执行完的结果的考量即怎么表示你计划完成的标志。我们采取 的是交付物的方式比如需求分析结束那么就应该提交需求规格说明书的最终版本也可能是阶段版本开发完成就应该提供相关的程序代码和部署文件等等。 并明确地指出交付物的形式、交付时间、责任交付人等等。计划必须落实到人计划制定的最大忌讳就是人事责
9、任的不清我比较反对集体对某件事负责其实就是无人负责很容易造成推委与扯皮。 四、计划的监督。 计划在执行中必须进行进程的监督千万不要过分依赖人的自觉性尤其是软件项目是个脑力劳动的产出受人的思想制约非常大因此要定期地进行监督和评价对偏离和延误计划的情况要及时纠正以便在正常轨道运行。 五、计划的决定要素: 资源R 时间T 流程Q. 资源是保障计划的实际开展 时间是保障计划点的准时实现 流程是保障项目的质量. 他们的关系是三角形状 中间保障的是质量 同时在制定计划的时候要保持计划在不同的阶段保持计划的时候 要注意不同阶段的衔接 保持项目计划整个过程的平滑 不要跳跃式的制定计划. 同时在制定的过程中又要
10、保持: 一、重视与客户和组员的沟通 与客户的沟通是很重要的。不必害怕客户知道我们的开发计划特别是项目进度情况应当和客户共享这些信息。 首先客户会提出一些对项目时间、进度、效果上的要求这个指标往往经不起推敲有的还带有较强的政策性。站在为了科学地分析和解决问题的立场上来看项目组和客户的目的是一致的所以对于合理的项目进度客户是会理解与支持的。 其次我们有义务要让客户知道项目的计划。这样才能让客户和用户主动、积极参与项目达到项目的最终目标。 6做计划不是项目经理一个人的事要让整个团队都参与做计划的过程特别的是涉及到任务的安排时应该和任务的责任人就计划达成一致。让所有项目组成员都了解计划的基本内容不要让
11、项目组成员“蒙在鼓里”其实他们很想知道计划的内容特别是和自己相关的部分。 二、该详细的详细该简略的就简略有针对性 软件项目计划就如同软件项目本身一样有它特殊性一个三五个人花两三个月就可以完工的小项目 可能项目计划就四五页纸包括一个WBS工作分解结构和一个Gantee图甘特图。一个需要五六十个人甚至上百人要花上半年或更长时间的大型软 件项目则会有更多的项目计划内容。我们得按照项目的的特定情况量体裁衣。 三、制订的项目计划要现实 制订项目计划仅靠“个人经验”是不够的不可能面面俱到不要期希望于“个人经验”。解决的办法有两个方面。 是充分鼓励、积极接纳项目干系人包括客户、老板、项目组成员来参与项目计划
12、的制定. 是要充分利用一些历史数据。历史数据是宝贵的财富是可复用的资源。不仅要注意积累这些数据也要学会从中提炼出可以为我所用的数据。如项目计划的模板计划的资源数据等。 阿里巴巴实际的项目涉及的计划 在阿里巴巴完成一个项目大概需要涵盖以下几个计划 一FRD前的计划 1. 技术可行性 针对一些架构和技术难点找架构师资深开发工程师进行初步的讨论评估可行性。 2. 项目规模有一个初步的识别 最好这个时候能有ra进入识别项目范围和影响面通过以上两点得出项目大概规模项目工作量人日。 3. 项目预算硬件资源估算 项目中是否需要涉及服务器、网络、存储资源的申请 4. 外部合作方的识别 从项目原始需求中辨识出初
13、步的外部合作方例如外部接口、外部数据、外部资源依赖。 二里程碑计划是一个目标计划它表明为了达到特定的里程碑去完成一系列活动。里程碑计划通过建立里程碑和检验各个里程碑的到达情况来控制项目工作的进展和保证实现总目标。里程碑计划一般分为管理级和活动级。 1. 列出你认为是里程碑的点。 一般项目大致如下 71 Kickoff 2 需求评审 3 设计评审 4 代码评审 5 提交测试时间 6 正式发布 2.根据工作量估算得出每一个点的完成时间 3.每一个里程碑点对应的输入输出要明确。 需求评审输入frd输出uc 设计评审输入设计方案设计方案应该是建立在frd和uc的基础之上输出为设计文档。 代码评审输入分
14、支代码输出为评审结果。 提交测试时间输入为可测试的代码输出为qc记录 4. 里程碑点的跟进 定期去跟踪每个里程碑点的执行进度如果有发现不符或出入的地方及时调整。 三开发计划 1. 大部分的情况下一个uc已经是最小的工作单位了某些情况uc还需要再细化成任务wbs分解。 2. 分解完各个任务之间的依赖关系找出关键路径。 3. 根据项目成员的能力情况分配任务以及指定每个任务的时间。 4. 预留必要的查漏补缺时间。 5. 给出高度可视化的图表例如甘特图。 四测试计划 由测试方提供详细的测试点然后和项目经理一起确认。 五发布计划 个人觉得目前项目中scm提供的模板已经比较细致了内容具体可以参见他们的模板
15、。 需要注意的地方 1. 各项任务之间的依赖关系要思考到位。 2. 每一项任务的操作执行时间要明确不能含糊。 3. 多方确认发布计划评审。 8制定计划的方法论 在制定项目计划时就必须对项目需要的人力及其他资源、项目持续时间和项目成本做出估算。如果新项目 和以往的项目类似估算可以参考以前的成本费用。 现在已有一些用于软件成本估算的技术可供借鉴。这些估算技术各有其优缺点但以下几方面是共同的 事先建立软件的工作范围 以软件度量经验度量、相似工程类比的度量为基础做出估算 把项目分解为可单独进行估算的小块 制定 WBS计划是制定项目计划最主要的活动主要分为以下三个步骤 第一分解工作任务。 将一个总的工作
16、范围软件项目XXX逐渐细分到合适的粒度以便对任务计划、执行和控制。 第二定义活动依赖关 系。确定了项目中要完成哪些活动以后需要对这些活动之间的依赖关系做出定义。 第三分配时间和资源。完成工作任务分解并定义了活动的依赖关系后应该为每项活动分配相应的时间和资源。为活动分配时间 可以采用自下而上和自上而下两种不同的方法。自下而上是先估计最小粒度的活动所需要的时间项目所需的时间则取决于所有项目活动的关键路径时间自上而下 则是确定完成项目所需要的总的时间然后将时间分配给不同的活动。这两种方法在实际中都有应用很多情况下只能采取自上而下的方式因为大 多数项目都事先确定好了项目的交付时间。在软件项目计划中资源分配主要指人员的分配指定了时间资源以后应该指定人力资源。一项工作任务是否能够完成所需要的时间和人员是两个最主要的变量。在一定的范围内时间和人员是可以互换的。即增加人员会缩短工作时间延长时间会降低对人员的需求量但这种观点的害处在于管理者往往会认为所有的活动都可以互换时间和人力资源。 成本估算是对完成项目所需费用的估计和计划是项目计划中的一个重要组成部分 这里简要介绍以下几种. 1.经验估算法 进行估计的人应有专门.
