前言

俗话说，实践出真知。在实践的过程中总能快速积累新的经验，学到新的东西。但是实践过之后经验如何转化为自己的能力？很简单，从头总结一遍，然后想着有一件类似的事情需要你独立负责去完成。你能否马上形成清晰的思路去完成。
从上一年下半年开始，有幸参与一个重要的内部业务系统项目，完整地经历了一个后台项目从0到1的过程。让自己对这类后台产品有了初步的积累。本篇就将参与本次项目所得经验总结成文，以便日后温故而知新。
总结之前，先明确后台产品的定义，目前后台产品按用户对象可分为两大类：企业外部用户系统和企业内部业务系统。两者的区别如下：
企业外部用户系统：外部用户系统又可以分为C端和B端系统，C端系统服务对象是个人，满足的是个人的需求，例如微信公众号后台。而B端系统服务对象是组织或机构，满足的是组织或机构的需求，例如淘宝商家后台。此类产品的需求需要产品经理通过数据分析，用户研究，市场调研等手段主动去挖掘。产品经理在规划和设计产品功能时，更加注重体验。但本文总结的不是企业外部用户系统，所以不展开详述。
企业内部业务系统：服务于企业业务，支持企业经营、运转的系统。例如OA、ERP系统等。此类本文总结的便是此类产品，此类产品和外部用户系统最大区别在于需求来源，内部业务系统直接来自内部业务部门，明确而直接。产品经理需要考虑是功能模块如何划分合理，流程如何设计严谨，注重业务方工作效率的最大化。

1 项目准备

1.1 了解项目背景

在项目开始前，产品经理必须对项目背景要有尽可能了解，项目背景会对产品经理理解项目核心诉求，设定项目目标，决策需求优先级，功能设计原则等都会有所影响。以我本次参与的项目为例。
本次项目背景：公司是以线下业务为主的业务驱动型公司，业务系统所承载的功能均为线下业务的体现。目前已有一套业务系统投入生产中，但在支持业务近10年后，现业务系统的可维护性和可拓展性已经极差，已经到了制约业务发展、创新的程度。
背景分析：
①项目定性为内部业务系统
②系统并不是从无到有，需求分析就多了一种方法——拆解旧系统。

1.2 清楚项目诉求

项目诉求即业务方对项目的最终能实现效果的期望，一般需要在需求调研初期和业务的最高负责人确定下来。如果存在多个业务部门时，则和多个部门的最高负责人确认。
例如本次项目一开始就确认了业务方的诉求为：在5-6个月内重新搭建一套业务系统来解决旧系统中存在可维护性，可拓展性差，制约业务发展的问题。并在新系统的基础上优化和规范业务流程，根据业务的新尝试，增加新的核心功能。
项目诉求中的关键信息有两点：一是项目时间（项目要做多久），二是项目纲领性内容（项目要做什么）。这两点在后面的需求优先级决策起决定性的作用。

1.3 制定初步计划

了解项目背景和诉求后，产品经理可以根据经验粗略产出一份项目计划，无论是对自己开展后面的工作还是，还是向上汇报，都可以起到指导说明作用。这也是自己项目思路的一种体现，不至于在做事的时候头脑混乱。当然，既然是初步的计划，后面一定还会根据项目的实际情况进行调整的。尤其是涉及到其他部门的阶段，例如技术部门的开发阶段，是需要等具体需求评审后，才能确定一个比较准确时间的计划的。
所以初步计划的可以制定的比较粗，然后在每个阶段再细化成具体可按期执行的计划。例如本次项目初步计划就可以按照下面格式来设定。

项目计划表

说明：
（1）可以根据实际情况，计划的颗粒度可以从项目阶段，到项目阶段任务、子任务。
（2）具体至每个任务时，需要明确具体负责人/参与人
（3）列出计划开始时间和结束时间。
（4）项目开始后，需要及时更新每个任务的进度及说明，也可以采用图形化的形式展示，更加直观。
（5）如有任务需要前置条件完成后才能开始，可以加以说明
（6）项目时间甘特图形式，可根据时间情况展示。

2 需求调研

在做好初步计划之后，就可以开始进行需求调研了，也可以说是业务调研。在设计业务系统时，有两点是必做的：一是对业务的人（岗位及职能）和事（业务内容）熟练掌握；二是对业务目标有所了解。做好第一点，基本就可以从梳理出业务系统需要功能框架和业务流程。做好的第二点就可以在设计系统时站在业务的角度来设计和考虑未来的拓展性。
业务需求调研的常用的方式有“需求访谈”，“现场观察”等。各有优缺点，如下：

2.1需求访谈

一般而言，“需求访谈”是必定会采取的调研方式，而“现场观察”则需要业务部门配合并且时间允许的情况才能进行。所以本次项目由于时间问题，基本没有完整完成过一次现场观察。
下面就“需求访谈”的经验进行总结，在需求访谈开始前，需要对业务有一定的了解，并且准备好需要访谈的问题。可以准备类似格式的调研表。

需求调研表

但访谈的前提是最好对业务有一定的了解，可以在访谈前，先搜集业务部门相关材料进行初步的阅读和理解。可以先从业务中出现的专有名词开始理解，这是听懂需求的第一步。

2.2现场观察

现场观察其实就是产品经理参与进真实的业务场景中，从场景中去搜集和归纳需求。最终目标是要从在使用场景中，对业务的完整全流程建立起逻辑上的认知，并基于这个认知的基础上构建起系统的框架和流程。

2.3拆解旧系统

“需求访谈”和“现场观察”都属于由下至上归纳出系统需求的方法，而拆解旧系统则是由上至下拆解出系统需求的方法。任何一个后台系统都是由功能和流程组成，如果将后台系统比作一个人，那功能模块则是它的骨架，流程则是它的脉络。流程将各个不相关功能串成一个整体。
所以拆解旧系统可以分为两步走，首先拆解它的功能架构，其次体验它的流程。最终产出物应当有一份思维形式，或excel表格形式的功能清单，一份业务流程图。
但拆解旧系统的缺点就是，部分已经不再维护或弃用的功能逻辑会对现有的业务逻辑理解造成误解，并且需要花费时间去排除。所以需求不能完全依靠拆解旧系统，需要和上述两种方法结合，交叉验证，了解真实的现在的业务需求。

2.4 需求调研结果

需求调研结果至少有三个输出物：一是组织架构图（含岗位），二是业务流程图，三是业务目标。
组织架构图作用主要有：厘清部门关系，明确部门权责。为系统的权限设计提供事实依据。

组织架构图

业务流程图以岗位泳道图为主，用于明确岗位职责和在业务流程中的关键位置，了解整个业务流程的运转模式。这将是整个系统的主脉络。

业务流程图

业务目标则只需了解的主要考核指标，以及指标现状。主要作用用于加深对业务理解，真正做到为业务而设计。所以业务目标没有定式，按照当时业务的实际情况来了解即可。例如

3 需求分析

经过需求调研后，就可以进入需求分析阶段。需求分析主要做两件事，确认需求内容和需求优先级。
确认需求内容关键点有二，一是需求调研的业务原始问题列表和需求列表，二则是根据一所抽象出的功能模块和功能列表。

功能模块图

功能模块图的表现形式可以视实际需要来定，例如上面的形式，适合做汇报。而excel的形式则适合细化和后面的执行。

功能列表图

需求的优先级可以按照是否核心诉求（重要），是否不做会影响系统正常使用（紧急）来分析四象限法来判断。一般对于从0到1的版本而言，项目时间都会是非常紧张的，如果不想项目进度被延误则必须要做好需求的优先级分析。

重要紧急四象限法

由此可得，落在A和C象限上的就是本期必须要做的需求。

4 概要设计

概要设计阶段内容，包含了：系统形态/定位（前后端平台）、系统部署设计（服务器、数据库等软硬件要求）、应用架构设计、演进蓝图。
实际上概要设计阶段和需求分析阶段并没有严格的时间先后，部分内容可以和需求分析同步进行，例如系统形态/定位。系统的功能仅需要后台，还是需要后台+前端，前端是需要H5前端还是APP等问题。

4.1 系统形态/定位

例如基于对业务的分析，本项目需要两个独立后台+一个前端支持。
业务后台（PC）：承载除报表外所有的业务功能
报表后台（PC）：承载业务数据清洗，和大部分定制化报表产出
APP：承载移动办公、直客业务等业务需求

4.2 系统部署设计

系统部署设计需要技术经理的参与和主导，最终产出部署架构示意图。

系统部署设计图

并且需要在此基础上产出一份软硬件条件清单，方便及早采购。例如

4.3 应用架构设计

应用架构设计同样需要技术经理的一同参与，主要用于说明新系统和公司现有的其他系统关系，以及基础组件的应用。以网上大牛所做的为例，通过应用架构图从数据层到业务逻辑层再到展现层。整个系统在公司系统体系中的位置就一目了然。

应用架构图，来自网络，侵删

4.4 演进蓝图

演进蓝图是基于功能模块图的基础上去做演进，决定整体需求的演进版本规划。

演进蓝图

例如标蓝的是一期版本需要完成的功能，标白的则是二期版本需要完成的功能。表现形式同样是根据实际情况自己来决定，上面这类适合汇报，不适合产品和技术实际执行。

5 整体设计

整体设计即是进入了细节设计阶段，在细节设计阶段，需要先做好标准化设计、权限设计、流程设计等基础模块设计。

5.1 标准化设计

对于一个系统而言，特别是大系统，一般都是由一组产品经理负责。不同的人在负责不同模块的情况下，设计的标准化就尤其重要。
标准化设计包括三方面：文案的标准化，界面设计的标准化和交互设计的标准化
①文案的标准化包括了系统所涉及的字段功能名称等，所有能标准化的字段必须统一标准。
②界面设计的标准化主要是原型设计和UI设计的标准化。例如产品使用统一的原型控件，设计师使用统一的设计规范。
③交互设计则是系统操作交互的标准化。
最终如果项目的标准化设计原则比较多，可以列出来，让每个成员可以时刻查看。

设计规范点

5.2 权限设计

系统权限包括了功能权限和数据权限。在概要设计完成后，即可以开始建模设计了。
内容较多，具体细节不在本篇展开，后面另开一篇来总结。

5.3 流程设计

流程设计指的是审批流设计，同样是在概要设计完成后，即可以开始底层设计。
内容较多，具体细节不在本篇展开，后面另开一篇来总结。

6 需求评审

需求评审阶段也并不是等整体设计完成后再评审，在需求调研阶段就同步展开了。因为需求评审分为内部评审、业务评审和技术评审三个阶段。

以上三个阶段的评审也有可能是混杂在一起进行，并且有所反复，评审不只一次。可根据项目的具体情况自行做安排。

7 系统开发

到了系统开发阶段，主要工作便转为待确认问题的跟进和需求变更管理。
需求变更管理同样可以按照是否核心诉求（重要），是否不做会影响系统正常使用（紧急）来分析四象限法来判断。如果是即重要且紧急和紧急但不重要，就在当前版本做变更。其余需求则列入下一版本需求池再做规划。
需求变更记录形式可按照我之前在《产品新人的需求管理方法论》一文中的格式进行记录。

需求变更管理

发生需求变更时，需要及时知会业务、产品和技术三方负责人，以及对应的执行人。可再以邮件或群发消息的方式通知整个项目组成员。

8 系统测试及验收

系统测试和验收都需要制定一个详细的计划。
①测试计划可以由技术负责制定，按照技术开发的节奏进行测试。
②验收计划由产品经理负责制定，内容包括业务培训和验收测试计划。
制定计划时，按照5W1H原则和SMART原则来制定即可。

感想

完成一个大型的后台项目，需要完成的工作很多，细节更多。每个步骤都可以另开一篇总结。所以本文仅从后台项目的完整性流程总结，后面会继续对有价值的模块单独总结。

附每个阶段的输出物（仅供参考）