数字化项目开发的几点经验_第1页
数字化项目开发的几点经验_第2页
数字化项目开发的几点经验_第3页
全文预览已结束

下载本文档

版权说明：本文档由用户提供并上传，收益归属内容提供方，若内容存在侵权，请进行举报或认领

文档简介

开发数字化项目的时候，一定要有风险意识：数字化项目个性化很强，每个项目都要当成创新项目，都可能偏离用户需求；每个数学模型的工作量都可能会很大，都有可能花费半年到一年的时间。对需求的理解，非常容易出问题。如果对需求理解不到位，很可能到临近结束或验收时才发现问题。这样就非常被动了。为了避免这样的问题，我有如下几个建议：01会写代码的人，写用户需求。做数字化项目的过程，是把人的想法转化成计算机代码。日常语言的严密性和计算机代码的严密性完全不是一个级别的。写过代码的人，才能体会到日常语言描述的模糊性。原始需求是用户提出的，写过代码的人要在理解用户需求的基础上重写、变成正式的文档，反馈给用户。期间要经过几轮交流，才能确认下来。02需求描述必须要清楚做模型的要知道：用户需求不仅仅是达到某些指标。用户首先是在特定场景下做某件事情，这件事情对指标有要求。许多项目的失败，源于对需求场景的理解。所以，描述需求的时候，建议采用原型方法，比如先把用户界面“画出来”（可以用PPT），要和用户交流在各种场景下，如何使用这个软件。用户对计算和模型有需求时，要用数学公式表达数据的输入输出关系和这些公式的适用场景，避免模糊的日常语言。03尽量与不同岗位的人交流、与最终用户交流即便在用户的工厂里，不同人对需求的理解是不一样的。厂长的理解可能与技术人员不一样，技术人员可能与操作工不一样。不同岗位的人，理解也不一样。这些人都需要进行交流。特别地，要尽量创造条件，与最终用户交流。许多系统的最终用户是现场的操作工。04注意交流的方式交流过程，开始的时候最好不要一对一；因为某个人的表达和理解可能会有问题、中间可能会卡住，可能会说不清楚。多个人交流的时候可以互补、可以换个角度描述、可以互相启发。特别地，有些项目涉及到多方面的人，就需要各个部门的人都参加。但是，为了有较好的交流效果，参加的人数也不宜过多，双方各出2、3人比较合适。如果涉及到的人很多，就分多次交流。交流到后期，遇到具体问题时，可以找关键人物单独交流。编写代码时，对细节要求非常高。如果问得过细，用户就可能会感到厌倦。为了避免这类问题，开发人员要尽量事先做好准备、有尽量多的专业知识。同时，最好能与对方建立较好的私人关系。05注意总结经验教训经验往往来自于教训。所谓的教训，就是后来想的和最初想的不一样，导致有些工作推倒重来。出现教训后，一定要想出办法、避免下次再犯。总结教训时，不要仅仅是举一反一，要举一反三、举一反十。总结教训的时候，要集思广益。总结教训不要等到项目结束，最好是日常性的。06前期调研时间要足够长对于创新项目来说，如果前期调研不够细，后面难免推倒重来。前期要舍得花时间，才能避免这种情况。真正动手做的时候，要把风险基本排除，让写程序的人觉得模型真正具备可行性。想不清楚就不要做。其中，最困难的问题大概是模型。所以我一直强调，做模型的思路要对、不要复杂化，要做点预研来判断模型的大

人人文库> 全部分类> 行业资料 > 信息产业

温馨提示

  • 1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论