都说管理者比干活的人更聪明。更善于总结思考。对应的从薪酬上也比其它寻常人会多一些。能者劳心不能者劳力。可是在劳心的过程中那些事情是须要劳心的呢？动脑子和动手能够理解为劳心与劳力，在项目中领导者脑子里应该装些什么。他应该去关注什么。假设从开发人员的角度而言。一个bug或者一个功能做与不做的影响是这个功能，由于你仅仅顾你的一亩三分地。

有这个功能锦上添花，没它也无可厚非。可是领导者所关注的就不再仅仅是某个bug或者某个功能，更准确的说就是他会从整个项目的角度去观察去关注一些细节。总在说宏观把控。那宏观把控包含哪些嘞？以下就说说笔者对这个问题的认识

业务的把控

就不说什么“业务为王”的老话了，可是作为领导者（尤其是敏捷开发中）一定要清楚新功能或者新用例在总体业务的位置。由于这直接关系到后面的版本号把控和进度把控的精确度。最糟糕的情况是废了九牛二虎之力做出来的功能或者说新特性不是客户所须要的（需求理解错误），假设把业务理清了不但能够避免上面的情况，也非常有可能去挖掘客户的潜在需求。

（曾经写的一个关于农民和科学家的故事）

分支（版本号）的把控

项目非常可能有非常多分支，做产品的团队发版的时候往往须要不止一个版本号。其它人能够不关心这些。可是作为项目经理你必须关注这些。由于你要保证用户每次升级的结果是稳定的，仅仅有稳定才会有下一步的功能的添加或者性能的提高。最重要的是稳定，安全永远是第一位的。假设没有足够的时间不要把改变核心功能的用例带上去，由于一旦有问题不是分分钟能改的，不是一个hotfix就能够搞定的。要保证全部的新特性都是经过严格測试的（我知道我又绝对化了）。

之前从网上看到一个关于分支管理的博客，直接把图拿过来了。一张图顶千言万语。

（图片来自于网络。假设这是您的图片请告知。定会标明出处！

）

技术把控

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

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

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

进度把控

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

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