当前位置:   article > 正文

史上最详细的项目管理开发流程架构及说明【实例】_在项目初期阶段,通过与客户进行面对面的交流,了解客户的真实需求和痛点,客户成功

在项目初期阶段,通过与客户进行面对面的交流,了解客户的真实需求和痛点,客户成功

项目开发流程是一个项目和产品的能否做好的关键。今天分享给大家一个史上最详细的项目管理开发流程架构和说明实例,是咱们社区的实战大咖湘北总结撰写的,供大家借鉴参考!

项目开发流程架构总览

项目开发流程及交付物

01

项目售前阶段

项目售前阶段共有七个部分,分别是:客户现状调研分析,技术可行性评估,制定技术概要方案,制定业务概要方案,工作量与人力成本评估,POC验证,售前业务交接。

1.1 客户现状调研分析

通过访谈或问卷调查方式,了解客户当前的痛点问题,以市场为导向,有效收集来自客户的原始需求,准确把控核心价值点,寻找商业合作机会。

1.2 技术可行性评估;

  • 销售顾问对收集到的客户痛点问题与需求进行澄清与说明;

  • 售前顾问对客户的诉求,以及结合本公司的产品业务与技术能力进行评估,确认本公司的产品业务或技术能力上是否能够满足客户的诉求,给出评估结论;

  • 若售前顾问无法准确评估,可邀请实施团队技术专家参与技术可行性评估;

1.3 制定技术概要方案;

  • 根据客户的需求说明,输出技术概要方案;

  • 技术概要方案不需要特别详细,可以以技术架构的流程图简单说明实现逻辑;

  • 若售前顾问在输出技术概要文档过程中遇到相关技术难点,可以寻找实施团队的协助;

1.4 制定业务概要方案;

  • 根据客户的需求说明,整理输出产品业务的概要方案,要求需求框架与层次结构清晰以及对需求的简短说明;

  • 可以与客户进行沟通,由客户输出业务需求概要方案;

1.5 工作量与人力成本评估;

  • 根据技术概要方案和业务概要方案,梳理出涉及的业务领域模块(如:前端/后端/ETL/等)以及拆分出大概的业务工作,各自评估业务领域内的工作量,从而评估出总人力投入;

  • 人力评估时,尽可能预留30%-40%的缓冲量;

  • 此次评估为概要的人力评估,后续需要参与开发的角色进行详细的人力评估;

1.6 POC验证;

  • 基于输出的业务概要和技术概要方案,整理输出POC材料;

  • 基于POC材料对客户的痛点与诉求进行方案讲解说明与疑问答疑,提升客户对我们的信心与合作意向;

1.7 售前业务交接;

  • 由销售顾问与售前顾问整理前期涉及的文档材料(如:客户需求说明文档、技术概要文档、业务概要文档、初步的人力成本评估、POC材料等);

  • 若实施团队对提供的材料存在疑问,可以要求销售顾问或售前顾问进行澄清说明与问题答疑,然后完成正式的业务交接工作;

02

产品策划阶段

产品策划阶段共有10个部分,分别是:2.1 项目立项;2.2需求调研;2.3 项目入场准备;2.4 产品需求澄清;2.5明确验收标准;2.6开发与测试人力详细评估;2.7 制定项目里程碑计划;2.8 输出工作任务说明书;2.9 合同签订2.10 召开项目启动会。

2.1 项目立项

  • 熟悉售前交接资料,了解项目背景、项目目标、项目范围、技术概要方案、初步的人力规模评估;

  • 根据项目的目标与节点要求,PM与架构师明确涉及的业务与开发人员,并确定各角色的人数规模;

  • 根据评估的业务及人员规模结果,与团队PE沟通,明确项目是否由团队承接与立项结论,并协调人力资源,组建项目团队;

2.2需求调研

  • 根据前期搜集的客户诉求及需求点与客户进行详细的需求调研,讨论需求细节、评估技术可行性与风险,并对项目风险进行记录与跟踪;

  • 讨论的过程中,允许对需求点进行更新补充,形成最后的产品需求文档,作为项目开发范围基准;

  • 需求调研结束后,明确产品需求文档与原型设计输出时间;

2.3 项目入场准备

  • 若客户明确要求项目组驻场,则需要提前做入场工作准备,以便快速投入项目工作;

  • 入场准备信息包含但不局限于:

办公环境:办公位置、权限开通、工作电脑、服务器资源、开发环境等;

工作规范要求:IT管理工具、保密合规性、文档管理、开发规范、沟通机制等;

产品需求:需求开发依赖的前置条件等;

  • 相关信息收集后,提供给客户确认,提前做入场准备;

2.4 产品需求澄清

  • BA/客户根据前期需求调研输出的产品需求文档及原型设计方案对项目组成员澄清需求;

  • 需求澄清的过程中,可以提出自己的需求疑问与实现的技术风险,需求疑问由BA/客户进行答疑,技术风险进行记录跟踪;

  • 产品需求澄清过程中,可以持续完善产品需求文档;

2.5明确验收标准

  • 根据产品需求文档及客户要求、组织项目成员讨论,设定阶段目标验收标准,同时梳理项目的测试维度与每个维度所需达到的质量标准;

  • 测试维度包含但不限于(基本功能、数据权限、数据准确性、兼容性、性能、自动化等);

  • 项目验收标准确定后,与客户进行沟通,达成一致,作为项目结项的验收条件;

2.6开发与测试人力详细评估

  • 根据产品需求文档与测试质量要求,拆分需求颗粒度、进行工作量的详细评估;

  • 个人评估完成后进行汇总,若工作量评估较大的,由责任人说明评估理由;

2.7 制定项目里程碑计划

  • 根据集成产品开发流程,设定里程碑阶段、然后评估每个阶段的工作任务与工作量,从而得出项目里程碑计划时间;

  • 若客户有产品阶段交付目标要求,如第一阶段/第二阶段/第三阶段分别要求交付的内容,然后根据阶段目标,确认所需完成的工作,然后评估工作量,从而得出阶段目标计划;

2.8 输出工作任务说明书

  • 基于现有的信息,与项目组成员一起输出项目工作任务说明书,目的与客户的项目沟通与合同签订;

  • 工作任务书包含如下信息:项目背景、项目目标、项目范围、项目组织结构与职责、项目验收标准与验收流程、项目里程碑计划、项目开发计划、技术架构、项目问题管理、项目变更、项目交付件与移交流程等;

2.9 合同签订

  • 根据工作任务说明书内容与客户进行沟通确认,确保双方达成一致;

  • 达成一致后,开始走合同签订流程;

2.10 召开项目启动会

  • 明确项目背景、项目目标、项目范围、技术可行性、项目里程碑计划、项目团队成员与职责、项目章程等信息,输出项目启动会材料;

  • 召开项目启动会,同步项目信息与运作模式,且保证团队成员都清楚知道项目的最终目标、交付成果,并确保目标统一;

  • 同时启动会过程中识别项目风险;

03

项目计划阶段

项目计划阶段共有5个部分:3.1需求任务拆分;3.2 明确需求优先级;

3.3 制定项目选代开发计划;3.4 制定项目测试计划;3.5 制定需求准入准出标准。

3.1需求任务拆分

  • 根据需求文档进行需求拆分,拆分的层级类型有Epic、Story、Task;

  • 需求拆分的维度可以按照基本步骤流程、业务操作步骤、简单/复杂性等进行拆解;

  • 需求任务拆解完成后,录入IT管理系统,并进行需求/任务间进行关联;

3.2 明确需求优先级

  • 组织项目团队与客户明确需求的优先级,以便进行项目计划排期;

  • 排列优先级的三个要素业务视角(客户价值、商业价值、近期版本目标、用户量与使用率)、实施视角(实现难度、大小工作量、外部依赖)、风险视角(市场风险、技术风险、政策与法律风险等);

  • 需求优先级确定后,在IT系统进行优先级标识;

3.3 制定项目选代开发计划

1、根据需求优先级和版本计划,提前梳理当前迭代内待开发的需求清单;

2、明确需求的验收标准及依赖条件;

3、明确每个需求的开发责任人、测试责任人、开发与测试工作量;

4、根据团队可投入人力,评估需求的各迭代开发计划;

3.4 制定项目测试计划

1、根据项目特性,明确测试类型(如:功能测试、单元测试、接口测试、白盒测试、探索性测试、兼容性、稳定性、性能、合规性等);

2、根据项目开发计划与测试资源情况等,输出项目测试计划;

3.5 制定需求准入准出标准

组织项目组成员沟通需求的准入准出标准,明确需求管理规则,如满足什么要求才能提交测试,达到什么状态需求才能提交合入;

如:需求准入条件--(需求明确/技术方案评审通过/开发与测试认知清晰/验收条件明确);

如:需求提测条件--(开发完成自检/输出测试建议/自测问题修复);

如:需求合入条件--(产品与UI验收通过/测试验收通过/无遗留严重问题/代码评审通过/交付件输出);

04

迭代开发阶段

迭代开发阶段共8个阶段:4.1 项目入场;4.2技术方案评审;4.3 测试策略/测试方案/测试用例评审;4.4新需求开发;4.5需求开发自测验收;4.6选代需求测试验收;4.7 需求进度与风险跟进;4.8 选代复盘。

4.1 项目入场

  • 根据客户入场要求,组织项目组成员按时间规定进行入场;

  • 与客户沟通,安排好办公座位,确认对应的办公权限;

  • 搭建好开发与调试环境,对开发、测试、生产服务器进行部署,并输出对应的部署文档;

4.2技术方案评审

  • 根据项目的需求文档及功能特性,输出详细的技术方案;

  • 组织项目组成员与客户对技术方案进行评审,根据评审意见进行优化修改;

  • 评审通过后,开发基于技术方案进行编码,测试也可以基于技术方案设计测试方案和用例;

4.3 测试策略/测试方案/测试用例评审

  • 根据项目的需求文档&功能特性、技术方案,测试建议等,输出详细的测试策略、测试方案、测试用例;

  • 组织项目组成员与客户对测试策略/测试方案/测试进行评审,根据评审意见进行优化修改;

  • 评审通过后,项目的测试验收按照评审通过的方案执行;

4.4新需求开发

  • 功能开发前与产品/PM/客户沟通需求,确保自己理解的需求与产品需求文档描述的一致;

  • 提前识别需求的技术风险和依赖关系,确保开发前都得到确认与解决;

  • 根据产品需求文档、技术方案、测试方案/用例进行需求编码开发,开发完成后进入自测流程,并输出测试指导建议;

4.5需求开发自测验收

  • 功能开发完成后,根据需求的验收条件或测试用例进行自测;

  • 自测过程中发现的严重问题需要完成修复;

  • 组织完成功能开发代码的Review工作;

4.6选代需求测试验收

  • 根据需求的测试方案、测试用例以及开发提供的测试建议,完成需求的测试验收;

  • 测试过程中发现的问题反馈给开发人员,并对问题进行记录与关联至需求卡片;

  • 梳理问题的严重性及优先级,跟踪问题的处理进度;

  • 问题修复后,完成需求的回归测试验证;

  • 需求验收通过后,且无遗留问题,则输出需求测试报告;

4.7 需求进度与风险跟进

过程管控:

  • 通过工具可视化看板,随时关注需求的进度状态与风险;

  • 通过每日早会/日报/周会单独询问,了解团队成员的工作进展与项目风险问题,协助推动;

  • 通过需求的日常开发过程中,定期审计需求开发的合规性,如:流程合规性、质量合规性等;

  • 记录项目的过程管理数据,定期进行分析总结;

4.8 选代复盘

  • 整理迭代过程中的度量数据(如:迭代需求开发计划完成情况、需求测试情况、遗留问题、需求变更等等)、收集迭代过程中好与坏的反馈,并进行归类;

  • 收集团队提出的问题点、痛点问题;

  • 复盘过程中,PM向团队展示当前迭代的过程数据,并确认原因;

  • 呈现做的好的地方,进行表扬,继续保持,呈现团队提出的痛点问题,进行责任人陈述;

  • 梳理高优先级的痛点问题进行沟通讨论,明确问题原因及改善策略;

  • 针对改善策略进行责任人认领,明确计划完成时间并记录到跟踪表持续跟进;

05

项目集成验证阶段

项目集成验证阶段共有五个部分:5.1 SIT系统集成测试;5.2 专项测试;5.3 UAT客户验收测试。

5.1 SIT系统集成测试

需求功能集成后,根据测试方案,组织团队进行系统集成测试验收,其中可能包含:

  • 全功能测试、冒烟测试、探索性测试,主要是围绕功能交互层面的测试验收;

  • 测试过程中发现的问题,进行记录,及时反馈给开发处理,并跟踪问题的解决进度;

  • 测试通过后,输出系统集成测试报告;

5.2 专项测试

  • 根据产品/项目的特性,设定专项测试类型:如可靠性测试、性能测试(流畅性、稳定性、功耗、内存性能等)、兼容性测试、权限相关、数据相关等等;

  • 测试过程中发现的问题,进行记录,及时反馈给开发处理,并跟踪问题的解决进度;

  • 测试通过后,输出专项测试报告;

5.3 UAT客户验收测试

  • 当内部已完成系统集成测试和专项测试后,且无遗留严重问题后,组织进行UAT客户验收,验收的维度包含但不局限于(功能、UI效果、交互逻辑、视觉、动画、性能等维度);

  • 客户验收过程中,若发现问题后,需要快速响应处理;

  • 全部功能验收通过后,根据项目验收流程进行签字确认,代表项目完成客户的验收;

06

产品发布阶段

产品发布阶段共五个部分:6.1 问题修复;6.2体验优化改善;6.3 重大问题决策;6.4发布评审决策;6.5 发布部署上线。

6.1 问题修复

项目持续性的内部与客户验收过程中,可能会测试出其他项目问题,根据问题的严重性与优先级安排处理;

6.2体验优化改善

  • 客户验收与体验的过程中,如果提出体验优化项,需要评估优化的内容是否在项目范围内的,如果在范围内,则排期优化,若不在范围内,则根据优化内容的复杂程度与工作量,确认是否需要重新修改合同与人力预算,然后再排期优化。

6.3 重大问题决策

  • 项目即将上线过程中,遗留部分问题未解决,迫于项目上线压力,组织项目遗留问题盘点,对问题的严重性、价值、技术难度、概率程度等多方面进行评估决策,给出决策结论;

  • 根据决策结论,安排下一步计划(后期优化还是当前紧急攻关处理);

6.4发布评审决策

  • 邀请项目相关干系人参加发布评审决策会议;

  • 会议前提前准备相关材料(如:项目测试报告、客户验收结论、项目遗留问题);

  • 发布评审会议过程中,同步项目测试报告、客户的验收结论以及当前的遗留问题,整体评估项目质量要求及功能还原度是否满足发布标准,并给出发布评估结论;

6.5 发布部署上线

根据上流程的发布评审决策结论,若评估需要处理遗留问题,则修复后组织部署上线、若结论是通过,则可直接部署上线。

部署上线后,需要安排人员进行运维监控,及时响应处理发布后的各类突发问题。

07

项目交接阶段

项目交接阶段共五个部分,分别是:7.1 运维监控;7.2客户体验问题优化;7.3 客户培训;7.4 项目复盘总结;7.5 客户满意度调查。

7.1 运维监控

项目上线后,进行持续性的运维监控,通过系统平台获取平台的性能情况,以及收集客户问题反馈,快速响应处理,同时进行问题归档,便于后续的项目复盘总结。

7.2客户体验问题优化

系统上线后,如果客户提出体验优化项,需要评估优化的内容是否在项目范围内的,如果在范围内,则排期优化,若不在范围内,则根据优化内容的复杂程度与工作量,确认是否需要重新修改合同与人力预算,然后再排期优化。

7.3 客户培训

根据产品功能需求,输出产品使用指导手册和使用指导录屏;

根据客户需求,组织客户参加产品使用培训;

7.4 项目复盘总结

  • 通过项目复盘识别项目过程中的系统问题、总结项目经验,推动研发工具、流程的优化及研发能力提升,支撑持续高效的项目交付;

  • 复盘的大概步骤:回顾目标(目标计划、初期规划的成本、预期目标结果)、评估当前结果(实际结果、与目标相比哪些做的好,哪些未达预期等);

  • 分析原因(深入分析差异根本原因)、总结规律与经验教训、形成具体的行动计划并落地执行;

7.5 客户满意度调查

  • 项目上线后,根据前期提出的交接要求,输出对应的交付件材料;

  • 组织客户交接团队,同步项目相关信息(如:产品功能需求、技术方案、接口信息、数据库设计等等),并解答交接团队的疑问点;

  • 当双方沟通达成一致,无其他疑问点后,将交接材料移交客户,即完成最后的项目交接工作;

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小蓝xlanll/article/detail/300001
推荐阅读
相关标签
  

闽ICP备14008679号