[转]技术人员应真正学会的第二课程

       如果说掌握一门赖以生计的技术是技术人员要学会的第一课的话， 那么， 我觉得， 技术人员要真正学会的第二课，不是技术，而是业务、交流与协作，学会关心其他工作伙伴的工作情况和进展。

 

       为什么这么说呢？ 因为技术人员太容易陷入“孤岛”状态，更注重自己的工作任务的完成，忽视其他工作伙伴的工作，甚至一无所知。 我就一直犯这样的错误。我敢说，对内心我还是比较明白清楚的，但是对外面所发生的事情实在是知之甚少，这不是好的状态。 一个开明、开放的程序员不应该囿于自己狭隘的小天地，而是更广阔地去看待工作和职业，和同伴一起进步和成功。

 

       为什么要关心业务？

 

       很多技术人员都立志成为系统架构师， 那是编程领域的“圣杯级职业”。问题是， 系统架构本身是为了业务需求和扩展而服务的，必须充分理解业务需求和未来的发展趋势，深入理解系统所涉及的数据及分布， 才能作出更可靠的设计决策。如果对业务知之甚少，以为仅靠书上说的那一套，或者以前的零碎经验，就能够胜任的话，那这个项目多半要失败的。 因此，即使立志要成为系统架构师，也要对业务有很深的理解。

 

       其次， 技术的发挥必须有用武之地。如果没有足够强度和有挑战性的业务需求和扩展， 足够多的问题的磨炼，技术的提升又从何谈起？ 仅仅靠阅读那些技术书籍吗？ 那只能提供一个指导的作用罢了；真正还是要在实战中得到提高。

 

       如果一个技术人员对业务不感兴趣，只对技术感兴趣， 那会发生什么事情呢？ 他将只能满足于使用自己所熟悉的技术去完成上面分派下来的任务； 也许今天是做一个系统A， 明天是做另外一个类似的系统B。 他对系统涉及的各种业务都不甚了解，也不清楚行业领域的发展状况， 就只能局限于使用技术来做各种具体的功能，无法提出中肯的建议。他的职业发展将严重耦合于所掌握的技术。如果该技术保持比较长久的生命力，那么， 他还能兵来将挡水来土淹， 但无论如何，也只能局限于成为这门技术的“高级工程师”而已；如果该技术开始被淘汰，那就悲剧了。

 

       換一种方式。如果一个技术人员很关心业务。 那么，经过一段时间的磨练之后，他能够提出中肯的意见，知晓行业领域的发展状况， 在深入理解业务的基础上，同时发展相应的技术专长， 做一个在业务和技术方面并行发展的技术人员。 他的职业发展将不是完全耦合于特定的某种开发技术，而具备了更大的灵活性。

 

      你知道吗？ 三国时期，我最佩服的是徐元直先生。 他是一个技术和业务同样精通的人才； 技术方面， 作战思想丰富， 业务方面， 实际指挥作战和应变能力都很强， 这样的人才， 难怪即使不献一策， 曹操这样的人物也愿意留他在帐下， 让他无功受禄，—— 能够不让他为竞争对手所用就已经是大功一件了。   

 

        

       放下技术情结

 

       技术人员要学会放下心中的“技术情结”。 因为我也是技术人员，也有技术崇拜的倾向， 也能够感受到这种情结带来的益处和束缚。 “技术情结” 表现在哪里呢？ 你期望能够尽可能多尽可能深入地掌握各种技术，这给你带来一种很好的安全感，因为有了强有力的依靠，—— 你对自己的能力充分自信； 但也束缚了一个人的发展： 他的内心容易更加依赖于自己的能力，而对别人的能力抱有怀疑，难以与别人形成优势互补和良好搭档，很难发挥出超出自己能力的能量。

 

       是的， 你学了 C, java, python , Lisp , ....,  还可以列出更长，你还想掌握并发编程，软件架构等等，你的同事却只会C， java 或 python ,  会敲入一些命令， 这样你就舒服了吗？ 感到优越了吗？ 高枕无忧了吗？  成为核心骨干了吗？  

 

       技 术是学无止境的， 一个人的精力却有限，就算一个人在某个领域里非常精通，那么同时也可能意味着这个人在其它方面是孤陋寡闻，“技术牛人” 和 “科学大师” 一样， 可能只是一个美妙的光环，是程序员给自己套上的铁链。不要妄想一揽子全抓在手里， 确立自己的专长， 善于与别人优势互补，良好协作才是。敢于舍弃 “技术情结” 给自己带来的安全感， 才能走出更广阔的空间。  

 

 

       技术人员的通病

 

 

 

 

       大多数技术人员，包括我在内， 都不甚明了自己究竟能够利用计算机做什么。 我们只是年复一年日复一日地学习和使用某种编程语言和技术来写程序，以为这就是利用计算机的唯一的正统方式。你用过MATLAB吗， 一种很强悍的科学计算软件？ 那里一条命令， 就顶一个编程人员几个月的努力。作为一名计算机专业人士， 学习了那么多专业知识，难道仅仅只是为了掌握一两门编程语言和技术来写点程序养家糊口吗？  如果一个程序员懂得去使用一些专业软件，学习一些信息处理、统计分析方法， 那么， 他所能提供的价值可能远远超过一个普通开发者所能提供的价值。具备编程能力和对编程技术的领悟，是技术人员拥有的特别优势， 但并不意味着一个技术人员能够干的活就只是编程。只是，大多数技术人员，由于各种原因，就把自己定位在一名普通的程序开发人员身上， 跳不出“开发人员”的视角。 

 

       我们总是沉迷于重新发明轮子，以及被迫重新发明轮子，用不同的编程语言，或者用同一套技术框架，搭完了管理系统ABCDEFG，再搭HIJKLMN，以 及OPQRSTUVWXYZ， 感觉很有成就感吧？ 不懂尊重和利用别人已有的工作成果，低水平重复建设，耗费大量的时间、精力、人力和资源成本去做那些没有太大意义的事情； 总是沉迷于争论语言、技术之间的孰优孰劣，却甚少关心哪些事当做不当做，甚少关心做那些关键重要的事情有哪些方案以及孰优孰劣；总是沉迷于某款科技产品的 宣传和特性，甚少关心环境问题和儿童失学问题，如果说程序员有什么可怜可恨之处，那绝对不在于这一族自甘被孤立，难以为人所理解， 而在于他们自身的心态就将自己锁在了井底之中，还自以为很与众不同。 

 

       假设你不再为公司编程，而为自己写程序， 你知道自己该干些什么吗？ 你会感到迷茫吗？ 如果我们连自己该干什么能干什么都不清楚， 那么徒有一身武艺，又有什么用呢？ 

 

       大多数技术人员，包括我在内，都还不懂得主动与工作伙伴良好协作，只是因为工作关系而不自觉地交流和协作。不信，在你工作之余的时候，你会主动邀请别人 一起来编程，共同去做一个有用的产品，  还是埋头去学习技术，孤立地去做一些技术实验，来掌握所谓的某门开发技术？  

 

       一个技术人员对于另一个技术人员的认可往往起始于对其技术能力的是否认可。技术人员面试的时候通常会更关注： 他掌握了哪些技术？ 对这些技术的掌握程度如何？  而不是这个人利用自己的技术能力和所学做了哪些影响卓著的事情。这就导致了： 技术人员往往更关注自己的技术能力的发展，而忽视其他能力的培养。

 

       因此，大多数技术人员，包括我在内， 都有四个通病： 一，不清楚自己究竟能够利用计算机做什么，不懂得如何充分利用计算机的真正威力； 二.  不能主动与别人优势互补和良好协作； 三。放不下技术情结； 四.  局限于狭隘的自我优越感，以及伴随而生的强迫症。这四个通病导致一个人永远局限于只见一叶不见林的狭隘视角。   

       

      

 

       真正优秀的技术人才       

 

 

 

 

       作为一名技术人员，你对公司的业务发展能够提出自己的建议吗？ 你有能力说服工作伙伴和主管来采纳你的提议吗？ 能够集思广益，融众人之所长吗？ 我认为，一个真正优秀的技术人才，应当具备这种多方面的能力，除了技术专长，他具备说服能力，集思广益， 能够有力地推动事情的发展。企业也应当提供机会，让技术人员参与更广阔的工作，而不仅仅是写代码和完成需求功能。  

 

 

 

       我相信，从企业聘用人才的角度来说，它们更看重一名技术人才究竟产生了怎样的影响。只是当大量技术人员没有什么可证明自己做过有影响力的事情的情况下， 才不得不求其次，去聘用那些在技术能力上有更高造诣的技术人员； 从技术人员的角度来说，因为他没有什么可以证明自己确实做过有影响力的事情，只好倚靠有限的技术水平为自己寻一个差强人意的安身之所。我觉得， 那些没有做过有影响力的事情的技术人员，相比那些利用自己所学做过有价值的事情的人来说，其职业高度就已经低了一个档次，尽管后者可能在技术能力上要差一 些。

 

       事实上，我敢断言： 中国不缺技术能力优秀的人才，虽然技术级别与国外还差一两个档次， 但还是人才济济的。确实有很多人依然努力成为最好的技术人才，致力于引进国外先进技术。中国缺少的是那些懂得利用计算机能力创造价值、服务和效益的技术人 才。 这种技术人才必须能够放下技术情结，以更开放、开明的心态去与其他的人良好协作，优势互补， 一个真正优秀的产品往往是多个人共同协作完成，孤胆英雄的年代已经过去。即便是一个黑客，如果他能与另一个黑客强强联合， 也能产生出比自己一个人更强大的能量。要知道，苹果至少也是由乔布斯和沃兹尼亚克两个人初创起来的。      

 

 

       要一起进步和成功

 

       最后， 如果一个技术人员通过重重磨难终于成为了很牛级的人物，而他的亲友早已埋没于尘世中，过着一般的日子， 他的成功又有多大意义呢？ 应该聚合所有人的才智和经验，一起创造共赢的结局才对，缺了谁都不行。人生苦短，正是因为一路上有了亲友的陪伴， 才不会寂寞， 人生才不至于苍白。不要只顾着自己一个人往前走路， 把亲友们抛在看不见的后面。

 

     

      PS:   因为本文的非技术成分很高，而且很有点罗嗦， 故将其删除； 后经人提醒， 认为此文还有些价值， 因此又发上来， 希望文中的一二观点能够对大家有所启发。