透過湖工教務項目淺談項目管理過程
1、項目背景介紹：
湖工項目是湖北工業大學教務系統，是一種專注於大學和高等院校的教務管理系統。其中包括一些校園基本信息管理，教學培訓計劃管理，學生排課系統，成績管理，排考管理等一系列業務管理體系。
湖工項目與我們接頭的是教務處，其中管理人員曾經也是做程序的，喜歡代碼Sql，就算是加班工作他也很樂意，該院校原有的教務系統就是他個人創作的，所以對教務管理這一塊有非常豐富的管理經驗。
2、項目情況：
項目持續有一年左右的時間了，項目需求頻繁變動，人力投入了卻不見成效，一直虧損，導致項目到現在仍然無法結項。
3、問題歸納總結與應對措施：
a、客戶現場目標不明確，去客戶現場事先準備不充分。到了客戶現場像無頭的蒼蠅一樣，不知道該演示什麼，該跟客戶從什麼地方開始談需求調研。
這樣就會導致你很被動，談需求時也讓客戶會認爲你不夠專業，對本行業不夠了解，對你喪失信心，這是很致命的。
人非聖賢，不可能什麼都知道，什麼行業都瞭解。但作爲項目經理，對客戶的項目事先必須得先了解。
每次去客戶現場，在內心中必須整理出一個大綱，首先演示什麼，然後我們接下來談什麼需求，帶回去給我們的小夥伴做，對於這些需求你有什麼看法，構想下客戶針對你的看法會有些什麼疑問，你將如何應對，如何回答。
針對需要演示的功能，去之前項目經理必須整理出一個穩定的版本，即使這個版本功能不夠完善。去客戶現場前一天或幾個小時，都要發佈一個版本給測試部門進行功能測試。確保本次去演示的功能無誤，如還有功能爲完成，分析應對策略，將其中本次版本中剔除，本次不演示，並向客戶說明原因，不要留一個半吊子功能。
然後一一實現你今天來客戶現場的目標。
b、 需求調研需要抓住客戶對需求的偏重度。偏重點這個不能一概而論，需要你對客戶的瞭解和分析客戶最近的偏向來決定客戶此次談論需求的偏重點。
很多次我們在與客戶溝通的時候不能深入瞭解客戶所說內容的重點，往往只停留在理解客戶的表面描述上，這樣分析出來PBI不夠準確，導致開發出來的東西不能打動客戶，就會無限期的返工，開發成本就是無底洞了。
記得在與客戶溝通一次網上評教模塊時，客戶就描述了一系列他的想象，並結合了他們學校的評教業務來跟我們講解了下需求，並批評了我們前期做的一個版本，當時我們聽完後，感覺完了，這個功能得重做了(前期做過這個模塊)。
但是回去後深入的理解了下客戶描述的需求與學校的實際業務規則，發現與之前我們開發的版本差異不是很大，這讓我們喜出望外，立馬就在以前版本的基礎上改進了，此次交付就得到了客戶的認可。
c、詳細的產品BackLog和業務規則。
開發過程中詳細的產品用戶前景是很重要的，只有站在客戶的角度去想問題，去實現客戶的需求，才能真正的貼合實際應用場景。往往在與客戶的需求溝通過程中，客戶講解的需求是A，我們理解爲了B，然而客戶卻以爲我門理解的是A，這樣就會產生需求的偏差，所以瞭解客戶想要這個功能是要達到什麼目的，起到什麼效益這纔是根本，產品BackLog一定要儘可能的詳細。
Backlog的校驗規則在一定程度上是類似測試用例的，所以校驗規則越詳細越好，這能提升我門開發質量和測試效率。
d、 持續按敏捷開發的流程執行，但在實際開發週期中，我門往往會由於項目時間緊，趕項目功能而忽略一些敏捷開發中的環節。
所以我列出了幾個重要的環節1、迭代計劃會議，計劃會議是PM向開發人員講解產品需求，然後將產品前景分配給開發人員設計，這是一個需求理解的會議，所以不能少。2、設計評審會議，評審開發人員設計的功能模型，對需求理解有無偏差的過程，這是糾正需求理解偏差的會議，所以不能少。3、迭代演示會議，將本輪迭代的內容內部演示，暴露問題，將項目問題內部消化的會議，俗話說不出現在客戶現場的bug不叫bug。所以也不能少。4、迭代回顧會議，尋找不足，下次改進，持續改進的會議。
敏捷開發是一種持續改建模式，以最小的代價來應對客戶頻繁變更的需求。
4、項目回顧：
其實管理是一門藝術，是一種雙贏的下注，更是是一門技術活。
團隊是在不斷的磨合中成長起來的，沒有生來就很強的團隊，只有更專業，更默契，更團結的團隊。
