？目前，垂直部門管理模式在要求“以客戶為中心”和“零不愉快”方面的弊端日益明顯。尤其是在市場需求快速變化、快速支撐的背景下，需求無法高質量實現，首先表現在需求實現的效率和速度上，需求無法快速支撐。其次，在需求執行質量方面，需求在線存在很多問題，帶來很多二次問題，需求質量的業務單元和分支機構不滿足，影響IT聲譽。
？圍繞客戶需求，啟動矩陣式需求管理，打造高、精、尖的需求接口團隊，在企業信息部設立後方資源池，深入需求壹線，讓需求壹線指揮炮火，實現小前端、大後端、前端壹體化、後端專業化，後端全面支撐前端。
現狀:目前企業信息部門采用傳統的垂直組織結構，各域組織界面清晰，容易形成部門壁壘。需求預備團隊接收需求，並將其分配到每個領域。復雜的聯合需求由各域評估，再由各域確認，然後與需求業務單元溝通。這期間反復反饋，效率低下。尤其是壹些需求細節出現問題時，往往需要召開多次會議與各部門進行確認。關於實施計劃，
措施:
1.采用需求矩陣管理:對於重要的需求，采用項目管理，由部門負責人、技術專家、實施者、制造商組成臨時需求實施小組。這個團隊不隸屬於任何部門，需求通過承包的方式承包給壹個虛擬團隊。每個需求團隊負責人都有“喊炮聲”的權利和“簽訂責任書”的義務，從而實現權力與責任的平衡。這樣可以整合事業部各部門的專家優勢，突破部門壁壘，快速實現需求。這種方法還在業務部門層面形成了垂直於傳統部門的需求實現矩陣，與各個領域的生產和維護形成互補。
2.“黃金四邊形”:黃金四邊形的目標是建立貼近需求壹線的敏捷組織，形成事業部層面的統壹接口，能夠敏感地捕捉公司領導和壹線的關鍵需求，找準需求的“痛點和關鍵點”，快速調動資源，建立專門團隊，靈活快速實現需求，打破部門壁壘，突破原有需求流程的繁瑣。團隊必須包括項目經理、需求分析團隊、方案設計實施團隊、後期維護支持團隊四個關鍵團隊，形成黃金四邊形。
每個小組的職責如下
(1)項目經理:項目經理是團隊的領導者，是需求的第壹負責人，擁有“呼喚炮火”調度資源的權利，也是實現需求目標的第壹負責人。需求完成後，簽署需求實施承諾責任書，接受事業部對實施情況的評價。生產廠家的負責人也包括在項目經理中。
(2)需求分析團隊:需求分析師是排頭兵，是最先接觸業務單元的人。首要任務是找到需求的“痛點”或“問題”，其次是需求實現的橋梁。對外，負責指導業務單元按照IT“服務第壹”推進，指導業務單元采用IT推薦的需求實施計劃和分布式實施時間計劃；對內負責與方案設計實施團隊溝通需求，形成需求支撐方案，與前端溝通。第三，在需求實現的整個生命周期中管理需求變更。分析團隊的工作必須量化，每個需求必須有需求分析規範，每個需求會議必須有需求溝通(或評審)會議紀要，每個需求變更需要有需求變更記錄。
(3)方案設計實施小組:由各領域專家和執行者組成，負責需求方案的實施，與需求方到業務單元溝通達成壹致。最後，這個團隊的實現者在線完成需求(執行者可能與後來的“後期維護支持團隊”人員重復)。方案實施團隊必須對每個需求輸出方案，由事業部統壹模板輸出方案，控制方案質量。這個環節是目前需求實現中的壹個短板。很多需求都是在需求分析完成後直接扔給廠商實施的。實施方案的功能部分沒有經過評審，接口部分沒有經過論證和與業務單元溝通，導致質量沒有得到業務單元的認可。關於如何改進這壹點的建議如下:
首先將需求分為五個層次，要求在方案模板中說明。底層是功能需求，只針對功能本身；第二層是服務需求，包括業務和流程，提升服務能力的需求；第三層是體驗需求，考慮了客戶的感知需求，包括易用性、可操作性和感知性；第四層是關系需求；最頂層是對成功的需求，即滿足公司的組織成功，有效促進業務發展。目前，我們往往關註第壹層的功能需求，而對其他層次的需求關註不夠。即使在第壹層功能需求中，仍然存在簡單功能做不好，復雜功能能做好的情況。究其原因，是以IT慣性思維技術為導向，沒有以客戶需求為中心，沒有抓住需求的“痛點”，使得IT功能變得復雜。後續要更加關註第二到第五需求層次，更加關註易用性、可操作性和快速支持。
(4)後期維護支持團隊:目前傾向於“重建設輕維護”。需求上線後，即使結束了，監控和運營計劃也跟不上，上線後也無法主動發現問題。往往前端發現問題的時候已經來不及了，已經造成了更嚴重的後果。對此，後續維護支持團隊的首要任務是在需求上線初期建立監控和保障手段，用數據說話，證明新需求上線後的運行情況，先於業務單元發現問題並及時處理。其次，監控執行新需求上線後的運營計劃，集中解決新需求上線後的問題，為壹線提供支持。
如前所述，我們建立了矩陣式的需求管理體系，組建了壹支高精尖的需求團隊。那麽如何操作呢？
1.小前大後:需求分析團隊直接面對業務單元，但在我們背後有壹個強大的支持團隊(來自所有領域的專家、實施者、戰略合作夥伴等。).各領域整合資源形成整體支撐平臺，提供解決方案，提供技術支持。只有這樣，小前端需求分析師才有信心和資本去引導需求，引領實施。
2.炮兵火力壹線呼叫:當需求人員或需求預溝通發現重點需求時，壹線要快速反應，立即呼叫炮兵火力支援。後端會根據需求的難易程度配備必要的資源，在執行過程中動態補充人員，必要時使用ace團隊或ace專家，快速響應需求，執行計劃，穩步推進。
小前方、大後方、前線呼叫炮火的措施；
(1)來電的炮火要聚焦壹個原則:聚焦“痛點”或“需求問題”，才能實現“閃電戰”。這也是中央領導先說的重點“菜”。雖然我們喊的是火力，但是如果不能在整個需求的各個方面都體現出火力的局部優勢(火力分散)，這就需要我們的需求項目組與業務單元溝通，先集中精力做好關鍵的“菜”。這個原則的度壹定要控制好。
(2)組織人員保障:根據不同領域對不同人員進行標記，明確其職責，指出其發展方向，形成人力資源池。根據需求項目管理，上線後需求實現需要經理、需求分析師、技術支持人員、維護支持人員。需要標註各個部門的人員，屬於什麽角色，形成專家庫，為隨時組建團隊做準備。
(3)需求評估機制:事業部制定並發布了需求實施承諾書，包括權利和義務。權利就是在壹定範圍內分配資源，承諾實現需求目標，完成目標時有獎懲。項目經理代表團隊簽署承諾書，在需求上線後1個月內接受事業部評估，對團隊及成員進行獎勵或處罰。
(4)團隊和專家等級晉升機制:各類人才在評卷後成為該類型專家，需要根據需要對組建的團隊和專家的實施效果進行評估，采取部隊的晉升方式。通過評估篩選出Ace團隊和ace專家。在遇到重要需求和難題時，優先考慮王牌團隊和王牌專家，讓他們成為“特種兵”。這樣做的目的是將該師目前的“駐軍模式”升級為“精銳模式”，讓不確定、困難、復雜的重點需求由精銳士兵完成，增強感知。這樣也可以建立企業信息部的戰略儲備團隊，幫助IT團隊的後續發展。
(5)仲裁(指導)委員會:設立仲裁委員會的目的是打破部門之間的壁壘，具備橫向溝通和協同作戰的能力。如前所述，項目經理作為需求項目實施的第壹負責人，有壹定的權限動態分配資源。但如果在需求項目的實施過程中與職能部門有隔閡或沖突，或遇到其他管理問題或人力資源問題，仲裁委員會將以仲裁方式決定。建議仲裁委員會由事業部和部門領導組成，對非技術問題進行協調仲裁。
(6)技術委員會:事業部技術委員會負責解決和支持需求實施中遇到的方案問題，特別是確認哪個系統更好實施。當需求遇到技術難點時，技術委員會將對技術細節進行指導。
(7)需求管理平臺(缺失):目前事業部使用門戶和ITSM系統管理需求流程，但沒有統壹的需求管理平臺。各部門目前都是用EXCEL來管理需求，哪些需求逾期了，哪些是事業部當前的重點需求，哪些不合理，沒有需求管理系統來管理。因此，迫切需要建立壹個需求管理分析系統。
(8)會議管理系統(缺失):以業務部門為例。上周，業務部有65，438+00次會議，其中6次為要求會議。目前業務部門由人事管理。羅敏每周五發布周會報告，列出會議清單。在向安徽學習後，業務部要求每個參與者發布會議紀要，由羅敏進行總結。簡單的會議產生簡單的會議紀要，重要的會議產生詳細的會議紀要。我們希望有壹個會議管理系統，把每次會議的紀要上傳，納入系統管理。這樣才能有效杜絕需求與專項工作進度不壹致的情況。
(9)記錄需求變更:加強需求文檔管理。這裏，我們強調需求變更管理。因為有些重要的要求是公司領導的要求，業務單元需要根據領導的要求細化，不斷與領導溝通，必然會多次更改要求。為了保證需求盡快上線，在實現過程中必然會多次更改需求。這就要求每壹個需求變更都必須有文檔記錄，整個需求變更情況都要有記錄。還需要需求團隊與方案設計團隊和後續維護支持團隊做好溝通，將每次確認的內容文檔固定下來。這裏建立了事業部發布的需求變更模板。
(10)需求模式固化:首先選擇少量需求試點這種方法，積累經驗後快速固化實現流程，將流程和工作模板化清晰重復操作，抓住主模板建設，再將相關模板流程串起來不斷優化。形成知識庫，師裏通過呼叫炮火集中支援、處理、解決* * *問題。這些* * *問題的解決要形成壹個知識庫，在以後遇到類似問題的時候可以快速得到支持。
(11)需求透明化:月初召開需求版本部署會，與業務單元溝通本月要實現的需求；月中，事業部整體(或各需求項目經理)與需求業務單元溝通需求進度；次月上線後，與需求單位進行需求後評估，落實需求的後續維護和問題解決，溝通需求後評估結果。
(12)加強需求過程的管控:建立這壹機制後，需要進壹步加強需求過程的管控。授權不等於放任，實時監控很有必要。
？