開發(fā)數(shù)字化項目的時候，一定要有風險意識：數(shù)字化項目個性化很強，每個項目都要當成創(chuàng)新項目，都可能偏離用戶需求；每個數(shù)學模型的工作量都可能會很大，都有可能花費半年到一年的時間。對需求的理解，非常容易出問題。如果對需求理解不到位，很可能到臨近結束或驗收時才發(fā)現(xiàn)問題。這樣就非常被動了。為了避免這樣的問題，我有如下幾個建議：01會寫代碼的人，寫用戶需求。做數(shù)字化項目的過程，是把人的想法轉化成計算機代碼。日常語言的嚴密性和計算機代碼的嚴密性完全不是一個級別的。寫過代碼的人，才能體會到日常語言描述的模糊性。原始需求是用戶提出的，寫過代碼的人要在理解用戶需求的基礎上重寫、變成正式的文檔，反饋給用戶。期間要經過幾輪交流，才能確認下來。02需求描述必須要清楚做模型的要知道：用戶需求不僅僅是達到某些指標。用戶首先是在特定場景下做某件事情，這件事情對指標有要求。許多項目的失敗，源于對需求場景的理解。所以，描述需求的時候，建議采用原型方法，比如先把用戶界面“畫出來”（可以用PPT），要和用戶交流在各種場景下，如何使用這個軟件。用戶對計算和模型有需求時，要用數(shù)學公式表達數(shù)據的輸入輸出關系和這些公式的適用場景，避免模糊的日常語言。03盡量與不同崗位的人交流、與最終用戶交流即便在用戶的工廠里，不同人對需求的理解是不一樣的。廠長的理解可能與技術人員不一樣，技術人員可能與操作工不一樣。不同崗位的人，理解也不一樣。這些人都需要進行交流。特別地，要盡量創(chuàng)造條件，與最終用戶交流。許多系統(tǒng)的最終用戶是現(xiàn)場的操作工。04注意交流的方式交流過程，開始的時候最好不要一對一；因為某個人的表達和理解可能會有問題、中間可能會卡住，可能會說不清楚。多個人交流的時候可以互補、可以換個角度描述、可以互相啟發(fā)。特別地，有些項目涉及到多方面的人，就需要各個部門的人都參加。但是，為了有較好的交流效果，參加的人數(shù)也不宜過多，雙方各出2、3人比較合適。如果涉及到的人很多，就分多次交流。交流到后期，遇到具體問題時，可以找關鍵人物單獨交流。編寫代碼時，對細節(jié)要求非常高。如果問得過細，用戶就可能會感到厭倦。為了避免這類問題，開發(fā)人員要盡量事先做好準備、有盡量多的專業(yè)知識。同時，最好能與對方建立較好的私人關系。05注意總結經驗教訓經驗往往來自于教訓。所謂的教訓，就是后來想的和最初想的不一樣，導致有些工作推倒重來。出現(xiàn)教訓后，一定要想出辦法、避免下次再犯?？偨Y教訓時，不要僅僅是舉一反一，要舉一反三、舉一反十?？偨Y教訓的時候，要集思廣益?？偨Y教訓不要等到項目結束，最好是日常性的。06前期調研時間要足夠長對于創(chuàng)新項目來說，如果前期調研不夠細，后面難免推倒重來。前期要舍得花時間，才能避免這種情況。真正動手做的時候，要把風險基本排除，讓寫程序的人覺得模型真正具備可行性。想不清楚就不要做。其中，最困難的問題大概是模型。所以我一直強調，做模型的思路要對、不要復雜化，要做點預研來判斷模型的大