都说管理者比干活的人更聪明，更善于总结思考，相应的从薪酬上也比其他平常人会多一些。能者劳心不能者劳力，但是在劳心的过程中那些事情是需要劳心的呢？动脑子和动手可以理解为劳心与劳力，在项目中领导者脑子里应该装些什么，他应该去关注什么。如果从开发者的角度而言，一个bug或者一个功能做与不做的影响是这个功能，因为你只顾你的一亩三分地。有这个功能锦上添花，没它也无可厚非。但是领导者所关注的就不再仅仅是某个bug或者某个功能，更准确的说就是他会从整个项目的角度去观察去关注一些细节。总在说宏观把控，那宏观把控包括哪些嘞？下面就说说笔者对这个问题的认识

业务的把控

就不说什么“业务为王”的老话了，但是作为领导者（尤其是敏捷开发中）一定要清楚新功能或者新用例在整体业务的位置，因为这直接关系到后面的版本把控和进度把控的准确度。最糟糕的情况是废了九牛二虎之力做出来的功能或者说新特性不是客户所需要的（需求理解错误），如果把业务理清了不但可以避免上面的情况，也很有可能去挖掘客户的潜在需求。（以前写的一个关于农民和科学家的故事）

分支（版本）的把控

项目很可能有很多分支，做产品的团队发版的时候往往需要不止一个版本。其他人可以不关心这些，但是作为项目经理你必须关注这些。因为你要保证用户每次升级的结果是稳定的，只有稳定才会有下一步的功能的增加或者性能的提高。最重要的是稳定，安全永远是第一位的。如果没有足够的时间不要把改变核心功能的用例带上去，因为一旦有问题不是分分钟能改的，不是一个hotfix就可以搞定的。要保证所有的新特性都是经过严格测试的（我知道我又绝对化了）。之前从网上看到一个关于分支管理的博客，直接把图拿过来了，一张图顶千言万语。

（图片来自于网络，如果这是您的图片请告知，定会标明出处！）

技术把控

技术选型应该怎么做，分两种情况：

从零开始：要考虑项目以后可能到达的规模，技术是否开源（方便排错，可以从更多的人那里获得帮助），是小众的技术还是厂商的规范，技术的活跃程度（用别人的框架发现bug是郁闷的事情，比这还郁闷的是这个框架迟迟不推出新版本！）

半路升级：千万千万不要在同一个地方使用两种有冲突的技术，我知道你有能力解决（程序员的三大优点之一：傲慢），但是把时间浪费在让两个本不应该在一起的框架和平相处的事上岂不是有些傻。

进度把控

时刻保持backlog当中的bug是需要修复的，别以为不用修的bug放在那里没人领就没事，团队里的人每人去看一次这将浪费整个团队的有效开发时间。时刻保持本迭代中的bug是优先级最高的，相信二进制，相信科学，不要相信人的自觉性。不重要的bug放在那里要么是耽误每个人的时间（人人都去看一眼），要么有人误领（更浪费时间）。

写完了才发现其实各个方面中可以提取一下公因式（“把控”），那么宏观把控（就笔者目前所了解的）可以总结为几个词语：业务、分支（版本）、技术、进度。