本文是作者在建立数据共享系统时对遇到的一些情况进行的复盘思考，按照产品层和开发层两个角度总结出的经验教训，与大家分享！
一、产品介绍
1. 数据共享系统
数据共享系统是一个实现数据上云与下云的工具型产品，第一期主要实现结构化数据与非结构化数据的下云任务，同时可以对申请的任务设置定时调度更新。
2. 产品原型五大模块
用户分组——用户可以以组的形式申请、创建任务；
自定义数据源——对想要进行数据共享的数据源自主系统注册，通过选择对应数据源，实现特定数据源下数据共享；
以任务的形式实现数据共享；
审批工作流的功能——对共享的任务需要进行严格的审批流程，以保护数据安全；
全系统审计——对保证数据安全传输及共享，对系统中任务动作都进行日志审计；
二、产品回顾
当前产品的第一期已经接近尾声，回顾整个项目历程，中间遇到的部分功能重构情况是完全可以避免的。
系统首期即将结束，对项目中遇到的一些情况进行复盘思考，并从中总结出了一些经验，以下是按照不同角度进行分类的经验教训：
1. 产品层
2.1.1 多与客户沟通，了解功能背后的业务背景
通过与客户不断沟通，逐步了解客户使用系统的场景及功能的业务背景，才能真正让系统功能满足客户需求。
项目启动后，第一时间奔赴客户端，与客户进行了系统性的需求了解。根据第一次的沟通，首先梳理了整个业务流程；同时查找根据获取的相关信息查找对应的竞品。流程定后，再次与客户确认整个流程的完备性。
就这样流程、功能点、系统模块分类、初版原型、原型确认、调整原型、再次确认等不断的与客户进行沟通，一次次的向最底层需求探索，一步步熟悉了解客户的业务场景。
由于整个项目的周期较短，需要对系统功能等尽快确认，抓紧时间定板整个设计。
产品的功能包括数据源管理、用户组管理、任务管理、审批管理等，任务管理是整个产品的核心。由于数据安全有较高的要求，任务管理中数据的共享就要设计好相关的安全策略，对相关的设计要即时向客户确认。
这样就可以避免因一点的设计偏差引起其他点的偏离，影响整个项目的周期。
2.1.2 界面细节
前期需求设计时多考虑细节，如写清楚必填字段，减少后期的沟通成本。
整个产品涉及的页面较多。虽然按照优先级输出了原型，但是原型中许多细节没有完全注意到。比如页面的必填字段、需要校验的字段、某些字段的关联性等。
产品设计时要尽可能多考虑这些细节，时间紧迫的情况下，可以按照需求的优先级，保持和开发同步的节奏进行产品设计。先把一个功能点想透彻后并在原型中备注后，在考虑另一个功能点，这样开发在进行中，会节省很多沟通成本，同时逻辑也会更加清晰。
2.1.3 功能优先原则
根据项目的性质不同，重功能，体验次之。
对于B端产品来说，更重要的是解决客户问题，实现客户的业务需求，真正帮助客户提高办事效率，特别对于工具型系统来说，功能就比较重要，这个和展示型系统有较大的区别。在功能实现的基础上，再完善用户体验问题。
2.1.4 需求整理
将各类需求归总整理，确保需求不遗漏。
在需求确认阶段，需求会比较集中。当进入设计阶段后，需求的来源就会比较多，如与客户的讨论中客户忽然提到的新的需要点、客户在进行原型评审时提到的一些反馈点，有些功能点常常是口头或是微信等提到就结束了的等。
对于研发人员，他们介入一个项目时往往是刚从另一个项目中抽离出来。他们最迫切的就是先进行研发，对于一些细节、优化、BUG等都会放到后期一起处理。
这时将需求要进行统一整理，形成项目的需求池就显的至关重要，这样在后期追踪或是客户忽然提到时有准备，且开发时不会遗漏，同时也节省开发人员节省寻找需求的时间。
2.1.5 与技术人员沟通
需求变动时，先与技术人员沟通，确保技术的可实施性。
当接到新的需求时，先要思考客户为什么有这个需求？这个需求的业务场景是什么？客户的提到的需求是解决方案还是真实需求？还有更重要的，要与开发人员沟通实施的可行性，需求是否合理？
从研发的角度出发，对于新的需求需要的视角与实现的难易程度，当与开发确认好后，再次确认需求的必要性。当所有都满足时再加入到需求池中，排入开发周期中。
2.1.6 系统演示
产品设计后，要尽早进行给最终客户进行系统演示。
当原型设计好后，尽早给客户演示，尽早的让客户看到系统的样子，激发他们的需要点。这样有利于更快挖掘到客户内在需要，为开发等争取更多的时间，为后期系统优化争取尽可能多的时间。
2. 开发层
2.2.1 尽早的参与到需求评审中
产品在与客户沟通时，项目组中重要成员要尽量一起参加，这样可以对需求理解的更加深刻。看到系统原型时，可以从开发的角度出发，提出建设的意见，提高整个项目的沟通效率，对产品设计不合理的地方尽早提出，这样可以规避重工的风险。
产品在设计时虽然是根据客户需求，对整个项目的需求起到把控的作用，但要做到各个功能、各个细节想到位有点难。这时就需要研发人员及时沟通与反馈，及时从开发的角度提出他们的想法，如整个流程及功能的想法，这样提高效率的同时，减少功能重工的风险。
2.2.2 技术框架
根据系统功能，先要尽可能多想一步，定的框架不会因为后期的部分更新导致框架的重构。
开发在拿到系统原型后，首先要考虑整个系统的架构问题，不是看原型就开始敲代码。一个灵活，兼容的框架会使后期少去很多工作量。
