项目计划书

实行软件工程项目管理： ▲　项目经理（负责人）：项目经理（负责人）对整个项目负完全责任，是指导、控制、管理和规范某个软件和软/硬件系统建设的人，项目经理（负责人）是最终对客户负责的人。 ▲　软件项目经理（负责人）：软件项目经理（负责人）对一个项目的所有软件活动负完全责任，控制一个项目的所有软件资源，按照软件约定与项目经理（负责人）打交道。 ▲　软件工程组： 软件工程组是负责一个项目的软件开发和维护活动（例如：需求分析、设计、编程和测试）的人员（包括管理人员和技术人员）。 ▲　系统工程组： 系统工程组是负责下列工作的人（既有经理也有技术人员）的集团：规定系统需求；将系统需求分配给硬件、软件和其它成分；规定硬件、软件和其它成分之间的界面；以及监控这些成分的设计和开发以保证它们符合其规格说明。 ▲　系统测试组：系统测试组是一些负责策划和完成独立的软件系统测试的个人（既有经理又有技术人员）的集团，测试的目的是为了确定软件产品是否满足对它的要求。 ▲　软件质量保证组： 软件质量保证组是一些计划和实施项目的质量保证活动的个人（既有经理又有技术人员）的集团，其工作的目的是保证软件过程的步骤和标准得到遵守。 ▲ 软件配置管理组： 软件配置管理组是一些负责策划、协调和实施软件项目的正式配置管理活动的个人（既有经理又有技术人员）的集团 总体流程如下： 计划阶段－》需求分析阶段－》软件开发阶段－

在有些项目的尾期，看似已经即将结束而实际上却是麻烦重重，由于种种原因没有人能说出项目结束的时间。 这些原因中有包括设计漏洞百出，客户因为看到结果后才意识到问题而导致的需求的频繁变更，设计进度计划没有半点准确性等等。这些问题在实际中实际上是很常见的，这里看到一位老兄站在管理层面上看待同样的这个问题的一些看法，转录如下--来自 leo's blog 项目修复－把有麻烦的项目带向成功 定义有麻烦的项目 首先，我们来定义一下什么叫有麻烦的项目，它们一般具有以下特征： 1、项目表面上已经进入后期，但是没有人能说出项目结束时间。 2、产品漏洞百出。 3、管理层已经无法控制进度，制定的进度计划没有半点准确性。 4、开发人员日夜加班，效率低下。 5、项目小组的 士气极度低落，失去了工作的激情。 像这样有麻烦的项目在行业内普遍存在，如果不采取一些措施来修复的话，项目注定会失败，什么是失败？失败项目的成本、工期远远超过估算，甚至项目被取消。作为项目经理，项目的负责人，我们有什么方法可以把这些有麻烦的项目拉向正轨呢？本人前一段时间亲身经历过一个像这样的有麻烦的项目，读过《快速软件开发》一书后，其中的“项目修复”一节使我受益非浅，成功的把项目拉向了正轨，本文在参考《快速软件开发》一书的基础上介绍一些实用的项目修复方案。 修复项目 修复项目有三个最基本指导思想： 1、筛选需求，缩减项目规模。 2

项目修复－把有麻烦的项目带向成功 定义有麻烦的项目 首先，我们来定义一下什么叫有麻烦的项目，它们一般具有以下特征： 1、项目表面上已经进入后期，但是没有人能说出项目结束时间。 2、产品漏洞百出。 3、管理层已经无法控制进度，制定的进度计划没有半点准确性。 4、开发人员日夜加班，效率低下。 5、项目小组的 士气极度低落，失去了工作的激情。 像这样有麻烦的项目在行业内普遍存在，如果不采取一些措施来修复的话，项目注定会失败，什么是失败？失败项目的成本、工期远远超过估算，甚至项目被取消。作为项目经理，项目的负责人，我们有什么方法可以把这些有麻烦的项目拉向正轨呢？本人前一段时间亲身经历过一个像这样的有麻烦的项目，读过《快速软件开发》一书后，其中的“项目修复”一节使我受益非浅，运用上面讲的一些方法后成功的把项目拉向了正轨，本文在参考《快速软件开发》一书的基础上介绍一些实用的项目修复方案。 修复项目 修复项目有三个最基本指导思想： 1、筛选需求，缩减项目规模。 2、注重短期的过程改善。 3、面对现实，放弃原计划，着手制定新的计划。 对于一个有麻烦 项目，很多人都还把注意力放在如何赶上原计划上，这样的项目，最重要的是怎么完成，完成！不要再幻想出现什么转机，项目已经有了麻烦，和原计划已经有了出入，所以，我们应该面对现实，把当前的事情做好。 如果你想改变项目的现状的话，动作一定要大一点

UML 动态图：胎动顺坐 ：状态机图，活动图，协作图，顺序图 状态机视图，活动视图，交互视图 1、 配置管理计划的内容： 软硬件资源，配置项计划，基线计划，交付计划，备份计划，变更管理，配置审计和评审 2、 配置状态报告 的内容： 产品描述记录 每个受控软件组件的状态 每个构建版发布的内容和状态 每个基线的内容 配置验证记录 变更状态记录 所有位置的所有配置项的安装状态 3 、工作说明书 的格式内容：口诀：人言，定量色交也犯法但付款承诺保密 P391 前言 项目工作范围 项目工作方法 假定 工作期限和工作量估计 双方角色和责任 交付件 完成以及验收标准 服务人员 聘用条款 收费和付款方式 变更管理 承诺 保密 4、种一果，必见鸡鸡 项目评估的内容 建设必要性和现实性 建设条件的评估 技术方案的评估 机构设置和管理机制的评估 社会经济效果的评估 社会效益的评估 综合评估 5、项目评估方法 项目评估法 和全局评估法 总量评估法和增量评估法 费用效益分析法 成本效用分析法 多目标系统分析法 6、沟通管理计划应该包括以下内容： （1）项目干系人沟通要求。 （2）对要发布信息的描述，包括格式、内容和详尽程度。 （3）信息接收的个人或组织。 （4）传达信息所需的技术或方法，如备忘录、电子邮件和／或新闻发布等。 （5）沟通频率，如每周沟通等。 （6上报过程，对下层无法解决的问题

项目整体管理的一个重要作用就是对5大项目管理过程组和44个项目管理过程进行有效的整合。整体管理贯穿项目启动到收尾的整个过程。启动过程的一个重要标志是项目章程的制定，有时候可能也可能是一次项目重要干系人参加的会议决议文件，但目的都是正式委任项目经理，确认资金已经到位，项目可行可以开始。如果项目还无法确认是否可行，则应该首先将项目的可研阶段作为一个独立的项目进行。 项目章程重点是项目经理确定，上项目的理由，总体的项目进度，预算和范围，干系人影响等内容。以下为一个项目章程的例子 CRM软件开发项目章程 基础信息 1.项目起始时间: 2006-6-1 到 2006-11-30 2.项目经理:张三 联系电话 13898888888 3.项目理由:结合**公司多年的销售和营销经验,**公司已经形成了一批潜在的客户群,**公司已经有成熟的软件体系架构 4.项目目标:以标准的客户关系管理理论为指导，结合公司的营销经验，在6个月时间里开发完成具备客户管理，市场管理，销售管理，服务管理，统计分析和Call Center六大功能的CRM客户管理管理软件。预算6个月投入为50万人民币。 项目管理方法论: 1.项目管理方法采用公司标准的项目管理和CMMI规程。 2.软件开发过程和方法采用RUP统一过程方法论 角色和职责 1.沃尔特:项目发起人和赞助人，负责监督项目 2.张三:项目经理，负责计划，监控项目

一、项目计划阶段 项目计划的好坏，对执行结果起到了决定性的作用，也是项目经理最大价值体现的阶段，到了实施阶段才能发现问题就已经晚了。 1、获得团队承诺 很多项目经理都会把计划看作是简单的工作内容排序或是工作内容罗列，这就没有获得团队承诺。 团队成员明确自己工作要达到的目标后，必须进行过程细化，得出具体的工作清单，工作清单上的工作项目组合后，可得到工作结果，并且执行者对清单上工作内容和结果有信心。 2、时间计划的颗粒度决定了项目的时间计划可信范围 例如计划中的一项任务完成用10天，那么其实际完成的时间误差，显然会远远高于计划用1天完成的任务。这是因为计划者或执行者并没有对10天完成的工作内容进行细分，所以计划就已经体现出很多未知风险。 如果想减少时间风险，必须通过对10天任务的细分来达到，例如把10天的任务，分解为5个子任务，每个子任务用2天完成，这样虽然增大了检查进度的工作难度(检查点更难沟通)，却起到了更早发现进度问题的作用。 3、风险大的技术点和营销点已经被控制和管理起来 在项目启动阶段，已经对重要的技术点作过基本论证，必须在计划阶段实现对技术点、营销点进行控制和管理，特别是团队没有实现过的功能要求、性能目标、营销假设必须得到检查与确认，把这些问题消灭在计划阶段。 4、可量化的进度里程碑决策点 计划的细分任务是可检查的最小点，如果对每个任务点进行检查管理成本过高

实行软件工程项目管理： ▲　项目经理（负责人）：项目经理（负责人）对整个项目负完全责任，是指导、控制、管理和规范某个软件和软/硬件系统建设的人，项目经理（负责人）是最终对客户负责的人。 ▲　软件项目经理（负责人）：软件项目经理（负责人）对一个项目的所有软件活动负完全责任，控制一个项目的所有软件资源，按照软件约定与项目经理（负责人）打交道。 ▲　软件工程组： 软件工程组是负责一个项目的软件开发和维护活动（例如：需求分析、设计、编程和测试）的人员（包括管理人员和技术人员）。 ▲　系统工程组： 系统工程组是负责下列工作的人（既有经理也有技术人员）的集团：规定系统需求；将系统需求分配给硬件、软件和其它成分；规定硬件、软件和其它成分之间的界面；以及监控这些成分的设计和开发以保证它们符合其规格说明。 ▲　系统测试组：系统测试组是一些负责策划和完成独立的软件系统测试的个人（既有经理又有技术人员）的集团，测试的目的是为了确定软件产品是否满足对它的要求。 ▲　软件质量保证组： 软件质量保证组是一些计划和实施项目的质量保证活动的个人（既有经理又有技术人员）的集团，其工作的目的是保证软件过程的步骤和标准得到遵守。 ▲ 软件配置管理组： 软件配置管理组是一些负责策划、协调和实施软件项目的正式配置管理活动的个人（既有经理又有技术人员）的集团 总体流程如下： 计划阶段－》需求分析阶段－》软件开发阶段－

商业计划书撰写指南 （本文《商业计划书撰写指南》转载自搜狐·理财频道： http://money.sohu.com ） 　　 商业计划书撰写指南 　　商业计划书， 商业计划书撰写指南实战 　　在融资过程中，创业者如何与风险投资者接触并建立良好的合作关系，除了创业者与风险投资家的直接面谈，一份精美而详尽的投资计划书是必不可少的，即便创业者具有良好的口头表达能力和逻辑思维能力。投资计划书不仅可以介绍项目本身所具有的技术条件和市场前景，而且对项目的背景、公司的状况、产品的战略定位，领导者的管理思路及财务情况都能进行清晰的阐述并展示在投资者面前，使投资者能够对项目形成整体把握，认为创业者已为项目的实施做了缜密的准备，从而表明项目的运作已经具备了确凿可信的条件，投资者还会据此认为创业者具有良好的敬业精神。 　　一份完整的计划书内容应包括如下主要部分：摘要；公司及未来； 管理；财务说明危险因素；投资回报与退身之路；经营分析与预测；财务报告；预测；图表信息。 　　对于各部分的编制要求我们作如下说明： 　　摘要：摘要是风险投资者首先看到的部分。通过摘要，风险投资者对你和你的计划书形成第一印象，所以摘要必须形式完美，叙述清楚流畅。 　　公司及未来：这部分要使风险投资者对你公司的几个主要项目及未来的发展战略有一定程度的了解，各专题既要独具特色，又要构成一个相关的整体。主要应介绍公司的自然情况、历史情况

本文已同步至 GitHub / Gitee /公众号，感兴趣的同学帮忙点波关注~ 第一章 引论 1、“项目管理知识体系”：应该包含所有行业、应用领域项目管理的具体知识、技能、方法和实践。 2、我们发的这本巨厚的书叫“项目管理知识体系指南”简称“PMBOK 指南”，PMBOK 指南的目的： 收录项目管理知识体系中被“普遍公认”的“良好做法”的那一部分。 形成的一个项目管理标准和框架，提供一套项目管理专业的通用词汇；适用于所有领域、行业的项目管理。 标准实践中可以加以选择和裁剪； PMBOK 指南只讨论单个项目的管理 PMBOK 指南只讨论项目管理的共性 它是一套项目管理的指南，并不是具体的方法论。 1. 什么是项目？ 项目是：为创造独特的产品、服务或成果而进行的临时性工作。 pmbok 告诉我们项目有三大特性： 临时性 、 独特性 、 渐进明细 。 1）项目的过程是临时的，但临时并不意味着时间短。比如：修建体育场鸟巢是个项目，这个项目用了好几年时间，这个时间很长。过程是临时的，指的是项目有明确的起点和终点，起点是立项的时候。终点是： 目标达成（正常收尾） 不能达到目标项目终止（有可能是没钱了） 项目需求不复存在 客户或发起人希望终止等等 2）结果的独特性：项目创造的可交付成果是独特的，所以导致项目的不确定性和风险。项目创造出来的结果，PMBOK 里叫做可交付成果。可交付成果

制定项目管理计划是对定义、编制、整合和协调所有子计划所必需的行动进行记录的过程。项目管理计划确定项目的执行、监控和收尾方式，其内容会因项目的复杂性和所在应用领域而异。编制项目管理计划，需要整合一系列相关过程，而且要持续到项目收尾。本过程将产生一份项目管理计划。该计划需要通过不断更新来渐进明细。这些更新需要由实施整体变更控制过程进行控制和批准。 编制项目管理计划需要整合诸多规划过程的输出。其他规划过程所输出的任何基准和子管理计划，都是本过程的输入。 事业环境因素 可能影响制定项目管理计划过程的事业环境因素包括（但不限于）： 政府或行业标准； 项目管理信息系统（如自动化工具，包括进度计划软件、配置管理系统、信息收集与发布系统，或进入其他在线自动化系统的网络界面）； 组织结构与文化； 基础设施（如现有设施和固定资产）； 组织过程资产 标准化的指南、工作指示、建议书评价准则和绩效测量准则。 项目管理计划模板。项目管理计划中可能需要更新的内容包括（但不限于）： ○ 根据项目的具体需要，“剪裁”组织标准流程的指南与准则； ○ 项目收尾指南或要求，如产品确认及验收标准。 变更控制程序，包括修改公司标准、政策、计划和程序（或任何项目文件）所需遵循的步骤，以及如何批准和确认变更。 以往项目的项目档案（如范围、成本、进度与绩效测量基准，项目日历，项目进度网络图，风险登记册，风险应对计划和风险影响评价）