没有一种简单而通用的方法能适合一切项目的风险分析,都要结合实现项目背景进行具体分析,加以特定处理。由此何见,评价模型的通用性是风险研究中巫待解决的问题。用户的需求是复杂而又个性化的,通用性虽然可以提高模型的抽象能力,但势必造成一般用户难于理解、不便使用,有时也使数据采集相当困难。

因此,风险评价模型还需要在两个方面做出努力。一方面是从模型入手,不断从实际应用中总结经验,提高模型的通用性,另一方面要从问题空间入手,不断地对系统进行抽象概括描述,使其地反映实际系统,适应风险管理决策的要求。

代码质量评测。分析项目在GitHub上的代码质量、逻辑架构来判断项目的开发实力。如果代码质量差或者架构存在重大缺陷，预示着项目的高风险性1。功能评测。对项目产品的实际运行性能评测，包括主网功能、钱包功能 、区块浏览器功能、协议的实际案例落地运行情况等。代币分布。评估项目方公布的代币分配计划是否合理、分配细节是否清晰。

改进措施，完善项目沟通管理机制，明确信息同步途径和信息同步频率，利用wiki、svn等信息管理平台或工具维护项目公告信息，并确保项目组新老成员都及时阅读相关信息；重视流程，但不应机械对待流程，对正式途径反馈的风险以及非正式途径的风险问题信号应同等重视，并主动推动相关成员按照流程反馈风险。项目联调阻塞产生进度风险，没有***相关***针对问题进行分析，而是简单粗暴的要求项目组成员加班赶工。但随后事实证明阻塞问题不是单纯工作量问题，项目组成员加班除了苦劳以外，并没有解决任何问题，终导致项目出现严重进度滞后。