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

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

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

??????? 項(xiàng)目的管理，包括需求管理、標(biāo)的管理、設(shè)計(jì)管理與開發(fā)管理。項(xiàng)目管理是一個(gè)需要一個(gè)人主導(dǎo)并且全員配合執(zhí)行的過程。

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

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

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

??????? 開發(fā)管理，開發(fā)管理是始終穿插在開發(fā)過程中的。包括項(xiàng)目進(jìn)度跟蹤，聯(lián)調(diào)計(jì)劃執(zhí)行、測試計(jì)劃執(zhí)行。他們有一個(gè)共通點(diǎn)，就是都是需要多人協(xié)作完成的。一旦涉及到多人協(xié)作的問題，就需要一個(gè)協(xié)調(diào)者來組織。因?yàn)榇蠹以诙己苊Φ那闆r下是沒什么時(shí)間自愿去充當(dāng)溝通者的。但是大家又的確有著信息溝通的需求，因?yàn)閳F(tuán)隊(duì)中的每個(gè)人都有了解整個(gè)項(xiàng)目進(jìn)度的義務(wù)和責(zé)任。大家對項(xiàng)目整體進(jìn)度了解了，對需求了解了才能更好的進(jìn)行各自的工作。打一個(gè)很簡單的例子，前端了解后端的API是如何設(shè)計(jì)的，才能知道在哪個(gè)頁面調(diào)用哪支API。同時(shí)，后端要知道前端頁面內(nèi)有哪些內(nèi)容，才能知道如何去設(shè)計(jì)API，給出哪些數(shù)據(jù)給前端。這樣在真正聯(lián)調(diào)的過程中，才會有更高的效率，不至于修改很多。所以無論是敏捷開發(fā)還是傳統(tǒng)開發(fā)，溝通是必不可少的。我反對長時(shí)間毫無目的的會議，但完全不開會，靠程序猿私下溝通，這個(gè)效率可能也會很低。

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

轉(zhuǎn)載于:https://blog.51cto.com/wangweiak47/1649796

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。