“以偏概全”是一种常见的逻辑谬误，有两种表现：一是从不具代表性的个例推导出一般性结论，二是从局部性质推导出整体性质。最典型的例子就是“幸存者偏差”：记者在春运火车上采访乘客是否买到票，问到的都说买到了，于是得出结论“大家都买到票了”——却忽略了没买到票的人根本不在车上。在GJB5000B实施过程中，这种错误同样屡见不鲜，值得每个实践域警惕。
领导作用
某单位有一个项目试点GJB5000B后，进度偏差明显缩小。领导便认为：“所有项目只要套用这套流程，都能大幅提速。”于是要求全组织立刻全面铺开。这就是从个别项目的成功推导出整体必然有效的结论，忽略了项目规模、人员能力、业务类型的差异。试点有效，不等于全面有效。
实施基础
某项目组使用了一款新的配置管理工具，觉得效率提升明显。组织便决定所有项目统一采购该工具，不做需求调研。一个项目用得好，不代表所有项目都适用。工具选型应基于组织整体需求，而非局部经验。
项目策划
策划时参考了一个类似项目的估算数据，发现偏差很小，便直接照搬参数。但那个项目人员稳定、需求明确，当前项目却人员流动大、需求模糊。从一个代表性不足的样本推导出估算结论，必然导致计划失真。
项目监控
某次周报显示关键路径任务按时完成，项目经理便认为整个项目健康，放松了对其他任务的跟踪。局部正常不等于整体无风险。一个任务的进度正常，不能掩盖其他模块的延期隐患。
外部供方管理
某供方交付了一个合格部件，采购部门便认为该供方所有产品都可靠，后续采购免检。一个产品的合格，不能代表供方整体质量水平。供方能力需要持续评价，而非一劳永逸。
需求开发与管理
需求调研时，访谈了少数几位积极用户，他们都表示需求清晰。项目组便认为所有用户需求都明确，不再深入分析。那些沉默的、不善于表达的用户，他们的需求可能完全不同。样本缺乏代表性，结论自然不可靠。
验证与确认
测试人员抽测了几个核心功能，没有发现缺陷，便认为系统整体质量过关，减少了回归测试。局部无缺陷，不等于整体无缺陷。未测到的模块可能藏着严重问题。
运行维护
运维数据显示某个模块长期稳定，运维团队便认为整个系统都很稳定，放松了全系统监控。一个模块的稳定，不能代表所有模块都可靠。系统是整体，短板往往在别处。
配置管理
配置管理员抽查了几个配置项，版本号都正确，便认为整个配置库管理规范。几个配置项正确，不代表全部配置项都受控。未抽查到的配置项可能版本混乱。
质量保证
QA抽查了两个过程，没有发现不符合项，便给出项目“完全符合”的结论。抽查样本少、覆盖面窄，不能代表项目整体执行情况。以局部合规推导整体合规，是典型的以偏概全。
测量分析
组织收集了一个项目的缺陷数据，发现缺陷率很低，便得出“组织整体质量很高”的结论。一个项目的数据不能代表所有项目。不同项目难度、人员、需求差异巨大，需要更多样本才能得出可靠结论。
GJB5000B强调基于证据的决策。证据是否充分、样本是否有代表性、局部与整体是否相关，直接决定结论的可靠性。遇到“一个项目这样，所以所有项目都这样”的说法时，多问一句：样本够吗？有代表性吗？因果关系成立吗？
用四句诗总结：
个例难撑全局论，
局部岂能代整体。
样本代表须审视，
实事求是方为基。
参考书目：一读就上瘾的逻辑学，作者：阿健，出版社：天地出版社
