部门会议总结

道歉与感谢

在这次版本发布之际，我想先向一些项目中的同志道歉。回顾这个版本的开发过程，我认识到自己在领导Go二组时出现了一些失误。特别是在风险管理方面，我没有及时收集并上报关键信息，导致问题的严重性没有被上级及时认识到，给团队带来了不必要的压力和挑战。

我要特别向可视化组的向阳、院红、琼婷、育孟，以及引擎安装的贺泽道歉。我的管理和技术上的不足影响了他们的绩效，尤其是在他们向我报告风险并提出解决方案时，我未能采取有效措施。他们在问题发生后积极参与解决，为团队做出了巨大贡献，是我学习的榜样。

同时，我也要向向阳致以深深的歉意。他加入团队后，不仅帮助我领导团队，还在可视化组独立后承担了重担，我相信他会成功完成项目。

对于C++组、测试组和项目经理们，我也表达我的歉意。在规范开发流程的过程中，我们之间发生了一些不必要的言语冲突，我对此感到十分后悔。我认识到这不是任何个人的过错，而是整个流程中的挑战。

我还需要向技术部的李福林、王总道歉。由于我的不足，技术部在客户那里面临了挑战，给团队增加了困难。

最后，我要向老板们道歉。我没能完全达到你们的期望，但请相信，团队中每个人都有出色的潜力和能力。作为组长，我将承担主要的责任。

在此，我也要感谢那些在困难时刻仍然坚守岗位的团队成员，如志凯、立成、慧军、松达，他们的努力保持了项目的稳定。同时感谢思华、宋燚、周宇、福林、王总、桂华、刘总，给予我许多信息、资源、时间上支持和帮助。

好和不好的点

在这个版本期间，为流程规范建立和执行，团队成员都非常配合，让我真正看到团队在齐心协力地改进项目形态，让项目从幼稚走向成熟。

团队中各成员的配合还不够默契，还有改进的空间。

任务评估这个环节上还不够全面、准确。

总结一下，这个版本让我看到每个团队成员都在成长、在突破。

提一下团队成员的诉求

• 打包时间过长
  • 之前需要 二、三十分钟，后面我们已经安排做了缓存优化，能优化到 1 分钟。只是生产环境应用的时机问题。
• 超融合机器有时性能不行
  • 这个后面测试团队接手了这部分工作，我相信他们能帮我们提供这方面支持，改善我们用机器的性能问题。
• 需求改动频繁，临近上线还有需求变更，版本需求临界点不清晰问题
  • 已跟产品团队做了信息同步，将在下版本尽量优化改进，大家也要多给团队一些时间、包容，要记住我们是一个团队，荣辱与共的团体。
• 测试介入有时不及时，已提测比较久后才发现提了BUG
  • 跟测试团队联系更紧密
  • 项目经理优化测试资源调度
  • CI/CD 流程建立

总的来说，项目确实是越來越庞大，但也越来越好了。

“海阔凭鱼跃，天高任鸟飞。” 我期待我们所有人在石犀这片蓝天中自由翱翔、不断进取、一往无前。

自身的问题

是一个失败的管理者

• 整个组织对管理和技术缺乏认知, 让管理者天然被矛盾包围, 又要人成长又要拿结果, 无休止的加班也换不来认可
• 单纯的压力传导, 对管理和技术毫无想法, 仅仅是倾斜上层压力给团队
• 以架构师, 技术专家的思维方式去对待团队, 把人看成工具和资源, 只考虑结果不考虑过程, 造成团队内耗严重, 长期无法形成战斗力

是一个失败的架构师

• 技术规划的两个极端

  • 在技术规划和设计中忽视人的因素, 没有将其纳入分析范围, 导致落地变形失败
  • 对效率的认识不足, 过于考虑使用者的所谓成长空间等本不该考虑的问题,导致方案不伦不类

• 想要目标感, 目的不明确, 缺乏理性, 情绪化, 朝令夕改

一、主要成就

首先，我想与大家分享我们团队在过去一段时间里取得的显著成就。我们的成就不仅仅体现在完成任务上，更在于我们如何高效、创新地完成这些任务。

1. 成功研发1.3.0版本：我们的团队按照既定的需求任务，成功完成了总控、引擎、插件1.3.0版本的研发工作。这个版本的研发不仅涉及复杂的技术挑战，还需要我们在紧迫的时间线内保持高效率和高质量的输出。我们的团队展现了出色的技术实力和项目管理能力。

2. 规范研发流程：我们不仅关注产品的开发，同样重视研发流程的规范化。我们对部分研发流程进行了规范，并以微盘文档的形式进行记录和分享，这不仅提高了工作效率，还促进了团队内部的知识共享和学习。这些文档为新成员的快速融入和老成员的持续学习提供了极大的便利。

3. 流程培训和共享：我们认识到仅仅规范流程是不够的，团队成员对这些流程的理解和应用同样重要。因此，我们不仅制定了流程，还开展了相关的培训活动。通过这些培训，我们确保每位团队成员都能充分理解并正确应用这些流程，从而提高整个团队的协作效率和产品质量。

4. 技术创新和问题解决：在这个过程中，我们的团队面临了许多技术挑战和问题。我们不仅成功地解决了这些问题，还在此过程中创新了一些新的技术和方法。这些创新不仅提高了我们当前项目的效率和质量，还为我们未来的项目打下了坚实的基础。

这些成就是我们团队共同努力的结果。每一位团队成员的辛勤工作和奉献精神都是我们能够取得这些成就的关键。

二、挑战与困难

在我们的旅程中，我们面临了不少挑战和困难，这些问题对我们的工作流程和项目交付产生了影响。

A. 需求管理

1. 需求文档质量问题：我们遇到了需求文档描述不清晰的问题，这导致了流程的不合理性和功能目标的自相矛盾。为了解决这一问题，我们将加强需求文档的评审流程，确保在开发前与需求方达成一致，并且减少不必要的功能和模块的设计，避免界面风格的不统一。

2. 需求变动频繁：频繁的需求变更，特别是在项目接近上线的阶段，对我们的工作计划和资源分配造成了冲击。未来，我们将设立更明确的版本需求临界点，并加强与各方的沟通，以减少临时变更的影响。

B. 开发过程

1. 设计文档不全：部分功能模块缺少完整的设计文档，这影响了开发的连贯性和质量。我们计划在未来强化设计文档的完整性，确保每一个功能模块都有详细的设计记录。

2. 设计不充分：我们也面临了设计考虑不周全的问题，尤其是在安全性、性能和影响范围方面。我们将加强设计阶段的评审流程，确保设计的全面性和适应性。

C. 安装升级和联调

1. 安装升级问题：我们遇到了依赖性和升级兼容性问题，这导致了安装和升级的困难。解决这个问题的关键是优化依赖管理和测试升级路径。

2. 联调协作不足：我们的项目在多层面的协作中遇到了障碍。我们计划加强团队间的沟通和协作流程，以改善联调效率。

D. 测试与部署

1. 测试介入时间：测试可能的延迟介入影响了问题的早期发现。我们将调整测试流程，确保测试团队可以及时介入和提供反馈。

2. 打包部署效率低：打包和部署的周期过长，影响了整体的工作效率。我们将提升打包部署环境的硬件资源，优化资源配置，以加快这一过程。

E. 技术支持与资源配置

1. 加强技术支持：为了改善工作环境，我们计划提供更好的硬件资源，包括磁盘、CPU和内存，并确保网络环境能够满足低延迟和高吞吐量的需求。

2. CI/CD实践指导：我们还面临着CI/CD实践的挑战。项目经理和开发团队将更紧密地协调人力和资源，确保CI/CD流程的有效实施。

三、未来规划

1. 改进需求管理流程：我们将专注于改进需求管理流程，确保需求文档的质量，并减少临时需求变更的影响。

2. 优化开发和设计流程：我们计划优化开发流程，强化设计文档的完整性，确保设计的全面性和适应性。

3. 强化安装升级和联调流程：我们将专注于解决安装升级的问题，优化依赖管理，并加强团队间的协作，以提高联调效率。

4. 提升测试和部署效率：我们将调整测试流程，以及提升打包部署环境的硬件资源，以加快测试和部署的周期。

5. 增强技术支持和资源配置：为了支持这些改进，我们将加强技术支持，提供更好的硬件资源，并优化CI/CD实践。

四、个别成员表现

在这一阶段的工作中，我们有几位团队成员的表现值得特别提及。他们的贡献不仅体现在完成任务上，还包括在团队中的积极态度和个人品质。

1. 吴松达和贺泽：他们在工作中展示了复杂情况下的应对能力。尽管在任务反馈的及时性、请假规定的遵守、考勤和日常报告方面存在一些挑战，但他们在承担的任务量和范围方面表现出色。他们积极活泼的态度，以及对问题的提出和解决方案的思考，体现了他们的爱思考、坚韧、社会性和好奇心这四种珍贵品质。在未来，我们将与他们一起努力改进这些方面的不足。

2. 韩志凯和范众星：这两位同事的表现也非常值得肯定。他们在沟通方面表现充分、稳重，确保了负责模块的无纰漏运作。他们的工作可能不总是显眼，但正如“善战者无赫赫之功”一般，他们在日常工作中的卓越表现是团队稳定运行的关键。他们的贡献在维护模块稳定性和高效性方面尤为突出。

五、感谢

1. 对全体团队成员的感谢：首先，我要感谢每一位团队成员。无论是面对复杂的技术挑战，还是在紧迫的项目时间线上工作，大家都表现出了非凡的专业能力和坚定的承诺。您们的热情和奉献是我们团队成功的基石。
2. 对面临挑战同事的感谢：或多或少我们都经历了挑战，再次感谢特别是面对挑战时坚持不懈的同事，您们展现的韧性和解决问题的能力对于团队的成功至关重要。
3. 对管理团队的感谢：我还要特别感谢我们的管理团队，他们在规划和指导中展现了卓越的领导力。在面对各种挑战和变化时，他们的决策和支持为团队提供了坚实的后盾。
4. 对家庭和亲人的感谢：最后，我要感谢我们每位团队成员的家庭和亲人。他们的理解和支持使我们能够全身心投入工作。没有他们的支持，我们的成功也不会完整。

待关注的点

项目管理

• 有时项目紧急，人员抽调不合理
• 不是所有禅道任务项目管理都有被跟踪、更新
• 项目里程碑、版本设计不合理
• 开发节奏太紧、流程、规范要求占用很长时间，但是项目管理上没有时间消耗的意识
• 禅道任务拆分粒度过大，原因是大家对其认知不够，导致时间评估上不准
• 基础设施 禅道、CI/CD、wiki 、团队知识库依然简陋

开发

• 有些开发不知道这套系统整体长什么样，不知道怎么部署环境
• 代码不规范、review 缺失，也要注意，做这些前提是给时间

总结

人为什么会追求权力、金钱、颜值？因为拥有这些东西的人走到哪里都是众星捧月，本质上，最终追求的还是别人的认同。
但是，做事情的人都是孤独的，没有人能照顾到各方利益，得到所有人的认同，总会有各种不和谐的声音存在，也没有人能走出绝对正确的路线，总会有试错、反复试错，并在这个过程中变得越来越好。

举个例子：

做事情的过程中，感受各方面的条件限制，各方面的压力，各种睡不着、焦虑。
而结果是没法即时验证的，所以这种压力会持续很久，直到时间让人淡忘。
有些结果可以短时间内验证，如果证明走错了路，当你埋头思考、总结经验时，你会感受到“墙倒众人推”的滋味。
当然，如果走对了路，那大家就会认为你有能力、优秀，不过也别飘，下次失败时，还是会“墙倒众人推”。

面临这样的压力时，大家会想起什么？我只想送一句话，看透世界的残酷而依然埋头赶路的才是英雄。

我说完了，看起来我说了很多，其实我什么也没有说，要相信，我说的是错的，有收获是你自己的。

附录：1.3.0 版本问题整理

A. 需求管理

1. 需求文档质量问题：

   • 功能和目标描述不清，导致流程不合理和自相矛盾。
   • 需求文档应在开发介入前完成评审，确保与需求来源方达成一致。
   • 避免多个模块界面设计风格不一致，减少无意义功能和模块。

2. 需求变动频繁：

   • 需求变更频繁，尤其是在接近上线阶段。
   • 需要设立明确的版本需求临界点，及时沟通变更。

B. 开发过程

1. 设计文档不全：

   • 缺少部分功能模块的设计文档。
   • 强化设计文档的完整性和规范性。

2. 设计不充分：

   • 安全性、性能、影响范围等方面考虑不足。
   • 加强设计评审，确保全面性和适应性。

C. 安装升级和联调

1. 安装升级问题：

   • 依赖性和升级兼容性问题。
   • 优化依赖管理和测试升级路径。

2. 联调协作不足：

   • 各层面协作问题，如项目经理、开发等。
   • 加强团队间沟通和协作流程。

D. 测试与部署

1. 测试介入时间：

   • 测试可能介入太晚。
   • 调整测试流程，确保及时介入和反馈。

2. 打包部署效率低：

   • 打包部署周期长，影响工作效率。
   • 提升打包部署环境，优化资源配置。

E. 技术支持与资源配置

1. 加强技术支持：

   • 提供更好的硬件资源，如磁盘、CPU、内存。
   • 确保低延迟高吞吐量的网络环境。

2. CI/CD实践指导：

   • 需要更有效的CI/CD实践。
   • 项目经理和开发团队应协调人力和资源，确保流程的顺利实施。

---

以上内容梳理了1.3.0版本在需求管理、开发过程、安装升级和联调、测试与部署、技术支持与资源配置方面遇到的主要问题，并提出了相应的改进措施。请根据实际情况进一步调整和完善这些内容。

1. **团队的主要成就**：在过去的一段时间里，团队取得了哪些显著成果？
2. **挑战与困难**：团队在工作中遇到了哪些难题，以及是如何克服这些挑战的？
3. **个别成员表现**：是否有特别需要表扬或提及的团队成员？
4. **未来规划**：团队接下来有哪些计划或目标？
5. **感谢与鼓励**：对团队的感谢之词或鼓励的话语。
6. **其他补充信息**：任何您认为重要的信息，比如团队的特殊事件、重要里程碑等。



团队的主要成就：

1. 按照需求任务，完成 总控、引擎、插件 1.3.0 版本需求的研发
2. 规范了部分研发流程，并以微盘文档的形式以供团队学习，部分流程开展了培训。

挑战与困难：

见附录

个别成员表现：

1. 吴松达、贺泽： 安排的任务反馈不及时、请假没有按规定、考勤不好、情绪不稳定、日报周报等常常遗漏。但是承担的任务很多，范围很广，平时积极活泼，常常提出问题，思考解决方案。对应了人类珍贵的四种品质：爱思考 坚韧 社会性 有好奇心。
2. 韩志凯、范众星：沟通比较充分、稳重，负责的模块不出纰漏，善战者无赫赫之功，维护好一个模块将日常的工作做到极致也是非常值得肯定的。

未来规划：

1. 需要建立更规范的规章制度和流程规范。规章制度流程规范是组织内部管理和操作的核心组成部分，要确保有效性、透明性和适应性：需要做到

   **明确性（Clarity）**：规章制度应该清晰明确，易于理解。避免使用模糊不清的语言，确保所有相关人员都能准确理解其含义和应用方式。

   **一致性（Consistency）**：制度和流程应该在整个组织内保持一致。这有助于减少混淆，确保所有部门和员工按照相同的标准执行。

   **可访问性（Accessibility）**：员工应能轻松访问到相关的规章制度文档。这通常意味着将它们存放在中央、容易访问的位置，如内部网络或手册。

   **适用性（Applicability）**：制度应与组织的运营、文化和目标紧密相连。它们应该针对组织的具体情况设计，而不是简单地复制其他组织的模式。

   **合法性（Legality）**：所有规章制度必须遵守相关的法律和行业标准。它们不应与任何法律条文相冲突。

   **灵活性（Flexibility）**：制度应该有一定的灵活性，以适应不断变化的环境和需求。应当定期审查并根据需要进行调整。

   **可执行性（Enforceability）**：应该有明确的执行机制。员工需要知道，对于不遵守规章制度将会有何种后果。

   **透明性（Transparency）**：制定和修改规章制度的过程应公开透明，以便员工理解制度的目的和重要性。

   **目标导向（Goal-oriented）**：流程和规章应支持组织的总体目标和战略。

   **评估和反馈（Evaluation and Feedback）**：应定期评估制度的有效性，并对员工的反馈做出响应

   

   原因：

- **团队规模增长时**：随着团队规模的增长，原有的非正式或口头沟通方式可能不再有效。规章制度可以帮助确保信息的一致性和准确性，特别是在团队成员之间需要协作的情况下。
- **面临复杂项目时**：当项目涉及多个部门、多个阶段或高度复杂性时，明确的流程规范有助于保持项目的顺利进行，并确保各个环节协调一致。
- **引入新技术或方法时**：当团队采用新的技术、工具或开发方法（如敏捷开发）时，建立相关的规章制度可以帮助团队成员理解和适应这些新变化。
- **遵守行业标准和法律要求时**：在某些行业中，遵守特定的法律法规和标准是必须的。例如，在医疗、金融或政府项目中，规章制度和流程规范可以帮助确保合规。
- **提高效率和质量时**：为了提高工作效率和产品质量，团队可能需要引入标准化的工作流程和质量控制措施。
- **面对频繁的变更和迭代时**：在快速变化的市场环境中，规章制度可以帮助团队快速适应变化，同时保持工作的连贯性和效率。
- **实现知识共享和传承时**：随着团队成员的更迭，重要知识和经验的传承变得尤为重要。规章制度可以帮助新成员快速融入团队，理解工作流程和文化。
- **远程工作或分布式团队时**：对于远程工作或地理位置分散的团队，明确的规章制度和流程规范对于保持团队协调和高效合作至关重要。



2. 更细致的分工

研发岗位的组长和组员强调对于技术方面更多的参与，关注代码本身。

对于组长以上，应该做到对规章制度和流程规范，项目管理层面的把控，注意合理、可行、公平

3. 完成 1.4.0 版本需求
4. 优化端口策略

- 复用

- 尽量连续

  

5. 拥抱信创

- Envoy Polycube waf 等编译
- MySQL5.7 MongoDB HyperScan
- so 依赖库问题
- 组件依赖汇编



## 附录

### 1.3.0 版本问题整理

### 需求

#### 需求文档质量差

各个模块完成的功能和目标没有梳理清楚，导致流程不合理、自相矛盾的情况屡屡发生。

需求文档应该在开发介入前评审完成，而不是让开发和需求同时进行

产品经理应该和需求来源方达成一致后

多个模块、界面设计风格不一致

存在很多无意义的功能、模块

设计功能、模块时未考虑对系统性能影响，导致影响越来越大，最终系统中部分的业务性能出现瓶颈，导致需要开发设计重构，需求重做。至今尚未解决性能问题。

需求文档没有经过拆分，一个版本一个需求文档，找到某一个功能的需求非常困难

#### 需求变动频繁、随意

需求变动频繁，临近上线还经常看到群里有需求变更，甚至还添加新需求，版本需求临界点不清晰

### 开发

#### 设计文档不全

这版本之前开发的功能模块开发的设计文档都是没有的，相当一部分人没有补齐

#### 设计不充分

有些设计文档也有考虑不周的情况，安全性、性能、影响范围、测试建议、自测实现思路、兼容性（不同组件、不同版本）

#### 安装升级问题

##### 安装升级问题

依赖

升级兼容性

#### 联调

从各个层面，如何协作才能更好完成

##### 主管

#####  项目经理

##### 大组长

##### 开发

### 测试

#### 测试介入时间是否及时

测试是否介入太晚？有时候看到测试提的bug是几周前就已经提测的需求了，这些问题按道理应该是需要提前发现提出的

### 打包部署

#### 打包部署一次周期很长

##### 现象

打包部署一次时间很长，这个现象已经持续很久，急需解决。

超融合机器性能不好，部署周期过长，从打包到升级耗时往往超过1小时，期间如果出现包有问题的情况可能一个上午就过去了，甚至会出现几天没有一个有用包的情况出现

##### 解决

###### 技术支持

更强大的技术支持，如打包机器用更好的磁盘、CPU、更多内存，集测环境机器网络延迟和吞吐量要满足低延迟高吞吐量要求。

###### 架构、研发经理

CI/CD 实践指导

###### 项目经理

指定并协调人力、时间资源

###### 开发

- 开发人员跟打包部署测试人员要做充分沟通（提交新的代码）
- 在某一功能新开发时就充分考虑功能的扩展性、兼容性，在后续开发时首先在自己组件层面做好数据兼容，逻辑兼容，涉及多个组件交互的模块尽量解耦，尽早识别风险。如果遇到绕不过，需要其他组件配合实现的，在打包时跟相关开发和打包部署测试人员充分沟通后走流程。
- 数据提供方在设计完成后优先考虑数据结构交互部分的实现，如将 接口请求响应、API文档部分完成。



## 






在这次版本发布之际，我首先要向团队中的同事们表达我的歉意。回顾这个版本的开发过程，我认识到自己在领导Go二组和可视化小组时出现了一些失误。特别是在风险管理方面，我没有及时收集并上报关键信息，导致问题的严重性没有被上级及时认识到，给团队带来了不必要的压力和挑战。

我要特别向可视化组的向阳、院红、琼婷、育孟，以及引擎安装的贺泽道歉。我的管理和技术上的不足影响了他们的绩效，尤其是在他们向我报告风险并提出解决方案时，我未能采取有效措施。他们在问题发生后积极参与解决，为团队做出了巨大贡献，是我学习的榜样。

同时，我也要向向阳致以深深的歉意。他加入团队后，不仅帮助我领导团队，还在可视化组独立后承担了重担，我相信他会成功完成项目。

对于C++组、测试组和项目经理们，我也表达我的歉意。在规范开发流程的过程中，我们之间发生了一些冲突，我对此感到后悔。我认识到这不是任何个人的过错，而是整个流程中的挑战。

我还需要向技术部的李福林、王总道歉。由于我的不足，技术部在客户那里面临了挑战，给团队增加了困难。

最后，我要向老板道歉。我没能完全达到您的期望，但请相信，团队中每个人都有出色的潜力和能力。作为领导者，我将承担主要的责任。

在此，我也要感谢那些在困难时刻仍然坚守岗位的团队成员，如志凯、立成、慧军、松达，他们的努力保持了项目的稳定。同时感谢思华、宋燚、周宇、福林、王总、桂华、刘总的支持和帮助。

“海阔凭鱼跃，天高任鸟飞。” 我期待我们所有人在石犀这片蓝天中自由翱翔、不断进取。



在这个版本发布后，我想先向一些项目中的同志道歉。原因是这样的，在这个版本开始时，我接手的Go二组和可视化小组是包含关系。桂华将小组责任交与我，但是我并未将其按质按量完成，在风险管控上，未让相关人员收集所有信息导致不能早早让上级意识到这是个严重的问题，以至于暴露出的问题让老板都惊讶。

我深切认识到，这确确实实是我的责任。在此，先是可视化组成员：向阳、院红、琼婷、育孟等，再是引擎安装的贺泽，第一，他们因为我能力上的不足导致在绩效上非常受影响。第二，重点道歉院红、琼婷、贺泽，在发现了风险后，他们向我提出过这些问题和详细信息，但是我没有实施有益的措施帮助。而后，他们非常积极的帮助补救形势而努力工作，他们是我学习的榜样。下面也要向向阳道歉：向阳进入团队后，一直为团队摆脱困境协助我带领团队，后面可视化独立成一个组去收拾我留下的烂摊子，我相信他会把项目完成好。第三，向 C++ 组成员、测试组和项目经理们道歉，在这个版本进行中，还有一件大事同步进行，就是规范项目各种开发流程，这期间很多次跟很多人发生冲突，可能表现为语言上冲突很严重，有时说完立刻就觉得很后悔，这可能并不是任何人的错，不应该有人为此承担责任的。第四，向技术部李福林、王总道歉，消耗了许多技术部资源但是我这边交付的需求不达标导致他们在客户那边很难维持关系，给我们技术部团队添了太多麻烦。第五，向老板道歉，我觉得我辜负了老板对我的信任，但是我想澄清的是，团队的表现不佳，并不代表团队中每个人都不好，最大的原因一定是带头实施的人员没做好。最后，我想郑重向我的上级道歉，虽然是我在道歉，但是最终犯错的结果、责任还是落在上级头上。

道歉后，我想感谢一些人，除了刚刚提到的院红、琼婷、贺泽、向阳外，还有一些团队成员，志凯、立成、慧军、松达，他们没有受到我的影响，为维持总控项目的基础稳定进行了出色的工作，是团队中最可敬的人。还有思华、宋燚、周宇、福林、王总、桂华、刘总，他们给予我许多信息上、资源上、时间上非常多的帮助。

海阔凭鱼跃，天高任鸟飞。希望大家在石犀这片蓝天中自由翱翔、一往无前。