【轉載】最近一個項目的反思

來自：http://www.cnblogs.com/strick/p/3946475.html

　　入行這些年，沒多少成功的經驗，失敗的經驗卻愈來愈多。今天花點時間好好的反思一下，總是稀裏糊塗的可不行。我下面寫的不針對任何人，就事論事。

 

1、無管理核心

 

　　缺乏了這個重要的凝聚力，下面的人能夠說是在單兵做戰，人心渙散，各自爲戰，怎麼可能把項目作好。還有下面的這些問題：

　　一、團隊成員碰到的問題沒法獲得及時的協助和解決，會讓人有愈來愈多的挫折感。

　　二、無人管理開發文檔，開發任務沒有科學的制定會拆分。

　　三、因爲沒人督促，readmine形同虛設，徹底沒發揮他的做用。

　　四、人員不能被合理的分配，成員之間的協做愈來愈少，甚至有隔閡。

　　五、不能有效的控制需求，一下子作這個，一下子作那個，最後什麼也沒作成，士氣愈來愈低。

　　六、項目中遇到的意見不統1、衝突，都不能有效的協調好，團隊成員思想不能一致。

　　七、沒法把控開發人員們的進度。

　　八、階段性成果，沒有安排時間及時確認。

　　接下來的那些問題不少都是由於無管理核心致使的，聯動效應。

 

2、需求混亂

 

　　規範點的說，需求的管理應該只有一個進口一個出口，拿到需求後，先作個分析，分解細化，而後再轉換成可執行的操做，畫原型，製做效果圖。

　　如今的狀況是出現開發與規劃不符的狀況時候，直接與開發人員肯定需求，今天要這樣改，明天那樣，不斷的變化，得不到控制，原先的開發計劃不斷的插入新的功能修改，徹底不按照計劃來了，最後固然不能在指定日期完成預約功能了。

　　開發人員沒有參與到需求的討論中，聽需求的人，在把需求傳達給開發人員，常常會出現誤差，最後開發人員買單，將作好的功能頁面等再推翻，修改，費時費力，還影響開發人員的心情。

　　常常會糾纏於一些需求的細節，一步到位，力求達到最好的用戶體驗與效果。我我的以爲用戶體驗的好壞是須要真正的用戶用過之後才能肯定的，在開發階段是快速的將一個可用的軟件拿出來，之後再根據各類數據爲基礎，改進用戶體驗。項目的開發都是漸進明晰的，一開始的開發確定不能預料到各個方面，既然預料不到，就把重要的先作好，之後再改，有了可用軟件，什麼都好說。

　　還把測試人員給拖累了，常常會抱怨開發人員臨近上線纔開始提交代碼測試，抱怨開發人員本身很差好測試。臨近上線還要一堆BUG。徹底沒有留時間給他們，讓他們很難作，有時候是快到上線日了，軟件都尚未，根本沒有測試的東西，別人很忙，本身卻很悠閒。

決策者能夠直接繞過需求人員直接指示開發人員修改， 開發人員之間也缺乏協調	需求是一個進口一個出口， 開發人員之間有很好的協調

 

3、不懂業務

 

　　開發開始前，應該讓開發人員們使用市面上面相關的軟件，實際操做下，體驗流程。實際操做的效果比嘴上說要有效的多。在操做的過程當中，就能體會到市面上的軟件哪些地方作的很差，哪些地方作的好，真正換位到用戶的位置上。你們嘴上常說要換位思考，但實際操做起來真的很難，但讓本身作一個真正的用戶就方便不少。

　　開發人員不懂業務，是個軟肋，致使不少問題。第一個是最大的問題。

　　一、沒法質疑需求的合理性，上面傳達下來的需求即便有錯，也繼續編碼，最後就是返工。

　　二、很難對項目提出一些比較好的建議，有時候也不能有效的和最高決策人溝通。

　　三、開發人員本身估算工做量的時候，會有一些誤差。

　　四、代碼的設計會有影響，懂業務能更好的設計代碼的結構，擴展等

 

4、溝通阻塞

 

　　一、測試人員與開發人員之間：

　　一開始測試人員不熟悉系統，提了許多易用性方面的問題，還有一部分BUG在開發人員眼中並非問題——就是那樣設計的。在提出後，放到readmine上面，分配給測試人員認爲的相關開發人員，到這裏都很天然順暢。可是掛在readmine上面的這些問題就這樣掛着了，不修改也不反饋，不了了之了。他們的工做很難展開，測試與開發之間出現了小隔閡，團隊的凝聚力愈來愈低。

　　後面通過你們的討論，給出一個解決方案。須要一箇中間的管理人，讓他去分析提交上來的問題，根據他的理解定位這個問題屬於誰，再由他轉給某個開發人員，由這我的來追蹤。測試人員的工做也單一了，不會總是由她來催促修改問題。

　  二、Web端與服務器之間：

　  此次的項目是須要不一樣終端互相協調的，web端須要服務器端提供接口協助，讓那邊提供接口卻老是一拖再拖，遲遲不給，即便在readmine中開個任務，仍是沒有在預約的時間中給接口，一催二催三催，沒有結果。這裏也缺乏箇中間的協調人，須要這我的作溝通，安排時間，分配人力，知足web端的需求。開發人員之間是平等的，不存在指揮的關係，誰也管不動誰。開發人員之間出現了小隔閡，團隊凝聚力再次下降。

　  三、開發人員與需求提供人員之間：

　  需求的提供有從最高決策人那裏直接發出，有時候也會經過另外幾我的員發出。因爲需求的一直變化以及傳達的時候常常出現誤差，致使了開發人員不在很是相信他們，對於他們提出的需求，常常會作反覆的確認，但最後仍是會改。他們作的原型或設計的流程，與最高決策人作一一確認有點不現實，這樣常常會致使被推翻，直接影響了開發人員，開發人員在實現了之後也要返工。這個地方缺乏了個需求的管理者，須要他來制服需求，這頭猛獸在摧殘着各個相關人員。反覆無常的變化，讓他們的工做也很難展開。開發人員與需求提供人員之間出現了小隔閡，團隊凝聚力勢必再次下降。