本书主要希望给读者带来几个方法：
1、为什么用提问式进行领导：
书中描述了了两种领导方式：
1、命令型：习惯性给员工指导或解决方案；
2、提问型：遇到事情总会先询问员工，向员工提问解决方案。
我是12年开始做项目经理，也先后负责过七八个项目，项目团队规模有1~2，3~4，5~8，到现在的8~20等等不同规模的项目团队，很幸运，大多数项目都成功上线以及最后收款，其中部分项目是不充分获得到客户的认可的，当然也没有到做砸的程度。
在项目管理的前期，我都基本是以书中的第一种方式，即为命令型的方式进行项目的领导，个人比较英雄主义，基本事必躬亲，而且希望别人完全按照自己的思路、做事模式去走，有几个比较典型的例子/反例：
1、我们每次系统上线前，都会准备一个上线的golive的计划，原来小项目团队，基本是我个人在准备，因为原来项目上的基本所有模块、大多数细节我都会比较清楚，所以基本出来的golive计划会有一些细微的偏差，但基本没有什么大的问题。今年上半年有一个项目，整体使用的技术可以说是大部分是在我技术盲区之外的，这次还是理所当然的我来排golive的计划，计划排出来之后，有大概和技术负责人过了一把，对，过了一把：
“
D：上线计划我排了一版，我邮件发给你了，你帮忙看一下，是否有问题，是否有需要补充/去掉的，时间安排是否合理；
P：我补充了几个小点，其他的应该没什么问题了。
”
OK了，按照正常，上线计划可能会预留10%的buffer，然后发出给客户。
未来一周正常按照计划进行，整个过程中出现较多的“意外”，导致没有按照计划能够部署上线，整体延迟了一周多，即为原来计划的2.5倍的时间，所以从这一整个结果来看，这个是一个完全比较失败的计划安排。后面由于一些其他的原因主动延期了项目的上线，没有造成太大的影响，但是如果这是一个航天项目，没能按时发射，那该是多大的后果啊。
那问题出现在哪里呢？当然整个安排、执行整个过程从结果来看确实存在比较多的问题，但是和这次相关的，我感觉主要有几个方面：
1、我的命令式领导的方式：在不了解过多细节的情况下，制定了计划/方案，希望客户DBA、项目技术负责人按照该计划/方案进行；
2、在确认计划/方案的时候，没有问对问题，或者说没有充分调动最了解系统的人思考。
如果再有个机会，针对上线计划这个事，后续我可能会这么做：
1、和技术负责人、模块负责人沟通清楚上线的目标；
2、不同模块各个负责人根据目标进行计划/方案编制；
3、内部一起Review整体计划的安排，确认整体方案的可行性；
4、和客户最终拍定计划的安排，并按照大家约定好的方式去执行。
OK，道理出来出来了，那我们怎么整体去做呢，
