近期在任务上独立完成了一份后台的需求规格阐明书，因而有了一些心得领会。在这之前，我阅读过许多关于后台设计的文章，大局部文章都是在论述如何设计后台，给了我们很多设计理念上的建议与协助。
只是，无论什么样的设计都最终都需求以文档的方式产出，因而，本文我将在后台需求文档的撰写上分享本人的心得和建议。如今，我们先来做做下笔前的思想任务：
为什么要停止后台设计？
我们设计后台的初心，都是为了支撑业务，并进一步进步运营效率和产品竞争力，这是我们在设计后台时需求时辰提示本人的。由于后台的产品不需求过多的思索UI和交互设计，所以在明白好业务逻辑和零碎架构之后，将效率的提升作为后台产品的重要目标（KPI），留意防止用户在运用你的产品时，做太多反复、机械的操作。
下笔的前提：
关于后台的设计还是需求老话重提。产品经理一定要对你所设计的后台业务了如指掌，亲身深化到业务的实践任务中去，将任务流拆分红多个环节，构成功用的初步设想。时期，你需求记载下业务的全体流程和触及到的元素，如字段、字段限制、业务要求等。
我团体的习气是先将这局部内容写于纸上，清楚的梳理好业务之后，再将内容转化成电子档。在纸上，你可以迅速的对内容停止编辑、修正，甚至可以将原型直接画出，让功用先复杂的出现出来，再停止调整改动，这样可以增加很多电脑操作的工夫。
同时还需明白目的用户，也就是这个功用是给谁用的。普通后台的目的用户都是公司外部人员，如运营、市场等等，用户就在身边，那么产品经理千万不能糜费时机，一定要与用户停止沟通，提炼出他们的需求。以下是可以提的一些成绩举例：
- 过来是怎样处置这项业务的？
- 哪一个环节给你带来困扰或许说需求破费你少量的工夫去完成？
- 你最希望完成的功用是什么？
- 谁可以操作这项业务？操作的范围又是哪些？
- 能否需求对用户的操作行为停止记载？
……
大家可以依据实践状况停止成绩的罗列和发问，只要充沛地融入到用户中，才干设计出走心的后台哦。
总结一下，下笔之前需求明白几个要素：角色、角色的权限（包括功用权限和数据权限）、业务流程、所需字段、操作日志等。
下笔的顺序
无论是功用还在初拟阶段还是曾经开端撰写需求文档，下笔的顺序一定是从中心功用（业务）->分支功用（业务），由于中心功用是奠定整个后台的根底，其他功用都是围绕着中心功用延伸开来。无论是字段规则还是业务规则，其他功用都必需与中心功用坚持分歧，才干够保证后台的顺利运转。
当你完成中心功用的设计和文档撰写时，可以先与研发讨论设计能否合理和可行，接着再停止分支功用的设计，这么做防止前期需求推倒重做的困境。
后台零碎的目的用户能够是运营人员、市场人员……，而需求文档的目的用户一定是你的研发同事们，需求文档是你输入的一个产品，因而我们一定要让需求文档变得更明晰更易懂。
什么样的需求文档研发爱看？
简约、高效
设计时要遵照“简约、高效”的准绳。能用一个词阐明清楚的事，千万不要用一句话。
前后描绘分歧
设计后台时，模块之间必定会有关联性，不同的模块能够会触及到相反的字段，因而关于每项字段、字段类型、字段阐明等外容必需坚持分歧，不要有前后矛盾的状况。
善用表格、图文并茂
- 后台中的功用构造、角色权限的分配等构造性内容采用表格的方式；
- 数据流向、业务流程用流程图、泳道图等描绘清楚；
- 功用用原型图出现，原型图中的信息停止归类，不能由于是后台，无需思索太好的用户体验而无视了页面的明晰整洁度。
- 原型图的各类按键规格坚持分歧，让研发或UI更好的设计，降低沟通本钱。
描绘办法
普通后台功用可分为列表数据、功用操作（增删改查等）两大块。可以从以下方式停止描绘：
1.列表数据
- 字段：字段称号、字段类型、字段描绘、数据来源、字段规则等；
- 列表：出现字段、排序规则、分页规则、形态等。
2.功用操作
办法一：事情流程法
比拟复杂的后台功用在同一个功用点中能够包括多个事情，所以复杂后台功用可依照：根本事情流程、子事情流程与特别需求来描绘。
办法二：条件描绘法
这个办法适用于查询功用，直接对需求查询的条件、规则停止描绘。
办法三：输出输入法
输出处置输入大局部是由开发来思索的，但产品经理假如能站在开发的角度，明白输出、处置、输入的内容，那会省去很多开发的了解本钱。
办法四：扼要测试用例
测试用例可直接用来表述复杂、罕见的功用，直击功用的目的。前提是这类功用一定是比拟罕见的，不需求过多的深化描绘，开发也能懂。
一些小TIPS
- 需不需求描绘很细节的东西？这个成绩要取决于整个开发团队的默契度，以及在开发之前能否曾经构成了规范的标准，假如是，那么产品经理可以适当增加一些细节描绘，扼要概括，将重点放在业务的流程和逻辑上。
- 大局部状况下，前台需求决议后台需求，后台产品经理设计前一定要与前台产品经理停止深化沟通，不论是对目前有的功用还是将来的前台需求规划，后台产品经理都要理解，提早做好规划，目光放久远，考虑功用的可继续性。
- 有些团队的后台文档能够会由若干个产品经理共同完成，建议对每个模块的作者做好标注，方便开发找到担任人沟通。同时，做好各大模块的标题和纲要，供开发查找。
- 一份需求文档一定会修正好几个版本，普通采用R（Requirement）0、R2.0……来表示版本号。