作者多年经验总结，指引项目管理方向

终于看完了，历时20天，每天30分钟左右，当然，有那么一周没有时间看，整个算下来预计可能是5-7小时左右。

当然，我对PSP和TSP以及CMMI都不太熟，原因就是个人是从运维走向开发，半路出家，每天救火，疲于奔命了。人说三十而立，目前的状况只能说稍有改善。救火的性质依旧没有变。
公司内部的精英被分散在各处，也都是疲于奔命的状态。

看到前言中写到，作者之前在推广CMMI等软件开发标准做出很大的努力，突然想起被同事们各种吐槽CMMI的文档。出发点不同，过程和结果自然也不同。
CMMI倒是被组织内部的软件开发人员诟病多年，认为极大的拖慢了开发速度。
而且，一般项目都是在项目结束时才开始写CMMI的各类文档。

幸好，在附录部分，有简单提到PSP、TSP和CMMI这几种过程方法。
看书的过程中也进行过搜索，发现这些概念都是好多年之前的呢，真是out了。
不过，迟点儿发现总比没有发现好，什么时候学都不晚。

OK，下面说说这本书，当然，是我认为比较重要的部分。
作者毕竟在软件界混了多年，各类管理、团队问题都屡见不鲜，提出了常见问题的应对方案和解决方法，有不少都是可以借鉴的，因为我们可能知道，但在处事时会忽略。当然，也有他处理不了，对此给出的意见就是及时换领导。
至于团队成员，我这边的现状就是大部分成员都是上面指派的，少数是我直接招聘的。对此我想说，有招聘的机会多多使用吧，自己招来的人，怎么说都比上面直接分配的人要好得多。团队中有站着名额不做事儿的，没办法通过上面调整的，那还是今早离开吧。
计划的制定非常重要，更重要的是随时更新计划，并让上层知悉。这一块在我这边处理得很不好，上上下下都是习惯性的指定完计划就按照自己心中的计划开始进行了。后面需要注意并落实。
捍卫计划是绝对必要的，我们不能期待上层管理者直接接纳，我们需要据理力争，这个“理”就是详尽的计划（当然，最初制定的计划和最终的计划还是有差异，随着对项目了解的深入，计划会被不断更新）。
最后就是自己，我们要带领团队冲锋陷阵，更要以身作则，给团队以示范。