锐捷网络股份有限公司（以下简称“锐捷”）是领先的ICT基础设施及行业解决方案提供商，主营业务为网络设备、网络安全产品及云桌面解决方案的研发、设计和销售。
自成立以来，锐捷始终致力于将技术与应用充分融合，通过对客户需求的敏锐洞察、对行业趋势的准确把握，依托强大的研发实力和雄厚的技术积累，快速开发出有针对性、创新性的产品方案。贴近用户的创新成果已广泛应用于政府、运营商、金融、教育、医疗、互联网、能源、交通、商业、制造业等行业信息化建设领域，助力各行业客户实现数字化转型和价值升级。同时，锐捷与各行业头部客户建立了深度合作关系，服务1000多家金融机构、100%的双一流高校、60%的全国百强医院、超200家中国500强企业。
凭借强大的自主创新实力、贴近用户的解决方案和专业快捷的服务，锐捷在网络设备及云桌面业务领域稳居市场前列。根据IDC数据统计，2019年至2021年，锐捷网络在中国以太网交换机市场占有率排名第三；2021年中国企业级WLAN市场出货量排名第一，其中Wi-Fi 6产品出货量在2019年至2021年连续三年排名第一；2015年至2020年，连续六年中国企业级终端VDI市场占有率排名第一；2021年至2022年，中国本地计算IDV云桌面市场占有率排名第一。
250px|700px|reset
一、项目背景
锐捷在通信技术领域有20多年的技术沉淀，集团下存在众多事业部，如云桌面、云安全、SMB等，系涉及通信硬件设备研发、软件研发、应用研发等多种研发方式。随着锐捷内部研发管理体系的变革，研发应用工具也亟待改进与替换。
锐捷是飞书项目最早的共创客户之一，随着 IPD 变革逐渐拆解，对飞书项目的业务场景能力不断提出更高要求，预期替换锐捷原有自研 PMS 系统，并与 PLM 、 OA 等系统集成打通，完整覆盖研发管理各场景体系。
锐捷对项目管理要求有明确的管理区分，注重流程规范、评审规范、任务规范性，在实现IPD框架设计中将较多线下评审的边界限制通过飞书项目开放能力自主开发达到定制化的管理约束与多系统交互校验。
二、核心诉求与解决方案
核心诉求
- 在企业变革的中间过程中，如何构建整体研发体系是一大难点，希望在满足稳定性的情况下，又能构建可以实现业务拓展的体系规划。
- 构建严格控制IPD研发管理落地的最佳实践，实现针对不同管理要求的有效集成，工具快速适配内部流程变革。
- 对于重点关注的评审审核、交付物管理、工时汇报管理场景，如何让方案构建与实践效果需要能满足汇报与度量，推动工具有效落地。
- 对测试管理与测试机制的场景构想，需要可以满足锐捷原有的测试管理场景，最好可以给出更便捷更高效的管理模式；
解决方案
- 在飞书项目中搭建统一基架空间，按主要事业部研发管理体系拆分3～4个主要空间。
- 飞书项目通过IPD共创，从零打造WBS拆解模型，设定主子流程层级拆解模式，并支持跨工作项流程嵌套、节点启动完成依赖，前台实例自定义节点与工作标准。
- 基于评审管理、交付物管理、工时汇报管理场景，重新落实系统实现与配置方案，扩展可支持常规通用重交付管理模式，并且各类数据都可以通过度量图表进行统计查询。
- 飞书项目完整定制测试管理模型，便于轻管理企业直接使用进行测试管理，并预留与外部代码平台或测试系统的集成端口。
250px|700px|reset
三、IPD研发管理整体设计框架：需求、项目双线路跟进
3.1 设计流程理念
3.1.1 框架图
3.1.2 设计理念
需求管理主线
- 对市场原始需求进行完整定义与描述，对需求进行不同层级阶段的拆解划分，每一级需求的设计与拆解都需要有对应级别资质的工程师才可以执行，否则就要进行项目负责人的授权；
- 需求主要拆分出四个层级：原始需求→初始需求→系统需求→分配需求
- 原始需求：主要聚焦于原始市场客户信息收集，以及管理需求前因后果、概况评估，确认是否需求有必要执行；
- 初始需求：通过原始需求拆分基础特性结构，进行初步研发可行性判定与设计；
- 系统需求：对初步判定后的需求拆分到各系统级的设计分解，会延展到特性下的具体组件、结构件情况；
- 分配需求：需求拆解的最终颗粒度，对具体的需求执行还会在需求中建立对应的任务绑定相关交付物进行具体执行的跟进；
- 需求在系统与分配两个层级时已经初步会产生具体执行任务，对于任务的生成由具体拆分负责人进行初步制定，常规会根据需求层级预置标准任务与交付物，也允许负责人临时增添；
项目管理主线
- 对于项目的应用上，锐捷以标准的IPD理念对各TR里程碑进行了定义，制定里程碑基线后进行对应活动的细分与拆解。活动作为项目中主要环节与动作进行描述，而到具体执行层面则深入聚焦到具体任务中。
- 项目管理主要分成这几个层级：项目集（概念大项目）→项目→里程碑~~活动→活动（多层级）→任务：
- 项目集：定义上是公司最高级别的战略级定义项目，会作为公司财务预算、费用归集的最终载体，允许直接通过项目集进行项目工作开展；非锐捷管理体系下建议项目集作为归集概念，至少存在一个子项目（即自身）
- 项目：项目集推进执行的拆分项目，一般会由于事业部、业务线不同进行拆分；
- 里程碑：项目关键节点基线定义，当里程碑计划时间发生变化时需要进行评审评估；
- 活动：实际承载项目工作的具体事项，可以多层级拆解；
- 任务：定义为企业管理上不可再拆分的最小颗粒元素，是作为工作指派报工等事项的实际载体，交付物会绑定在具体的任务中；
企业管理整体考量
- 锐捷作为集团型企业，存在不同的事业部，研发体系众多。即使同是软硬件领域的研发，由于实际产品的方向、对客的级别、项目的规模等不同，实际应用的流程也会存在不同的场景化分支。那么企业如何在飞书项目中定义管理维度：
- 若企业管理可高度集中——模型可拓展：
- 项目间工作存在较大关联性，且实作团队按项目矩阵定义，允许跨事业部构成项目组；
- 此时建议飞书项目内一套完整空间设定应用流程与场景；
- 在项目执行中，核心成员以项目为主体进行工作事项安排；
- 若后期进行集团事业部或大团队拆分，可通过基础模板进行扩展；
- 数据统计与分析在飞书项目中管理的内容相对一致，与外部系统进行整体数据BI构建时清洗也相对容易，其代价是会牺牲一定团队的易用性并且单空间的配置成本较高，整体配置成本降低；
- 若后期按业务领域进行拆分，可通过基础模板扩展后禁用非相关流程；
- 若企业考虑业务模型精准可控——模型轻拓展：
- 项目间工作存在一定关联，但主要是相同作业类型的项目存在较大关联，比如按软件研发、硬件研发、平台研发等方向；
- 此时会考虑将不同业务模型单独建立一套空间，在每套空间内可以完整的进行该业务模型的完整项目管理；
- 若存在跨不同类型的项目关系，会在项目中建立不同模型空间间的关联，例如硬件研发项目可能会作为主项目关联形成软件研发的子项目
- 在项目执行中，原则上成员可能存在跨事业部体系的情况，但大体方向应该不会出现跨业务领域；
- 若后期进行集团事业部或大团队拆分，会考虑整体多套模型拆分出完全新的平行空间组；例如A事业部要从集团独立出管理体系，要把集团当前使用的软件、硬件、平台三个研发空间完整复制平移，只保留自身数据；
- 当不同事业部或大团队流程应用在日常工作差异较大时，可能相同工作内容会用不同的工作项呈现，例如缺陷会按照不同类型拆分，不只是流程包括字段与要求；
- 若企业是事业部管理控制——模型无法拓展：
- 事业部内独立管理和考核，集团层级只抽取关键数据进行统计分析，事业部内给与独立授权可自行调整流程与管理规则，从逻辑上将如果一个事业部自闭环，存在独立的研产供销全业务，那么独立出来不失为一种考量；
- 此时项目间几乎不会存在“跨”的概念，如果确实出现其他事业部需要协助的时候建议作为内部反馈的一种途径，在统一的反馈空间（需求反馈一般不区分事业部）进行信息同步，其他事业部接收作为非本事业部的内部需求；
- 此方式适合分层型集团公司，可以允许不同大事业部团队根据自身需要进行配置定制，但是对企业的整体维护成本与后续的数据抽取分析成本会相对较高；
- 从扩展性上来说未来事业部可以再次拆分，但若拆分的子事业部模式也不统一则类似重新建立一套空间关系，同时多个不同事业部难以进行整体定义或不同空间合并；
3.2 管理定义
3.2.1 需求WBS层级拆解
- 实质上不一定是展现出WBS的计划表拆解的样式（后文有样式详解），而是基于WBS的拆解理念形成多层级的拆解模式；
- 拆解后各级需求向上溯源，可以依次进行拆解任务的查看。
250px|700px|reset
3.2.2 项目WBS层级拆解
- 在项目中主要以活动子节点流程、里程碑子状态流程、任务子状态流程三种内容展示：
- 项目集下会存在子项目；
- 项目中会定义当前模板所承载的活动-节点流；
- 活动下会按实际操作路径绑定具体任务-状态流；
- 对于存在交付物的任务会存在其交付物-WBS特化模型节点流。
250px|700px|reset
四、WBS流程拆解需求与实现效果
4.1 项目计划表可预置多层级环节和里程碑
- 在硬件或长周期交付物项目管理中，会累积较多不同要素不同场景的具体事务，通过WBS的模型可以进行一个节点流涵盖多层、多种、多类其他工作项的流程设计；
250px|700px|reset
- 对于一些核心节点，在流程设计中需要区分其特性，作为里程碑立在关键的节点位置上；
250px|700px|reset
- 成为里程碑的节点或子流程会体现为一个“菱形”；
250px|700px|reset
- 整体设定后的模板计划会在建立项目时自动完成对应下级工作项的创建，并携带子流程所预置的流程。
250px|700px|reset
4.2 直观查看计划时间与完成时间情况，排期自动计算
- 对于项目各环节的计划开始、计划完成时间都支持进行直接指定或者管理员预置后台自动计算规则；
250px|700px|reset
- 前台进行计划表编辑时也可看到依赖计算的标志；可以进行某个节点的排期调整后根据关系自动计算后续节点计划时间；
- 同时下方截图中我打了一个配置的断点，在“D2问题详述”后，没有设定D4的开始时间计算，演示一下支持在实例的操作调整关系，并且修改中间节点向其他计算被依赖节点延展的效果。
250px|700px|reset
4.3 项目阶段自动变化，阶段内最后一个wbs事件完成后自动切换到下一状态
- 对于标品的节点流，其工作项的状态变化，是通过在节点的开始完成事件上配置状态流转来达到状态的切换；
250px|700px|reset
- 在WBS流程设计中，状态是浮于节点之上，类似对“项目阶段”的定义；
250px|700px|reset
- 并且支持WBS计划查看、流程图查看、泳道图查看三种展示形式；
250px|700px|reset
- 默认视图可以选择泳道图或流程图；
250px|700px|reset
250px|700px|reset
4.4 子任务、交付物负责人按角色分配，并且支持手工调整
- 在主流程中可以设定主流程相关节点事项的负责人，并且支持一同配置子流程负责人角色
250px|700px|reset
- 前台可以通过角色获取一些具体成员，也支持直接项目经理（工作项负责人角色）更换和调整负责人。
250px|700px|reset
4.5 设定活动、任务，即WBS节点环节的依赖关系
- 常规流程的前后节点关系是一种比较基础的FS（finish与start）关系，而往往在复杂的项目定义中对于SS、SF、FF、FS四种启动结束关系都有一定的需求，有兴趣可以参照我之前写的一个小场景案例：Project计划排期运算模型
- 在系统中配置存在普通依赖模式：基础的前序节点完成后执行下一步的关系
- 以及可定义跨前后节点的高级依赖关系：目前已支持FS、FF两种，可以选择具体依赖的节点、子流程节点、任务
250px|700px|reset
- 实际执行中可以看到对应的依赖项，并且控制节点的执行要满足要求后才可以开始或完成
250px|700px|reset
五、评审管理、交付物管理、工时汇报特化模型
5.1 评审场景与IPD评审插件
- 在锐捷的管理定义中，较多任务、交付物、阶段事件都需要进行较为复杂的评审流程
250px|700px|reset
- 而各评审环节仅仅通过一个评审节点和字段配置需要大量的调整工作项模型，并且难以形成结构化的评审样式
250px|700px|reset
- 基于上述场景，飞书项目扩展了完整的评审要素插件，用于进行大范围评审事项的安排；
- 可以将评审要素预置，并指定所需使用的流程节点环节
- 定义要素可见性、检查人、管理人、分类、严重度等常规指标（目前不支持扩展自定义指标）
250px|700px|reset
- 在对应评审节点中配置“评审要素表”控件即可获取到指定评审内容
250px|700px|reset
5.2 交付物管理
- 在复杂交付物的管理场景定义中，往往会存在交付物自身存在一定的制定流程、评审确认、版本更替的情况，那么在系统中只体现一个交付物的附件或链接字段是无法对交付物进行很好的描述，并规范化结构化
- 锐捷提出主要交付物需求集中在交付物的自有流程，交付物的负责人与原有项目任务联动，以及交付物自身的结构化归集
- 那么首先要对交付物有基础的概念定义，此时引入在交付物的模板概念，模板交付物本身不是实际的交付物内容，是对固定交付物的类型、制作要求、流程场景进行定义归集的一种概念，例如产品文档很多企业已经习惯于使用confluence进行编写与管理，那么对应的要求和流程就可以通过飞书项目来定义，并链接到对应的文档中
250px|700px|reset
- 同时交付物也会存在一些自身的属性，比如是什么用途、什么来源、什么场景应用的交付物，基于这种场景考量通过特化的工作项来实现是有一定的必要性。
- 除模板强定义的交付物外，本身也存在日常交付物的使用场景，交付物作为一个工作项，那么就可以通过常规的工作项关联来与普通工作项进行关联嫁接，当我们想要通过WBS链路或者关联关系查找交付物是可以根据所需逻辑进行相关工作项获取，那么再根据其来源或类型进行分组即可获得交付物的树形概念。
250px|700px|reset
- 同时包括锐捷在内很多企业的交付物最终是要归档到企业的文件管理系统中，如SVN等，那么进行归档的动作转化为一个流程节点，可以更好的描述其标准，接受第三方系统的执行反馈；
250px|700px|reset
5.3 工时汇报插件
- 在进行项目事务推进时，计划的工时工期是项目经理给出的预期要求，而实际人员在作业中会进行工时的有效反馈，针对此场景，我们将工时汇报的方式模型化，形成可以按工作日、工作周、自定义工作时段进行事项工时记录与反馈的特化模型
250px|700px|reset
- 对于启用了工时登记功能的工作项，不再允许人员手工维护实际工时信息，需要通过工时登记功能进行填写反馈。
250px|700px|reset
- 锐捷在工时管理上对常备事业部的管理机制通过基础的工时登记汇报即可，但也存在更深层次的绩效考核指标与人员考勤的联动可能，这部分能力会在飞书项目中逐渐迭代开放可对接人力、财务系统的出口，便于企业进行快速的工时管理与绩效管理打通。
六、测试管理与测试机制
- 此插件基于锐捷前期需求延展，已形成标准插件能力，不限于WBS企业使用，可参考：飞书项目 x 测试管理插件
6.1 回归测试管理的主要理念与逻辑
- 测试的主体离不开需求、版本、迭代的范围定义，版本一般会专项于某个产品的内测或外发版本
- 测试的执行会通过具体测试用例执行效果，来判定是否满足对应测试场景的验收标准
- 测试的发起往往会由测试负责人拉起测试计划进行测试人员安排
- 测试的执行资产需要可以进行定义分析，比如按产品、按特性结构、按市场方向等维度进行测试通过率、测试投入、测试归类
6.2 飞书项目测试管理插件中特化的三个主要模型
- 测试用例：支持自定义扩展的用例档案工作项，类似其他系统的一种基础资料的概念，主要用于描述测试的场景、条件、结果标准；
250px|700px|reset
- 测试计划：进行测试的实际载体，锐捷应用下会绑定在对应需要进行测试的具体任务中，常规我们不限制在具体的版本、迭代、项目工作项进行计划的生成；
250px|700px|reset
- 测试执行用例：在测试计划使用某个用例时，即是执行这个用例时产生的实际测试数据，用于记录本次测试的实际情况结论。
250px|700px|reset
6.3 用例包的搭建与用例包树状结构建设思路
- 在锐捷的实际使用中，对用例还会进行很多额外扩展，比如设定用例包的概念，用例包会定义其所属分类，用于快速进行用例的选取与归类分析使用
250px|700px|reset
- 用例包会作为测试用例的上级，原则上一个用例可以属于多个用例包（多选关联）；
- 若用例包需要有其他属性结构，比如按需求、按项目等方式定义用例树，也可以与对应工作项进行关联便于进行用例包划分；
250px|700px|reset
- 在导入用例时，可以提前归类好用例包，或在系统中调整用例包范围，在测试计划选择用例时根据用例包进行选取。
250px|700px|reset
