第
一、高層領導參與。
之前我負責過乙個世界500強企業自然美的專案。合同前完後，需求調研時，我就加入了自己很多的設計（從經驗和假想中而來）；等到設計確認時，總得不到乙個能說上話人。給我答覆是，上報，討論。後來也就不了了之。我的工作於是變成提供方案，等待確認；然後修改方案，無回執；按照無反饋的設計開發下去。到了實施階段，我發現客戶一點都不急。總是說最近很忙，沒時間來搞這些東西。我就納悶，你們花錢買的東西如果不用，那花這個錢幹什麼呢？這個過程中，沒有找到乙個客戶的領導。很多任務作，當然開展不下去。作為系統分析師和專案經理，要注意能不能找到客戶的高層領導。
第二、少扯談。
如果你喜歡扯談，那就不用說了。我覺得對於開發人員來說，扯談的事情應該很不喜歡。拿到合同時，對於一些字眼，要定義清楚，或者說要相對清楚。我遇到乙個很牛的公司，把某市的110系統外包給我們。他們把300萬的合同內容寫的和3萬差不多。他如果按照3萬的解釋，就是3萬；他要是按照300萬的說法，也能要到300萬。我們就慘了，面對客戶時，人家說物非所值。作為系統分析師和專案經理，要知道合同。對於一些無法實現的任務，你要早點發現。
第三、要知道放手和把關。
在某市110專案中，我對於實施階段還出現問題及其惱火，不再信任下屬。一些事情乾脆親自編碼。這樣造成自己的時間出現驗證不合理，一些調節和設計工作出現漏洞。其實如果放手讓下屬做好，並做好讓他自己檢查的方法和規範。群策群力，絕對比乙個人獨抗好的多。後來的專案中，我就理清自己角色。把規範做好後，方法及步驟溝通完，只做質量把關。很多任務多執行緒併發執行，整個團隊作戰能力大大提高。作為系統分析師和專案經理，要注意群策群力，你角色在設計和質量把關。
第四、使用者至上要有分寸。
我們常說，使用者至上。什麼是使用者至上，讓專案順利進展和客戶滿意。我之所以提出這兩點，因為有時候這兩點是矛盾的。比如在系統臨上線錢，客戶要提出改動什麼什麼，你不改他不滿意；但是如果你改了，系統不能上線，他更不滿意。
使用者至上，不是一味地接受；但也不能讓人很反感。怎麼做，嘿嘿，看你為人處世的技巧了，這就複雜了。
第五、多讓使用者參與。你在開發階段使用者參與的越多。那麼你實施階段，得到滿意度就越高。因為你的做法他們早就知道了。
資訊系統建設專案風險評估方法
評估這個詞並不陌生,但專案風險評估在我國的 應用還不太廣泛，資訊系統建設專案的風險評估的應用就更少了。實際上，幾乎幹什麼事情都或多或少地存在著風險，對於我們已經順利完成了的專案，只不過是我 們在不知不覺中克服了風險而已，而那些沒有進行到底而流產的專案，則是典型的風險發作。專案中途流產，一般要造成很大...
稅務資訊系統建設安全管理平台的研究（三）
注 作為該系列文章的最後一篇，本文首發於本人的51cto部落格。文章對 稅務系統安全管理平台的建設規劃提出了一些思路和建議。參考 需求分析與總體設計 建設一套全面的稅務安全管理體系是乙個系統工程，牽涉到單位的方方面面，不僅是安全管理部門的事情，也不僅是資訊中心的事情，還涉及到各個業務部門，甚至單位中...
稅務資訊系統建設安全管理平台的研究（二）
注 本文已經在 上發表，現同時發表在本人部落格上，這裡略有改動。在建設稅務系統安全管理平台的過程中，不可避免的會遇到其他種類的管理系統或者平台，例如終端管理系統 資料庫審計系統 網路管理系統 運維管理系統，等等。稅務系統安全管理平台必須正確處理好與各個管理系統之間的關係，確保不出現新的管理孤島，不增...