THINKING AS A LEADER

本文主要是介绍THINKING AS A LEADER，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

THINKING AS A LEADER

大家是否有这样子的一个同感：领导不愧是领导，看问题非常透彻，能够分析到问题的本质。而自己却考虑的很表面，很肤浅。

那是不是因为领导比我们智商高呢？——未必！

那么今天我们来稍稍分析一下这种现象。给大家举两个简单的案例。

故事背景：

人物：员工A、PM、PL

议题：现网问题分析回溯

那么请看这三个角色对同一个问题的考虑和总结

问题1：一个升级脚本的编码格式问题导致升级失败

 

员工A总结很不错，有头有尾，总结了自己有报错日志到定位问题发现问题的全过程，最后得出了问题的原因是：出问题的脚本编码方式不对，正确的应该是

而出错的是：MAC ANSI。之后还有一些发散的思考，就我个人的水平来说，这样子的总结已经很不错了。问题基本说明白，而且还有自己的一些思考，很不错！——其实爱思考的同学这里就已经发现总结缺少了什么（我暂且卖个关子）

听完这个总结有一个收获：清楚了问题以及问题原因

 

然后是PM的一个总结。说实话，在没有听PM对这个问题的总结的时候，我觉得刚刚的总结已经很完善了，问题说的很清楚。但是....，PM的总结就像是做一道数学证明题一样，由因到果，由果到因推断的有理有据：

1.自测的时候是用PLSQL刷脚本，对于sql脚本的单行长度没有限制

2.升级环境刷脚本用的是SQLPLUS。有长度限制，单行最多2499字节。

3.对于换行符的表示，MAC：\r  windows:\n

4.在linux环境下vi打开有问题的脚本发现换行符没有生效，所有的脚本全部挤成一行了。

5.开发人员使用的脚本编辑工具，比如notepad++对两种系统的换行符都兼容，导致开发人员不能够及时的发现脚本的编码方式有问题。

最后大家听完这个报告会有两个收获：

a.把问题很透彻的分析了，涨姿势

b.开发要注意编码方式

貌似PM的分析更有说服力，对问题的理解更深刻一点。

 

最后PL告诉大家，这个问题的原因我们搞清楚了。但是大家没有总结怎样杜绝同类问题，你自测的时候没有问题，用notepad++打开没有问题，自己刷数据库也没有报错，问题往前分析最后知道是因为编码方式导致的。那么大家有没有想一下，当初这个脚本的编码方式为什么会变成了MAC ANSI？（这里有一个我认为不错的思考方式：当定位问题遇到阻塞的时候，不妨往前追根溯源，或许能发现更本质的缘由）——这一点员工没有反思，PM的总结也没有提到。可能各位看官在看员工总结那一段就已经想到了（但是为什么能力不错的员工和PM都漏掉了最重要的一点呢？）

 

问题1：字段携带和接口文档不一致

员工总结的原因大致是两方面原因，一、这是一个很早之前没有给提供接口文档就做了的需求，后面才发现自己实现的和接口文档不一致。然后现在暴露了问题。第二点就是当时没有留下邮件等证据，不能自证清白。

PL给提高一个维度：

1.咱们的目的不是自证清白，我们自身做的也有问题，如果按照正规流程做：没有接口文档就不做这个需求等就不会出问题。

2.有些部件的代码实现和接口文档不一致，我们应及时更新接口文档，避免后人踩坑。

3.正规流程+及时更新的接口文档  差不多就可以解决问题。

 

好，以上就是关于两个问题的讨论。在下文笔有限，描述的不够“生动”，以至于大家觉得好像“你描述的“领导思维”也就一般般嘛，我也能想到这些”。那我这样分析大家看是否在理：你之所以能够和我描述的“领导思维”保持同一个高度那是因为你现在处于一个旁边者第三方的角度来看问题，自然是会客观理智很多。

 

OK，那我们再回到最初的问题，“为什么领导总是能够抓住问题本质？”

1.对，因为领导比起普通员工对这个问题的分析更像是一个“旁观者”的角度；

2.专注，员工会被问题的各种细节分析精力，导致对问题的重点把握不准；

所以，要想具有“领导思维”可以从两方面入手，即：客观和专注。要不然我说怎么会有“回过头来”这个词语呢，回过头再分析一下可能会有意想不到的收获。在我们“回过头来”的时候希望大家执行两个动作：1.保持清醒客观 2.注意力集中 （或者说人们“回过头来”的时候往往就自带客观和专注属性） 肯定就能够对问题有一个更好的认识！回过头来一想，这好像就是我想要传达给大家的：“领导思维”。于是就有了这篇文章的题目：Thinking As a Leader.

这篇关于THINKING AS A LEADER的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---