團隊項目失敗說明與總結

很遺憾咱們的團隊項目失敗了，原先是要作一個微信記帳小程序，激情洋溢開始,卻以一聲嘆息結束。

　　此次討論一下項目管理的失敗，爲何討論失敗？有句話說失敗是成功之母，咱們討論失敗，是爲了規避失敗，趨近成功。

　　每個項目都是獨特的,然而項目失敗的根本緣由一般都是相同的。

　　關於團隊，這雖然不能說是一個很失敗的組合，但倒是一個很失敗的項目建設過程。爲何這麼說呢？

　　首先，這不是由需求引發。沒有需求而進行開發是很危險的，若是沒有需求而爲了原則問題進行生硬的團隊建設，無異於爲項目埋下了一枚定時炸彈。團隊做業需求分析與設計有認真完成的.軟工網絡15團隊做業3——需求分析與設計。經過問卷星平臺建立大學生記帳微信小程序用戶需求(ID:22529810)相關問卷,再發給身邊大學生填寫問卷。利用問卷調查，也瞭解用戶對記帳小程序的一些基本要求。

　　緣由其一，沒有一個明確的負責人。一開始你們都以爲本身能力不足，沒人出來當這個PM。

　　這裏重讀了鄒欣老師《構建之法》關於項目經理這一章節，更是讓我感觸頗深，體會到一個強有力的領導者對於軟件項目相當重要的做用。在此以前我一直認爲優秀的開發團隊只須要技術人員就足夠了，項目的開發也是以編碼爲主，其它爲輔，且不會在軟件開發過程當中佔據多大的比例。像咱們平時的那些大做業，90%都是以編程爲主，沒有誰會去過多關注需求、測試、運維等環節。可是當我讀了《構建之法》後，發現軟件項目的開發並無我想象那麼的簡單，一個真正的大型軟件項目的開發是異常複雜、嚴謹、規範的。其整個流程包括：產品定位、市場發展、需求分析、業務運營、市場推廣、商務合做等等，編碼實現只是其中很小部分，而爲了實現這些過程，有一個角色不可或缺---PM（項目經理）。一個成功的項目，必需要有一個成功的項目經理。這是項目管理的首要前提。

　　其二，工做分擔（責任範圍）不明確，工做分割結構（WBS）與項目組織結構不明確或者不相對應，各成員之間的接口不明確，致使有一些工做根本無人負責。你們不知道本身該幹什麼，也存在當我想幹什麼的時候，發現不少隊友也想幹一樣的事，這樣就只能排隊解決。浪費時間，且不能產生價值。

　　其三，項目工期估計不現實。糟糕的估計發生是由於：沒有利用相似項目經驗或者文檔來估計本項目會持續多長時間；作估計時沒有考慮隊友的經驗，而是假設全部的職員都是專家，他們均可以毫無差錯地工做；估計是由不熟悉細節問題的人作出的，那些負責工做的人沒有參與作估計；時間有限，課程多，實驗多，要求項目快速完成，這就致使制訂了不切實際的完工日期，並刪除了「沒必要要的」任務。

　　項目組人員能力的低下是項目失敗的緣由之一。其餘組多「一神帶多坑」，咱們組全是「坑」。

　　以上談到了項目失敗的幾方面緣由，實際上還有不少看起來無害的細節,像滾雪球般膨脹,從而使整個項目陷於停頓。很難一一列舉。在這裏咱們沒有篇幅提出如何避免這些問題的對策，可是經過這些緣由的列舉，但願能激起你們的共鳴。

　　至此，團隊成員楊澤斌跑路（臭不要臉，在Ａｌｐｈａ階段就想好跑路，跑哪裏了），剩下咱們四個願與項目共存亡。

　　沒有人會認可失敗, 尤爲當沒有人要求你這麼多的時候。 咱們的項目也是,可是其實, 咱們其實應該認可,咱們有作了一個失敗的項目。

　　從開始到結束, 沒有開始的開始到沒有結束的結束, 整個過程一切都在咱們腦海中, 剩下幾個殘缺的需求文檔和由於服務器緣由沒法投入使用的中間代碼。

　　儘管如此,「項目失敗」並不等同於「項目死亡」。往後有時間，有能力必定重拾項目。