??????? 最近，公司在開發一款新的APP項目，由于APP項目本身的時效性要求非常高，所以項目本身的工期被限制到很短的時間，大概就一個月的工作日時間。在這一個月的時間內，項目本身是從零開始搭建的，并且要承受需求變更、目標變更的風險與開發人員不足的缺陷。這就使得團隊之間的配合要非常緊密，合作無間，并且在業務邏輯上不能出現大的偏差與錯誤，對團隊的整體素質要求比較高。而令人沮喪的是，我們的團隊是剛剛組建起來的，并且團隊中有經驗的人員又相對較少。

??????? 說到這里，可能有人會說，既然是這樣，那項目怎么可能在這么短的時間內完工呢？其實一開始定計劃的時候，我也是這么想的，按照以往的開發經驗，確實很困難，因為敏捷開發崇尚的每周40小時工作制是有它的道理的，程序猿其實是一個半腦力，半體力工作者，每天集中精力經過8小時的精神上與身體上的摧殘，基本上已經耗盡了身體上的能量。剩下的時間是需要好好回顧一天工作中所遇到的問題，及尋求解決方案，這樣才能達到最高的效率。每天長時間的體力勞動（加班）會降低程序猿的思維敏捷度，導致生產出來的代碼會有很多bug，從而導致生產效率下降（生產效率＝出產的代碼/花費的時間）。所以加班不是個好辦法。當然，在項目后期，大家的精神會因為聯調（指前端與服務器端的數據交互調試）達到長時間也可以高度亢奮的狀態，這也就是為啥通常在項目上線的前兩天，大家都要加班加點的工作，而不是按部就班的完成上線工作。所以，當初在領導說出項目的上線日期時，我的第一感覺就是，以我們團隊目前的能力（包括人員素質，人力資源）是肯定完不成的，就算加班也完不成。但是領導有所要求，作為團隊中的一員，應該盡自己所能的去做。（前提是要保證自己不會坐馬桶死）然后，我們的團隊開始了一個“盡力而為”的開發過程（其實，大多數項目，我們都是在人力不足，工期短的情況下加班加點熬出來的，這是一個很殘酷的現實）。

??????? 這次的開發出現的問題完全在我的預料之中，包括由于開發人員對于需求的理解所花費的時間、開發人員開發水平不足所帶來的開發效率下降，負責某項工作的人員由于人手不足導致整個項目開發出現瓶頸，旱的旱死，澇的澇死以及必要的不同開發角色之間的相互溝通所耗費的時間。目前，我們還在開發中，并且截止日也快到了。所以在這么一個時間節點，我對整個項目進行了一下反思與總結，我的想法是試圖從項目管理的視角上去盡量優化整個項目的開發進度，以降低除硬性開發時間上的其它時間成本。這里強調下，我沒有學過PMP，也不大懂CMMI，我的想法完全是根據自己以前的一些工作經歷再加上一點點的意淫出來的，所以肯定有鬼扯的成分在里面，如果各位看了覺得不靠譜，那就當我在放屁就好了，嘿嘿，請不要噴我就行。下面，我就向大家說下，我對于項目的理解。

??????? 項目的管理，包括需求管理、標的管理、設計管理與開發管理。項目管理是一個需要一個人主導并且全員配合執行的過程。

??????? 項目管理以標的管理最為重要，也就是我們這個軟件是用來干嘛的。這個問題也許看起來很好回答，但實際上并不是那么容易。因為在項目的每一個階段，標的是不同的。也許在第一個階段，軟件的目的是用來演示的，第二個階段是用來給內測用戶試用的，第三個階段才是公測給所有用戶使用的。項目標的決定了開發策略，是用原型開發，還是用迭×××發取決項目標的是什么。而開發策略不同，會直接影響之后的開發進度。所以項目的決策人在項目伊始階段，一定要交心以及頻繁的溝通交流，確定好項目標的。一個團隊內對于軟件在某一個時間段上的目標必須是一致的，這樣才能有凝聚力。當然，確定項目目標不是一個輕松的活，是需要領導們把想法從抽象到精華的過程，而且是需要技術決策人與項目決策人深度交流的一個過程（所以這種費腦子的事還是給領導們去做吧，哈哈）

??????? 需求管理，為啥程序猿都恨產品狗？因為需求變更。但產品也是無可奈何，因為人的思維本來就是不斷進化的，有些東西不畫出來，不多想一下就不可能更深入的理解，一旦進行了深入理解，想法一擴展，原先的設計就會被自我否定掉，然后就出現了萬惡的需求變更。那么在需求變更的情況下，能夠保證項目的進度么？這個要看情況，如果是顛覆性的，比如今天我要生產蘋果，明天改生產梨子了，那么可能就保證不了了。但是如果今天我要生產一個紅蘋果，明天改成生產一個青蘋果，我認為還是有辦法的。通過軟件架構的設計，我們可以做到，在一定范圍內的需求變更情況下，把項目進度的延期降到最低。所以如果我們以項目進度為最高優先級，對于需求管理，第一要控制需求變更的范圍，第二就是要設計一個好的系統架構。需求管理，在軟件工程上是一個很重要的課題，包括需求文檔管理與需求開發管理，在傳統的需求管理中涉及到大量的跟蹤，追溯文檔，并且要與后期的開發代碼對應。不過在如今這個快節奏的開發過程中變得不再適用，但并不代表我們不需要需求管理。我們應該讓需求管理輕量化，比如通過一個excel來記錄需求變更的過程以及原因，并且記錄需求變更的通過原因及否決原因。這樣產品經理可以通過需求變更了解到自己在產品設計中進入的誤區，程序猿可以了解到現在有哪些功能是應該要做但沒時間做的。決策者也有一個直觀的視圖了解到目前軟件具有哪些功能，是否達到了階段性的項目標的。

??????? 設計管理，在確認項目標的與需求后，就應該進行架構設計。架構設計對于一個項目的開發及后期的變更起到了至關重要的作用。架構設計要根據項目的人員配比，人員水平，需求變更以及項目進度計劃來確定。它不僅僅是一個技術決策，更是一個管理決策。比如在人員配比失衡的情況下，如負責前端的開發人員較多，但負責后端的開發人員較少，那么這個時候，還是按照傳統的開發方式，將所有的業務邏輯全給后端人員去做，前端人員只負責視圖和套模板的話，無疑是在本來就很擁堵的馬路上放行更多的車輛。又比如在一個需求頻繁變更的場景中，還是根據功能來設計API的話，那后期的代碼更改，不管對前端還是后端來說，就是噩夢。架構設計也不是一個一勞永逸的工作，針對不同的項目標的，架構也會不斷的更新。比如第一階段的架構設計主要是實現系統功能，第二階段的架構設計需要優化系統性能，那么第一階段只需設計好業務框架、數據庫結構。第二階段再來設計緩存策略，心跳監聽等。

??????? 開發管理，開發管理是始終穿插在開發過程中的。包括項目進度跟蹤，聯調計劃執行、測試計劃執行。他們有一個共通點，就是都是需要多人協作完成的。一旦涉及到多人協作的問題，就需要一個協調者來組織。因為大家在都很忙的情況下是沒什么時間自愿去充當溝通者的。但是大家又的確有著信息溝通的需求，因為團隊中的每個人都有了解整個項目進度的義務和責任。大家對項目整體進度了解了，對需求了解了才能更好的進行各自的工作。打一個很簡單的例子，前端了解后端的API是如何設計的，才能知道在哪個頁面調用哪支API。同時，后端要知道前端頁面內有哪些內容，才能知道如何去設計API，給出哪些數據給前端。這樣在真正聯調的過程中，才會有更高的效率，不至于修改很多。所以無論是敏捷開發還是傳統開發，溝通是必不可少的。我反對長時間毫無目的的會議，但完全不開會，靠程序猿私下溝通，這個效率可能也會很低。

??????? 好久沒寫博客了，最近實在太忙。以往只喜歡寫關于技術方面的問題。這次不知怎么突然腦袋抽風寫下了上面的文字，也許是怕自己一閃而逝的想法被遺忘，所以記錄下。往后還是會繼續寫關于技術方面的文章，話說我的apache系列還沒講完呢。。。

轉載于:https://blog.51cto.com/wangweiak47/1649796

總結

以上是生活随笔為你收集整理的关于项目管理的一些想法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。