[架构之路-53]：架构师 - 嵌入式软件常见难查问题与解决办法大总结-2-非技术性问题

Posted 2022-11-18 文火冰糖的硅基工坊

目录

概述：非技术性问题概述

问题分类1：公司、部门的组织架构与目标系统的组织架构错位导致

问题分类2： 技术人员对代码熟悉程度不同导致处理问题的效率不同

问题分类3： 不合理的项目管理与任务分配

问题分类4： 组织架构的调整导致人员的变动

问题分类5： 不合适的KPI导致各个部门对接手问题的调查保持谨慎的态度

问题分类6： 大型组织

问题分类6： 其他....

---

概述：非技术性问题概述

在大规模系统中，存在大量并发执行的程序，每个程序都可能对它们的执行环境（CPU和内存）造成影响，而这些环境由会影响其他程序的执行，这就导致现象与原因不在一个地方。

同时，在大规模系统中，按功能，软件系统被分割成无数个模块、组件，负责这些组件、模块的开发人员属于不同的职能部门，这些职能部门有各自不同优先级的任务和KPI。而解决这些复杂的问题有需要这些职能部门的配合，才能找到真正的出错原因和找到最终的解决方案。或许最终解决问题的代码在仅仅在组件X， 也只有简单的一行代码，然后，找到问题的原因和给定解决方案的过程却是漫长、麻烦的。

问题分类1：公司、部门的组织架构与目标系统的组织架构错位导致

@问题描述

公司人员的组织架构是为业务服务的，公司人员的组织架构要服从业务架构的变化而变化，公司人员的组织架构要适应业务架构的变化而变化。

业务架构有体现在：业务模型（系列产品） + 产品（又称为目标系统）的架构

而组织架构又体现在：职能部门的组织架构+项目管理的组织架构。

（1）业务架构（商业、盈利、市场）

• 系列产品的层次以及他们对组织战略的职责（如何盈利）
• 系列产品之间的关系

（2）目标系统架构（产品、服务、软件、硬件、分层）

在软件开发环节，“产品（目标系统）的架构”体现在如下的两个方面：

• 目标软件系统的软硬件模块层次以及他们职责
• 目标软件系统的软件模块之间的关系与工作流程

（3）职能部门（技术部门、岗位）

公司的职能部门的组织架构体现在

• 组织内部的职能部门（人员或职位）的层次以及它们的职责
• 组织内部的职能部门（人员或职位）之间的关系与工作流程

（4）项目组织架构（项目团队、项目管理）

项目管理的组织架构体现在

• 组织内部的职能部门（人员或职位）的层次以及它们的职责
• 组织内部的职能部门（人员或职位）之间的关系与工作流程

我们常看到的一个现象有：

• 公司的组织架构是“因人”设岗"
• 上述四个架构之间不协调、错位。
• 目标系统架构与业务架构不协调 =》 导致开发的产品没有市场价值，把公司的资源投入到对公司业务没有价值的产品上，导致开发人员的付出无法转换成公司的价值，人力资源的严重浪费。
• 职能部门和项目管理的的组织架构与产品架构不一致 =》 开发流程不顺畅、开发效率不高、产品质量差。

@解决之道：

公司的职能部门的组织架构、项目管理的组织架构、目标系统的组织架构这三者必须协同一致，这样组织的开发效率才能最高，生产出来的目标系统才能稳定、可靠。

 

问题分类2： 技术人员对代码熟悉程度不同导致处理问题的效率不同

@问题描述

在大规模分工的系统中，每个技术领域，都有一群人负责，有技术能力强的人，有技术能力弱的人，问题的解决效率与个人的技术能力有极大的关系。有些简单的技术问题，如果参与的不是合适的技术人员，简单的问题就变得复杂。正所谓“难者不会，会者不难”。 

@解决之道：

• 培养和提升技术人员的技术能力
• 长期的积累，而不是频繁的更换

问题分类3： 不合理的项目管理与任务分配

在复杂的系统中，程序员可能会同时处理很多的问题，不同的人，从不同的角度都在push程序员，尽快解决自己的问题，然而，程序员的精力是有限的，把精力放到某个问题上时，自然放到另一个问题上的精力就少了。如果程序员并发的处理多个问题的时候，这个每个问题处理的宏观的时间就会被拉长，如果说，该问题是独立的，与其他人员无关，这倒没什么，该程序员总体的输出并没有收到影响。然后，复杂系统中，一个问题需要涉及到多个部门，大量的人员，一个程序员在某个环节上的放缓，导致整个组织的其他人人员的进度也跟着放缓。整个组织的执行就会极大的降低。从宏观上看，整个组织都很忙，但总体的效率却很低。从宏观上看，一个简单问题就变成一个复杂问题。

@解决之道：

• 按优先级排序分配任务，在一个高优先任务完成前，不要处理其他任务
• 降低程序员并发处理故障的个数（1-2个比较合适，最多不要超过3个），否则“线程”切换的开销就很大。
• 高难度+与低难度任务搭配：同时处理多个高难度问题，整体效率是下降的。

问题分类4： 组织架构的调整导致人员的变动

导致负责原来软件的人员负责新的软件，而接手这部分软件的人对软件的架构和代码不熟悉。这导致查找问题的效率极大的降低，原本一天解决的问题，可能需要一个星期、甚至一个月才能解决。

@解决之道：

• 尽量保持组织的稳定性和一致性，除非业务重组

问题分类5： 不合适的KPI导致各个部门对接手问题的调查保持谨慎的态度

在大规模分工组织系统中，每个部门都有解决bug的KPI，导致各个部门对接手问题的调查保持谨慎的态度，在没有充足证据证明是自己技术领域的问题之前，每个部门都不愿参与调查，这导致当前主导调查的技术人员很是无助，导致调查的进度很慢，很难推进，调查的效率比较低。 

@解决之道：

• 避免过分强调每个Bug的处理时间 (以时间的长短作为处理每个bug的KPI）

问题分类6： 大型组织

一个复杂的目标软件系统是有无数个子系统和组件组成的，一个复杂问题，往往可以在不同的子系统解决。各个子系统，或出于保护自己的子系统免受新的代码改动造成的冲击，或处于bug的主体责任的考虑，或因为子系统人员工作量等因素的考虑，我们经常看到一个现象：每个子系统，都希望，最终的解决方案，不要放到自己的子系统，希望推到其他子系统，此时，如果没有一个权威能够拍板最终的解决方案，结果就是：看谁更能够耍赖、看谁的嗓门更大、看谁更能够 狡辩、看谁更容易被欺负，而不是选择最优的技术方案，有时候，因为不是一个最优的方案，一个简单的问题，就变成了一个复杂的问题。

@解决之道：

• 增加能够最终拍板的人

问题分类6： 其他....