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

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

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

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

02需求描述必須要清楚

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

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

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

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

04注意交流的方式

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

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

05注意總結(jié)經(jīng)驗教訓

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

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

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

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

審核編輯 ：李倩