建立大局观

前几天老婆告诉我，发现了我一个缺点，就是太注重细节。于是这几天晚上就在琢磨这个事情，想了几天终于琢磨出些东西，写下来可以提醒自己，顺便做点自我总结。

想了很久关注细节有些什么好处和坏处，想我到底应不应该关注细节。看到很多书上说细节决定成败，失败的很多关键是在一些细节的把握上。然而想想大局的把握也很重要，细节太多了，哪里管的过来，如果把握好大局至少可以让事情的发展不会太离谱。这种问题实在两难，两种说法都有理。

不经意间，我想到了一些自己实际的经历。结合自己的这些经历再想是该关注细节还是更应该把握大局，忽然觉得问题容易了些，也不存在细节与大局的两难之争了。看过 Scott Berkun 的《 The Art of Project Management 》，里面讲项目管理是平衡的艺术，你需要在文档化和口口相传之间取一个平衡，也需要在追求完美的代码设计和功能的快速实现间取一个平衡。其实细节和大局间也需要取一个平衡，但是开展一个项目时，把握大局更重要些，但一些重要的细节也会对项目造成重大影响。说的具体点，就是项目初期制定好计划，对任务进行分解，后期进行进度的跟踪， milestones 的检查，各阶段产物的检查。一些细节问题会在项目计划初期或者开展过程中浮现，例如一些关键技术难题，这种关键的问题及早的发现可以更早的进行应对，可以避免后期项目计划和设计的更改。对于如何圈定这些细节问题，就需要项目组和项目经理根据以往的经验来把握。

能回想起一些细节把握方面的错误经历，需要写下来，以提醒自己以后不重犯。我有时候会忙的忘了去检查项目的进度，这个属于主次不分，有些手头的事情应该放下来，把更多事情放在项目管理方面。亲力亲为身先士卒不总是好事，相反应该努力去让组员去解决这些问题，因为项目经理的价值在于整个项目。也许是小公司固有的特点，几任前辈都像是救火队员，经常需要去解决一下其它员工不能解决的问题。想到这里，对于自己埋身于问题解决中感到有些无奈。真的很钦佩那几位大佬，对他们的能力我仿佛是仰望高山，感叹无法达到这样的高度。不过好在项目组的发展越来越上正轨，技术水平也在不停的提高，所以我现在可能有更多的时间去想产品的功能和项目的管理。又有些时候我在自己做一项功能的过程中，会在发现一些代码不是很好，于是会跑去修改，最后却错过了最初要做的功能的时间进度。完美主义固然好，却要选对时机，不可以忘了自己主要的目的。

对于学习新事务时我也有类似的问题，因为研究细节而导致学习进度慢。看东西的时候我常常需要去注意细节，总得去推敲揣测，经常还要研究些细节才明白。举个例子，看《 COM 本质论》的时候，第一章的概述部分列举了使用 COM 技术的好处，有个优点就是使用 COM 组件可以实现二进制文件的可移植性。用惯了 C++ 的我也就能理解源代码级别的可移植性，二进制级别的可移植性很不能理解，而且我也总记不住 COM 的这个优点。等看完了后续的章节，并找了些 C++ 内存模型方面的书研究完，才明白了为什么 C++ 写的 COM 组件就可以做到二进制级别的可移植性。自从理解了以后，就一下子记住了 COM 技术的这个优点。看很多人能不用看后面章节就把前几章概要部分的内容记下来，我真的很羡慕，因为他们可以在很短的时间内记住重点。可能是记忆模式原因，不太擅长强记型记忆，而更擅长理解型记忆，所以我总是做不到别人那样子。不过好在我能深入浅出，深究了一些细节之后总能跳出来站在比较高的角度总结一下，把比较核心的东西找出来，并且从此可以记得很不错。虽然我对自己这种学习新事物的进度很不满意，但却发现了它的优点。先举一个反面的例子，有个认识人的在中兴通讯做测试，各项步骤记的很清楚，按部就班，也没出什么差错。后来他换了一家公司，同样是做测试，但对新公司测试方面的各项工作都不明白，仿佛都是全新的东西。想了一下，是他没有理解测试，只是记住了日常工作中的一个个步骤。其实，测试的理念和各种思想是相通的，如果想明白了这家公司测试过程中为什么有这么些步骤，那你也会很容易的把另一家公司的过程想明白。我学习通信网络时也有一些经验感受，我看 MGCP 协议的时候花了三个多月时间，等再看基于 MGCP 思想之上扩展的另一个协议 MEGACO 的时候，我差不多只用了两个星期。其实你理解了 MGCP 的模型之后，很容易就能理解 MEGACO 。我在工作中花了三年的时间来彻底理解 VoIP 网络，等我转做移动核心网的时候，发现新的网络模型很容易看明白。为什么呢，因为诸如路由，媒体协商，编解码转换，注册和认证等等的这些概念在各种通信网络里面都很类似。虽然有上面说的好处，但对时间的耗费却是个不争的事实，项目的时间一般都不会允许用这么长的时间去学习新东西，所以快速把握新事物总是充满了诱惑。

总的来说，我对于大局的把握还做的不好，尤其是项目管理方面。所以日后要更加的花心思在这个方面，努力把项目做的更好。