編輯導語：本文闡述系統建設過程中甲乙方的差異與矛盾，以及如何幫助系統更好達成預期目標的措施，適合證券期貨公司業務人員/項目人員/信息人員以及系統供應商從業人員閱讀，希望對大家有幫助。

在供應商行業工作過并且也接觸過大量的友商之后，才知道當初自己做甲方的時候為啥總覺得乙方的產品很差。話說回來，系統建設不好這事兒，真不能全怪乙方。

外包系統建設的流程大致如下，下文把它切分為六個階段，重點闡述籌備、實施等環節的問題，文末分別針對甲方和乙方給出參考方案。

一、項目籌備階段

對于證券期貨公司來說，大多數項目是因為以前沒有需要新立項，少數項目是由于系統的直接用戶/領導難以忍受來通的bug或者無法負載需求而立項。

當系統建設需求產生后，一般由IT團隊給出系統建設的意見，是自研還是采購。有的時候業務部門會因為需求急迫而希望采購“能直接使用的系統”，排除IT部門給出的自研或者合作研發方案。

我們不去討論研發模式的選型問題，但是可以發現，不論是自研、采購或者合作研發等模式，都需要在項目推進之前，明確系統需要解決哪些場景的問題。

項目實施后往往會發現，因為前期需求不明確，而導致業務部門與IT自研團隊產生的矛盾，與后期和乙方產生的矛盾是驚人的相似。業務部門會覺得自研團隊響應很慢（開發速度慢），質量不好（系統有缺陷），功能不好用（需求理解和實現不一致），上線后逐漸就不再使用這個系統了。

尤其是對于新立項的項目，一定要在前期籌備階段，就要想清楚這個系統用來解決什么需求，哪些需求由其他系統解決，哪些需求還需要澄清或者有其他替代解決方案。以及系統上線后，如何評價系統是否滿足符合預期。

這些工作單純的靠業務部門很難梳理清楚，我接觸過大多數公司的業務同事基本都沒有全局需求分析能力，更多只能從場景提出問題，所以提出的需求往往有遺漏。

所以IT部門一定要通過邀請不同的供應商來進行業務培訓（系統培訓）幫助業務團隊形成需求概念，然后基于供應商提供的功能清單評估采購計劃和簡要需求概述，從而幫助業務團隊形成項目背景和項目范圍的描述。

否則項目驗收時候會發現業務代表提了一堆缺陷或者問題，實際上對開發商或者自研團隊來說是新需求，導致項目延期。

二、項目招標階段

金融機構的系統發展到一定階段必然會趨同，當IT部門邀請3~4家供應商講解方案之后，基本就會發現幾個系統基本一樣只有某些環節或者某些功能的差異，究其原因也是因為需求一致，那么最優的解決方案也會趨于一致。

金融機構的業務系統并不存在絕對的競爭壁壘，一個供應商剛發布了新產品，可能兩個月后另一個供應商也能夠馬上推出一款新產品（集中交易系統等這類復雜系統除外）。

對于供應商來說，第一個系統基本來源于定制化的產品，為某家客戶提供了定制化的系統之后，再做一定的封裝（為了對接異構系統），然后拿到其他客戶處銷售，然后再基于其他客戶的需求在基線版本（標準版本）上進行迭代，產生不同的版本分支。

供應商是典型的企業服務類公司，這類公司的組織結構和收入結構也很清晰，利潤=軟件銷售收入-人力/場地成本。

所以一套系統能賣的客戶越多，那么這套系統的邊際成本就越低。一個團隊能拿收入和回款就有獎金，否則就被撤銷。

為了提高人員利用率，供應商經常會安排一個人會參與多個項目的實施，這樣導致了為什么給供應商提需求的時候，供應商的脾氣器比自研團隊的排期要晚的原因，不是供應商的員工刻意擴大工時，而是他們的員工不是專人專用。

此外在定價的過程中，并不是也無法按照一個標準的價格進行報價，往往采用了價格歧視的定價策略，基于客戶的收入（證券期貨業排名）和議價能力（自研能力）進行報價，這種報價策略會導致客戶在評估真實價格的時候受到誤導。

最終在報價的時候，由于多家廠商產品同質化競爭，會發現有的廠家會不計成本以低價進行銷售，然后在項目后期迭代的時候賺回成本（后期迭代的時候甚至一個接口都會收費），或者在項目實施的時候配置極低的人力資源參與（比如剛畢業一年或者剛入職的員工）。

對于證券期貨公司來說，理想的項目價格是通過需求估算其研發成本（或者其他公司的平均成交價）和改造成本，通過（研發成本+改造成本）x系數獲得項目預算。而非一味的砍價而導致自己失去供應商優質人力項目資源的配置權。

三、項目實施階段

系統實施項目最常見的風險是進度風險（是否能完成），其次往往由于趕進度產生了質量風險（驗收上線不出問題）。項目進度也即項目計劃一般被三個因素影響：項目范圍、項目周期、項目人員。

確定供應商后，一般供應商就要進場和業務部門確認需求了。

問題往往在于，如果供應商可以隱瞞系統的缺陷或者體驗不好的地方，業務部門是無法在確認階段識別需求點的。尤其是對于新研發的項目，在沒有產品可以體驗的情況下，業務部門也難以基于直觀感受給出需求反饋。這樣往往導致在驗收過程中業務部門才提出未實現預期需求的情況。

作為業務部門盡量在前期在IT部門的協助下，產出一份結構相對完善的需求描述，用于供應商評估和框定項目范圍。

然后要求供應商基于需求描述產出詳細的需求文檔或者功能操作演示，由IT部門協助對業務場景、異常場景進行提問和解釋整理出詳細需求。然后對詳細需求進行優先級排序產出研發計劃，這個過程也能幫助供應商發現需要系統對接的工作。

要注意的是，業務部門不要抱有我付了錢所以都要做的想法來評估需求范圍，而要站在是否為最優解決方案的角度來評估需求是否實現和需求優先級。在有限的項目周期內，良好的需求管理能夠為系統對接和測試提供更充裕的時間。

新項目研發的周期一般不超過半年，否則會分1期和2期，已有項目的研發一般2個月左右就要求上線。

上線意味著要在有限的時間內完成系統對接、系統改造、功能測試、性能測試、系統部署等眾多工作。

上面提到新系統在沒有可以直觀體驗的產品下，業務部門難以給出需求反饋，即使采取上面描述的解決方案也很難保證業務部門不提出新的需求（需求總是會因為領導意見、流程變更、市場環境等原因而產生變化，所以項目周期不要做太長時間的規劃）。

所以在項目規劃的時候一定要在“上線后”（達成項目開始的計劃后）額外預留1~2個迭代的時間給客戶用于需求適配。

目前基本沒有系統可以“拿來就用”，而且業務和IT部門也經常會有相關的需求，這就導致了雖然供應商想賣標準的系統，但是每套系統實施都會有產生人力資源投入的情況。

換句話說，系統賣的越多，人力成本就越高。供應商為了降低人力成本，往往一個產品的核心人員只會配置2~3個，負責團隊管理和標準化產品設計，實際派出到客戶的項目人員以初級員工為主，一般畢業0.5~2年，甚至很多供應商不會配置產品經理或者需求分析師，而是由研發人員或者項目經理兼任，難免在溝通和理解上出現差異。

對于客戶來說，如果想保證項目質量或者控制風險，在了解乙方組織結構的情況下，要求他們的骨干人員直接參與項目，并且構建良好的溝通關系是最好的方式。

四、項目運維階段

在項目研發和項目迭代過程中，會產生很多系統間對接的場景。

這些問題可能不會在項目實施和研發過程中暴露，但是會在項目后期迭代和運維的過程中產生重大影響，系統之間對接的越多，運維的成本接越高，一個系統升級要考慮對周邊系統的影響，可能伴隨著幾套系統一起升級。

如果是面向終端用戶的產品，還要考慮多個APP、PC版本共存的情況。

大多數供應商的人員流失率都很高，除了一人身兼多個項目外，也會被專業能力、薪酬福利、出差頻率等各種因素影響。這也會給系統的二次開發帶來負擔，供應商接手的員工可能還沒有客戶的老員工對項目了解。

綜上所述項目啟動前，即使是業務部門主導的項目也要邀請IT部門，在需求確認后參與技術方案的評估和討論，通過統一的技術方案如APP小程序架構、統一接入、微服務等技術基礎設施實現系統直接的對接，來降低后期系統運維的成本。

對供應商來說，如果可持續性的完成多版本的迭代尤為重要。

在系統設計之初，就需要產品架構師和技術架構師做好充足的研究分析工作，以業務開發平臺為核心理念，切割功能模塊的職能，并且暴露好對外的接口。這樣不論是大型復雜項目的團隊協作，還是業務系統的持續迭代都不至于到后期“推翻重來”。

綜上所述，對于證券期貨公司而言，業務和IT需要緊密配合，在項目前期需要幫助業務梳理需求并且控制范圍，并且確定技術對接方案并且評審技術實現方案。對于核心系統在項目后期參與運維和二次開發，管理供應商人員變更的風險。

對于供應商而言，在啟動階段多進行研究分析，做好領域設計工作。在需求階段多與業務部門澄清需求，與IT部門確定系統對接模式。在實施階段預留好需求變更的時間，用于管理客戶預期。

本文由 @陸子樊 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議