编辑导语：案例复盘恐怕是产品经理或产品设计必须进行的一个步骤，一个完整的案例复盘有助于产品和项目的正常运行与下一步的更新迭代。在本篇文章里，作者就对其参与的项目进行了完整的复盘整理分析，读完之后，也许会对你有所启发。

在这里分享一下一些项目历程，以供朋友们参考，有不对的地方请加以指正！

一、项目历程

XXXX项目终于上线了，下面就简单地写一下项目从开始到结束的一些经历，并对各个阶段我们做的一些工作进行简单的阐述，以此来分享或者展现一下遇到的一些事情和经过，以及对项目现阶段做一个总结。

1. 规划

2019年初，项目经理、产品经理、研发经理与项目相关业主进行了一次次的例会讨论之后，确定了项目的目标。

我们根据他们给出的概念性信息进行方案的制定，为他们勾勒所需的蓝图，给出了规划方案、基础需求文档和一些图例、以及汇报PPT，并在此期间搜集相关的资料进行基础数据的建构。

期间经历了重重的调整和完善之后，这才得到业主的认可，然后制定下个阶段的工作计划，并进行阶段性会议的汇报。

2. 调研

2019年夏季中旬，在对这个项目进行了一系列的规划准备之后，开始针对于项目方面进行线下调研的工作。调研之前，首先针对于在规划阶段不清楚和不明白的地方制定了调研问题表，并根据业主的需求应该调研哪些方面的方向计划表，然后到项目部驻场。

1）调研准备

我们选择的调研项目主要有三个，分别为XXXXX、XXXXXX、XXXX，在项目部驻场至少有两周的时间，整体下来差不多花了一个半月的时间完成。

调研期间我们除了对整个项目部的核心数据进行梳理和整理之外，还根据规划中制定的需求方向进行了功能、数据、设计和逻辑方面的一一印证，期间也会和项目部的成员进行例会或者一对一方方式的交流，在获取项目部成员建议和结合项目部管理数据的情况下，查漏补缺，调整和完善方案。

2）阶段调整

每从项目部驻场结束之后，小组成员都会开一次总结性的会议，根据整理的数据和从项目部成员那里得到的问题进行梳理，并结合原先的规划制定解决方案，并根据最新的规划方案和数据与业主沟通。

整个调研阶段结束之后，根据已经调整和完善的数据与业主进行一次阶段性的汇报。

3. 需求整理和分析

1）需求整理

以规划和调研两个阶段为基础，结合两者之间得到的所有数据进行系统性的整理，并在需求说明书的基础之上进行拓展，使得需求明确，根据业务的发展方向制定合理的解决方案。

另外我们会与业主进行交流，找出一些需求的盲点，进行分析之后细化新的需求，与老的需求进行整合。

2）绘制图例

在需求基本确定下来之后，绘制相关图例。

我们绘制了思维导图、功能模块图、关系流程图、功能流程图、用例图、结构数据图等，图形绘制完成之后及时与业主进行确认和沟通，不妥的地方调整，认可的地方进一步细化和完善。

3）需求规格说明书

在规划阶段需求说明书的基础之上，结合所画的图例和数据撰写需求规格说明书，以功能模块内的每个功能为维度，全面解读相关需求内容。包括功能和数据之间的逻辑关系、模块与模块之间的关联点，以及整个架构方面的具体设计方向。在此期间原型设计也已经同步进行。

4. 权限分析

1）权限的确认

由于这个项目涉及到的用户权限比较多，权限维度也比较复杂，所以针对这方面我们专门找了时间和业主进行了长达几轮的例会讨论。除了从调研那里得到的权限数据之外，也经过一些方式从业主那里要到了一些关于用户权限的内容，包括组织架构方面的内容。

2）权限的整理

对仅有的一些权限数据进行分析和整理，制定了基础的权限清单，和业主频频确认。之后和相关的产运部、安全部等集团部门沟通，从中进一步的细化权限。

3）权限清单的制定

以需求为基础，根据PC端不同的端口（管控端和项目端）制定不同维度的权限表单，然后将确定下来的功能模块内的功能一一列出，与对应的用户权限进行关联，并进行明确的标注和说明。

通过权限清单的制定之后，最后与业主进行汇报和确认。

设计方面也以权限清单为参考，尽量设计成有利于权限分配的方向。

5. UE/UI设计

1）草图设计

规划阶段的时候就已经进行草图设计，主要是用来是印证基本需求，这样也有利我们与业主进行交流。

因为这个时候业主只有一些概念性的东西，所以对于自己想要的功能还没有一个深刻或者全面的认知，只是从业务的角度进行阐述。所以我们根据他们的需求和要求，对所提的基本功能模块进行草图设计，然后在例会中（事实上和不懂技术的业主进行沟通也只能利用这种方式，用其它方式（比如数据表、流程图、思维导图）几乎起到的效果不是很大）展示。

其实每次沟通他们要求看的也只有设计，他们会根据设计来确认这些是不是自己想要的。我们将合理或者认可的地方保留下来，不合理或者不认可的地方他们也会提出修改的意见。

将他们提出的问题先整理成文档，根据问题对草图设计进一步地调整和完善，接下来再找业主进行确认，直到他们认可为止。

如果在需求确认的过程中他们提出了新的需求，将新的需求加入进去，并在原型中进行标注。

当然，期间出现的需求变更和新需求的加入也都会在需求规格说明书中进行同步，并对有关的图例和数据表进行更新，或者整理成需求变更或者优化点文档。

2）高保真设计

在草图设计所涉及的所有需求都进行了确认之后，我们会将其进行系统性地整理，加入必不可少的动态交互效果和高保真的静态布局，与真正的系统做成一比一的逼真模拟，然后来印证其中的可行性和逻辑性。

不容易或者不能表现的出来地方我们会进行标注说明，这样有利于其功能性的拓展，然后将高保真原型和业主进行更加深入的交流。

通过高保真的原型，业主对整个系统有了一个全面和深入的认知，结合提出的需求就会有更深的想法。

我们从头到尾系统性地进行查看，从他们那里得到不足的地方和没有考虑到的方面，进行深入地调整和细化。

经过一次又一次的确认，高保真原型也经过了一波又一波的调整和完善。得到业主认可之后，结合前面所说的权限清单，根据高保真原型来印证系统中关于权限分配的内容，从中发现一些问题，继续优化。

3）原型说明书

高保真原型完成之后，根据原先备注的说明和对一些复杂性的功能进行描述，从而形成与其相匹配的原型说明书。两者结合在一起，让后面研发人员有一个很好的支点，这样更有利于理解和开发。

6. 数据建模

根据需求和设计，对平台中所出现的各个实体的属性进行整理，使其形成数据词典，以此作为后继研发过程中数据结构设计、数据库设计、数据库表结构设计的主要参考来源。

并说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑、而提出的对数据要求的限制（容 量、文卷、记录和数据元的个数的最大值）。

对于在设计和开发中确定是临界性的限制更要明确指出。

1）内部数据

我们对内部数据及项目现场的业务数据进行了整理。

业务数据来源于项目过程管理，包括项目的筹划信息、进度数据、质量数据、安全数据、施工风险数据、报表数据等。

2）外部数据

对外部数据包括来自既有信息系统（如XXX主数据系统、XXXX系统、XXXXXX平台、XXX管理系统、XXXXXXXX系统）的工程基本信息和专题信息，以及通过离线方式导入的地理信息数据及其他数据。

以上数据均在平台数据标准的约束下进入数据中心，通过中心数据库与应用系统形成数据交换，并在此基础上开发标准化数据接口，将数据共享给其他需要的外部系统。

3）数据逻辑

对数据进行逻辑描述时可把数据分为表态数据和动态数据两种。

把各数据元素逻辑分成若干组，例如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定义（或物理意义）度量单位、值域、格式和类型等有关信息。

7. 风险评估

我们邀请公司比较权威的相关人员对需求、设计、数据字典等各方面从技术和业务两个角度进行了风险分析，对实现的可能性评估，并结合他们的建议，对其中容易出现风险或者风险比较高的方面进行深入审查。

整理成风险评估清单，将出现风险的地方进行一一的记录，并对其划分高低等级。同时细化这些内容，与业主进一步确认，并提出相关解决方案。

8. 研发项目

1）项目研发计划书的制定

研发经理根据项目的需求量和出现的风险量，对整个项目需要投入多少工作量和人力物力资源进行整体评估，和产品经理一同指定项目研发计划书，并找相关领导进行报备，待确认下来之后再进一步细化项目研发计划书的同时，开始着手研发的准备。

2）开发环境搭建

• 对XXXX3.0 PC端的环境进行搭建；
• 对XXXX3.0 APP端的环境进行搭建；
• 在此期间根据业主的要求，对PC端和APP端的项目端与管控端进行划分。

3）研发过程管控

• 对开发各阶段所需的研发人员（前端和后端）进行调配；
• 与项目经理及产品经理进行深入式需求沟通，并对需求的轻重缓急进行区分，制定合理的阶段性、月、周工作计划；
• 对于风险评估中出现的技术风险进行研究，并找出解决方案；
• 分析XXXX2.5上的历史数据，结合最新的数据字典设计进行数据结构的设计；
• 与产品经理和项目经理结合需求针对于原型设计深入式沟通，并每周与业务部门进行例会沟通需求；
• 与产品经理和项目经理深入式沟通系统所需权限清单，根据整体架构来制定权限研发结构；
• 开发任务分配及把控，开发过程中遇到一些问题，并及时进行项目组人员任务的分配；
• 对于PC端和APP端布置两个应用环境，一个是测试环境，主要用于我们内部进行出去查看、测试、复测和印证用的。另一个为正式环境，主要提供给业主和相关用户使用的，每天都会对着两个环境进行维护；
• 与产品经理和项目经理每周进行开发任务状况的跟踪，上线期间每天召开晨会进行项目组开发任务的进度确认及任务调配，开发问题搜集及解决方案沟通确认；
• 出现需求变更的时候，根据项目经理和产品经理制定的变更方案及时调整研发人员进行处理，并与产品经理对其印证；
• 期间出现的问题以线上文档的方式记录下来（记录提出人、提出时间、问题描述、相关图片、完成情况、印证情况、备注等内容），每天实时跟踪解决的情况；
• 每当阶段性计划完成之后内部会进行一次总结性的汇报会议；
• 每隔一段时间给部门领导、公司领导和业主进行一次汇报；

9. 项目测试

需求的分析及挖掘隐性的需求，依据是需求文档、设计、图例、内部上线系统、进行测试用例的撰写，在产品经理和研发经理的参与之下沟通具体的需求。

1）测试需求分析

从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过分析、理解，整理成为测试需求，清楚分析出被测试对象具有哪些功能。

明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。

2）业务流程分析

分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。

从业务流程上，应得到以下信息：

• 主流程是什么?
• 条件备选流程是什么?
• 数据流向是什么?
• 关键的判断条件是什么?

3）测试用例设计

• 编写完成测试用例后，自我检查以及与测试组长评审；
• 测试用例的更新与完善；
• 执行测试用例；
• 禅道中提交执行测试用例时发现的问题（bug）；
• 研发修复问题后，再次执行测试用例进行回归测试，关闭禅道中已修复的问题（bug）；
• 根据测试情况编写测试报告，对整个测试过程和版本的质量做一个评估；

10. 培训过程

1）用户操作手册

根据业主的要求，项目经理和产品经理制定出版级别的用户操作手册，修改程度涉及到了图片规格、文字大小字形、段落间距、标题标准、封面的美观度、页眉页脚与内容的同步性、每页图片和文本之上水印的设置、表格规范化等细节。并装订成彩色纸质手册，直到业主的最终确认才终止。

制定出来的用户操作手册一共有PPT、WORD、PDF三个版本。

2）视频培训教程

除了制定用户操作手册之外，根据业主的要求还要制定整个与系统流程相关的视频培训教程。

产品经理与项目经理共同撰写录制视频的脚本，然后由相关领导审查，根据领导的建议进行调整和完善。

根据脚本，产品经理对新系统进行视频的录制，对录制的视频进行细节剪辑、效果处理、格式编码、存储大小的压缩和字幕的嵌入。

将已经处理好的多个小视频根据内容进行区分成五组，然后进行合成，生成五组主视频。

根据脚本录制音频，对录制的音频进行细节剪辑、效果处理、格式编码、声调的设置和语速的调整。

将已经处理好的多个小音频根据内容度也区分成五组，进行合成，生成五个主音频。

合成主视频和主音频，将五组视频教程挂到系统上面，并以二维码的形式展示，用户只需要用手机扫描二维码就可以进行查看。

3）培训座谈会

我们以座谈会议的形式与相关用户进行培训，首先讲解系统项目端及管控端的功能、使用人群、如何开账号、如何查看报表、如何填报等，然后宣讲集团管理要求、考评要求等，并针对系统上线后的填报要求（比如2月25日之前全部填报完成等）。

11. 维护与稳定

1）解答问题

根据使用用户的不同职位和公司，建立多个学习交流群，用户在群内反应问题，我们则在群内解答集团、各子、分公司管理员、分管领导、项目经理操作过程中遇到的问题。

2）整理QA问题单

解答问题期间，用户反映的系统操作不熟悉或者不知道应该怎么使用新系统的问题，我们会整理成QA问题单，将问题相关的图片和操作流程以及使用步骤都会针对性地转写下来，然后每天在各个群里面更新一次。

这样不同的用户就不会问相同的问题，结合QA问题单会更快上手新系统，也用来补充在制定用户操作手册期间漏掉的内容。

3）处理并优化问题

解答问题期间，用户反映的在操作系统过程中遇到的BUG，我们会整理成线上问题表，然后将提出人、提出时间、BUG描述、相关截图、完成情况等字段在表内清晰的标出，项目经理和产品经理每天跟进，由研发经理主导项目组研发人员进行BUG的及时处理。

BUG处理完成之后，我们会进行一次复测。完成一一印证之后，没有问题的情况下及时反馈给相关用户，有问题的话会与研发人员进一步的沟通，并将出现的问题修复。

4）维护数据

• 上线前：XXXX2.5历史数据的迁移，并进行脚本的编写、测试、脏数据或者测试数据的清理；
• 上线期间：XXXX2.5历史数据的迁移，组织结构、人员、角色、权限等数据的整理和导入；
• 上线后：XXXX3.0数据的整理，历史欠缺数据的维护，垃圾数据的清理；

二、遇见的问题

由于这个项目存在多个甲方经理，期间并有许多部门（安全部、产运部等）的领导参与，因为他们之间没有沟通，提出的需求不统一，所以出现需求变更频繁、要求混乱和新需求后面层出不穷的情况。

再加上集团方没有一个与我们进行业务对接的固定人员存在，导致整个项目一直处于不稳定的环境下，从而造成了不停往后延期的后果。

三、总结

在以上各种环境因素的影响之下，经过我们合理和灵活的调整，XXXX项目在磕磕绊绊中也算走上了正轨。从2019年1月份开始，到2020年12月份底正式上线，期间历经几番周折，整个项目组可谓历经了九九八十一难，这才取得真经。

经过将近两年的合作，我们项目组除了默契越发紧密之外，其他方面也都有不小的收获。不管是相互之间的沟通、团队合作能力、工作任务执行力和负责工作的责任感都越来越好、越来越顺利。在技术交流和相互学习方面频次非常高，可谓有了长足的进步。

当然金无足赤，人无完人，何况是一个团队。通过这次XXXX项目的研发，我们从中也认识到了一些不足之处，不过在发现之后都进行了有效地弥补和学习。随着项目的深入，我们随时保持自省的能力，在发现问题之后第一时间给出解决方案，加班加点也要解决。

时间在走，回顾虽然让我们能更加看清曾经走过的路，但是从中吸取教训走好未来的路才是最重要的。看着2020年就这样成了历史长河中的一部分，2021年就这样悄无声息的来了，我们整装待发，期待在新的一年里打出一个好成绩。