数据管理后台的需求回顾

题目虽然是叫“数据管理后台”，但实际上它仅仅是一个网页，可能叫“数据展示页”更为合适。之所以称为“管理后台”，是因为这样听起来比较牛逼，哈哈哈~

┃需求背景

对运营而言，我们现在有三个后台：老的数据后台、新的数据后台、运营管理后台。现在的产品数据分散在三个数据后台中，不仅运营每次需要在三个后台来回取数据，而且期中两个数据后台的入口极深且操作繁琐。取完数据后，运营还得花大量的时间去做图表。

随着我们产品用户量的增加，运营对数据的需求也越加细化，原有分散且不全面的数据已经严重影响到了运营的工作。所以，经例会讨论，决定在现有运营管理后台上集中运营所需要的所有数据。

当然，这件事属于支线任务，只有一个后台实习生支持，而且没有设计交互、前端、测试的支持。

PS：我也得在原本忙成狗的工作中，抽出一些时间来做好原型、沟通跟进、测试直到上线了。

┃入口位置

在现有运营后台（网址），菜单栏新增一个菜单，命名为“数据管理”。

[配截图]
PS：这里就不放了，毕竟涉及内部信息。

┃需求简单说明

1.此数据后台为内部使用，不对外。

2.由于时间和人力有限，且主要数据后台是内部几个运营同学使用，对页面设计、交互效果要求不高。重要是数据准确，展示和导出功能正常。

┃需求原型

大图查看链接：点我点我

┃详细定义及文档说明

PS：这里就不放了，主要是对原型中的很多定义做了解释，并且给了更加详细的逻辑及信息。

┃一些回顾

原以为这个这个需求会比较简单，能很快搞定，可事实远比想象的要复杂。

原因一：涉及到几十个复杂概念的定义。

比如“高质量管理员回复产品”，这个定义是指产品在“接入”的前提之下，连续4周管理员有回复且在统计周内至少有1条管理员回复的帖子被展示。而“接入”的判断标准是产品累计发帖数大于等于9。尼玛的.....

这个需求中涉及到很多类似这种非常复杂的定义，这些复杂定义产生的原因一方面是因为产品本身的复杂度，另一方面是有些定义为上面大佬想了解的.....

运营作为过来不久的同事，对我们产品有些定义也不十分明确。所以，我费了大量时间和运营一起去逐个确定概念的定义，并反复讨论了多次。当我清楚这些定义之后，给了后台同学文档，并逐个解释。然而，在做这个数据后台的过程中，后台也需要和我反复沟通定义问题。没办法，有些定义实在太复杂了。

原因二：多重维度、高度自定义的数据呈现及导出，在一个页面中以最简洁的形式呈现。

原型中既有按天的数据，又有按周的数据；即有按ID搜索的单个产品情况，又有整体的产品情况；既有按日期的单日量，又有按选择时间范围内的集合总量。

这些无法统一为一个形态展示的数据及需求，被放在了一个页面之中。所以，页面的布局我也考虑了比较久的时间。

原因三：中途新增需求

新运营同事的不熟悉，导致有一些中途新增比较大的需求。

比如：单个产品ID的搜索及相关数据的展示及导出。

这个需求在已经做得差不多的情况下提出，而且对运营来说是一个蛮重要的点，无法滞后或转移。于是，只能在现有页面上用最小的改动以达到想要的效果。

不过，最终的效果还是不错的。

经过了一段复杂的过程，终归有了一个不错的结果，是一件令人非常高兴的事情。

不断的学习、思考、执行、总结，这是产品人必经的成长过程。

哎呀，今天还没看书，赶紧学习去了......