在現代的網際網路時代，在傳統企業和現在的初創中小企業裡，it技術部門如何更好的支援業務發展已經成為越來越熱的話題。很多cio老總的吐槽觀念總結起來有幾點：
1.it部門不是處在被業務部門圍攻的煎熬之中，就是處在即將被業務部門圍攻的煎熬之中的路上；
2.在傳統企業由於業務流程和業務規則都很成熟，it開發照葫蘆畫瓢很容易成功，但是在中小初創企業，這種方式很容易失敗。形象的比喻就是業務部門需要乙個衛生間馬桶，it開發如果只是依照馬桶開發而不考慮上下水將必將失敗。
3.中小初創企業對業務把握不成熟，業務人員對自己的業務方案、市場表述不清，今天的想法很容易明天拋棄，it立項開發完成之後容易遇到系統沒人用的尷尬境地。
4.管事容易，管人費勁。往往跟業務部門溝通交流下來還吃力不討好。
業務部門和it部門的從業人員往往被形象地比喻來自不同星球，不是一類人。那麼如何最大限度地促進業務部門和it部門的融合，最大限度地發揮1+1>2，最大限度地提高企業價值，我認為對於事和人分別需要做到下面幾點：
對事處理：
1.專案章程必須明確範圍，目標，目的，可控/不可控風險，進度，成本等。
2.在需求確認階段系統原型、業務流程、業務規則不能省略，其他如文件可以後面再提交以加快迭代。需求交付包括需求頁面原型，開發人員參與需求早期與業務的溝通。
3.需要有需求管理制度，規範使用者提出的需求，需求文件模板等等。
4.排列需求優先順序，設定優先順序。
5.系統的快速需求變更或bug修復需要業務部門、it部門和其他相關部門一起組成變更組快速評審再去做變更。
對人處理：
6.it與業務對接，保持積極的心態很重要，雙方都要主動地溝通和交流。誰都知道，it人員不善於交流而業務人員善於溝通，這兩類異星人如果不能保持積極的心態去真誠交流，那麼只有通過規章制度強制交流來解決思維差異的問題，當然，最重要的還是真誠交流的心態。
7.需求溝通要隨時隨地，重要事項才需要定時正式地需求溝通。
9.it需要引導業務提出需求，尤其注意跨部門類的全域性性系統需求。
10.系統開發進度定期及時對業務分享讓其了解進度，心知肚明。
最後，最關鍵的，乙個專案成功了，it將得到業務部門的認可和信任，將有利於後面的需求溝通和交流；如果失敗了，業務部門必定踢皮球，和將對後面的業務溝通交流產生負面影響。
x眾銀行實際做法例項：
a. 網際網路產品經理主導系統需求。
b. 又懂網際網路又懂傳統金融的人不好找也找不到，優秀的結合辦法是網際網路和金融2個團隊互相結合產生化學效應。
c. 系統先考慮哪些是使用者要的而先不考慮it。
d. 有業務產品經理和it產品經理。
e. 行裡高階領導主導產品管理開發/變更委員會。
專案流程管理的研討
公司近期作調整，設立大開發部，把以前分散的開發人員集中起來，並結合hay諮詢公司一起作部門的規劃。有天晚上被領導留下，和幾個同事一起拍腦袋，定義了乙個的開發流程。專案開發流程說明 list 由產品線發起專案立項，企管辦確定專案優先順序，產品線制定專案經理，由產品線指定的專案經理與開發部門協調部門協調...
需求工程 需求管理
需求以自然語言進行描述，應該以某種標識方案進行編號。幾種常見的需求標識和分類的技術 最靈活和不容易出錯的方法是利用資料庫生成唯一識別符號的方法。這是因為資料庫系統支援在併發的情況下對每個新資料記錄生成唯一的識別符號。有些資料庫還可以通過版本號擴充套件唯一識別符號的方式來支援對相同記錄的多個版本的維護...
需求管理隨筆
最近在工作中碰到了些需求上的問題，今天有感而發 需求獲取應該是主動的,不能等客戶來說，因為大多數時候客戶並不清楚他們的真正需求，需要由需求分析人員抽絲剝繭來逐步問出需求。在訪談前列出要問的問題，然後發給訪談物件，讓他事先對所問問題有個了解，以防出現訪談過程中過多出現 這個問題要仔細想想，等以後告訴你...