• Feeds

  • 技术工程师的能力与目标

    曾经有这样试验,随机选择一组对象进行工作的自评,几乎所有对象的自评分都在实际成绩的平均分以上。在工程师团队中也不例外,许多工程师有这样的困惑,自己觉得工作已经做得不错,但是上司好像察觉不到,甚至还对自己的工作吹毛求疵。如果有个合适参照标准,工程师或许就可以更好的对自己工作进行自评。

    管理者也同样面临类似困惑,在一个组织中,需要定期对团队中的成员进行考核及晋升,但是考核的标准是什么?小团队中主要取决于管理者的意志;大型组织中流程会更规范,但也存在考核者凭感觉来给被评估者打分的情况,或者是考核者心中的衡量标准千差万别。

    从工程师自我提升追求及职业规划的角度,情况会更复杂。每一个工程师都有不同的追求目标,孟岩有一篇很有影响力的《技术路线的选择重要但不具有决定性》,文中工程师的追求类型被描述成事业目标型、团队精英型、技术高手型、得过且过或养家糊口型四种。文中将“独特的个性知识经验组合”看做是工程师的核心竞争力,不过对于这个经验的组合不同人会有不同的理解。

    从团队或者企业的角度来看,主要从团队的贡献角度来评估技术工程师的成绩,就如同评估一个科学家的成看他看对人类的贡献类似。离开了环境,单纯评估技术没有意义。比如一个技术人员对Linux内核看得滚瓜烂熟,单就这一点并不能看到太大直接价值。

    但是在业界,知识点的重要性通常被放大了,业界也形成了一些非理性的氛围。工程师会努力学习某个技术(如C++语言)的方方面面,即使大部分场合只用到了其中小部分功能。技术管理者在招聘、考核、晋升等过程中也通常把知识点放在一个很重要的地位,面试题中会出现工作中并不常用的领域的各种知识点。

    这跟前几天某条关于大学教育的微博有异曲同工之妙,大学教育经历了全部是知识点的教育,慢慢意识到需要培养的能力不仅是知识点,而主要应是独立思考能力。

    技术人员追求的也不仅是知识点,而是在专业领域正确做事的方法及达成目标的能力。两个同时入职的员工,一段时间后技术好的那个就发展得好吗?还是有更好做事方法及能达成目标的人更容易得到认可?

    我认为一个好的工程师必要的能力

    设计能力

    设计能力参见前文技术评审中关于设计的描述,简要的说就是具备设计简洁、易于扩展及维护的功能及特性能力。

    需要补充一个设计方面的anti-pattern,选择合适的技术及架构,意味着不引入及增加不必要的抽象层或框架,并提供高质量、稳定、高效、安全的代码。不少能力还不错的人员有这个缺点,一个简单的项目,出于追求流行或者对于某项技术的崇拜心理,引入了复杂的技术或框架,对于个人来说确实提高了见识,增加了业内交流的资本,但是对于组织来说这种锻炼却是团队成效的噩梦,对于技术从业人员来说,不盲目引入不必要的高深技术来保证项目进展是一种基本的职业素养。

    此外设计中还有一个隐含的条件,就是选择的方案能相对减少开发周期,加快交付时间。也就是下一点介绍的。

    交付能力

    通俗的说就是不管发生了什么,都能按时交付。
    充分考虑自身技术能力、项目依赖、队员排期冲突、负面情绪、技术方案风险、未预知的技术障碍、需求变化等。
    具备为功能的设计做取舍的能力,但功能取舍并不以牺牲产品的核心愿景为前提。

    规范与协作

    在编码前能够完成模块或特性的清晰架构或设计文档,并保持在开发过程以及代码重构过程中文档的一致性。
    推动及促进团队的代码及设计规范,并确保执行过程中与规范的一致,并能根据实际情况对流程及规范提供优化建议。
    编写的代码通常当做团队的模板或者是最佳实践的设计模式。

    团队效率贡献

    有改善团队效率方面的贡献吗?比如做一个相似项目为何周期很长?为什么开发完成之后又花了比开发周期更长的时间调试或修改bug?
    推进代码复用,你的代码和工具其他小组或部门愿意用吗,准备让他们用吗?有推动让他们用吗?
    自动化体系来帮助提高测试、开发、debug、跟踪用户问题的效率
    能够用服务化的方法来解决异构、多版本问题
    有优化流程贡献?

    已经不是那个独行侠或个人技术英雄的时代了,融入团队,多考虑对团队的贡献,更容易得到成长。

    后记:职业发展方面话题比较大,不容易写好,本文也写得比较辛苦,改了两个晚上,暂不写类似话题。这也再次说明,当你有一个非常大的愿景(想当青年导师?),但系统能力还跟不上时,更应从小处着手。

    如想及时阅读Tim Yang的文章,可通过页面右上方扫码订阅最新更新。

    « | »

    28 Comments  »

    1. 很不错,学习了!

    2. yjf512

      好文章,学习了

    3. 后记是说基础(细节)真的很重要!

    4. Magic

      文章被cnBeta盗了,还没写出处。
      http://www.cnbeta.com/articles/173947.htm

    5. ZhangLI

      “已经不是那个独行侠或个人技术英雄的时代了”
      —是啊,很多技术人都只考虑个人的效率而忽视团队的效率!

    6. 非常认同TimYang的观点,后述话题会有很大的延伸,比如说如何达到按时交付项目,这跟WBS息息相关,而且本人一直极力推广的就是以最简洁明了的代码来实现最复杂的功能,越简洁越能体现水平,如果单纯为了体现个人技术高超而故意把其复杂化的,其实就是低水平的表现。

    7. Andrew li

      1. 不影响团队协作
      2. 具备引领团队之才能
      3. 具有创新意识
      4. 个人效率
      四者结合便是上等人才

    8. Daniel Qian

      没错,团队协作能力特别重要,程序员内向、不善交流的形象需要被改变

    9. 没看明白配图和文章有何联系…这是配图党么…

    10. 想知道配图那本书叫啥名字。

    11. @Edison tsai:复杂的并不是代码,所以单纯追求简洁没有意义

    12. mcy

      @krashna
      《苹果往事》吧 http://book.douban.com/subject/4214837/

    13. 李毅

      希望以后有机会在珠三角技术交流会上见到杨大师。

    14. 无语抡笔

      辛苦了,感谢分享这么好的内容。实际上技术性人才的通病无非就是偏执以及“掌握XX技术就能XXX”的错误认识。现在不少公司面试的时候都侧重考查“用过哪种技术”或者“有过什么经验”,不过小弟一直认为学习能力以及执行能力才是一个人最核心的价值所在,可惜通过一个短短的面试很难了解全面。

    15. lxrm

      感谢分享,很多点,感触很深。平时最容易犯的错误就是,为了解决一个小问题,引入的东西太复杂,反而降低效率了贡献,甚至延迟了交付日期,所以,不可以不重视啊。日参省乎己!

    16. 感触量多

    17. 很有启发

    18. sunny

      加入有道笔记,仔细琢磨这个问题。

    Leave a Comment