都說管理者比幹活的人更聰明。更善於總結思考。對應的從薪酬上也比其它尋常人會多一些。能者勞心不能者勞力。可是在勞心的過程中那些事情是須要勞心的呢？動腦子和動手能夠理解為勞心與勞力，在專案中領導者腦子裡應該裝些什麼。他應該去關注什麼。假設從開發人員的角度而言。乙個
bug或者乙個功能做與不做的影響是這個功能，由於你僅僅顧你的一畝三分地。
有這個功能錦上添花，沒它也無可厚非。可是領導者所關注的就不再僅僅是某個bug
或者某個功能，更準確的說就是他會從整個專案的角度去觀察去關注一些細節。總在說巨集觀把控。那巨集觀把控包含哪些嘞？以下就說說筆者對這個問題的認識
業務的把控
就不說什麼「業務為王」的老話了，可是作為領導者（尤其是敏捷開發中）一定要清楚新功能或者新用例在總體業務的位置。由於這直接關係到後面的版本號把控和進度把控的精確度。最糟糕的情況是廢了九牛二虎之力做出來的功能或者說新特性不是客戶所須要的（需求理解錯誤），假設把業務理清了不但能夠避免上面的情況，也非常有可能去挖掘客戶的潛在需求。
（曾經寫的乙個關於農民和科學家的故事）
分支（版本號）的把控
專案非常可能有非常多分支，做產品的團隊發版的時候往往須要不止乙個版本號。其它人能夠不關心這些。可是作為專案經理你必須關注這些。由於你要保證使用者每次公升級的結果是穩定的，僅僅有穩定才會有下一步的功能的新增或者效能的提高。最重要的是穩定，安全永遠是第一位的。假設沒有足夠的時間不要把改變核心功能的用例帶上去，由於一旦有問題不是分分鐘能改的，不是乙個hotfix就能夠搞定的。要保證全部的新特性都是經過嚴格測試的（我知道我又絕對化了）。
之前從網上看到乙個關於分支管理的部落格，直接把圖拿過來了。一張圖頂千言萬語。
（來自於網路。假設這是您的請告知。定會標明出處！
技術把控
技術選型應該怎麼做，分兩種情況：
從零開始：要考慮專案以後可能到達的規模，技術是否開源（方便排錯，能夠從很多其它的人那裡獲得幫助）。是小眾的技術還是廠商的規範，技術的活躍程度（用別人的框架發現bug是鬱悶的事情。比這還鬱悶的是這個框架遲遲不推出新版本號！）
半路公升級：千萬千萬不要在同乙個地方使用兩種有衝突的技術。我知道你有能力解決（程式猿的三大長處之中的乙個：傲慢），可是把時間浪費在讓兩個本不應該在一起的框架和平相處的事上豈不是有些傻。
進度把控
時刻保持backlog其中的bug是須要修復的。別以為不用修的bug放在那裡沒人領就沒事，團隊裡的人每人去看一次這將浪費整個團隊的有效開發時間。時刻保持本迭代中的bug是優先順序最高的，相信二進位制。相信科學。不要相信人的自覺性。不重要的bug放在那裡要麼是耽誤每乙個人的時間（人人都去看一眼），要麼有人誤領（更浪費時間）。
寫完了才發現事實上各個方面中能夠提取一下公因式（「把控」）。那麼巨集觀把控（就筆者眼下所了解的）能夠總結為幾個詞語：業務、分支（版本號）、技術、進度。
專案經理注意事項（3） 巨集觀把控
都說管理者比幹活的人更聰明，更善於總結思考，相應的從薪酬上也比其他平常人會多一些。能者勞心不能者勞力，但是在勞心的過程中那些事情是需要勞心的呢？動腦子和動手可以理解為勞心與勞力，在專案中領導者腦子裡應該裝些什麼，他應該去關注什麼。如果從開發者的角度而言，乙個 bug或者乙個功能做與不做的影響是這個功...
專案經理注意事項
專案經理是乙個專案的直接負責人，其最大的作用就是和客戶溝通獲取需求，然後根據需求合理安排自己團隊的資源。於是在開發過程中專案經理一定不要將 不知道 掛在嘴邊，做到十 知 是本分之內的事情。在開發過程中面對自己團隊的開發人員遇到的業務問題，千萬不能說不知道。下面是一段經典問答 開發人員 a 這個按鈕在...
遊戲專案經理工作注意事項
1.學會做什麼比怎麼做更重要 作為團隊管理者，應該要比所有人都清楚，什麼時間點該做什麼事情。專案在每個階段都會有不同的特點和人員構成，每個階段的工作重點也是不一樣的。2.有計畫的做事情 乙個團隊工作是否有序，是否能按期達成目標，首先看是否有有效的中長期版本計畫。很多人認為這是最容易做到的，其實不然。...