个人后台设计法则：
一 像业务一样的发散考虑业务未来可能的发展情况，在此基础上需要哪些功能。
二 像研发一样的逻辑化思考，尽可能的少造轮子。
三 像实际使用者一样思考，第一次使用是不是会犯错，重复使用会不会效率低下。
对一个问题站在不同的角度上考虑，给出不同的解决方案。然后站在产品的立场上对所有解决方案进行对比整合进而做出最优解。
同所有需求的处理方式一样，接受到后台需求的第一步就是搞清楚需求是什么。常见的后台类需求主要为这样几个类型：已有功能提升效率/实现对前台功能的管理/后台管理功能。
日常工作中会遇到的真实场景是：
a.XXX，我这每天处理这么多东西，很难用，你要不加上XXX就好了。
b.XXX，APP上我想做个入口，然后这样XXX，再XXXX，就可以增加用户活跃了。
c.XXX，每天在库里面拉数据，太麻烦了，能增加XXX功能吗。
其实以上a b c 对应的就是上面所说的三个类型。其实这个类型划分并不够精准，但是对于现阶段日常工作来说，这种划分及后面总结的处理方式可以很方便解决问题。
当然后台划分十分复杂，经常接触到的是客户端的后台，但实际工作中还会涉及到从零开始设计后台的情况。当前我就在独立设计一套后台系统，在这个过程中，希望自己可以通过不断反思的方式优化自己的设计。
现在来说关于上面三个不同类型后台需求的处理方法。
第一种：已有功能提升效率
需求关键点：量大/慢/忙不过来/容易混淆/难上手
问题下手点：
a 首先需要克服心态上的错误认识，比如这就是你的工作啊，不就是干这个的吗。这种情绪会影响思维的客观性，不利于工作的开展。会导致简单粗暴的完成需求，很可能重复返工。增加自己和研发的工作量。
b 同需求方沟通需求之后，自己在测试环境上尝试十次以上他们的日常操作，分析问题原因是系统设计本身问题，还是使用习惯上的问题。使用习惯类的问题，在研发时间紧张的情况下，通过培训等方式解决；研发时间宽裕的时候，优化操作，并记录到PRD文档中，在日后设计中注意此类问题。
c 系统设计类问题，找到问题的关键点。例如我曾处理过的一个需求为客服使用业务系统的时候需要跳转多个页面查询需要内容。那么这个需求的关键点就是客服平时使用系统的时候都要看哪些字段，分布在哪些位置，为什么要看这些字段，看完之后的动作是什么。
d 分析问题出现原因，给出解决方案。后台是给人用的，那么在给出解决方案的时候，不能只是简单的头疼看头，而是针对问题给出全套解决方案，从操作开始到操作结束。上面提到的客服问题，通过沟通和观察可以发现客服的常用处理流程为：接听电话，查看用户信息，查询客户问题原因，记录客户来电内容，解决客户问题，回访解决情况，案件入库，案件质检评分，结束。那么解决方案就不应该是简单的把客服所有需要的内容挤在一个页面展示。而是包括：客服来电自动查询，页面集成展示客户非敏感资料，页面填写来电记录，页面可跳转查看用户所有来电咨询内容，问题处理进程可视化等步骤。
e 评估解决方案当前可实现情况。一个问题给出了全套的解决方案之后，需要同研发沟通实现过程的困难点和实现各个功能的时间，再同需求方沟通对方期望的上线时间和实现方案的修改等内容。
f 产出文档。以上过程中应该已经完成了简单的原型制作，保证了三方（研发/需求/产品）对需求本身都有了较为深刻的理解，再此基础上完成文档的编写即可。
我当前再写文档上还是会出现特殊情况思考不够全面的问题，除了写的时候思考更全面一点，也准备入手学习基本的测试方式。（写文档的时候要站在测试的角度上！亲测好用！如果测试可以看懂并且认可你的文档，那就是好的文档了！）
第二种：实现对前台功能的管理
同第一种相同的地方就不再赘述，着重分析这种情况下，处理思路和常见问题。
前台功能是指会直接面对客户功能。这类功能的需求方不是简单的客户，还包括运营。但在一定程度上客户和运营想要达成的目标可能会存在矛盾，如何平衡用户和运营，并在此基础上保证研发不会砍死自己，就成了此类需求吸引人的地方。
举个例子，刚在别的社区看到APP上要管理问股这个功能，后台要怎么设计。（问股：就是炒股的朋友们会在社区里面问一些关于股票的问题，由专业的人士回答这类问题）那么这个需求我的处理方法如下：
a.去不同的问股类的论坛。看他们经常问什么，最常问的十个词是什么。看最赞的回答是什么，最赞的回答常有的十个关键词是什么。看回答的内容是不是已经得到验证。提问的人大概画像是什么，回答的人画像是什么。
b.找运营同事，这个功能提出者为什么提出这个功能，希望这个功能达成什么目的（盈利/促进活跃/树立品牌），打算怎么运营这个功能（免费/付费/邀请制/注册制/用户等级打算如何设计等），可能会采取哪些运营动作（活动/广告/营销）。
c.同设计前端的产品，沟通打算如何设计这个功能，如何展示，为什么要这么设计。期望用户的行为路径是什么。不同身份用户进入之后是否会有不同的展示。（一般情况下，一个功能是包括前端和后端的，很多公司中一个功能的设计是一个产品完成，但复杂的需求也会拆分为前端产品和后端产品）
d.根据前面的分析，拆分维度。
人的维度：客户（提问者/回答者/其他客户）/运营（活动运营/用户运营/社区运营）
不同维度希望达成的目标如下：
提问者：提问数增加/提问有回答/可以匹配合适的回答者
回答者：完善的奖励机制（头衔/收入/其他奖励）/回答活跃
活动运营：可以针对该功能推出针对性的活动，并可以对活动进行监控。
用户运营：保证用户体验和活跃度
社区运营：保证社区秩序和话题度
那么通过拆分可以得出该前台功能需要后台实现如下功能：
1.用户分群管理（用户头衔管理/资料管理/提问回答历史管理等）
2.个性化推荐（首页展示/详情页展示）
3.埋点统计（用户行为埋点统计）
4.活动管理
5.广告管理
6*充值类客户账户管理（如果回答和提问时付费的，则此部分需要同财务沟通）
7.数据报表（活跃度/运营数据等）
8.监控管理（敏感词管理/用户账户安全管理等）
e.之后的步骤就是常见需求处理及页面迭代的工作。
上面的拆分只是简单的分析，实际上这种需求的难度和需要的功能会远多于上面列举。举着个例子只是提供一个此类需求的分析处理思路。不涉及具体的后台页面设计，比如各类栏目如何排序，每个栏目下的一级页面和二级页面如何关联。
设计需求时站在需求方需求发展的角度，设计原型时站在使用者的角度，写文档时站在测试的角度。
第三种类型的处理思路和上面已经有重复就不展开说明了。
工作就是不断总结经验，有时间会把自己处理过的需求梳理一下，整理出常见的错误和优化方案。
希望自己新的系统设计愉快，需求爸爸和研发爸爸可以满意。
希望我可以坚持把这个反思写个十篇吧。捂脸逃。
网友评论