企业级需求管理的“道、法、术、器”（新一代核心系统需求管理实践和领悟）

企业级需求管理的“道、法、术、器”
（新一代核心系统需求管理实践和领悟）

刚刚经历了新一代核心系统进行改造，历时2年多“试炼升级”过程，作为需求管理主管的我，第一次经历如此复杂系统建设的需求管理过程，感受真是五味杂陈，既有切肤之痛，也有喜极而泣。幸运的是，我们终于跌跌撞撞扛过来了，期间走过不少弯路，有过很多教训，实属不易，但也收获满满，感悟良多。前些天一直有想写点东西的冲动，但每次又觉得要写的东西太多而又无从下笔。今晚辛晓琪一曲“领悟”不经意间飘到耳边，一句"多么痛的领悟，你曾是我的全部，只是我回首来时路的每一步”，触达我内心，不禁感慨万千。历经这2年多的感受，不能说过去就过去，现赶紧抓住它的尾巴，今晚赶紧把这段经历过程中的“领悟”整理出来，这是一笔财富，也算是对这2年多我们付出的总结，给自己一个交待，也给同行们提供一点点借鉴。
一、 开局不顺，陷入混乱
新核心项目群启动不久，我们需求管理组便陷入了"颠狂模式”怪圈 。之所以说"颠狂”，一方面是每天面对来自各方需求海量涌进，需求受理、组织分析、讨论协调，工作量呈倍增加，我们“白加黑”地疯狂加班；另一方面是混乱，需求质量混乱、版本混乱、传递混乱、协同混乱。需求组承受前所未有的压力，需求受理、需求分析、需求澄清、争议处理、需求评审、需求协调、问题处理等让我们每天超负荷工作。我们需求管理组七八个人，每天处于焦灼状态，被各类事务赶着走，每天下来筋疲力尽，陆续有人累倒。即便是这样，我们的努力也只是能对混乱局面稍有改善，但杯水车薪。领导们也是看到眼里、急在心里：需求一乱，开发不就乱套了，这可咋整？问题在哪？有什么解决方案？如何让我们迅速脱离困境？
二、道法自然，识本质、找规律
（一）解决理论方法指引的问题
虽然从事需求管理领域有多年经验，我自认为懂业务、懂需求、懂系统。平时对别人讲起需求方法、理论模型和实践经验也头头是道，但此次面临的困境是我始料不及的。发现我们理论、方法和经验完全解决不了当前的问题，特别是在新核心系统建设期间，面对同时几十个系统建设齐头并进，在时间紧任务重的大环境下，完全没条件、没时间按所谓的标准化方法、规范来推行。“武术套路”打不过一群散打，这种感受让人憋得难受。但促使我们去思考，方法理论为什么不管用？为什么不能帮我们解决问题？我们哪里出错的？经历过一段时间，我们终于领域出一个道理：方法理论的存在，只是帮助我们理解原理和规律，帮助我们用科学方法去思考，找到解决问题的办法（解决方案）。所以说先有“方法指引”、再结合实际想出“办法”、才能解决问题，所以“方法”不能跳过“办法”直接解决问题。
【领悟】：理论方法不能照搬（作了抽象，提炼本质，才能大道至简），在具体应用时要针对实际进行补充、改良和完善（一定要根据现实环境做有针对性的还原），“以道御术“，形成可落地的解决方案，才能切实有效地解决问题。

（二）审视需求管理的本质、探寻核心诉求，找方法
我们在项目前期一直陷入需求的各类具体工作，被繁琐具体的事务推着往前走，渐渐迷失了需求管理的目标。我们为什么要管需求？需求是什么？管理的目标是什么？管理的核心诉求是什么？如果这些分不清的话，将会让我们分不清需求工作的主次和重点，需求管理在本项目发挥的作用和价值大打折扣。对于此，我们充分与各层级人员进行深入沟通，一直追问"为什么”,一直追问他们的“核心诉求是什么？”。当然这些问题的答案有很多，且随着项目推进也有不断地在调整。
关于什么是需求和需求管理，它们的本质是什么，在很多理论书籍中都有定义的描述，在此，我只是按这几年我们的实践进行总结和归纳，如下：
【领悟】：需求的本质是基于业务目标进行分析，并将需求采集结果进行提炼、分析、整合并规格化的过程，需求存在的价值是需求能说清楚、道明白，即能完整正确写出来、能很好传递出去、并能让需求接收者能看得清晰、看得明白。
写好需求是业务能正确落地IT系统的必要条件，但在具体实践中，需求质量参差不齐，一方面需求内容的质量，由于缺乏专业的需求分析（BA）技能，需求提出人往往只是简单的按单视角、单场景表达需求意愿，后续缺乏需求提炼和整合，造成需求质量不高，全面性和一致性考虑不够。因此，首先要解决“需求能否表达清楚的问题”；另一方面需求规范性的问题，由于需求在组织间进行传递，需要接收人和干系人能很好理解需求，须遵从组织规范，统一需求语言和行文格式要求，并能方便传递。
【领悟】：需求管理的对象是“需求内容”，不是“需求文档”，也不是“需求单”。
这是我们在项目初期所犯的一个致命错误，公司已有所谓的“需求管理平台”，之所以加上“所谓”2字，表达了我们极端的不满。原有的需求管理平台实际只是一个“走流程表单+需求附件文档”的流转系统，导致我们前期工作只围绕着走流程、走审批，导致需求内容自身的管理与控制被迫线下化处理，需求内容的澄清、变更、影响分析、沟通记录、问题定位、内容跟踪等重要内容无法记录，也使得需求拆分、评估、分配、关联、精准推送等无法实施。这使得我们增加巨大的线下工作量，也是造成工作被动的最大原因。之所以在此强调，让大家谨记，选择需求工具，一定要具备需求内容管理与跟踪，千万不能被所谓的“走流程、跑表单”类的需求管理系统给蒙骗了（业内大部分所谓的需求管理工具大多是这种，其挂“需求管理”之名，实质是“跑任务流程”而已），我们认为一切不基于需求内容管理的需求工具，实际是“挂羊头卖狗肉”。
【领悟】：需求管理本质是：管好需求、管好关系，特别是需求全生命周期过程（提出-受理-开发-测试-投产-沉淀）中进行动态管理，维护其管理秩序。
由于项目群的规模大、关系复杂，且开发链条、涉及部门多，导致需求管理复杂度呈指数增长，需求传递路径长而复杂，再加上需求本身动态变化，要在动态变化中依然保持整体的管理秩序是需求整体机制有效运行的重中之重。其中“管理关系”是重中之重，也是最复杂的，包括4个维度的关系：1是需求与需求间的跟踪关系，2是需求与开发、测试、投产间的工序关系，3是需求与系统、项目、版本间的关系，4是需求版本间的关系（一类是需求自身版本演进跟踪关系，另一类是需求版本与开发测试版本、投产版本间的关系）。更头疼的是这4个维度的关系是相互作用、相互关联的多维关系网，而且还是动态变化、不断演进的过程。这下头大了吧，需求管理工作是否到位，就看这几个关系网是否到位，所以当项目规模扩大到一定规模后，这个多维关系网会呈指数级增长。这就是为什么单项目和项目群的需求管理的难度完全不在同一数量级的原因。
【领悟】：需求管理的核心诉求是：让需求涉众能低成本、精准、快速获取最可信、最新的完整需求。
这句话，是我们在需求管理2年多领悟最深刻的“致理名言”，也是公司上下推行的需求管理价值的核心目标，需求管理的一切工作开展，都围绕这个目标展开。得到了公司上下的一致认同，特别是反映出项目组的开发、测试人员的核心诉求（需求管理的目标就是要给他们明确的、具体的工作要求）。上面的每个词都是经过项目实践，由大家一起推敲定义出来，其含义用通俗语言解释如下：
 低成本：别让我到处找人要、到处翻邮件、到处查版本、或到处平台找，最好能主动推送到我案头或需求池。与我有关的需求有变化（如变更）也及时推送给我；
 精准：遵从最小化原则，只把与我相关的那段需求内容推送给我，不要把整篇文档发我，也不要把不相关的需求或变更发我，即消除需求噪音；
 快速：需求快速受理、快速分配、快速沟通与澄清、变更快速推送给开发测试；
 最可信：需求是从可信渠道、可信组织给我的可信版本（别给错需求了，让我白忙活）；所有人工作在同一可信版本需求之上；
 最新：给我的是最新的需求，即使有变更的话，最好归并为最新需求，别让我在“一个老版本+一堆变更单”上工作，别让我自己合并需求（不一定合并对）。
 完整：不要给我碎片化需求，要给我完整需求和上下文，如果推给我的需求可能是整个需求中的局部内容，我也要看需求上下文，才能更好地理解需求。

三、 以道卸术，找解决方案
（一）、为什么我们这么难？
在大学课程《软件工程》中就有专门的章节谈需求管理，那时对需求管理的认知比较简单，认为保持需求一致性、作好传递和变更就行。但在实际的工作中，需求管理的难度随着需求团队规模扩大、项目复杂度增加而呈指数级上升，比如教科书和CMMI标准中所说的“需求变更要及时通知受影响的所有涉众（干系人）”，但在我们新一代核心系统建设中，涉及上千人的项目群团队，如果不用非常手段或工具的话，这个看似简单的要求很难达成，几乎是奢望（通常情况能做好需求文档级变更推送就很不错了）。需求变更通知所有涉众的前提：1是记录和维护该条需求（不是文档，是指需求内容）与干系人的关系，2是要定义出哪些是干系人？是通过哪些行为来识别出“干系人”，干系人涉及多种层次人员，包括项目管理人员、需求人员、开发人员、测试人员、投产人员等。 面对成千上万的需求，这么多的关系几乎是很难维护的，更别谈需求影响分析了（如：影响哪些系统、哪些环节、哪些开发测试任务、投产版本等）。
所以，需求管理的复杂度影响最直接的就是项目规模，而项目规模又决定其相互关系的复杂性，在我们这个项目中体现得淋漓尽致。这个项目需求管理的难点主要体现在以下方面：
1、 项目规模大、业务和系统的复杂度高、涉及部门、管理层级和人员多；
2、 需求从提出到实现的传递链条长；
3、 需求间的关系复杂、需求影响分析和需求统筹难度高；
4、需求受理渠道多，需求规范性和一致性较差；
5、需求多态性：意向性需求（提案）、业务需求、软件需求，维护3者间关系困难；
6、需求变更频繁，缺乏变更控制手段，影响评估困难，缺乏动态变更管理机制；
7、基于文档级、流程级管理，做不到需求内容级管理，需求关系跟踪全靠个人经验和手工作业，极大消耗人员精力；
8、需求碎片化严重，需求版本混乱，造成需求跟踪困难，连最基本的需求文档版本都无法跟踪。
【领悟】：正确认识你所面对的事和人、客观评价自己和所处的环境，否则“打肿脸冲胖子”，后果严重，难以收场。

（三）问题在哪？怎么调整？
从客观来说，面对如此庞大规模的项目群（涉及50多个系统），其需求管理难度必定是十分大的。虽然我们对此困难早有预期，但真正到来时，其难度又大大超过了当初的设想。现在回顾起来，我们犯了以下几个重要的错误：
1、认识不足，未做好准备
从公司领导层到PMO到项目组更多关注项目管理过程，更多关注的是各系统开发建设的项目管理，更多的是关注各个项目建设的问题风险。对如此规模的需求管理难度没有全面认知，对需求管理团队的配套能力建设未能提前规划，对需求自身的管理没作好准备，特别是需求标准、需求受理、需求统筹、需求质量、需求变更等相当缺乏有针对性的方案（这些方案更多的是项目级的，完全用不上）。
2、缺乏企业级管理思想
前期需求管理定位是跟着各个项目走，但实际运作下来，发现项目群的需求都是企业级的，80%以上需求都是跨系统、跨部门、跨项目，都涉及到组间需求统筹、协同和分配。由于缺乏企业级思维，造成未能建立需求管理的企业级管理标准、组织级流程和协同机制，导致项目群一开始就出现整体混乱。
3、需求管理团队定位偏差，认识偏差
需求管理团队只有7个半人，其中的半个人还兼职其它事务。当时需求管理团队的定位是做好业务和IT之间的桥梁，受理业务部门需求，进行预审后向各项目组传递需求。但实际执行时，这个定位完全与我们团队自身能力不匹配，7个半人受理所有核心系统建设的需求，还要进行预审。不说工作量有多大，单从对人的能力要求而言就让人“不寒而䅇”，对业务能力和需求能力太高（这是要求我们的人都是全业务专家和需求专家，我认为全行也没人能“享受”这个“荣誉”）。在此情此景下，我们只能硬着头皮先上，很快被陷入到各个具体需求的分析、讨论之中，回头才发现还有一大堆需求趟着原地不动，我们不吃不睡也干不完，自身已成为最大瓶颈。
4、看重流程与合规性，忽视需求内容管理
需求管理过程只注重流程审批，有相关责任人的签批记录，需求过程看似流程合规，但也带来了一系列问题：1是流程太长，流转速度太慢 ；2是审批通过后，如后续需求调整或变更，特别是需求内容局部变更，又没办法重走流程（重走时间太长），不走流程的话又出现流程评审后的需求与真实需求不一致，无法追责；3是从执行情况来看，需求流程对需求质量没有增值，缺乏需求内容管理的流程审批只会产生负面影响。最后造成的结果是流程上走一套需求，线下执行的是另一套需求，造成需求两张皮现象，分不清以谁为准，这种需求管理只为所谓的“合规性”服务，却不能为项目提供实际价值，反而造成需求混乱和可信度下降。
5、需求前期要求完美，要求一次成型，缺乏需求共创共享机制
本次项目虽然采用传统的“瀑布模型”开发建设，但在实际项目推进时，特别是时间紧、任务重的情况下，需求与开发完全串行是不合理的。项目前期，要求BA提交完美的需求文档，在前期反复修改消耗了大量时间，也造成了设计与开发等待。哪怕是前期所谓“完美”的需求真的“完美”吗？从实际执行结果来看，需求至少也调整了一半以上。在这点上，我们确实要换一换思路，借鉴敏捷思想，需求也是在项目推进过程中通过大家一起迭代完善，这样才能更省时省力。
6、需求沟通、协调处理、争议处理效率太慢
公司虽然也用了需求管理平台进行过程管理，但也只能做到流程和任务级管理，无法进行需求内容级管理，无法进行内容精准推送和沟通协同管理。因此，所有的需求内容沟通和协同，要么采用邮件和电话沟通，要么被动卷入一场场线下会议（要求所有相关人都要到，往往约不上会，或人到不齐，大量占用时间，效率极低），使得需求沟通效率低下，效果也很差。
7、前期没有可落地、可操作的工具
说起工具，我们最可气了，公司有项目管理平台、需求管理平台、测试管理平台，号称从需求到项目到开发全过程打通。当时领导也说了，我们的工具链都齐了，但在实际应用上来看，还是各个平台各自为阵（结果我们被厂商套路了）。为什么呢？从面上来看，确实流程和任务在3个平台上打通了，但缺乏需求内容的流程和任务打通有什么用？还是和上面提到的“第4点”一样，只是满足管理上的合规和走流程的要求，原有的“需求管理平台”只是一个“表单+需求文档附件”的流程工具，需求内容不能在线看、不能在线修订与变更、不能在线版本管理、需求内容不能切分、需求不能在线沟通与分享、需求不能关联与影响分析，更谈不上跨组跨项目间的企业级需求管理（如：需求统筹、需求资产、需求质量管理等），我们和项目组（需求、开发、测试人员）想要的功能一样都没有，我们在前期只能操着“烧火棍”干革命了（幸运的是，我们后来紧急采购了一套很好用很称手的需求管理工具，后面再介绍）。
【领悟】：上面7点，条条是金句，都是我们心血换来年教训。

四、 重现曙光，踏上改进之路
经历新核心项目前期的需求混乱，我们也进行了问题分析，公司领导终于意识到需求管理的重要性，同时给予我们更大的支持，按领导的话说，只要能快速解决问题，快速缓解瓶颈，要人给人，要枪给枪（估计领导们也是被逼无奈了）。在此前提下，我们聚集于主要矛盾，迅速进行了调整，逐步走出困境。现在重头回顾，以下调整措施是全面扭转局面的关键所在（篇幅限制，只说干货哈，不说虚的）：
1、 重新定位，调整策略
需求管理组从需求受理与分析的主要参与者变为组织者，定位调整为：定规则、建平台、维护整体机制运转。
2、 设定“需求负责人”，分解职责，防止人员瓶颈
每个新建需求，设定“需求负责人”，负责本需求的业务需求分析、组织协调和质量把握和全过程跟踪；指定BA负责业务统筹;指定SA负责科技统筹；明确各自职责后，在需求管理组拟定的规则下，依托平台对本需求进行全面负责和端到端跟踪。
3、 建立需求模板，拟定需求质量标准
为引导业务人员提交高质量需求，防止需求碎片化，建立需求分类分级模板，拟定需求编制要求和质量标准，需求管理组进行指导和纠偏。
4、 补齐工具短板，紧急采购称手工具
明确当前需求工具的要求，设定必要满足条件，划定工具的9个特性要求如下：
1）支持需求内容管理与跟踪（如：需求内容拆分、评估、质量检查与评审等）；
2）支持WORD文档线上编制、修订和全文浏览；
3）支持需求条目化和精准推送，支持需求条目标签管理，支持需求条目级关联；
4）支持需求内容线上线下协同，要求“上得去、下得来、还要回得去”（这条就否定了市场上80%以上的工具）；
5）支持需求内容变更与关联影响分析；
6）支持基于需求内容的流程管理与跟踪；
7）支持需求文档级、条目级的版本和基线管理；
8）支持需求条目化资产的沉淀与复用；
9）页面简洁、易于操作、开箱即用；
10）符合我行的需求管理特点和用户习惯。
我们列了以上10个要求，可在市面工具是寻找，发现否掉了90%以上工具，最终选定国内1家(维普时代的Visual RM)和国外2家的产品（IBM 的DOORS NG和Micro Focus 的Dimension RM）,进行工具产品特性分析和适配性验证后，我们依然选择了价廉物美且符合我行特点的国内工具：Visual RM，实践证明，我们的选择极为明智，Visual RM为后续需求管理工作发挥了巨大作用。
5、 简化需求流程，重在项目支持
以项目支撑为导向，以需求价值提升和传导为标准，裁剪了非必须的流程环节，加快需求在项目中的流动和价值传导。
6、 需求条目化，需求精准推送，减少需求噪音
需求管理从文档级提升至条目级，系统自动条目化后，按条目进行精准传递、跟踪与管理，大大减少了需求满天飞、消除了重复或无关需求对项目组的干扰。
7、 需求在线管理，协同共创、维护一份最新需求，贯穿始终
全面推行需求线上化（需求受理、编制、检查、评审、修订、变更与跟踪），使所有与本需求相关人员始终在同一份需求上协同工作、共创共冶、分享和沟通，所见即所得，加快需求进程。
8、 接受变更、控好版本，始终获取最新最可信需求
利于Visual RM自动进行需求内容的变更控制，自动进行变更影响分析，始终让大家能获取到最新需求，同时跟踪内容演进过程，提升需求可信度（知道为什么变？变了什么？影响到哪？）
9、 建立需求管理视图，宏观可视，微观洞察
利用工具，自动汇总数据，形成企业级管理视图，从宏观上为管理层提供需求整体情况信息（领导们好放心、好决策），微观上我们可以钻取，获取某条需求的详细信息并进行跟踪。
【领悟】：领导支持很重要，有政策、有资源，能快速反应，快速调整。但如何调整？调整方向定下来后，调整策略更重要，步步验证，分步调整要见效果，逐步深入。

五、 工欲善其事,必先利其器
西方对工具的理解是生产力三要素之一（劳动对象，劳动者和劳动工具），而我们老祖宗的“工欲善其事,必先利其器”总结得精妙。这次引入的Visual RM工具可是帮了我们大忙，不过，这也是我们精挑万选的结果。之前我们很多管理思路的调整，也得益于此工具的思想，并在此工具上践行我们的思想落地。
关于需求工具这块，我也看过不少，用过不少。Visual RM在我们项目实践的成功，并不意味着适合所有企业或项目。每类工具都有其自身的定位，有其特定的客户群体，当然其使用的场景和解决的问题也不尽相同。所以说不同成熟度、不同类型的企业，要选择与之匹配的工具，才会相得益彰。在此我谈谈我的理解，按不同成熟度的客户，需求管理工具也分为三个层级：
第一个层级：以单项目为主，主要解决项目组内沟通和需求变更问题，需求工具采用“文档版本管理工具+单项目管理工具”比较适合，如常用的组合是：“CC+CQ”或“禅道+SVN；
第二个层级：以组合项目管理为主，其特征是建立跨项目管理流程，设立项目管理办公室（PMO），这个阶段主要解决各组间（各项目组、各部门）的管理协同问题，通常建立起组织级的需求管理流程。需求工具主要采用“组织级项目管理工具“，如：PPM、Visual Project、ONES等。
第三个层级：以企业级需求管理为主，其特征是“内容级管理+组织级流程+企业级资产库”，以提升企业需求管理能力为重点。这个阶段主要解决需求内容的分解、在线协同、沟通分享、精准传递，并在组织内进行需求内容的共创、共享、共冶，以及横向统筹、纵向跟踪，并积累形成企业级需求资产，作为组织资产进行需求传承和资产复用。这类工具均植入理论模型和落地解决方案，如：Visual RM 、DOORS、Dimension RM。
当然，面对不同成熟度和不同管理要求，企业可以选取不能层级的需求管理工具，但从我们实践来看，不管用什么工具，能解决问题就是最好选择。但从专业度而言，特别是经历我们项目来看，第三个层级才能称之为真正的需求管理工具，特别是我们利用Visal RM工具，实现了将需求方法与编制、需求统筹与管控流程、需求内容级管理、需求资产沉淀与复用进行统一，形成企业级需求全生命周期的内容级管理。现在总结来看，它在以下方面给我们发挥了重要的作用：
1） 实现了需求集中受理、统一需求入口和出口
通过需求集中受理，解决需求来源多带来的需求重复、交叉、质量等问题，统一了需求标准、提高了需求质量、维护了需求的一致性和权威性。
2） 需求内容在线编制与协同
为提升需求编制质量和协调效率，实现需求内容的多人在线编制和协同，并实时进行需求内容的质量检查、问题澄清，以及基于局部内容的传递、分享、评论和沟通。拉近需求人员与研发人员的沟通距离，通过团队协作和互动，快速及时精准传递和反馈需求，提升需求质量和促进需求干系人尽快达成理解一致。
3） 由文档级转为内容级需求管控
助力IT过程的精益管理，改变传统的需求文档级粗粒度的管理方式，通过需求结构化、条目化技术，自动对需求文档进行自动化拆解，形成需求内容单元（需求条目），将需求管理与跟踪的颗粒度细化到条目级，使得需求内容切分（应用分配）、需求内容质量管控、开发和测试任务的需求分配、投产内容的需求跟踪成为可能。
4） 控好需求内容变更，维护好最新需求
实现了需求文档级、条目级的需求基线管理，通过需求内容的变更控制手段，如：多人同时在线编制需求、变更需求、变更痕迹及历史管理、变更内容前后比对、需求变更影响分析和自动通知受影响的相关人员，使需求变更过程方便、快捷，且变更过程透明、可回溯。
5） 帮助项目团队快速、方便获取最新、最可信的需求
为解决需求来源多、需求传递混乱的问题，通过需求集中管理、规范需求受理和传递过程，需求内容质量检查和质量评审等措施，使得需求管理过程规范、透明和可控，同时保证需求质量。
6） 推动开发过程的需求协同，避免开发测试返工
需求传递由文档级过渡到需求内容级，使需求内容（全部或局部）和需求变更都能快速传递到项目管理、开发、测试和投产过程的各环节对应的任务，使项目组所有成员都在同一份需求内容基础上开展工作，形成以需求为主线的开发联动，自动构建起从业务需求->项目->切分系统->软件需求->开发->测试->投产版本的跟踪脉络，使需求的提出到落地的实现过程变得透明。
7） 需求资产沉淀，形成企业级的需求统一视图
帮助用户按各类管理视角或框架（如：业务框架、应用系统框架、产品框架、组织框架）组织需求资产，通过从各项目需求文档中抽取需求资产，并按管理框架归集和维护需求资产，确保可以从某一管理视角（如：某一系统、业务领域、产品类型等）获取当前最新、最全的需求，以反映当前系统（或业务领域）的最新的需求全貌。
8） 实现了需求资产复用
通过需求资产，需求分析人员在分析、编制需求时可以快速参考、引用需求资产内容，快速构建并形成新的需求；同时可以支持多人协作并行编制需求，加速需求形成过程。
【领悟】：好工具是最好的帮手，但选择一个什么样的工具，能解决你什么问题，要想清楚，否则帮倒忙。

六、 结尾
原本只是想写一个随笔，一个晚上就能搞定，没想到越写越多；也没想到写出来后给几个同事看了一下，引起了大家共鸣，在大家的要求后，我又进行了重新整理，希望对得起大家花时间来看我这稍微“冗长”的总结。

今天是教师节，祝所有老师节日快乐！

                                              2021年9月10日凌晨
                                                      DEAN