從事遠端學歷教育的教學教務管理平台的開發、管理多年，一直想把遇到的挫折和感悟和同行分享，於是集中幾天時間整理出這篇文章，希望能對在這一行業奮鬥的兄弟姐妹有所啟發。文章中的一些觀點也許有所偏激，但卻是我的心聲，歡迎批評指正。由於整個教學教務平台內容十分龐雜，本文涉及到的內容主要是教務管理方面。
在國內學歷教育教務管理平台是非常有特色的，由於此行業對政策相當敏感，教育部一紙政令就可能使平台發生翻天覆地的變化，而平台的主要使用者——學校，迫於招生壓力，會在政策允許或者沒有禁止的地方絞盡腦汁，想出種種奇招來擴大生源，留住學生，無形中也會對平台造成很大影響。大部分作教務管理平台的公司型別分成兩種，一種是以產品為主，根據常規的教務管理流程設計出一套平台，此類平台大都包含了通用的教務管理流程，但不會涉及到過細的內容，因為細節意味著學校的個性化，既然是產品就不能有個性化。另一類是以服務為主，往往是和某個學校合作，為校方定製平台，這樣就可以把學校的個性化最大化滿足。兩類平台各有利弊，前者優點是對於乙個軟體產品而言，擴充套件性、健壯性、移植性很好，這會讓軟體開發人員感覺很好，但對於學校，無法滿足其個性化要求，換句話說無法讓客戶滿意。後者優點是盡量滿足客戶個性化要求，客戶的需求能夠及時地實現，缺點是這套平台的擴充套件性、移植性非常差，而健壯性也會受到很大影響，原因很簡單，盡量滿足客戶需求就意味著要放棄一些軟體工程本身應該嚴格遵守的約定。這對於開發人員來說是很鬱悶的。實際上幾乎所有的公司都在嘗試在這兩類平台之間取得乙個平衡點，作產品的公司也會給客戶定製化，做服務的公司也希望能整合多個服務平台，以便降低維護成本。然而這個平衡點的位置卻是仁者見仁智者見智，個人認為要定位最佳平衡點需要專案管理者、開發、需求三方面一同努力。
管理者
此處並非特指專案經理，在國內很多公司，專案經理往往沒有實權，當客戶的要求與系統的穩定性出現衝突的時候，最終的結果往往是妥協。所以這裡的管理者是指真正有權利控制專案的方向的，應該是專案總負責人。
1、由於學歷教務平台的業務複雜性，往往從平台誕生到最後成熟，會存在乙個不斷提公升得過程，這個過程最初一般是在平台上打補丁，使之不斷完善，但到了一定階段，會遇到瓶頸，這種瓶頸產生的原因很多，最常見的原因是業務不斷變化，造成需求不斷變化，進而影響平台不斷變化，最後發現原有的平台已經無法再繼續打補丁了，或者說打補丁的代價過大，造成維護成本過高，這是就有必要重新設計一套基於未來可預見業務變化的新平台。這時管理者有可能犯的錯誤是找幾個技術高手，封閉幾個月，用最新的技術把新平台做出來。這種觀點往往不是管理者自身產生的，而是由技術人員提出的。有可能產生以下幾個問題：
l這些技術高手是否熟悉原有平台，如果是，此問題不存在，否則，讓完全不了解老平台的人來作新平台，無法使用以往的經驗，會重複以往的錯誤。
l新技術是否必需？其實不管是什麼語言或者最新的什麼架構，目的都是為了開發的方便，使開發的效率提高，功能增強，但對於使用者來說，沒有必要非要換新技術，因為對於教務管理系統，使用者最關心的是業務邏輯而不是使用者體驗，即使對於客戶有限的使用者體驗方面的要求而言，不論使用什麼技術基本都可以實現，只是實現的方法不同，是否便捷的問題。而為了開發方便貿然使用新技術，會存在對於新技術了解不深造成工期拖延的風險。
l管理者不懂技術，往往希望幾個人一努力，就可以在短時間內做出一套全新的平台，並且可以遮蔽原有平台的弊端。殊不知，軟體工程是乙個非常系統的工程，從客戶需求整理、需求分析、整體設計、技術預演、詳細設計、編碼、測試、部署，各個環節都必不可少，任何乙個環節的失誤都可能造成整個專案的失敗。但管理者往往不重視需求、測試環節，他們更看重編碼，所以往往要求技術團隊在一段時間內封閉工作，認為這樣就能把進度提前，其實在軟體專案的整個生命週期中，編碼只佔很小一部分，大部分應該在前期的需求蒐集、分析、整體設計還有測試，而這些環節幾乎沒有什麼方法快速實現，所以封閉除了造成專案質量下降之外沒有什麼好處。
2、客戶要求和專案質量之間的取捨。
很多管理者都遇到過這樣的情形，業務部門和技術部門掐架，業務說很早之前要的功能至今沒有實現，技術部門說業務部門的需求不合情理，自相矛盾，會對整個系統造成不可預知的危害。這時管理者採取的態度可能是，將兩個部門負責人找來，促膝長談，業務負責人說這個功能很重要，可以大大提高工作效率，降低失誤率，必須要，技術負責人說，此功能太危險，沒有分析清楚它所造成的影響之前不能做。管理者可能會說，公司今年的利潤指標還差不少，所有部門都在努力，業務部門是第一線人員，技術部門是後勤，保障必須跟上，如果你沒有足夠的理由說服我，就得做。此時技術部門只能委曲求全，最後的結果是功能實現，業務部門使用一段時間後，發現了種種問題，技術負責人當初預言的問題逐一出現了，但是第一步已經走出去了，只能硬著頭皮繼續往下走，系統繼續打補丁，系統穩定性每況愈下。這裡我們不能怪技術負責人沒有堅持原則，也不能怪客戶亂提需求，重要的是在於管理者，管理者不能以不懂技術為由，就對技術否決權持消極的態度，國內軟體公司大都重業務輕技術，原因很簡單，業務是利潤的直接製造者，而技術只是服務於業務，即使違背了技術人員的意願，平台還是照樣執行，不穩定？沒關係，有技術人員呢，他們就是幹這個的。而業務的意見則要重視，因為他們是利潤的直接製造者。這裡不是在挑管理者的毛病，至少對於管理者而言，一言一行直接關係到專案的成敗，沒把事情弄懂之前不要憑感覺辦事。
開發者
以下是幾點忠告
1.對於臨時需求能不加功能的盡量不加功能，做成功能就意味著要給使用者使用，而使用者不是技術人員，不會按照常規出牌。
2.如果沒有足夠的資源就別指望做乙個大而全的平台，面對不規範的使用者，這是自討苦吃。還不如完善現有平台，去滿足使用者的需要。要更實際些。
3.不要迷信新技術，新技術不會減少多少工作量，最重要的是業務，恰當的使用現有技術，要更實際些。
4.物件導向的設計方式，要辯證的看，不是**都適用的。
5.對於乙個頻繁發生變化的系統，維護成本是非常重要的指標。
6.頁面不要考慮太多的重用，否則過多的邏輯會使維護成本太大。
7.適當使用開閉原則。
8.不要太樂觀，幾乎所有的專案都因不可預知原因而延期。
9.資料庫上盡量少用外來鍵關聯，否則就是在底層把業務緊密地藕合在一起了，而要盡量採用業務層控制，這樣靈活性更好，當然它的缺陷是無法保證資料完整性，但對於靈活的需求，只能如此。
10.
任務計畫不能僅以客戶要求時間遠近來排優先順序，因為遠的任務，可能工作量很大，反
倒是緊急的任務。
11.嚴格執行**版本管理，在頻繁發生變動的系統中尤為重要。
12.人不是越多越好，溝通不暢造成的麻煩往往比缺少人力資源的後果更麻煩。
需求分析
這個崗位要做好很難，他同時要具備豐富的業務知識與嫻熟的溝通技巧。他對於整個專案至關重要，首先他要面對客戶，挖掘需求，而不是簡單的傳達，然後系統分析業務，避免造成拆東牆補西牆的結果，再者還要和開發者溝通，將業務傳達出去，任何乙個環節出現紕漏都會造成惡果。
需求常犯的錯誤：
1、簡單聽取客戶要求，不假思索，就傳達給開發。客戶所說的未必就是他們想要的，有的客戶提的要求很零散，乍一聽好像是個很小的問題，如果照著作了，就會發現他們又提出新的要求，理由很簡單，當初沒想到。還有一種客戶了解業務比較深，他們會從設計的角度考慮，提出貌似很合理的改動，仔細了解後會發現，他們想要的東西與說的差別很大，因為他們認為做了這樣的改動就可以出現理想中的結果，其實他們不是平台設計者，所以無法預知可能的結果，這時需求就必須糾正他們的觀點，讓他們明白客戶只要提出他們想要的結果就行了，該怎麼做是開發的事情。
2、對客戶要求分析不深，沒有了解要求背後的要求。客戶不是專家，他們需要引導，需求文件絕不僅僅是客戶要求的彙總，而是客戶要求的深度分析、歸納後的結果。
3、客戶至上。客戶是上帝沒錯，不過，如果因為照顧客戶而不顧平台的健康，結果也是徹底損害了上帝。客戶有時會提出一些無理的要求，對任何乙個系統都永遠不可能完全滿足客戶的要求。需求必須要在平台健康和客戶有好度之間決定乙個平衡點，並且要引導客戶認識到這個平衡點。
4、對業務不做深度分析。需求應該是真正的業務專家，由需求分析後的功能不能產生不可預知的結果，這個要求確實很難達到。因為就連網院專家也未必清楚乙個新的業務點可能產生什麼樣的結果，畢竟學歷教育從報名到畢業數年時間，學生的所有資料都在裡面，環環相扣，業務關聯性太複雜了，整個教務管理系統，隨便拿出乙個小模組就是乙個小系統，而且每個系統之間還存在著千絲萬縷的聯絡。就業務複雜性而言，沒有哪種系統能和學歷教務管理相比。就因為如此，如果不考慮周全，這套系統很容易出現業務邏輯問題。
以上是個人的一些拙見，在實際工作中遇到的問題還要更多更複雜，不過萬變不離其宗，只要管理者、開發、需求三者各司其責，做好自己該做的工作，那麼再複雜的系統也一樣能夠成功。
軟體專案測試管理經驗之談
一 軟體測試員自身素質培養 1 首先，應對軟體測試感興趣和對自己有自信，如果具備了這兩點，那麼在開發過程中不管遇到什麼樣的困難，我相信你一定能克服。2 善於懷疑，世界上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發生的事，我卻認為可能發生。別人認為是對的，我卻認為不是對的。3 打破砂...
專案經驗之談 棧溢位
前言 在嵌入式領域，我們編碼除錯時，經常會出現段錯誤 core dumped 根據個人經驗，最常見的莫過於 空指標 野指標 記憶體洩露 一般是堆區洩露 棧溢位 越界訪問等。筆者在此只闡述棧溢位 棧區被破壞 的情況，因為這種問題在專案中極具有典型性 隱藏性 且不易被跟蹤發現。棧破壞的具體表現為 在該函...
敏捷開發管理 任務分解經驗之談
敏捷開發是快速迭代，快速交付的開發模式。這也就要求迭代週期內任務量不宜過大，以保證在預期內能夠按時完成開發計畫。敏捷開發中怎樣保證開發任務的適宜呢？答案是任務分解。而任務分解的前提則是需求確認。敏捷開發中的需求確認 我們都知道需求的 渠道很多 如使用者調查問卷，使用者訪談，客戶服務人員 商務人員的反...