这是一个「开发」与「产品」之间的故事
一家再平常不过的公司，产品负责提需求、反馈客户意见，开发负责需求实现。在某个阶段会议上，经理问起客户一项需求的进展。开发说产品没有确认需求，产品答客户一直拿不定主意，最近刚刚选择了初版的方案。经理大为光火，责问开发为何不把初版方案先落实，呵斥产品为何不先把初版方案推进下去，因为交付时间越来越近了。
这是一个普通文员的故事
临近下班前主管要求她打印一份资料，又告知资料需要改动，随即又安排她忙别的事情，但忙完后已过了下班时间，打印这件事于是被耽误了。第二天等拿到改好的资料，不巧打印机故障。这时领导会议中正好需要该份资料，闹得领导十分不愉快，责问该文员为何前一天不准备好，为什么不事先追问下资料是否改好？
这是一个悲情销售的故事
因为没有及时跟进，销售丢了一个合同。老板生气地质问为何没有及时跟进，销售回答「三天前联系过，当时还没有消息」。老板训斥「为什么两天前不联系客户？」，销售哑口无言。
看完这三个小故事，绝大多数人可能会同意经理、主管和老板的意见——「是呀，为什么不提前做好呢，如果早点解决，不就没有后面的问题么？所以，都是下属的错！」
问题发生之后，我们可能会说，要是当初如何就好了，要是当初不那样就好了。
这种想法于事无补，尽管我们的确可以从中学到教训，但如果因为这种想法而对下属论责就非常可笑。因为问题在发生之前都不叫问题，毕竟我们如果知道了，一定会采取措施。所以事前需要提防的是那些无法预见的风险，管理者称之为「风险控制」。那么问题又来了，既然这些风险事前无法预计，又如何让下属进行「风险控制」呢？
拿上面的例子来说，开发和产品如何才能提前知道客户会选择哪个方案呢？文员怎样才能预计到打印机明天会故障？除非销售每时每刻都盯着客户的想法，否则他也不会知道客户什么时候改变主意，并且他还要另外承担过于紧密的联系会让客户排斥的风险。
那些管理者斥责下属当时为什么没有这么做，是因为当初他们无法预计到这些问题。而管理者能看到这些问题，是因为他们已经知道事情的结果了，所以这种「马后炮」式的论责方式十分无理。
管理者这么做的出发点，是只想要个完美的结果，他们犯了「唯结果论」的错误。这种做法完全是从结果倒推原因，这是一种推卸责任的做法。如果你也同意管理者们的做法，那么你也犯了同样的错误。
因为事后看，总是很容易就能找到问题在哪里，这时候提出「解决方案」顺理成章就成为了下属的问题，于是很多人感叹「管理太好做了，反正错了都是别人的。」
那么什么是管理者应该做的呢？
工作中的角色划分是为了提高效率，因为每个人都有自己的擅长和职责。管理者的职责就是让其他人更好地发挥作用，所以给他们创造好的工作条件是管理者最基本的职责。而工作中各角色之间有大量的工作流（信息）需要处理，如何让这些工作流更顺畅地流动，就体现出一名管理者的能力。
正确的做法是什么呢？是建立一个高效的管理模式，沿着这个模式可以预防大多数问题，并不断依据新发现的问题优化这个管理模式；而不是于事无补地「事后诸葛亮」般的指责，不是「马后炮」地责问为什么当初不如何？因为这样的预防措施谁都能看出来，如果管理者不想被当作傻瓜，那么明智的做法是建立这个高效的管理模式，而不是事后论责。
拿上述的三个故事为例，什么是更合理的管理模式呢？
经理应该规范「客户」与「产品」之间的沟通，减少随意的需求，并且内部将产品与开发的工作流制度化，用流程化的制度避免误解和推诿的产生。
主管既然知道该份文件的重要性，就应该建立绿色通道，让重要文件重点落实，并承担工作流的监控任务。
老板既然看重合同的成交，就应该给这位销售一份清单，让他知晓保持客户沟通应该注意的方方面面。
如此看来，如果这些管理者能够建立起更合理的管理模式，是不是要比仅仅指责「为什么当初不如何？」更受下属尊敬呢？并且他们也不需要再「马后炮」了。
网友评论