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

目录

概述：非技术性问题概述

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

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

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

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

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

问题分类6： 大型组织

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

---

概述：非技术性问题概述

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

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

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

@问题描述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我们常看到的一些现象：

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

@解决之道：

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

 

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

@问题描述

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

@解决之道：

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

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

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

@解决之道：

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

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

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

@解决之道：

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

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

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

@解决之道：

• 避免过分强调每个Bug的处理时间 (以时间的长短作为处理每个bug的KPI，对组织来是微信的信号）

问题分类6： 大型组织

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

@解决之道：

• 增加能够最终拍板的人

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