1、本书大纲
2、认识项目管理
观点一：项目刚开始总存在说不清的成分
1903年，亨利·福特（Henry Ford）在创立福特汽车之前，并不知道客户需要什么样的产品，于是他就找人做市场调研，去挖掘社会公众到底需要什么
社会公众真正想要的东西到底是什么？有人说想要“快”！实际上，这是没有分清目的和手段。在这里，社会公众想达到的目的是“快”，而手段（东西）则是一个“更快的交通工具”。
问题来了，这“更快的交通工具”长什么样呢？人类总会犯一个错误：人总是用之前见过的东西，来描述一个未曾出现过的东西（见图1-2）。也就是说，客户基于他们的阅历与认知，习惯于把自己的需求套到现实中可实现的方法或物质中。在这里，社会公众见过马但没见过汽车，于是他们用“已经见过的马”来描述“还未见过的更快的交通工具（汽车）”，所以他们的回答才会是一匹跑得更快的马。
这样就很容易理解，为什么一把成果呈现给客户，就被要求修改了。因为在没看到成果之前，客户也提不出具体要求，而把成果交到客户面前时，这个结果就能刺激客户进行思考：客户拿着这个结果与头脑中的想象做比较时就会发现差距，于是不断提出修改意见。
可见，项目在开始时总存在说不清的成分，这就会导致一个问题——频繁的变更。说白了，这种频繁的变更是由项目工作本身的性质决定的。
观点二：项目是一个业务过程，而非是技术过程
工程师普遍特别实诚，他们盯着细节不放；原来的那匹马时速多少公里？50公里的话，我给你找个80公里的。原来的那匹马身高多高？1米的话，我给你找2米的。原来的那匹马体重多重？100公斤的话，我给你找个200公斤的……于是他们开始在技术指标上较劲！
如果不盯着技术指标，问题也许还能解决，但若只盯着技术指标，往往就容易沉浸在细节里面出不来了。这不仅使得问题得不到解决，还会把自己搞得狼狈不堪
针对业务的解决方案才是客户的真实需求。具体而言，面对客户所说的“想要一匹跑得更快的马”这个问题，我们从开始就不要盯着马本身提问，而是应该去问客户业务问题。这些问题可以是：你要马干什么呀？想解决什么问题呀？你要的这匹马要在什么情况下使用呢？使用时会遇到什么困难呀？总之，围绕使用的背景、环境、目的等业务问题进行提问，而不是围绕“对马详细描述”的技术问题进行提问。遇到问题以后不要试图仅仅解决问题本身，还要去解决问题所在环境的问题。
事实上，系统工程的一个基本原理就是超越系统本身解决问题，即N维系统产生的问题只有在N+1维系统中才能解决。
可见，要能把需求确认落地，实施者必须有很好的业务建模能力，并以咨询方式展开，也就是要推出自己的方案，快速地给客户展示合理的样例。一方面，这样可以较好地引导客户提出合理的需求，把他们的思路控制在可执行的范围内。另一方面，通过逆向反馈，推动客户确认需求，可以较大程度地避免理解上的偏差。
观点三：拥抱变更
客户每次提出变更，都是帮助我们逐步逼近事实真相。
很多人在遇到变更时，首先想到的是客户多么不可理喻，还时不时问一句“改是可以，但这是不是最后一次”。问题是，在没有看到最终结果之前，客户怎么知道这是不是最后一次呢？
变更来源于项目属性，与人无关
项目在本质上是独特的、临时的非重复性工作，要求使用有限的资源，在有限的时间内为特定的人（或组织）完成某种特定目标（产品、服务或成果）。项目的定义非常简洁，但是含义非常深刻
独特性说明项目所创造的成果存在与众不同的地方，即成果的不重复性。同样，为创造独特成果而开展工作的过程不仅具有临时性，也具有不重复性。这种“不重复性”会给人们在认识项目的过程中带来很多不确定因素，这就是项目的风险来源。
独特性、临时性和渐进明细性，是项目最显著的三大特性，其中独特性和临时性是最基本的特性，渐进明细性是在这个基础上衍生出来的。
观点四：项目的渐进明细
在项目中，需要渐进明细的方面包括：
- 项目目标。开始只有方向性的大目标，然后逐渐细化出具体的、可测量的、可实现的小目标。
- 项目范围。开始只有粗略的范围说明书，然后细化出工作分解结构（work breakdown structure，WBS）和工作分解结构词典。
- 项目计划。开始只有控制性的计划，然后逐渐明细，制订具体的实施计划。
渐进明细VS范围蔓延
在去商场前，甲计划买两套运动衣，可是到了商场后，他发现运动鞋促销，于是就买了一双——这是范围蔓延。在到达商场前，甲只考虑需要买运动衣，没有确定款式、色彩、价位，到商场后，看到了越来越多的商品后，甲慢慢对要买的运动衣的款式、色彩、价位有了明确的认识——这是渐进明细。
项目的渐进明细，一定要在适当的范围定义下进行，也就是要在项目的边界内进行，以避免渐进明细演变成范围蔓延。渐进明细与范围蔓延根本不是一回事，前者是必须做的，后者是必须避免的。
若有收获，就点个赞吧
0 人点赞
