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

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

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

一、項目籌備階段

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

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

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

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

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

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

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

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

二、項目招標階段

金融機構(gòu)的系統(tǒng)發(fā)展到一定階段必然會趨同，當IT部門邀請3~4家供應(yīng)商講解方案之后，基本就會發(fā)現(xiàn)幾個系統(tǒng)基本一樣只有某些環(huán)節(jié)或者某些功能的差異，究其原因也是因為需求一致，那么最優(yōu)的解決方案也會趨于一致。

金融機構(gòu)的業(yè)務(wù)系統(tǒng)并不存在絕對的競爭壁壘，一個供應(yīng)商剛發(fā)布了新產(chǎn)品，可能兩個月后另一個供應(yīng)商也能夠馬上推出一款新產(chǎn)品（集中交易系統(tǒng)等這類復雜系統(tǒng)除外）。

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

供應(yīng)商是典型的企業(yè)服務(wù)類公司，這類公司的組織結(jié)構(gòu)和收入結(jié)構(gòu)也很清晰，利潤=軟件銷售收入-人力/場地成本。

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

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

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

最終在報價的時候，由于多家廠商產(chǎn)品同質(zhì)化競爭，會發(fā)現(xiàn)有的廠家會不計成本以低價進行銷售，然后在項目后期迭代的時候賺回成本（后期迭代的時候甚至一個接口都會收費），或者在項目實施的時候配置極低的人力資源參與（比如剛畢業(yè)一年或者剛?cè)肼毜膯T工）。

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

三、項目實施階段

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

確定供應(yīng)商后，一般供應(yīng)商就要進場和業(yè)務(wù)部門確認需求了。

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

作為業(yè)務(wù)部門盡量在前期在IT部門的協(xié)助下，產(chǎn)出一份結(jié)構(gòu)相對完善的需求描述，用于供應(yīng)商評估和框定項目范圍。

然后要求供應(yīng)商基于需求描述產(chǎn)出詳細的需求文檔或者功能操作演示，由IT部門協(xié)助對業(yè)務(wù)場景、異常場景進行提問和解釋整理出詳細需求。然后對詳細需求進行優(yōu)先級排序產(chǎn)出研發(fā)計劃，這個過程也能幫助供應(yīng)商發(fā)現(xiàn)需要系統(tǒng)對接的工作。

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

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

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

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

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

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

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

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

四、項目運維階段

在項目研發(fā)和項目迭代過程中，會產(chǎn)生很多系統(tǒng)間對接的場景。

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

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

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

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

對供應(yīng)商來說，如果可持續(xù)性的完成多版本的迭代尤為重要。

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

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

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

本文由 @陸子樊 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議