你的位置:首页 > ASP.net教程

[ASP.net教程]技术人员的疆域


郑昀

从初中级走向中高级、走向技术专家的过程,必然伴随着价值观输出。

 

为什么?

因为伴随着你越来越有 Power,越来越有 Experience,你一定会时不时输出一下价值观。你的疆域不再只是你写的代码,你负责的工程。限制你的仅仅是你的意愿和行动力。

 

什么是输出价值观?

  • 分享你分析问题、解决问题的过程,譬如主动撰写RCA报告;

  • 把经过自己深入思考、有了透彻理解的技术方案清晰明了地介绍给其他人;

  • 引入或建议团队引入提升工作效率、简化流程的以下事物:

    • 框架

    • 构建工具

    • 工具

    • 中间件

    • 理念

    • 最佳实践

    • ……

  • 积极参与Code Review

  • 在设计评审会上积极发言

  • 积极帮其他人调查技术问题

  • 主动承担系分工作

  • 看到目前系统中的不足,主动承担开发模块、外围支撑系统或中间件的重任

  • 看到团队一而再再而三地犯同样的错误,主动组织大家培训

  • 主动申请做新人的导师,对新人的工作质量负责

  • 主动撰写某个领域的最佳实践,并在团队内布道

  • ……

  • 你能想到输出你的价值观的其他事,小到技术团队内部,大到业界

 

我们内部有一份《研发P序列晋升评审表》,仔细读过之后你会发现它们背后隐含的就是『你有没有输出你的价值观』和『你输出价值观的功率有多大』

 

我们研发的晋级晋升基本上都需要过评审会,给P8以上的人一个机会,面对面挑战你的机会。

 

2011年,我在内部飞行研讨会上说:

         别人听不懂,那多半是因为你讲不清楚,你讲不清楚,往往是你一没听懂、二没想清楚。(所以你没逻辑。)

 

很多人会搬出“Talk is cheap, show me your code”的挡箭牌,说能 coding 就行。

我们是在一个协同性很强的(庞大)团队里,有产品有研发有测试有运维有运营,大多数场景下,不管你是P5、P6还是P7、P8,对外你需要公开地阐述清楚你对业务的理解和实现逻辑,用简单明了的语言挑战产品和运营,对内你更需要讲清楚实现细节,讲清楚故障原理。你横竖不可能让产品和测试看你的代码吧。

吭哧吭哧说半天,词不达意,细节模糊,也不会画辅助图(调用关系图、业务流程图、时序图、泳道图……),那你怎么自证靠谱?

这是外部逼迫你要搞清楚技术细节和原理,要能公开地清晰表达。

 

内在逼迫你的是学习金字塔原理:

为什么要写出来、讲出来呢?

因为有一个学习金字塔理论,如下图所示:

学习金字塔

 

我们读过的事情能够记住学习内容的10%,

我们听过的事情能够记住20%,

我们看过的事情能够记住30%,

我们听过和看过的事情能够记住50%——如看影像/看展览/看演示/现场观摩,

我们说过的事情能够记住70%——如参与讨论/发言,

我们说过和做过的事情能够记住90%——如做报告,给别人讲,亲身体验,动手做。

这也就是我在《我们过去几年做对了哪些事》中阐述的管理方法:我们从入职之后就(要)有意识地训练大家,让大家能够公开陈述、清晰表达。所以,试用期内,新人必须做一次技术分享和一次技术评审,面对各方的 challenge;预研的中间和结尾都要有分享会;平时也要定期组织技术讲座。

 

国家体操队有一幅标语:上级逼,下级逼,互相逼,自我逼。

如果你懒,

如果你杂事儿太多,

如果你没时间,没环境,

那么怎么逼你?

 

各位 Leader 一定要审视自己的队友,把那些藏在后面不露头的人叫出来,内部开讲,内部多挑战多提问,多做设计评审和CodeReview,不要求你涉猎旁通,经你手的每一件事总能公开地、流畅地表达吧。

讲给一块做过的自己人听能听懂,这不叫本事。

讲给没做过、不知道技术概念和术语的人听,他听懂了,那才叫本事。

讲给“小白”产品经理听,他能听懂,那才叫“清晰表达”。

 

留一个课后作业,大家回去跟自己的另一半讲一遍,争取让对方听明白:

RSA加密和RSA签名有什么区别,各自发生在什么场景下?

 

++请倾听我们过去几年做对了哪些事情++

-EOF-

欢迎订阅我的微信订阅号『老兵笔记』,请扫描二维码关注:
老兵笔记订阅号二维码
转载时请注明“转载自旁观者-博客园”或者给出本文的原始链接。