书上就算讲了具体实践也不能信

这就是为什么书上只讲原则。

三年前的今天我发了一条广播，大意是说如果宇宙真的存在颠扑不破的规律，那“没有银弹”一定会是其中一条。读这本书的时候总是有种感觉：说的道理都是正确的，但除了原则性的指导思想，书中并没有给出实践性很强的具体操作指导，有种平淡乏味的教科书感。我觉得一方面来说，这可能正好是作者强调的平平淡淡才是真的良好管理氛围，另一方面，对于这些原则如何实施，要写成百试百灵的最佳实践，应该是不可能的。

比如我一直觉得，时间管理在很长时间里都将是我最大的敌人，可能在我有生之年都是。不论一个人是不是团队的leader，他至少是自己的leader，他必须把有限的生命分配给自己去使用，针对什么目标才能最理性地分配这项资源是一个永恒的问题，让我们跳过它，假设明确的目标已经制定，接下来怎么去找到时间的正确使用方式呢？

“如何诊断自己的时间”一节中提到，要了解时间如何耗用，从而据以管理时间，首先需要记录时间的使用情况。这个思路很自然，解决问题首先要发现问题。不过这的确非常困难，我曾经考察过一些做记录的工具，如浏览器插件和桌面小程序，甚至自己手打日志，用以统计一天的时间使用情况，但记录方式仍然太麻烦，粒度不好控制，尤其是对那些时间真的非常碎片化、跑脚本的20秒空隙可以刷个豆瓣、刷豆瓣的10秒中间还会被人找、不停在常规事务队列和紧急事务堆栈之间疯狂切换的同学来说，几乎无法操作。也许对他们来说，想办法从那样的工作状态中解放出来，才是最需要优化的地方。

书中提到，人员过多，常造成时间浪费，会议太多，也常造成时间浪费。但事实上，并不能用尽可能削减项目人员和会议数量作为节约时间的实践指导。某条路线上的人手问题造成的进度瓶颈通常都是浪费其他人时间的罪魁祸首，尤其是当瓶颈出现后才意识到这里会有问题的话，那简直是项目管理中不可饶恕的错误，消灭这个错误将会花费难以估量的资源。

而由于会议不够造成的沟通问题所浪费掉的时间，每次都会是难以承受的重磅噩梦。怎样的会是必不可少的最小集合，一直是各种项目管理方法论的焦点。举例来说，我觉得Scrum的解决方案很有代表性，也是理想情况下的一种最不坏的方法。

实际上，Scrum实践了本书中讲到的很多条时间管理的指导思想。在减少会议的方面，Scrum规定每日必有简短的站立会议，不能省略也不能冗长。但时间也不是白白获得的，在沟通方面肯定会有所损失，于是有项目准备会（甚至准备会准备会）以及项目总结会作为必要的补充。这个会议集合已经囊括了项目执行阶段所需要的一切。

团队时间管理跟个人其实很相似，了解团队是如何使用时间的，就有机会更好地管理时间。在使用记录这个问题上，Scrum把时间粒度设定为点数，实际上是准确度和实用性的某种权衡。对时间的记录并不会有直接加快进度的神奇功能，但可以用于诊断问题和令进度透明化。Story/Card系统和燃尽图都是为了这件事而设计的。解决问题是一回事，知道问题是什么应当是第一步。

书中还说到了减少打断的显著作用。我写程序的时候，要是可以没有人理我，效率会疯狂提高。相信很多人都会是这样，不光是写程序，其他类型的生产生活大致也应如此。这点明显是Scrum提供给工程师最大的好处（当然这也不是免费的，要付出形式化的代价），因为它真的可以做到，即使是一个进度非常紧的项目，工程师也能尽量避免不必要的打断，在这个意义上，Scrum是有提升效率的可能的，因为工程师获得了更多的积累大块时间的可能性。另外，需求更改可以认为是打断的某种变种，在Scrum中也会得到一些控制，但这会是另外一个话题了。

但用过Scrum的团队都知道，它同样不是一种放之四海而皆准的实践方式。银弹仍然是不存在的，不过尽管如此，无论采用什么方式，时间管理的原则是不变的，管理者存在的意义也许就是不断寻找效率最优和心情最舒畅的解决方案，不管是绩效方案还是项目管理、个人时间管理，最佳实践一定是不断修改演化的。从另一个角度来看，正在使用中的方案永远不会是对的，总会有各种问题，这是自然规律，不需要因此沮丧。