数据共享系统项目复盘：产品层与开发层

一、产品介绍

1. 数据共享系统

数据共享系统是一个实现数据上云与下云的工具型产品，第一期主要实现结构化数据与非结构化数据的下云任务，同时可以对申请的任务设置定时调度更新。

• 产品用户：对结构化数据与非结构化数据下云的需求者；
• 产品服务购买决策者：总署信息中心技术科；
• 产品功能：数据源注册、下云任务申请、审批流程、下云数据，调度更新等功能；
• 用户主要诉求点：保障数据安全的在云上实现不同类型数据共享；
• 产品原型：5大模块，每个模块包含若干信息流；

2. 产品原型五大模块

1. 用户分组——用户可以以组的形式申请、创建任务；
2. 自定义数据源——对想要进行数据共享的数据源自主系统注册，通过选择对应数据源，实现特定数据源下数据共享；
3. 以任务的形式实现数据共享；
4. 审批工作流的功能——对共享的任务需要进行严格的审批流程，以保护数据安全；
5. 全系统审计——对保证数据安全传输及共享，对系统中任务动作都进行日志审计；

二、产品回顾

当前产品的第一期已经接近尾声，回顾整个项目历程，中间遇到的部分功能重构情况是完全可以避免的。

系统首期即将结束，对项目中遇到的一些情况进行复盘思考，并从中总结出了一些经验，以下是按照不同角度进行分类的经验教训：

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 技术框架

根据系统功能，先要尽可能多想一步，定的框架不会因为后期的部分更新导致框架的重构。

开发在拿到系统原型后，首先要考虑整个系统的架构问题，不是看原型就开始敲代码。一个灵活，兼容的框架会使后期少去很多工作量。

本文作者 @迎风走 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！