PM项目管理工作经验总结分享
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
八、项目经理的素质要求
8.1 毅力 项目管理成败的关键是毅力：如果你不坚持，谁也不会坚持下去的。只要决定进行
了项目管理流程，就不要后悔或后退，唯有坚持，因为你拼命努力而离终点只差再迈出 一步,你却不知，最后当你决定放弃的时候也许就是你要成功之时。 8.2 交际能力
因为处于中介者需要将项目干系人、项目组成员及管理层进行良好的沟通。当你拥 有良好的交际能力将会使你无往不利。交际能力的强弱直接影响到项目资源调动、成员 能力的发挥。对决定项目的成败启着关键作用。 8.3 高尚品德
很多公司都有自己常用的生命周期模型标准，我个人用的是改进的瀑布模型，根据具 体项目再进行适当的裁剪。
四、各阶段输入输出
下表展示各阶段输入输出文档、代码、资料，只是个人经验并非必要也非全部，很明
显的就能看到，本流程主要体现软件产品项目的开发生命周期，对于产品的市场行为以及
系统交付后的运行维护阶段并没有涉及。
PM
SWE：软件开发工程师：软件设计及编码，在有些小公司还承担单元测试的任务 TC：测试主管：组织测试人员测试 TE：测试工程师：测试用例写作及测试 度量人员：项目进度管理，一般由项目组某人兼任，输出度量表 资料人员：项目中面向用户的文档整理，如安装手册，操作指南等。
七、项目管理工具
PM 可以采用项目管理软件对项目实施监管。目前，大部分公司都有自己积累的项目 管理模板，采用相对固定的项目管理工具，一般都是 microsoft 的 Project + EXCEL 模板 + WORD 模板 + PPT+VSS 配置库等。
Software Development Plan Software Requirements Specification
Software Design Specification Software Test Plan
Software Test Specification Software Test Report
1.3 术语及缩略语
缩略语
SOW AR CI CM PM SE SWE TE UT IT ST WBS SSS SDP SRS SDD STP STD STR SVD
术语和缩略语定义
Work Of Software
Work Breakdown Structure System/Subsystem Specification
管理流程是不可能靠项目经理一个人维持的，必须要大家支持你。但是这却需要你 多帮助别人，别人才会帮助你。不管团队成员发生什么事情，你要尽你所能去帮助他，
测试人员需要准备的文档主要包括：软件测试计划书、软件测试说明书、软件测试报 告；测试并不是一个单一环节，它是贯穿整个开发过程的，从需求的描述开始，测试就应 该开始了，但不是对代码的测试，而是制作测试用例，并且需要及时发现需求文档的问题， 帮助分析人员在前期就减少 BUG 的可能，设计过程中也离不开测试，道理一样。
试用版及用户资料 需求矩阵
五、基线文档
对于 PM 来说，制定有跟踪的各类文档，监督工程的实施进度、评估团队成员的绩效， 及时适当地调整任务，对于项目的顺利完成比较重要，文档可以根据项目具体情况进行必 要的增减，但任何一个项目绝对不能没有任何文档资料。PM 经常制定或评审的文档主要 有：
工作任务书、系统规格书、项目估算、立项报告、项目计划、工作任务分解、过程裁
阶段
输入
输出
说明
项目计划阶段 需求规格阶段
SOW AR
PPL WBS
Estimate Report PPL WBS CMP RMP TSP QAP
评估报告 项目计划 工作任务分解结构 配置管理计划 风险管理计划
Team Software 来自百度文库rocess
质量管理计划
SRS
软件需求规格书
STP
系统测试计划书
概要设计阶段 详细设计阶段 Coding、UT 实现阶段
PM
STC RTM
HLD
ITP SRS
ITC
RTM
HLD
LLD UTP UTC RTM
LLD TSP UTP UTC
Code UTR Defect RePort MTS
系统测试用例 度量表
概要设计 集成测试计划 集成测试用例
度量表
详细设计 单元测试计划 单元测试用例
缺乏管理经验，考虑问题经常从会技术出发，本末倒置。综合型人才担任项目经理是众望 所归。
三、软件项目生命周期
决定采用何种生命周期模型，是各项目经理根据项目特点、经验积累以及公司工作流 程等方面因素综合制定，生命周期模型有： A: 编码修正模型：未成型的系统规范－>不断的编码修正—>发布； B: 渐进模型：最初概念－>设计和实施最初原型－>不断的精化原型直到可以被接受（开 发一个版本－>交付该版本－>得到用户反馈－>并入用户反馈）－>完成和交付最终版本； C: 瀑布模型：软件概念<－>需求分析<－>架构设计<－>详细设计<－>编码和调试<－> 系统测试； D: 螺旋模型：确定目标，备选方案，约束条件－>识别和解决风险－>评价备选方案－> 计划下一个迭代－>交付下一迭代解决方法－>确定目标，备选方案，约束条件； E: 没有模型， 完全根据实际情况进行调整。
PM
二、概述
2.1 项目管理简介 项目管理大致又可细分为： 1：项目预算和计划 2：开发内容管理 3：时间管理（进度管理） 4：成本管理 5：品质管理（质量管理） 6：风险管理 7：配置管理 8：交流与项目跟踪调整 在一个完整项目的管理上，以上任何一方面的管理都非常重要，缺乏任何一环，都是
一个不完整的项目管理。现实中的绝大部分 IT 项目经理不能是仅仅对项目进行管理的人， 从某方面来说，应该是具备系统分析的能力，将大的项目划分成几个小项目来做，将周期 长的项目化分成几个明确的阶段的能力，并且合理地组织项目组人员进行项目实施，这需 要项目经理具有长远的全局观，对整个项目的生命周期、未来的发展都要有一个很清晰的 思路。
PM
剪表、风险管理计划、缺陷预防计划、缺陷分析报告、质量管理计划、质量审计报告、配 置管理计划、需求变更表、度量表、需求矩阵、timesheet、项目周报、项目月报、阶段结 束、项目结束报告等
对于 SE 和 SWE，一般有些公司 SE 由 PM 担任，有些公司由核心 SWE 担任，主要 完成项目的设计开发等技术上的文档：系统/子系统规格书、软件开发计划书、软件需求 规格书、软件设计说明书；
EPG：CMMI 要求有一个最高领导机构，一般公司由分管项目的最高领导担任； CPM：项目总监：下达工作任务书 PM：项目经理：组织和协调人员进行编码，项目进度控制，风险估计及处理，团队 建设 SE：系统分析师：系统结构设计，需求分析等 CM: 配置管理员：代码的版本控制及文档归档等 QA：质量工程师：软件过程指导及监督，如果没有度量人员，还要兼任软件过程的 度量工作
调查显示：渐进模型和瀑布模型在软件开发项目生命周期中比较普遍，这两种模型也 是被证明比较有效的两种模式，在开发带有极大成长性的系统、提供给管理者和用户可视 的项目进展情况、管理成本的可控性、管理中途变更、以及开发高可靠性的系统方面，有 着比较强的能力。
另外有约 40％的项目团队选择编码修正模型或没有模型，这两种状况更多的被证明 是：没有充分理解客户的需求、没有充分的理解架构、管理风险差、管理成本高、不能提 供给用户和管理者可视的项目进展情况。
PM
PM
工作整理文档
文件编号： 密级：
总页数 编制：
生效日期： 版次：Ver
正文 审核：
受控编号： 修改状态：
附录 批准：
（版权所有，翻版必究）
PM
一、简介 1.1 目的
对前期工作中关于PM的经验做出完整、准确、清晰、具体的文档归纳。
1.2 范围
本文档适用于个人工作总结、项目经理经验培训、软件项目和/或软件产品相关的所 有项目管理人员、开发人员、测试人员。
个人推荐： MS Word：制定项目开发计划，需求分析，方案设计等 MS Excel：日报，周报，分析图表，WBS，风险管理等 WBS Chart Pro：分解项目任务，估算项目规模 Project：制定计划日程表，Project 和 WBS Chart Pro 的互用相当方便 MS Visio：主要用来划一些流程图表，设计时用这个就比较多 MS VSS：配置库，建议整个项目要么都用 VSS，要么都用 CVS，以免麻烦。 PowerPoint：项目阶段报告，主要给领导汇报用的 飞鸽，QQ，MSN，Skype，OutLook，FoxMail：项目组内外部交流工具 如果能学会用 EXCEL 编写程序，开发项目管理模板，根据公司具体项目实际情况制 订的模板更实用，并且可以复用。
Software Version Specif ication
中文说明
工作任务书 分配需求 配置项
配置管理员 项目经理
系统分析员 软件工程师 测试工程师
单元测试 集成测试 系统测试 工作任务分解结构 系统/子系统规格书 软件开发计划书 软件需求规格 软件设计说明书 软件测试计划书 软件测试说明书 软件测试报告 软件版本说明书
PM
9) 绩效评估：对项目成员的绩效评估。
2.3 PM 人员构成 项目经理目前接触到的主要由三类人组成： 非技术出身，拥有管理知识的项目经理； 技术出身，才被提升上岗位的项目经理； 拥有技术出身背景，且拥有项目管理知识的项目经理。 非技术出身的项目经理，对技术外行，在 IT 行业很难服众。技术出生的项目经理，
资料人员主要完成产品中面向最终用户的文档，一般包括：软件版本说明书、安装手 册、实用手册等。
六、项目管理中角色及任务
项目经理承担承上启下的工作，处于项目的一线位置，必须明确关于自己管理的项目 的相关接口，可以方便的进行工作。
一般来说，根据公司大小情况，项目管理中各种角色的分配可能存在人员重合，但各 角色承担的任务还是比较明确的。
度量表
单元测试报告 缺陷报告 需求矩阵
集成测试阶段
TSP
ITP
ITC
TSP 系统测试阶段
STP
STC
正式版本发布和项目 关闭阶段
System Test RePort
ITR Defect RePort
MTS
STR Defect RePort
MTS
VDD MTS
集成测试报告 缺陷报告 需求矩阵
系统测试报告 缺陷报告 需求矩阵
需求规格说明是对用户需求文档的进一步细化，需求文档是对用户业务的描述和简单 分析，需求规格说明中加了一些重要的类的提取，业务用例的提取和说明，一些关键的活 动描述，这时需要用到 UML 工具画活动图，提取类，画类图等；面向对象的分析和设计 文档，通常在 OO 的过程中不叫系统分析和系统设计，而叫 OOA 和 OOD，或 OOAD，面 向对象的分析和设计，这个过程主要工具就是 UML 工具，类图，活动图，用例图，序列 图，状态图，包图等，可根据项目需要而取舍。这几个文档对于很多开发人员来说相当不 愿意输出，很多公司一般在开发完成之后进行补写，这也是导致项目后期开发、运维工作 占用原开发人员很多时间精力的原因所在。
2.2 PM 工作任务 泛泛总结一下 PM 工作内容: 1) 项目范围：你的项目做什么的？你们要为客户提供什么服务？从什么标志开 始？到什么标志结束？达到什么样的要求？时间？。。。。 2) 项目计划：把你的项目中所要进行的活动具体地落实，软件项目不要只考虑软 件开发的计划，因为你还有很多的事情要做，例如客户沟通、需求采集、商务、 安装部署、用户测试、试运行、维护。。。。。。。。 3) 资源计划：人员、设备、场地等等，不要只考虑你们开发本身，还有客户和周 围环境。。。。。 4) 项目成本预算：人员开销、设备购置、租金、项目活动经费、项目激励奖金、 客户应酬费用、日常开支等等 5) 风险评估：具体风险列表及其应对策略，规避风险的策略等等 6) 进度跟踪及控制：很多人作了一个进度表，从来就没跟踪或更新过，这样的项 目只有失败，可以采取分级跟踪，进度的调整和更新等等。。。。 7) 需求的采集和变更控制，至一点在软件项目中尤为重要。 8) 团队沟通：公司领导对项目的了解、团队内部的沟通。
和编码修正模型相对的是非常成熟的螺旋模型。螺旋模型是一种以风险为导向的生命 周期模型，它把一个软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风 险因素，直到所有主要风险因素都被确认。
几种生命周期模型各有差异，在具体的运作中，要根据不同的项目有不同的需求，最 有效的模型完全根据项目需求。
PM
8.1 毅力 项目管理成败的关键是毅力：如果你不坚持，谁也不会坚持下去的。只要决定进行
了项目管理流程，就不要后悔或后退，唯有坚持，因为你拼命努力而离终点只差再迈出 一步,你却不知，最后当你决定放弃的时候也许就是你要成功之时。 8.2 交际能力
因为处于中介者需要将项目干系人、项目组成员及管理层进行良好的沟通。当你拥 有良好的交际能力将会使你无往不利。交际能力的强弱直接影响到项目资源调动、成员 能力的发挥。对决定项目的成败启着关键作用。 8.3 高尚品德
很多公司都有自己常用的生命周期模型标准，我个人用的是改进的瀑布模型，根据具 体项目再进行适当的裁剪。
四、各阶段输入输出
下表展示各阶段输入输出文档、代码、资料，只是个人经验并非必要也非全部，很明
显的就能看到，本流程主要体现软件产品项目的开发生命周期，对于产品的市场行为以及
系统交付后的运行维护阶段并没有涉及。
PM
SWE：软件开发工程师：软件设计及编码，在有些小公司还承担单元测试的任务 TC：测试主管：组织测试人员测试 TE：测试工程师：测试用例写作及测试 度量人员：项目进度管理，一般由项目组某人兼任，输出度量表 资料人员：项目中面向用户的文档整理，如安装手册，操作指南等。
七、项目管理工具
PM 可以采用项目管理软件对项目实施监管。目前，大部分公司都有自己积累的项目 管理模板，采用相对固定的项目管理工具，一般都是 microsoft 的 Project + EXCEL 模板 + WORD 模板 + PPT+VSS 配置库等。
Software Development Plan Software Requirements Specification
Software Design Specification Software Test Plan
Software Test Specification Software Test Report
1.3 术语及缩略语
缩略语
SOW AR CI CM PM SE SWE TE UT IT ST WBS SSS SDP SRS SDD STP STD STR SVD
术语和缩略语定义
Work Of Software
Work Breakdown Structure System/Subsystem Specification
管理流程是不可能靠项目经理一个人维持的，必须要大家支持你。但是这却需要你 多帮助别人，别人才会帮助你。不管团队成员发生什么事情，你要尽你所能去帮助他，
测试人员需要准备的文档主要包括：软件测试计划书、软件测试说明书、软件测试报 告；测试并不是一个单一环节，它是贯穿整个开发过程的，从需求的描述开始，测试就应 该开始了，但不是对代码的测试，而是制作测试用例，并且需要及时发现需求文档的问题， 帮助分析人员在前期就减少 BUG 的可能，设计过程中也离不开测试，道理一样。
试用版及用户资料 需求矩阵
五、基线文档
对于 PM 来说，制定有跟踪的各类文档，监督工程的实施进度、评估团队成员的绩效， 及时适当地调整任务，对于项目的顺利完成比较重要，文档可以根据项目具体情况进行必 要的增减，但任何一个项目绝对不能没有任何文档资料。PM 经常制定或评审的文档主要 有：
工作任务书、系统规格书、项目估算、立项报告、项目计划、工作任务分解、过程裁
阶段
输入
输出
说明
项目计划阶段 需求规格阶段
SOW AR
PPL WBS
Estimate Report PPL WBS CMP RMP TSP QAP
评估报告 项目计划 工作任务分解结构 配置管理计划 风险管理计划
Team Software 来自百度文库rocess
质量管理计划
SRS
软件需求规格书
STP
系统测试计划书
概要设计阶段 详细设计阶段 Coding、UT 实现阶段
PM
STC RTM
HLD
ITP SRS
ITC
RTM
HLD
LLD UTP UTC RTM
LLD TSP UTP UTC
Code UTR Defect RePort MTS
系统测试用例 度量表
概要设计 集成测试计划 集成测试用例
度量表
详细设计 单元测试计划 单元测试用例
缺乏管理经验，考虑问题经常从会技术出发，本末倒置。综合型人才担任项目经理是众望 所归。
三、软件项目生命周期
决定采用何种生命周期模型，是各项目经理根据项目特点、经验积累以及公司工作流 程等方面因素综合制定，生命周期模型有： A: 编码修正模型：未成型的系统规范－>不断的编码修正—>发布； B: 渐进模型：最初概念－>设计和实施最初原型－>不断的精化原型直到可以被接受（开 发一个版本－>交付该版本－>得到用户反馈－>并入用户反馈）－>完成和交付最终版本； C: 瀑布模型：软件概念<－>需求分析<－>架构设计<－>详细设计<－>编码和调试<－> 系统测试； D: 螺旋模型：确定目标，备选方案，约束条件－>识别和解决风险－>评价备选方案－> 计划下一个迭代－>交付下一迭代解决方法－>确定目标，备选方案，约束条件； E: 没有模型， 完全根据实际情况进行调整。
PM
二、概述
2.1 项目管理简介 项目管理大致又可细分为： 1：项目预算和计划 2：开发内容管理 3：时间管理（进度管理） 4：成本管理 5：品质管理（质量管理） 6：风险管理 7：配置管理 8：交流与项目跟踪调整 在一个完整项目的管理上，以上任何一方面的管理都非常重要，缺乏任何一环，都是
一个不完整的项目管理。现实中的绝大部分 IT 项目经理不能是仅仅对项目进行管理的人， 从某方面来说，应该是具备系统分析的能力，将大的项目划分成几个小项目来做，将周期 长的项目化分成几个明确的阶段的能力，并且合理地组织项目组人员进行项目实施，这需 要项目经理具有长远的全局观，对整个项目的生命周期、未来的发展都要有一个很清晰的 思路。
PM
剪表、风险管理计划、缺陷预防计划、缺陷分析报告、质量管理计划、质量审计报告、配 置管理计划、需求变更表、度量表、需求矩阵、timesheet、项目周报、项目月报、阶段结 束、项目结束报告等
对于 SE 和 SWE，一般有些公司 SE 由 PM 担任，有些公司由核心 SWE 担任，主要 完成项目的设计开发等技术上的文档：系统/子系统规格书、软件开发计划书、软件需求 规格书、软件设计说明书；
EPG：CMMI 要求有一个最高领导机构，一般公司由分管项目的最高领导担任； CPM：项目总监：下达工作任务书 PM：项目经理：组织和协调人员进行编码，项目进度控制，风险估计及处理，团队 建设 SE：系统分析师：系统结构设计，需求分析等 CM: 配置管理员：代码的版本控制及文档归档等 QA：质量工程师：软件过程指导及监督，如果没有度量人员，还要兼任软件过程的 度量工作
调查显示：渐进模型和瀑布模型在软件开发项目生命周期中比较普遍，这两种模型也 是被证明比较有效的两种模式，在开发带有极大成长性的系统、提供给管理者和用户可视 的项目进展情况、管理成本的可控性、管理中途变更、以及开发高可靠性的系统方面，有 着比较强的能力。
另外有约 40％的项目团队选择编码修正模型或没有模型，这两种状况更多的被证明 是：没有充分理解客户的需求、没有充分的理解架构、管理风险差、管理成本高、不能提 供给用户和管理者可视的项目进展情况。
PM
PM
工作整理文档
文件编号： 密级：
总页数 编制：
生效日期： 版次：Ver
正文 审核：
受控编号： 修改状态：
附录 批准：
（版权所有，翻版必究）
PM
一、简介 1.1 目的
对前期工作中关于PM的经验做出完整、准确、清晰、具体的文档归纳。
1.2 范围
本文档适用于个人工作总结、项目经理经验培训、软件项目和/或软件产品相关的所 有项目管理人员、开发人员、测试人员。
个人推荐： MS Word：制定项目开发计划，需求分析，方案设计等 MS Excel：日报，周报，分析图表，WBS，风险管理等 WBS Chart Pro：分解项目任务，估算项目规模 Project：制定计划日程表，Project 和 WBS Chart Pro 的互用相当方便 MS Visio：主要用来划一些流程图表，设计时用这个就比较多 MS VSS：配置库，建议整个项目要么都用 VSS，要么都用 CVS，以免麻烦。 PowerPoint：项目阶段报告，主要给领导汇报用的 飞鸽，QQ，MSN，Skype，OutLook，FoxMail：项目组内外部交流工具 如果能学会用 EXCEL 编写程序，开发项目管理模板，根据公司具体项目实际情况制 订的模板更实用，并且可以复用。
Software Version Specif ication
中文说明
工作任务书 分配需求 配置项
配置管理员 项目经理
系统分析员 软件工程师 测试工程师
单元测试 集成测试 系统测试 工作任务分解结构 系统/子系统规格书 软件开发计划书 软件需求规格 软件设计说明书 软件测试计划书 软件测试说明书 软件测试报告 软件版本说明书
PM
9) 绩效评估：对项目成员的绩效评估。
2.3 PM 人员构成 项目经理目前接触到的主要由三类人组成： 非技术出身，拥有管理知识的项目经理； 技术出身，才被提升上岗位的项目经理； 拥有技术出身背景，且拥有项目管理知识的项目经理。 非技术出身的项目经理，对技术外行，在 IT 行业很难服众。技术出生的项目经理，
资料人员主要完成产品中面向最终用户的文档，一般包括：软件版本说明书、安装手 册、实用手册等。
六、项目管理中角色及任务
项目经理承担承上启下的工作，处于项目的一线位置，必须明确关于自己管理的项目 的相关接口，可以方便的进行工作。
一般来说，根据公司大小情况，项目管理中各种角色的分配可能存在人员重合，但各 角色承担的任务还是比较明确的。
度量表
单元测试报告 缺陷报告 需求矩阵
集成测试阶段
TSP
ITP
ITC
TSP 系统测试阶段
STP
STC
正式版本发布和项目 关闭阶段
System Test RePort
ITR Defect RePort
MTS
STR Defect RePort
MTS
VDD MTS
集成测试报告 缺陷报告 需求矩阵
系统测试报告 缺陷报告 需求矩阵
需求规格说明是对用户需求文档的进一步细化，需求文档是对用户业务的描述和简单 分析，需求规格说明中加了一些重要的类的提取，业务用例的提取和说明，一些关键的活 动描述，这时需要用到 UML 工具画活动图，提取类，画类图等；面向对象的分析和设计 文档，通常在 OO 的过程中不叫系统分析和系统设计，而叫 OOA 和 OOD，或 OOAD，面 向对象的分析和设计，这个过程主要工具就是 UML 工具，类图，活动图，用例图，序列 图，状态图，包图等，可根据项目需要而取舍。这几个文档对于很多开发人员来说相当不 愿意输出，很多公司一般在开发完成之后进行补写，这也是导致项目后期开发、运维工作 占用原开发人员很多时间精力的原因所在。
2.2 PM 工作任务 泛泛总结一下 PM 工作内容: 1) 项目范围：你的项目做什么的？你们要为客户提供什么服务？从什么标志开 始？到什么标志结束？达到什么样的要求？时间？。。。。 2) 项目计划：把你的项目中所要进行的活动具体地落实，软件项目不要只考虑软 件开发的计划，因为你还有很多的事情要做，例如客户沟通、需求采集、商务、 安装部署、用户测试、试运行、维护。。。。。。。。 3) 资源计划：人员、设备、场地等等，不要只考虑你们开发本身，还有客户和周 围环境。。。。。 4) 项目成本预算：人员开销、设备购置、租金、项目活动经费、项目激励奖金、 客户应酬费用、日常开支等等 5) 风险评估：具体风险列表及其应对策略，规避风险的策略等等 6) 进度跟踪及控制：很多人作了一个进度表，从来就没跟踪或更新过，这样的项 目只有失败，可以采取分级跟踪，进度的调整和更新等等。。。。 7) 需求的采集和变更控制，至一点在软件项目中尤为重要。 8) 团队沟通：公司领导对项目的了解、团队内部的沟通。
和编码修正模型相对的是非常成熟的螺旋模型。螺旋模型是一种以风险为导向的生命 周期模型，它把一个软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风 险因素，直到所有主要风险因素都被确认。
几种生命周期模型各有差异，在具体的运作中，要根据不同的项目有不同的需求，最 有效的模型完全根据项目需求。
PM