對于項目管理，軟件工程，我還只是一個不得窺入門要領的門外漢。由于以前做的項目多半都是不規(guī)范之項目，過程坎坷，成長和思考的速度也略慢。
很多人都經(jīng)歷過沒有實踐指導而導致的項目噩夢，這里的很多人就包括我，在剛畢業(yè)的那會兒，想嘗試下自己做項目，剛好一個同事的朋友需要做一個在線設計衣服包括一般電商功能的網(wǎng)站出來。所謂初生牛犢不怕虎當時就答應了，后來這個項目雖然是收工了但也是草草收場，這個事情搞到現(xiàn)在我也是有點愧疚。所以說缺乏有效的實踐會導致不可預測性。
過程和方法對于項目的結果只有次要的影響，首要的影響是人。這里的影響也只是說首要和次要，但是兩者卻也是缺一不可，可以說項目的成功=優(yōu)秀的團隊+實踐方法。
就項目層次上來講講目前遇到的問題。
- 多人開發(fā)團隊的協(xié)作
- 文檔
- 需求溝通
應該說團隊招人是第一道坎，但是這道坎也是充滿著運氣抑或風險的，比如你錯過一個面試平平但水平不錯的或者誤招一個簡歷優(yōu)美面試ok但實際工作能力卻并怎么樣的同事。團隊之間重要的是溝通和規(guī)范的存在，比如代碼管理的規(guī)范，項目流程的規(guī)范，溝通自不用說，優(yōu)秀團隊可以不用都是一群高水平的程序員，但必須是彼此之間能良好溝通的。
第二點，剛進入公司時作為新人我都會寫很多文檔一方面熟練業(yè)務，另一方面也為后來者提供踩過的坑?，F(xiàn)在覺得這塊可能做得太細致。正如“敏捷軟件開發(fā)”書中所說的，code和road map才是最好的兩份傳授知識。代碼是唯一精確反映線上業(yè)務的信息。為了不過分因為編寫文檔而導致影響項目進度可以“直到迫切需要并且意義重大時才編寫文檔”
第三需求溝通。產(chǎn)品和開發(fā)需要溝通需求這部分沒有問題，頂多就是需求的增刪，沒有問題是因為這是項目內部的事情，當然也有因為項目內部溝通不順牽扯外部團隊的情況存在，這個這里不討論。和外部團隊，業(yè)務方溝通需求是最難得。正常的溝通，基于項目的減需求請求有時候也會被認為是擋需
求。這一步還需要經(jīng)驗去學習，紙上得來終覺淺，而這部分出于技術又在技術之上。
未完待續(xù)、
