故事背景：

老和尚问小和尚：

你要烧一壶水

烧到一半

突然发现柴不够了

你怎么办？

小和尚A：

那就不烧了呗，没柴了还怎么烧水呢？凑合着用吧！

小和尚B：

那得赶紧到到隔壁尼姑庵去借点柴去，把水烧开了最重要了！

小和尚C：

没柴了，那就赶紧去找柴呗，还能怎么办呢？赶紧找回来柴，把水给烧开了！

小和尚D：

为什么会没有柴呢？提前准备好足够的柴就好了，这种事就不应该发生！

小和尚E：

那我会问您目前的水温够了么？够了话，就先这样了，如果不够，就再想办法呗！

小和尚F：

师父，为什么要烧水呢？您是需要开水泡茶，还是说需要洗脚，或者是做别的用呢？您需要烧多少水才够用呢？

很显然，对于同一个问题，小和尚们给出了自己不同的回答，而这些回答，体现的是各自的态度以及对各自的定位。

对于小和尚A，做一天和尚，敲一天钟，得过且过，不会想办法解决发生的问题，或者说懒得去寻找问题的解决方案。这种人在公司里是没有立足之地的！

对于小和尚B和小和尚C，着眼点是把任务完成，在出了问题时，会积极思考补救的办法，所以会想着去借或者去找柴火，目标是把水烧开了，执行力足够！

对于小和尚D，则会在在开始烧水之前，检查所需资源是否充足，极力避免问题的发生，这想法是极好的。但是在实际的项目过程中，资源往往是有限的，如果资源充足，就不存在项目管理的问题了。

对于小和尚E，当发现柴不够时，会询问是否师父是否可以接受目前的水温，即询问客户或者项目负责人是否可以降低产品质量，通过项目验收。这种情况其实应该在实际项目中避免的。不过，在这个变更过程中，小和尚E已经试图去了解用户的需求了，而不是单纯的负责烧水。

对于小和尚F，在开始烧水前，会与师父去沟通具体的需求，为什么烧水，烧多少水，烧到什么程度够用，这个过程就是确认项目需求的过程。只有通过这个沟通的过程，才能了解项目需求，最终交付客户满意的项目成果！

在日常的IT项目中，存在两类非常重要的角色：项目经理以及工程师，项目经理负责了解项目需求，规划项目过程，工程师则负责具体的执行。

回到“和尚烧水”的故事中，我们可以把和尚烧水看做一个项目，在这个项目中，师父是业务方，所有的项目需求都来自师父。而师父给出的需求是烧水，但是烧水做什么用，烧多少水，烧到什么程度够用，是作为业务方的师父没有明确说出来的，因此这些需求是需要项目经理去和业务方进行沟通并明确为可执行的具体需求。

小和尚A、B、C、D、E、F则可以看成是项目成员，当然还可能有其它的项目成员，比如有人负责拾柴，有人负责打水，有人负责烧水，还有人负责沟通项目需求，等等。

在这个烧水的项目故事背景下：

小和尚A纯粹的烧水工程师，只负责烧水，准确的说，只负责添柴火，别的不管；

小和尚B和C，在负责烧水时，想当然的把用户需求默认为把水烧开，不管烧多少水，所以他们的解决办法是借柴或者找柴；

小和尚D具备足够的风险意识，把风险规避掉，如果提前预知到柴不够，就会提前准备；

小和尚E则会在出现问题时，询问客户是否可以接受质量的降低，但是小和尚事先是不知道用户的需求的，有可能用户会接受，有可能用户会不接受；

而小和尚F则更像是一个项目经理的角色定位，会事先沟通用户需求，并根据用户需求来规划项目过程即项目资源。烧多少水，烧到多高的温度可以满足用户的需求。因为如果师父想洗脚，项目经理不会允许把水烧到100度，如果是要泡茶，项目经理会根据喝茶的人数，确定烧水的水量。

因此，在一个项目中，一个人如果定位自己的角色，就会有不同的结果。在这个项目中，A、B、C、D四个小和尚更多地把自己定位为烧水工程师；E、F两个小和尚更多地把自己定位为项目经理角色。

在这个项目中，如果老和尚只是需要水泡茶给自己喝，那么并不需要太多的开水，把水倒掉一大部分，把剩余的烧开，就可以了；如果老和尚想要泡脚，那么就没有必要把水都烧开了，水温达到50度左右就可以了，或者剩余的柴已经足够了，或者不要继续烧火了！

此外，在这个项目中，柴是关键资源，关键资源在实际项目实践中往往是不足够的，项目成功应定义为在资源限制条件下交付客户满意的项目成果。关键资源的缺失，往往代表着巨大风险的存在。项目经理应该提前规划项目资料，并做好项目风险的管理！

当然，要交付客户满意的项目成功，最重要，也是最基础的是把用户需求具体化，做好WBS，把用户需求具化为一个个边界明确的工作包！