IT项目管理(原创培训课件)

• 弄清具体情况，无论是在项目前期，还是在项目进展过 程中；
• 针对总体制定规划，针对具体事务避免头痛医头脚痛医 脚；
• 少猜测，探求更多的信息，信息就是力量，“聪明反被 聪明误”；
• 留出时间来思考、分析； • 大忌 “我们就开始开发吧”，习惯“预备、瞄准，放！
”
回顾及总结：
W理论：每个干系人（Stakeholder）都成为_获__胜__者__。 弄清底细：留出足够时间__思__考___与__分__析___ 。 项目管理思维模式：一切项目活动着眼于_项__目__干_系_。人
——通用电器公司总裁杰克·韦尔奇
沟通和互动是项目成功的基础
• 决定项目成败真正因素大部分是沟通能力而不是技术能力
• 让客户满意方式：尽量满足客户所有需求、合理降低 客户期望值；
• 要使客户满意项目，就要及时和客户做沟通，使客户知 道项目的进度，以便决定是否改变期望的目标程度；
• 项目管理，不是你做了些什么，而是客户方、你的领导 知道你做了些什么；
尽
三：不重要但紧急
交
1、处理一般性文件。
量
1、造成干扰的紧急事件。
给
2、看电视消磨时光。
别
3、归档本周所有文件。
去 做
2、打若干个沟通的电话。 3、帮助客户解决一个难题。
别 人 去
做
• 难点，如何区分是否重要、是否紧急；
• 技术型项目经理容易烦的错误，优先做喜欢的事情
平衡四：矩阵式项目组织和职能部门冲突
矩阵式组织的每个人员都涉及到双线汇报关系，项目组会着 重于眼前任务的完成，而职能部门会关注长期的能力提高， 当产生冲突时，如何平衡？
优点：有效利用资源、职能专业知识可 供所有项目使用、促进学习、交流知识、 沟通良好、注重客户。 缺点：双层汇报关系、需要平衡权利 矩阵式组织结构的管理难度有时足以抵 消其成本和易获得广泛的技术支持带来 的好处。
每个干系人（Stakeholder）都成为获胜者（Winner）！
Stakeholder在项目管理专著中往往译为“干系人”，指所有与项目成败有直接间接 利益关系的个人或团体。在软件项目中，往往企业的投资者、各级管理者、系统 使用者、公司客户，甚至包括企业的合作伙伴和竞争对手
W理论好处
• 明确项目的目标：共赢； • 影响项目经理思考决策问题的出发点（冲突）； • 将项目管理关注度转移到“人”上来；（角度全面，
第三部分：需求管理
需求理论中著名的理解偏差漫画
需求作为其他活动开展的基础，如果工作在一个低质量的需求上，其产品质量问题 将是致命的，其最好的结果是制造了一个用户不需要的低缺陷率产品
我们需要特别关注需求的准确性 缺陷被修复的代价 COPQ: Cost of Poor Quality
缺陷被发现的阶段
关注最终点）
将项目成功的标准 关注点转移到人上来，让 人满意是最为重要的！
影响IT项目管理成功的关键要素
是否建立了良好 的、积极的、团 队合作的文化氛
围；
项目的目标、范围 是否明确；
是否具有有效、 全面的项目管理， 严格的变更控制；
项目可行性研究 和计划是否完整
和适当；
项目的组织是否 健全、稳定；
—项目管理关键要素
• 课程约束 – 按时出席 – 手机调至静音 – 积极参与课程案例讨论, 可随时提问及分享
• 课程假设 – 学员曾经直接或间接接触过IT项目
• 课前准备 – 分组，并选出小组队长
调查：参与或管理过IT项目的请举手！
互动：选定一个参与度最高的项目，说出你在项 目中的角色，你认为此项目是成功的还是失败的， 然后阐述下你认为重要的影响因素；
关注需求：理解客户需要解决的问题
正确理解客户需求：在需求收集活动中，最容易犯的错误是把需求收集的目标理 解为：用户打算要什么产品？而需求收集活动真正的目标是：用户拿产品做什么？
需求收集记录下用户期望如何使用产品去解决客户的真 正问题，才会真实而完整地记录下客户明确的和隐含的 需要。在项目需求还不是十分清晰的早期阶段，直接把 需求理解为产品功能，会由于技术域和问题域的“鸿沟” 产生不完整的和错误的需求。也就是说你必须站在客户 的角度去真正理解产品完成后，被应用的场景，而不要 太关注产品本身。
• 什么是可以预见的项目背景和存在的问题？
• 项目提出人（或客户）期待什么样的成果？
• 完成所需项目资源匹配情况？
• 项目干系人？
案例分析二：五分钟
识别项目干系人失败的案例
项目干系人分析的四步法：
• 步骤一：无遗漏地识别出项目干系人 • 步骤二：按重要性对干系人进行分析 • 步骤三：按支持度对干系人进行分析 • 步骤四：项目干系人分析坐标格
• 分析需求背后的需求，切忌头痛医头，脚痛医脚。 • 深入分析和发现客户的阴性需求，通过各种方式手段平衡
满足客户需求；
第四部分：沟通、还是沟通
沟通和互动是项目成功的基础
公司
客户
项目经理
分包商/ 供货商
形式多样 沟通及时、多渠道 认真倾听 真实汇报 / 反馈 明确指示
员工 管理就是沟通、沟通再沟通。
项目目标不 清晰
• 需求过多；需求不完整；需求不稳定；需求模棱两可； • 大量的返工，造成资源更加紧张 • 错误的需求往往在项目生命周期的晚期才被发现
人员 未到位
• 团队的成员构成大多是凸现个性，追求随意 • 项目经理的错误人选； • 缺乏支持的高层管理
拙劣的质量 பைடு நூலகம்理
。。。
• T产品工程的质量没有被贯彻到项目实际活动中 • 不成熟的技术 • IT产品的质量工程活动本身的不完善 • 。。。
项目经理思维模式：一切项目活动首先着眼于干系人
• 项目管理首要且重要任务，识别项目干系人及其角色 • 了解、分析和确定他们的需求和期望 • 设法满足和影响这些需求、期望以确保项目能够成功 • 项目经理必须从只关心做事转移到非常关注干系人 • 项目全过程要树立干系人思考模式，切忌头痛医头脚痛医
脚
摸清底细
什么才是成功的软件项目？
• 依据合同完成项目 • 满足客户的要求 • 不超预算 • 学有收获 • 赢得信誉，建立品牌 • 成为公司的优势
• 符合时间、质量、成本，不一定是成功的项目； • 不同角色角度定义的成功标准不同； • 最难定义的是项目经理这个角色，满足多角色目标（
公司、团队、个人）；
软件项目成功标准：W理论
成功的IT项目管理
学习了项目管理体系就可以成功的管理项目了吗？我们还需要 关注什么？
• 体系性知识体系可通过阅读书籍获得； • 个人参加项目管理培训感受；（理论+实践+意识）
课程重点关注：
• 项目管理关键要素； • 实战经验、失败教训； • 通过实际案例学管理；
Skills vs. Competencies like the iceberg...
• 沟通是具有目的性的，保障每一次沟通的有效性都是最重 要的事
• 注意非正式沟通，是正式沟通的有力补充
客户满意度曲线
满意度
什么是幸福？什么是满意？
有意识的“降 低客户期望”， 至少不随意的 提高客户期望， 从而变相的达 到提高客户满 意度的目标。
启动
过程中
验收
时间
案例分析三：十分钟
两个软件项目案例：过程相似，结果却大相径庭
需求控制：验证和确认 (V & V)
• 验证：正确的构造了产品
– Verification: Build the product right
• 确认：构造了正确的产品
– Validation: Build the right product
第26页
确认活动目的在于让客户可以确认其要开发的最终产品是满足客 户期望的。一方面，可以通过完成后的最终产品进行确认，但是 制造一个“错误产品”的代价是极其高昂的，所以开发过程中的 确认，特别是早期的需求确认活动是十分关键的
是否建立了有序的、 有效的、良好的沟
通渠道；
是否获得领导的积 极支持；
第二部分：摸清底细
案例分析一：十分钟
一个售前项目的策划：M省移动传输网项目
项目分析要素：
商业目标 建立客户关系
实施策略 以客户为中心
进入新市场
关注质量
• 项目的来龙去脉？
获得利润
关注成本绩效
• 项目对公司目标是什么？
• 项目带给客户的价值是什么？
2000 28 0%
23 50%
49 100%
为什么会导致IT项目的高失败率
项目进度不 切实际
• 大多数IT项目进度由不具备准确估算的人作出的（市场人员或客户），死亡之旅 • 只关注快速实现，忽略过程验证；只考虑功能，忽略了性能；只关注现在，忽略了后期维护铺垫 • 构建系统80%在前80%进度内完成，而后20%同样花费相同的工作量
关注执行
项目中间的大多数问题是出在执行层面，而不是计划层面 项目成功的关键不是编写出一个伟大的计划和蓝图，而是目标和计划
可以被落实，使得项目可以坚持到终点
第六部分：平衡的艺术
何为优秀的项目经理：
不是给你绝对充足的资源让你将项目做得尽善尽美，而是 在一定的资源范围内，是否取得了最大价值的结果（让更 多、更加重要的的干系人满意）；
对于项目经理： 一个IT项目成功的项目衡量标准是什么？项目经 理从哪些关键行动要素保证项目成功？
本次课程重点：不包括以下部分
• 项目定义：为完成某一特定的产品,服务或结果所做的一 次性努力
• 项目管理定义：在项目活动中运用知识、技能、工具和技术 来达到项目的要求
• 项目管理知识体系PMBOK：对项目管理所需的知识、技能和 工具进行的概括性描述
需求控制要领：抓住客户的两点担心，花钱和麻烦