数字化项目开发的几点经验

开发数字化项目的时候，一定要有风险意识：数字化项目个性化很强，每个项目都要当成创新项目，都可能偏离用户需求；每个数学模型的工作量都可能会很大，都有可能花费半年到一年的时间。

对需求的理解，非常容易出问题。如果对需求理解不到位，很可能到临近结束或验收时才发现问题。这样就非常被动了。为了避免这样的问题，我有如下几个建议：

01会写代码的人，写用户需求。

做数字化项目的过程，是把人的想法转化成计算机代码。日常语言的严密性和计算机代码的严密性完全不是一个级别的。写过代码的人，才能体会到日常语言描述的模糊性。原始需求是用户提出的，写过代码的人要在理解用户需求的基础上重写、变成正式的文档，反馈给用户。期间要经过几轮交流，才能确认下来。

02需求描述必须要清楚

做模型的要知道：用户需求不仅仅是达到某些指标。用户首先是在特定场景下做某件事情，这件事情对指标有要求。许多项目的失败，源于对需求场景的理解。所以，描述需求的时候，建议采用原型方法，比如先把用户界面“画出来”（可以用PPT），要和用户交流在各种场景下，如何使用这个软件。

用户对计算和模型有需求时，要用数学公式表达数据的输入输出关系和这些公式的适用场景，避免模糊的日常语言。

03尽量与不同岗位的人交流、与最终用户交流

即便在用户的工厂里，不同人对需求的理解是不一样的。厂长的理解可能与技术人员不一样，技术人员可能与操作工不一样。不同岗位的人，理解也不一样。这些人都需要进行交流。特别地，要尽量创造条件，与最终用户交流。许多系统的最终用户是现场的操作工。

04注意交流的方式

交流过程，开始的时候最好不要一对一；因为某个人的表达和理解可能会有问题、中间可能会卡住，可能会说不清楚。多个人交流的时候可以互补、可以换个角度描述、可以互相启发。特别地，有些项目涉及到多方面的人，就需要各个部门的人都参加。但是，为了有较好的交流效果，参加的人数也不宜过多，双方各出2、3人比较合适。如果涉及到的人很多，就分多次交流。交流到后期，遇到具体问题时，可以找关键人物单独交流。

编写代码时，对细节要求非常高。如果问得过细，用户就可能会感到厌倦。为了避免这类问题，开发人员要尽量事先做好准备、有尽量多的专业知识。同时，最好能与对方建立较好的私人关系。

05注意总结经验教训

经验往往来自于教训。所谓的教训，就是后来想的和最初想的不一样，导致有些工作推倒重来。出现教训后，一定要想出办法、避免下次再犯。总结教训时，不要仅仅是举一反一，要举一反三、举一反十。总结教训的时候，要集思广益。总结教训不要等到项目结束，最好是日常性的。

06前期调研时间要足够长

对于创新项目来说，如果前期调研不够细，后面难免推倒重来。前期要舍得花时间，才能避免这种情况。真正动手做的时候，要把风险基本排除，让写程序的人觉得模型真正具备可行性。想不清楚就不要做。其中，最困难的问题大概是模型。所以我一直强调，做模型的思路要对、不要复杂化，要做点预研来判断模型的大体精度。具体做法过去谈过多次。

开发个性化的数字化系统的成本和风险是很大的。如果经验、知识和代码不能复用，项目的经济性往往就不好。

审核编辑 ：李倩