小項目的管理感覺———作事就是作人

一、第一週階段總結： 

        目標要明確，即每一項工做達到什麼目標，要提出時間、步驟、進度、質量等方面的具體要求，可以量化的則要量化，不能量化的也要有質的要求。若是沒有具體要求，只是籠統地提一兩句話，那就很差操做，人們不明白具體目標是什麼、該朝什麼方向努力，就不會有壓力和動力，工做質量和效率就會受到影響。有些目標要求還要落實到擔當者。

 

二、第二階段總結：

      必須將項目任務細化、具體化，而後落實到具體的開發人員的頭上，並制定好明確的開發日程，按照開發日程嚴格監控項目開發進度，固定週期檢查先項目進度，發現項目延遲，直接定位到哪項任務、哪一個開發人員發生延遲，延遲的緣由，解決方案都明確出來，並要求遇上進度的期限，在該期限內重點監控延遲的任務。

     要掌握項目組當中每一個人的能力水平，這樣在項目開發過程中須要調配人員開發任務的時候才駕輕就熟，不至於新手負擔過重，老手過於悠閒，平衡項目當中的人員任務量，平均的推動項目進度。

    原本打算項目結束以後，召集項目組的全體成員聚一次，吃個飯，不事後來想一想，項目都結束了吃飯聯絡感情好像做用不是很大，遂決定，提早到項目的開發關鍵時期以前，這樣能夠承前啓後，激勵你們，同時聯絡感情在以後的工做能更好的團結協做。

三、第三階段總結：

      必定要保護好項目的核心主程人員，有鋼使在刃上，不能讓這樣的成員將時間花費在文檔，和重複性的編碼工做上，讓他們主要負責解決技術難題。

四、第四階段總結：

    開發以前就要肯定好開發環境版本，儘量提前真機或實際狀況下的測試，儘早提供系統的原型給客戶演示，找客戶確認，不斷地找客戶確認，跟緊客戶的思路。

哎！鬱悶！項目出現問題了，驗收階段，客戶提出了一些以前沒有的需求，還說這些是我應該早就想到的，崩潰，哪有項目開發的人主動增長客戶的需求呢！真受不了這個四川老了，當初需求一點沒有提，如今驗收階段提出了一堆問題，鬧死個心了，跟開發人員一協調須要整個調整程序結構，連帶着開發須要兩週時間來完成，這個客戶卻只給我兩天仍是週末，要求項目按原來流程走，啊！！！我該怎麼辦？？……………………………………問題解決了：只不過要加點班，全當吸收教訓積累經驗了。

五、第五階段總結：

    但凡是設計項目需求的相關問題都要以郵件的方式進行確認，而且郵件的標題就要寫明：項目名稱-需求內容，如此作就是爲了往後方便查找，在項目需求出現衝突的時候，能夠把又見拿出來做爲證據，切記這一點，凡是確認的東西都要保留文檔，造成資料。

    每一個不經意提到的要求，都要進行記錄並分析，能不能造成正式需求，可以造成的，就及時確認，不能造成的也要留好記錄，寫明原因，做爲之後該需求廢除的依據。

其實，反思本身，也有很大責任，存僥倖心理，對項目的理解不夠，歸根結底仍是項目的經驗不足，把握項目的需求能力欠缺，之後要在這個方面加大投入精力，涉獵各個方面的項目。更要站在需求分析師德角度上來考慮問題，而不是站在一個項目開發者的角度，這樣就更能把握項目的需求，若是一個項目坐下來本身都認爲用着麻煩，或者沒什麼用的時候，那麼這個項目確定很失敗，及時客戶勉強接受，那麼要想達到長期合做但願就很渺茫。

六、第六階段總結：

    項目開發之初就要明確的問題：項目開發所選用的語言、開發環境的版本、系統上線以後安裝的系統環境（操做系統版本、輔助的軟件版本環境等），以上這些問題是最基本的需求要明確的問題，若是開發之初稀裏糊塗，到項目結束的階段極可能形成開發、上線、以及後期維護一系列的問題，並且形成這些問題的責任還都要項目承接開發方來背。

    領導必定要有威嚴，對待下屬，辦很差作不完的事情，能夠再給一次機會，若是還作很差，必須採起懲罰手段（逐出項目組或直接辭退），對待下屬切不可一再的縱容，不然天長日久就沒人聽你的了。

    項目終於進入到驗收階段了，因爲質量控制作的還不錯，基本沒出現什麼問題，準備週末你們夥一塊兒聚個餐，增進一下感情，算是宣告項目圓滿結束吧！呵呵！

七、第七階段總結：

        項目結束驗收該準備的東西有不少，系統須要統計的數據也有不少，諸如：系統代碼行數、系統畫面數、系統測試bug數、系統測試bug的詳細記述列表、系統開發環境版本、最終的可執行程序、詳細設計文檔等。（注意：這些文檔都要仔細整理，驗收的時候要及時拿出來說解）

項目驗收會議注意事項：

a、首先必定要明確系統的功能範圍，固守住這個範圍，系統就實現哪幾項功能，其餘的一律不知道，分清本身的職責，不是本身的活，一丁點都不要沾，一旦沾了，就頗有可能會擴大化，進而不可收拾，讓人認爲這也是你項目中的一個部分了。

b、項目驗收會議上，做爲項目開發的乙方，只須要作好兩件事情：一、詳細介紹整個項目週期，每段時間內都完成了哪些工做，若是有延遲須要闡述延遲的緣由，但切記不要說因爲哪一方的緣由，而只針對問題點來進行闡述。二、介紹系統實現了哪些功能，每一個功能是怎麼樣的，系統達到一個什麼樣的性能指標等。三、都有編寫了那些文檔，每份文檔的內容都是什麼，作個簡單的闡述。四、詳細闡述都作了哪些方面的測試，測試的點數是多少？測試出的bug都有哪些？如今這些問題都是否存在（這方面設計產品的質量，是客戶所關心的）。闡述完成以上四點以後，就再也不發言，配合項目的發起人員來補充說明。

c、若有人提出問題，首先斷定是否在本項目範疇之內，若是不在，直接說不清楚、不知道，即使內心很明白也說不清楚，直接說非本項目範疇，不清楚沒法回答；若是在本項目範圍內，則直接闡述本項目的該項需求具體是什麼樣子的，如今項目實現的是什麼樣子的，已經達到了當初項目的需求，不要被人提出的問題帶偏了軌道。總之，記住一點，就是直說本項目之內的東西，相關的和之外的內容一律不談。

d、若有人提出一個功能點的時候，首先判斷是不是本次項目需求之內的，若是是則做答，若是不是直接反駁此功能點並不是本次項目需求，若是須要能夠做爲下期項目的需求來作，本次項目並無。

e、驗收會議上，把了解項目的人劃爲一方，不瞭解項目的人劃爲一方，作總結髮言的時候就說了解項目的人能聽懂的本項目的術語，迴避說不了解項目的人懂的相關術語及業務內容的話，要讓不懂項目的人提不出來問題，懂項目的人，都可以滿意如今的實現已經達到了開始的需求。

f、注意發言時的技巧（任何會議的場合只要發言都要如此）：一、開場白，再簡單的回憶也要有開場白。二、語速要慢、聲音要大、講解PPT的時候，一頁一頁的講，注意聽者的表情（聽者的表情可以直接反映出他們是否可以理解你所說的內容，是表情木然，仍是輕鬆點頭）。三、講解的時候重點突出項目最開始的設計意圖、着重點是什麼（這樣作就是爲了圈定項目的範圍，使得以後在討論的時候不至於提出偏離項目的問題）。四、明確會議的目的，對偏離會議主題的討論，及時做出定義迫使其中止（不至會議拖沓，失去中心進而縮短會議時間）。

g、會議上有發言的時候，必定要提早準備，進行策劃，從會議的流程上，發言的內容以及發言的技巧上面進行安排。

今天開了項目的驗收會議，雖然經過了，可是對本身的表現很不滿意，事出忽然沒作準備是一個緣由，再有就是發言的時候聲音過小，語速太快，聽者表情木訥。說了一些項目相牽連的方面，涉及到了驗收領導業務內的東西，勾起了他們表現業務能力的慾望，提了不少不相關的問題，偏離了驗收這個會議的主題，導致會議時間嚴重拖長。很失敗！前事不忘後事之師！但願經過總結下次再有機會的時候好好表現一下！呵呵！！