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

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

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

一、項(xiàng)目籌備階段

對于證券期貨公司來說，大多數(shù)項(xiàng)目是因?yàn)橐郧皼]有需要新立項(xiàng)，少數(shù)項(xiàng)目是由于系統(tǒng)的直接用戶/領(lǐng)導(dǎo)難以忍受來通的bug或者無法負(fù)載需求而立項(xiàng)。

當(dāng)系統(tǒng)建設(shè)需求產(chǎn)生后，一般由IT團(tuán)隊(duì)給出系統(tǒng)建設(shè)的意見，是自研還是采購。有的時候業(yè)務(wù)部門會因?yàn)樾枨蠹逼榷Ｍ少彙澳苤苯邮褂玫南到y(tǒng)”，排除IT部門給出的自研或者合作研發(fā)方案。

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

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

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

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

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

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

二、項(xiàng)目招標(biāo)階段

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

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

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

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

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

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

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

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

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

三、項(xiàng)目實(shí)施階段

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

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

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

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

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

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

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

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

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

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

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

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

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

四、項(xiàng)目運(yùn)維階段

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

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

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

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

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

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

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

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

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

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

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