【原】大多数软件问题归根结底都是组织结构问题

在《软件工程最佳实践》一书中给出了这样一条结论：

很多问题都可以追溯到组织的结构问题上。

初闻之下，如醍醐灌顶；细细思索，深以为然。

比如有这样一个案例。

小吴是某软件的负责人，他的软件在生产环节出现了问题。由于生产进度安排得非常紧，几乎没有多少软件验证的时间，所以小吴在匆匆修复了问题之后，自己调试软件功能正常，就提交给车间继续生产流程。结果这件事儿被质量管理部门发现了，打了不合格项。

在这个案例中，虽然尚未出现新的软件故障，但小吴的做法也违反了组织的软件工程规范的要求，包括：

• 软件更改之后会进行回归测试。

• 提交到生产环节的软件是非受控版本。

小吴，所以这样做是因为没有软件验证的时间。没有软件验证的时间是因为车间的生产周期很短。车间的生产周期很短是因为制定生产计划时没有考虑软件更改的流程可能需要更多的时间。没有考虑软件更改验证的时间是因为制定生产计划时并没有软件专业人员参与。这就是组织的结构出现了问题。

小吴这样做只被质量管理部门发现，软件部门事先都不知情。这说明项目监控出了问题，项目负责人不了解情况，QA不了解情况，软件项目组名存实亡，这也说明组织结构出现的问题。

除此之外组织结构如何更好的适配软件项目，还有很多要研究的内容。比如：

• 传统的层级式的组织结构和扁平化的组织结构，哪种更适应那些短平快的软件项目？

• 对于一个复杂的系统，需要一个庞大的团队，那么是否应该把系统拆分成小的系统或部件，把庞大的团队拆分成小的团队(6~8人)，这样会更有利于项目开发活动的进行？

• 一个团队如何组成才会更加高效？比如应该有几名开发人员，几名测试人员，是否需要有文档专员？是否需要有某个领域专家，是否需要有软件专家？

下表列出了30种软件专家及其在团队的分布情况。

表1 总数1000名软件人员中软件专家的分布情况

专家种类	数量	百分比
软件维护专家	315	31.5%
软件开发工程师	275	27.5%
软件测试专家	125	12.5%
一线经理	120	12%
质量保证专家	25	2.5%
技术文档专家	23	2.3%
客户支持专家	20	2%
配置控制专家	15	1.5%
二线经理	9	0.9%
业务分析师	8	0.8%
范围经理	7	0.7%
行政支持	7	0.7%
项目库管理员	5	0.5%
项目规划专家	5	0.5%
软件架构师	4	0.4%
用户接口专家	4	0.4%
成本估算专家	3	0.3%
度量/指标专家	3	0.3%
数据库管理专家	3	0.3%
本地化专家	3	0.3%
图形艺术家	3	0.3%
软件性能专家	3	0.3%
软件安全专家	3	0.3%
软件集成专家	3	0.3%
软件加密专家	2	0.2%
可重用性专家	2	0.2%
测试库控制专家	2	0.2%
项目风险专家	1	0.1%
标准专家	1	0.1%
价值分析专家	1	0.1%

如果团队当中有专家的存在必定会降低软件出问题的概率。比如有测试专家的存在，就可能会降低出现“验证不充分”的问题的出现；有性能专家的存在，就可能会降低“性能无法验证”的问题的出现。

总之，如果你的软件出现了问题，除了找到问题的出处，解决问题之外，还请思考一下相应的组织结构是否存在问题。因为组织结构的问题是根本原因所在，解决了组织结构的问题，就会避免批量问题的出现。

一劳而永逸，何乐而不为？