數(shù)字化項(xiàng)目開發(fā)的幾點(diǎn)經(jīng)驗(yàn)

開發(fā)數(shù)字化項(xiàng)目的時候，一定要有風(fēng)險意識：數(shù)字化項(xiàng)目個性化很強(qiáng)，每個項(xiàng)目都要當(dāng)成創(chuàng)新項(xiàng)目，都可能偏離用戶需求；每個數(shù)學(xué)模型的工作量都可能會很大，都有可能花費(fèi)半年到一年的時間。

對需求的理解，非常容易出問題。如果對需求理解不到位，很可能到臨近結(jié)束或驗(yàn)收時才發(fā)現(xiàn)問題。這樣就非常被動了。為了避免這樣的問題，我有如下幾個建議：

01會寫代碼的人，寫用戶需求。

做數(shù)字化項(xiàng)目的過程，是把人的想法轉(zhuǎn)化成計(jì)算機(jī)代碼。日常語言的嚴(yán)密性和計(jì)算機(jī)代碼的嚴(yán)密性完全不是一個級別的。寫過代碼的人，才能體會到日常語言描述的模糊性。原始需求是用戶提出的，寫過代碼的人要在理解用戶需求的基礎(chǔ)上重寫、變成正式的文檔，反饋給用戶。期間要經(jīng)過幾輪交流，才能確認(rèn)下來。

02需求描述必須要清楚

做模型的要知道：用戶需求不僅僅是達(dá)到某些指標(biāo)。用戶首先是在特定場景下做某件事情，這件事情對指標(biāo)有要求。許多項(xiàng)目的失敗，源于對需求場景的理解。所以，描述需求的時候，建議采用原型方法，比如先把用戶界面“畫出來”（可以用PPT），要和用戶交流在各種場景下，如何使用這個軟件。

用戶對計(jì)算和模型有需求時，要用數(shù)學(xué)公式表達(dá)數(shù)據(jù)的輸入輸出關(guān)系和這些公式的適用場景，避免模糊的日常語言。

03盡量與不同崗位的人交流、與最終用戶交流

即便在用戶的工廠里，不同人對需求的理解是不一樣的。廠長的理解可能與技術(shù)人員不一樣，技術(shù)人員可能與操作工不一樣。不同崗位的人，理解也不一樣。這些人都需要進(jìn)行交流。特別地，要盡量創(chuàng)造條件，與最終用戶交流。許多系統(tǒng)的最終用戶是現(xiàn)場的操作工。

04注意交流的方式

交流過程，開始的時候最好不要一對一；因?yàn)槟硞€人的表達(dá)和理解可能會有問題、中間可能會卡住，可能會說不清楚。多個人交流的時候可以互補(bǔ)、可以換個角度描述、可以互相啟發(fā)。特別地，有些項(xiàng)目涉及到多方面的人，就需要各個部門的人都參加。但是，為了有較好的交流效果，參加的人數(shù)也不宜過多，雙方各出2、3人比較合適。如果涉及到的人很多，就分多次交流。交流到后期，遇到具體問題時，可以找關(guān)鍵人物單獨(dú)交流。

編寫代碼時，對細(xì)節(jié)要求非常高。如果問得過細(xì)，用戶就可能會感到厭倦。為了避免這類問題，開發(fā)人員要盡量事先做好準(zhǔn)備、有盡量多的專業(yè)知識。同時，最好能與對方建立較好的私人關(guān)系。

05注意總結(jié)經(jīng)驗(yàn)教訓(xùn)

經(jīng)驗(yàn)往往來自于教訓(xùn)。所謂的教訓(xùn)，就是后來想的和最初想的不一樣，導(dǎo)致有些工作推倒重來。出現(xiàn)教訓(xùn)后，一定要想出辦法、避免下次再犯?？偨Y(jié)教訓(xùn)時，不要僅僅是舉一反一，要舉一反三、舉一反十?？偨Y(jié)教訓(xùn)的時候，要集思廣益?？偨Y(jié)教訓(xùn)不要等到項(xiàng)目結(jié)束，最好是日常性的。

06前期調(diào)研時間要足夠長

對于創(chuàng)新項(xiàng)目來說，如果前期調(diào)研不夠細(xì)，后面難免推倒重來。前期要舍得花時間，才能避免這種情況。真正動手做的時候，要把風(fēng)險基本排除，讓寫程序的人覺得模型真正具備可行性。想不清楚就不要做。其中，最困難的問題大概是模型。所以我一直強(qiáng)調(diào)，做模型的思路要對、不要復(fù)雜化，要做點(diǎn)預(yù)研來判斷模型的大體精度。具體做法過去談過多次。

開發(fā)個性化的數(shù)字化系統(tǒng)的成本和風(fēng)險是很大的。如果經(jīng)驗(yàn)、知識和代碼不能復(fù)用，項(xiàng)目的經(jīng)濟(jì)性往往就不好。

審核編輯 ：李倩