初开:不要把问题的前提当作原因

最近的上线的一个项目出现了比较严重的质量问题,在复盘过程中有一个值得思考的点可以单独拿出来聊聊。
当问自己是什么导致了这个质量问题时,一开始给出了这么几点:这是因为我们的团队是临时组建的,我们的成员对本次项目的业务和技术都不熟悉。
所以谈到改进点时就很自然的说:我们要加强团队人员的培训,提升团队的经验水平。
这个改进点有问题吗?
它本身没有错,但问题在于定位错了:把问题的前提当成问题的原因。
我们来看两种表述。

  1. 我们要组建一个经验丰富的项目团队,避免质量问题发生。
  2. 当我们面临一个临时组建,经验不足的项目团队时,仍要避免质量问题发生。

这两种表述的差异在哪?
前一种表述是因为我们“团队”的原因,导致了本次质量问题,所以我们要解决“团队”的问题。
而后一种是我们的团队就是临时组建的,我们的开发、测试就是对新项目的业务和技术不熟悉,在这个前提下,才会出现质量问题,那么在这个前提下,怎么避免质量问题。
这就好比我们说解决一个问题时,最快的方式是,我们不解决问题,而是解决出问题的人。
在这个项目里不就变成了,我们不解决问题,而是解决出问题的团队了吗。
正是因为这个误区,我们很多时候一出现项目质量问题,就把锅甩给我们团队的协作有问题,或者我们的项目时间紧张,然后一句下次改进就结束了。
这样的万能回答,看似一点没错,但往往就没法落地了。
明明项目时间紧,新团队协作经验不足本来就客观的存在,没有它就没有问题,怎么可以当作真正的问题呢
把问题的前提当作问题的原因,那么我们的复盘就无法转化为可参考的经验,因为前提都不一样了。
再进一步,问题本身是有前提了,改进本身也有前提。
比如上面这个从临时组建,经验不足的项目团队中总结的质量管理经验,往往也是只适合于此类团队本身,一个经验丰富的团队去开发同样了项目,还按这个模式走,时间投入产出比就过了。
因此,当我们去思考一个问题时,不妨多问一句,我们找到的是问题的原因,还是问题的前提?

Comments
Write a Comment