历时4小时的原型评审会

前言

本次评审的项目属于政务类管理系统。具体业务肯定就不能透露了，按照正常流程执行话，我预计评审时间在1.5h。这次却达到了惊人的4小时，本篇文章简单陈诉一下个人主观上总结的问题，同时也希望自己的总结能够给位同学的思考及帮助。

问题总结与分析

• 产品原型问题：为了提高操作数据录入效率，操作极其复杂，某些功能开发都难以理解。
  对于一个TOG管理系统，在满足需求的同时，产品界面统一简洁、操作方便 是非常重要的，因为公职人员群体年龄基本都是35+的偏多，所以在产品的设计上一定要考虑操作简单以及又容错性。我一个开发对于有些操作逻辑都很难理解，对于客户来说我相信就更难了。对于开发来说太复杂的逻辑也不利于后续的迭代。在传递这么复杂的操作上也花费了大量时间。

• 跨专业的讨论：业务过于介入到研发层面的讨论。
  业务介入到技术层面的讨论，导致双方理解不到对方的意思，这样的沟通导致浪费大量的时间。当然从另一个角度来说跨专业的讨论也可能产生一些新的idea，打破固有的思维局限。

• 前期的需求分析，数据调研不充分：没有需求文档，缺乏数据调研工作
  我们公司的开发流程是没有严格的需求分析流程的，需求是有业务反馈给产品，反馈给产品大多时候还是口头传递，没有需求文档输出。
  因此在评审的时候，这个需求到底是谁提的，产品和业务还在拉扯。
  有些数据应该有第三方在维护的，比如街道信息等，这些数据谁提供，能不能提供，是我们自己维护还是三方提供接口，这些前置工作没有提前做的。

建议

做To G的项目时，需求分析做得不够深入时，第一个版本，不要把细节做得太深入复杂。尽量常规功能常规做，多考虑产品易用性，减少用户误操作概率。调研工作提前开展，需求文档化。

欢迎各位大佬提留言评论