项目管理流程

ITIL IT 运维管理体系： IT 管理中的 PPT （ people 人； process 流程； technology 技术）； 标准化（是否有紧急故障处理流程）、工具化； 备份解决方案；灾备解决方案； 监控解决方案；上线（回滚）流程； 测试流程； 紧急故障处理流程； DB 恢复流程； 各种故障演练； 服务 service ： service 是向客户 customer 提供价值 value 的一种手段，使客户不用承担特定的成本 cost 和风险 risk 就可获得所期望 expected 的结果 outcomes ； 老板（价值）、员工（手段）； service management 服务管理： service management 是一套特定的组织能力，以服务的形式为客户提供价值； service provider-->resource-->capabilities-->transform-->valuable service(goods or service)-->customer-->core competence ITIL ， information technology infrastructure library ， IT 基础架构库，英国商务办公室从 20 世纪 80 年代开始开发的一套 IT 管理方法，已成为事实上的行业标准

这些"囧"事其中一些来源于《项目管理的最佳实践》，另一些则是 最近 个人工作过程 中 的体会。 一.缺少持续更新的文档 症状： 1.产品与需求文档不符 2.技术文档过时，无法保证技术的可延续性 3.没有记述项目的决策及项目决策原因和情境 4.缺少对项目变化或需求变化的评审与跟踪 二.鼓包现象 简单来说就是在项目“将要结束”的时候，所有这些额外的工作就突然冒出来了。如涉及到项目的外部影响、项目簇间的协调关系等等。 症状： 1.任何项目成员认为“以后会做”但却不在计划内的事。于是乎这些”以后“就是”遥遥无期“,或者临近项目结束时变成烫手的山芋。 2 .持续不收敛的缺陷和BUG 3.宣称在项目完成期限最后交付的文档 三.源头不保证质量 很多项目组成员并不总是认可”源头质量“的说法，他们往往会认为”别人会发现我那些错误“或者”质量那是测试实施部门的事“，而不认为自己需要对质量负责。而项目经理不可​能也无没有时间去评估每一个工作细节，所以他必须依赖每一个项目组成员的承诺。 症状： 1.在交付工作成果前没有评审或者当评审只是走过场应付形式。 2.对测试开发出的代码没有充分的测试。 3.不关注工作成果提交对项目的影响。 许多研究成果表明，项目的质量问题如果没有在源头发现，就要花数倍的成本在项目后期解决。 四、用人不当 症状： 1.项目组重复同样的表现 2.总是错过承诺的完成时间 3

在项目管理过程中，由于需求的变化，项目总是具有不确定性、易变性，踩坑对于项目管理工作者来说是家常便饭，甚至可以说，项目管理工作者的大部分工作时间都是在填坑。 项目频繁掉“坑”，抱怨和撂挑子只能爽一时，后续该做的事同样一个都跑不了。积极面对、冷静分析、借助资源和工具才是正确的应对方法。等你把遇到的坑都成功填上，你会发现，你的填坑力其实就是你的竞争力。下面就跟大家分析一些项目管理过程中常见的“坑”，以及如何避免“踩坑”。 一、项目管理有哪些坑？ 项目管理中遇到的“坑”虽然多，但因为都是在项目的生命周期中发生的，总结起来无非是发生在项目管理的启动、规划、执行过程中，涉及到范围、时间、成本、质量、资源、沟通、风险、采购、干系人、整合等项目管理的要素，下面挑几个典型的来具体说说： 1、跨项目资源分配不合理 我们在进行项目管理的过程中，因为公司效益的需要以及实际业务的不可控性，大多数时候都是多个项目并行的，这就会出现需要跨项目分配资源的情况。而资源分配中，资源冲突、超载负荷、不饱和等都是常见的问题。在有限的资源下，尤其是人力资源，如何确定优先级、如何最大限度地提高资源利用率，都是摆在项目管理者面前的难题。 2、项目进度延误 对于项目管理来说，进度延误是非常致命的问题：任务的时间延误、项目交付物的质量问题，皆会导致项目进度延误，带来成本超支。如果项目与项目之间存在关联

目录 产品项目开发流程 项目调研 项目立项 需求分析评审 原型设计 项目开发 项目测试 项目部署 后期维护 产品项目开发流程 目前市场上成熟的产品项目流程主要有项目调研，项目立项，需求分析评审，原型设计，项目开发，项目测试，项目部署以及后期维护等。 现基于市场上的开发流程以及以往的项目开发经验，个人对项目各个开发阶段进行描述以及项目整体开发流程进行总结。 项目调研 由于没有正式参加过项目调研，故省略...... 项目立项 主要由项目经理发起立项会议，组织相关人员参加立项会议并启动评审项目。在该阶段，项目经理提交项目立项申请书，该说明书主要包括以下内容：项目总体需求，项目目标，项目中技术难度，项目预期成果，项目主要开发人员以及项目总体开发计划（包含测试和验收）。 需求分析评审 一般的需求工程流程主要有 需求这一块，如果所在部门中并没有明确人员分工，就存在了一旦遇见和需求有关的问题，并不能立马解决以及没有相关需求文档资料查阅等问题。未来随着所在公司不断发展，建议由专门人员（并非开发人员）负责需求工作，对接客户需求。 在项目需求分析评审阶段，由于时间比较紧迫，最新开发的项目大概用了两周的时间。为了保障项目的顺利开展，我们不断对需求进行更改，评审会议也开了三次。但由于种种原因，并没有严格按照需求工作流程进行执行。 原型设计 基于项目立项申请书和项目需求文档说明书，项目经理确认项目开发架构

测试流程总结为： 需求分析（功能、环境、资源）-----需求评审---需求搞定，理解需求---测试计划---测试用例设计及评审---执行测试用例---发现bug-----提交bug----确认bug修复，关闭bug-----编写测试报告及总结-----编写安装文档或者使用手册-----结束 1、需求调研在软件需求分析阶段，测试就应介入参与需求调研，已测试的角度分析需求的可测性，可构思将来对其测试的方法、原则等，同时全面了解系统需求，从客户的角度考虑软件测试需要达到的验证状态，何鞋功能点需要重点测试，何些不需，已变来指定测试计划 2、执行测试计划 1）测试背景：a 软件项目介绍， b 项目涉及人员（研发、产品负责人） 2）测试依据;产品定义书、总体设计说明、详细设计文档、参考产品 3) 测试资源:a 测试设备需求、b 测试人员需求 c测试环境需求 4）测试策略：采取的测试方法、搭建那些测试环境、采取哪些测试工具已测试管理工具 5）测试日程：测试需求分析、测试用例辨析、测试实施（重点关注及投入资源） 简单内容描述：本次测试目的、对象、方法、范围、过程、环境要求、接受标准、测试人员、测试时间 3、需求review开发在完成软件需求之后，会提交需求分析文档，测试人员根据需求调研所了解的需求说明文档等资料，对需求文档进行review，检查文档是否满足需求，是否与需求一致 4

中国移动项目的传统行业，测试流程一套一套的，需求评审 -- 开发详细设计评审 -- 用例评审 -- 提测评审 -- 测试执行 -- 报告输出 -- 安排上线 -- 线上验收，很多会议是需要产研测全部参加的，时间投入很大，这原因是 因为项目/业务迭代周期是一个月上一次版本，有足够的时间去做这些，当测试全流程介入的时候确认能发现很 多问题，这里就引入一个词：质量前移 ，比较好理解，不是在测试执行才发现问题，而是将问题前移，移到需 求评审，设计评审，用例评审中去，这一步做的好的就是测试的一个方向：业务专家 ，看项目/产品的高度达到 了产品高度，从全局去考虑测试用例场景，对业务非常熟悉，提升影响力，开发/产品会来咨询你业务知识 唯品会的流程，核心是火车发布制，项目安排是每个星期发布一个版本，也就是每个星期只有一趟车，项目想 上线的话，就需要在指定时间上车，意思就是在规定时间开发测试打包完毕。整个项目的流程就是按照这个火 车开车时间来排期规划。（当然你要问到很多线上问题怎么办？紧急项目怎么办？ 春运不是也有临时车次这个 说法吗？） 在互联网行业的话，迭代速度明显加快，都是你追我赶的节奏，但很多流程也是必须有的。 需求评审会根据需求大小来看是否开展的，小需求的话，就直接是一份文档查阅就完事了的。 在唯品会的时候，所在团队有点做的比较好，就是提测环节，我们要求开发提测有输出，要求他们整理功能点：

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

目录 文件结构管理 流程进度 裁剪表 估算 测试计划 测试报告 文件结构管理 文件 子文件 三级文件 四级文件 备注 00项目管理 - - - - - 01KOM - - - - - 立项会议 - - - 02项目管理计划和报告 - - - - - 01项目计划 - - - - - 计划书 - - - 02构成管理 - - - - - 上述文件夹构成，bat工具可生成 - - - 03review管理 - - - - - review计划书 - - - 04过程管理 - - - - - 项目裁剪表 - - - 05测定和分析管理 - - - - - 基本测定情报，存放管理数据 - - - 06风险管理 - - - - 07培训管理 - - - - 08SQA管理 - - - - - 计划书 - - - - 报告书 - - - 09决定分析管理 - - - - 10成果物整合管理 - - - 03相关管理 - - - - - - QA - - - - 进度管理-各个阶段类似WBS - - - - 变更一览 - - 04进度管理 - - - - - - WBS - - - - task一览 - - - - 日程方针 - - 05会议记录 - - - - 06联络管理 - - - - 07估算 - - - - - - 估算表 - - 08课题管理 - - - - - - 课题 - - -

管理项目和管理房屋装修有很多相似点。首先需求分析-中式装修还是欧式装修，架构设计-绘制装饰图；接着模块实现-硬装，软装，水工，电工，木工，瓦工；再者联调-各工种合作；最后家具进场保洁交付-产品上线。 要想项目管的好，就需要客户需求提炼本质，架构设计的扩展性好，层级划分清晰，模块内聚，具体实施者做事靠谱，开发有实力，逻辑清晰，联调配合顺畅，测试case覆盖需求全面。 若涉及到结构件，电子件，还需要确认模具，EMC，若有无线传输，还需要无线准入测试，以及产品的认证。 大多数员工工作的主要动力是薪水，其次是兴趣。若把兴趣调动起来，工作效率就变高了。拉来项目的是老板，老板精通财务或市场，对技术是门外汉。因而公司组织架构对产品开发不是最优的，往往流程不畅。流程不畅往往会导致扯皮。这时很强的人格魅力，沟通技巧，处事的方法，深入浅出的技术解释能力，就会派上用场。真心诚意的和一线开发者沟通，效果最好。从经济效益出发，才能得到市场人员的赞同。 项目管理，心理要装着一条线（产品开发流程） ，各部门接口（考虑的方面全），抓住两头（需求，交付）。同时要学会控制自己的心情，不以对方修为高低，语言粗俗和高雅，都不需要记心里。学会适当的放空自己，放下心中以有成见，才能做到客观公正。 来源： CSDN 作者： 糟心的事太多，唯有写作可以解忧！ 链接： https://blog.csdn.net/weixin

　　个人整理的 系统集成项目管理工程师考试 资料，有需要的去下载(下载链接在最下面)吧。 目录如下所示： 第一章信息化基础知识 信息与信息化 政府信息化与电子政务 企业资源计划 (Enterprise Resource Planning,ERP) 客户关系管理 (Customer Relationship Management,CRM) 供应链管理 (Supply Chain Management ， SCM) 电子商务 商业智能 BI 第二章信息系统服务管理 信息系统服务管理 计算机信息系统集成单位资质管理 信息系统监理 第三章信息系统集成专业技术知识 信息系统集成简述 信息系统生命周期 信息系统开发方法 软件需求分析与定义 软件设计 软件测试 软件维护 软件复用 软件质量保证及质量评价 面向对象的基本概念 统一建模语言 (Unified Modeling Language,UML) 使用面向对象技术进行软件开发的最佳实践 ------RUP 面向对象系统分析 软件架构 软件中间件 数据库和数据仓库技术 Web Service技术 J2EE和 .NET 架构 工作流 常用构件标准 网络分类 OSI模型总结 网络拓扑结构 网络管理 网络服务器 网络交换技术 网络存储技术 网络接入技术 综合布线 机房工程 网络规划、设计与实施原则 第四章项目管理一般知识 项目目标、特点 项目干系人