本文主要是介绍老大语录七 谈问责，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
老大语录七 谈问责
管理者往往需要在出现问题时评判各种事故的对错。但很多时候会陷入一种困局，那就是你会发现在讨论事故责任时，往往各方都会举出不同团队各种层面的问题，进而导致好像说的都没错，各方都有失职。解决方案也变成了大家都有责任，且需要一个详尽完善的制度引入作为事故处理的收场。
这本是司空见惯的事情，但却值得细细深究。
先作一些前期假设。很多团队对一些编排细致，轮转精密的管理流程和制度并不能有很好的执行力。一般会出现前期想的非常详尽，头一两周坚持的到位，但时间一长，很多制度都被遗忘进而变成了沉没成本。这一方面是因为团队素质不可能像军事化一样高，另一方面是因为管理是需要有资源支撑的。团队成本过程中，业务上的成本投入会先于支撑资源的投入。
所以在现实情况下，一般需要坚持简单可落地的原则。也就是流程和制度尽可能的简单以增加落地性。当出现事故，引用现有流程肯定会有第一环节，不论这一环节出现的问题对最终问题影响有多在，都作为第一责任人问责。
有人可能觉得这好像不公平，可能后面的环节风险更大。这也往往是开头说的各方都能提出专业的观点，都是客观的可能会引起项目失败的风险，甚至可能是更核心的原因。但往往考虑太多时，就会发现找不到可解决问题的解。那第一问责制度是否会有效果。
在前面的假设下，在一些特殊的阶段，我们可以只处理一件事情，这样往往会处理的更好。当只执行第一问责时，不论大小，先忽略其它问题。这会给协同工作的多方一个信号，谁都不会愿意自己成为第一责任位置，这个效果会链式的传导，进而让各团队恪守住了自己的职责。当团队中每个组织都守住自己位置没问题时，那结果其实都会是良性的。
大道至简，根据一个简单原原则，进行链式传导。虽然粗暴，但特定时间往往会的奇效，那这也不失为一个好的启示。
这篇关于老大语录七 谈问责的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
