鹤啸九天 自律更自由,平凡不平庸 Less is More

如何营造团队技术氛围-How-to-shape-technical-environment

2020-07-03
鹤啸九天
阅读量

Notes(温馨提示):

  1. ★ 首次阅读建议浏览:导航指南, 或划到本页末尾, 或直接点击跳转, 查看全站导航图
  2. 右上角工具条搜索文章,右下角二维码关注微信公众号(鹤啸九天),底栏分享、赞赏、评论
  3. ★ 转载请注明文章来源,知识点积累起来不容易,水滴石穿,绳锯木断,谢谢理解
  4. ★ 如有疑问,邮件讨论,欢迎贡献优质资料


工程师成长之路

【2021-5-12】算法工程师的三个层次

  • 第一个层次:operating 使用工具,了解深度学习,tf工具,github上下载代码,跑通业务数据,完成分类、推荐、预估等问题
  • 第二个层次:optimization 改造模型,深入了解机器学习的原理和组件,熟练掌握最优化方法
  • 第三个层次:objective 定义问题,能够构造准确、可解、优雅的目标函数

什么是人才?

什么是好的人才?

我在前文中写过自己总结的S、A、B、C级人才定义

  • S级人才:心里有火,眼里有光,找方向、带队伍、卷出一片天
    • 不用告诉他干啥,他来告诉你该干啥。宏观战略到细节战术执行到抓团队结果;发现问题,能自己评估优先级,解决完了还会同步你;学习和进步的速度超过想象,经常感觉卧槽怎么这么厉害;自己能搭起来一个好团队
  • A级人才:能打胜仗,作风优良。
    • 能了解并确认你背后的原因和交付物,还往往会多做好几步,产出优秀,及时同步,老板不用追截止日期和进度;定战术到抓结果;发现问题,会和leader确认优先级和方案以后解决问题,之后会复盘如何改进;会有意识的去学习;能配合HR吸引到好人才
  • B类人:是各公司内卷和衰落之源
    • 简历很好看,名校大厂,历次跳槽涨了很多薪水,状态就两个字:油腻。各家一旦加速招聘,都会堆积很多B类人,极大稀释组织人才密度。产出不稳定,及格边缘徘徊,喜欢讨价还价指标,不愿意做份外工作,你不催他不动,有时候还可能没搞好或忘了,不问不会同步进展;发现问题等着别人给流程/推动,leader给了解决方案以后,就照做;不太喜欢学新东西,偶尔学;通常招进来C类人
  • C类打工人:推三下,动两下,牢骚一句。
    • 经常自己独立搞不定,需要别人盯很紧和协助,绝不做份外工作;发现问题就抱怨leader能力不够,抱怨公司不重视,吐槽流程吐槽管理,自己就是不去推动;发到眼前的学习材料也都懒得点开看,封闭/躺平心态;通常招进来比自己更差的人

关键核心负责人岗位、高杠杆/影响范围大的岗位(如产品经理)以及有招人权限的岗位,一定尽量找S或A级的,B和C级人才是STRONG NO。因为这些岗位招错人不仅仅是他的工资,更多是机会成本,往往导致整个业务时间被耽误。

怎么识人?

大部分面试官喜欢招有强相关经验的人,因为短期产出高,而忽略自驱力等基本素质,导致长期组织内堆积B/C级人才,而他们又容易招进来比自己更差的人,开出了孽之花,恶性增强回路。

招人是CEO和每一层leader的事儿,而不仅仅是HR的事儿。不仅要为岗位招聘,还要为公司招聘,为公司招到文化匹配的人才。如果有个人能力意愿都很强,但是现在没HC,为公司招聘的人会努力推动他进来。

对于核心关键人才,花了多久时间面试?是不是合伙人级别的人面试1小时就完事儿了?对于普通正式员工,在公司<500人的时候,面到了CEO/合伙人-1了吗?

自驱最重要

招人最简单莫过于招干过这个事的人 。不过能找到最具合适特质的人更重要。特别是创新企业,很多岗位未必有成熟的人对应,或者业界的普通标准并不 特别适合,或者具体的岗位有一些特别的要求。这时候通过对岗位的理解而去招 具备性格技能爱好特质的人就特别重要。—— 张一鸣

ASK模型

再引用一下BOSS直聘CEO赵鹏教我的ASK模型:

  • Ability(底层软素质,爹娘给的),Skill(技能),Knowledge(知识)
  • 要万分警惕:多数面试只问了K和S,没有问A。软素质不行,硬技能再高也不能要,这个坑我们踩了上百次
  • 一二线厂积累的 Skill 就要很小心,可能只有 Skill 没有软素质,彼之蜜糖,我之砒霜
  • S级的人,强主要强在Ability

Ability:聪明 正直 勤奋 上进 普世价值观 逻辑 常识通识 自驱 (这是八条,8 plus+1) + 有感恩之心。这里面我认为最重要的是自驱.

所以其实对于互联网公司这种主要靠脑汁的地方,对于核心关键岗位,我们面试和招人的时候主要还是应该考察 Ability,大部分公司就是被镀金大厂简历B级人才,Skill强 Ability弱 的人坑了;有Ability,进来再学 Skill 和 Knowledge 都很快。

复盘来看我们公司一些绩效差员工的bad case,很多都是能力(这里重点指工作相关的skill)够,但意愿(自驱力)不足的。所以一般遇到员工问题,我都会想这是能力问题还是意愿问题,区别S/A级人才和B/C级人才最主要的地方也是意愿,能力不足可以培养,也可以挪到其他更合适的岗位试试,意愿不够往往扶不上墙。

Ability(特别是自驱力)怎么考察?

自驱力

  • 克服过最大的挑战/困难/苦是什么?
    • 如果没有或很弱,通常是过去做的事情挑战不够
    • 重点观察如何解决问题的
  • 最近几年的目标是什么?有为这个目标付出过什么?有大概路径吗?
    • 有目标但行动很差的=光说不练=减分
    • 没有目标/目标模糊/路径不清晰 = 减分
  • 一般几点到公司几点走?
    • 我很少见到不勤奋能做好工作的,但这不是deal-breaker;加班多≠自驱力强,也有加班多但产出很差的,只是自驱的人从概率看通常工作时间比较长
    • 14年张一鸣在找潜在并购公司的时候找我聊,最后问了我一句,你们公司加班多吗?
    • 对于IC(Individual Contributor 个人)来说主要看勤奋;对于TL(Team Leader)主要看能多大程度调动团队产能,一般问团队工作时长情况
  • 有什么主动改进工作/改变公司,并有一定结果的case吗?
    • 自驱力更多是有没有意愿主动去改进工作
    • 关注主动自己想改进还是leader安排的任务
    • 改进工作指把本质份内工作搞得更好;改变公司指的是分外工作,但感觉公司需要,就主动去优化

其他能力

  • 问一个你擅长,但他大概率不擅长的问题
    • 候选人准备过的问题可能是团队智慧的结晶,而非个人思考;这个是随机题,候选人很难准备到
    • 不预期答得对,看回答的思路,逻辑
    • 反应速度、考虑问题周全程度通常和聪明程度正相关
  • 过去一年,有什么进步/高价值认知/改变/收获吗?最后悔什么?
    • 看反思、复盘、总结的能力
    • 看是否喜欢主动思考
  • 为什么离职?
    • 吐槽一堆前公司问题,自己一点问题都没有,完全不说一句前公司好话的,通常没有感恩之心
  • 人生意义/使命是什么?
    • 遇到S级/超强招的人才可以问下,看下底层价值观是啥,看在乎啥,将来纳入麾下怎么能更好的知人善任激励他

领导力

  • 问bad case咋解决的?如怎么降低delay,排期评估有水分怎么压缩,差绩效员工怎么办等
  • 团队的人大概多少是自己招的多少是HR招的?
  • 团队的人大概背景是啥样?(有不少人说自己团队特别好,展开说下背景发现其实很一般)
  • 喜欢用什么样的人?(看对人才的理解到哪个层次,喜欢用Ability强的还是Skill强的)

最怕B类人,觉得过去的经验是真理,不开放心态,说服成本特别高,甚至阳奉阴违,搞大厂生存那一套,非常耽误事儿。

考察专业部分 - 要先提升自己的认知

有时候你可能不是这个领域的专家,快速升级的办法是去把这个领域最好的人聊一圈,不要困在peer里和常规招聘渠道能触及的候选人里。最好是和超过普通想象力的顶级专家去聊:比如和厉害的CEO去请教怎么招人,和大厂高管问怎么思考问题,和优秀投资人聊他见过的CEO谁比较好,为啥… 如果你没有「卧槽,原来是这样」的感慨,那就是聊的人还不够强,还没有显著超越你的认知。不要天天就和原来的圈子聊,发现大家都差不多,觉得自己做的还挺好,世界变了都不知道。

同事问,「那人家为什么愿意见我呢?我能给人家带来啥?」

我说:「你啥也不需要。有个积极向上的年轻人找你聊,如果这个人还有点意思,你也可能会愿意帮忙的呀。」一颗赤子上进之心就够了。

聊完以后回来写笔记,思考,复盘。我和Max经常和别人聊完回来不仅写笔记还复盘讨论,画白板,看哪些适合我们。注意,很多武功基本要学一套,就学碎片容易走偏,也得看这武功是不是适合自己的阶段。

如果不是成熟领域,比如社区/社交产品,那就去把能找到的最好的文章扫一遍,最好找穿越一定周期的文章,带着脑子看,写笔记。

不能把别人说的和白纸黑字印着的都当真理,带着脑子🧠思考,聊几圈看几圈以后,会发现有的文章的局限性,有的人困在自己的经验里,啥是更接近本质或者接近更优解的,会逐渐清晰。

很多时候大家往往没有先去调研顶级人才咋看问题想问题的,直接上来就面试候选人了,然后就容易接触到世面上流通性最强的普通候选人,对「好」对认知可能就有偏差,很明显不是10年以上名厂经验/贵就是好;即便自己大概知道啥是好,但没有真的见过,就会容易怀疑自己是不是要求太高,凑合先把干活的招进来先用着再说。

Skill 和 Knowledge(专业能力)怎么考察?

必考题——最满意/有成就感/高光的case简单分享一下?

问得深远比问得多重要,就一个case问穿;经常会看到初面强招,终面我不招的候选人,就是初面面试官问了一些case但浮于表面,我深入一扒拉发现根本不行。case不在多,在于讲得是不是到位,如果没说到位要追问,重点是校验真实性,比如是他就是边缘参与的还是主要贡献者,为啥做、做了啥、怎么做、做完以后咋样了能不能讲清楚

最高光的case一般都是准备过的,这个问题是直接打在候选人最强肌肉上的,答不好就可以直接pass了,在及格边缘的最多再给一次机会。

  • 思考深度:最好的回答能包括做的结果,为什么做(背景和决策过程,解决了本质问题和做了本质解吗,还是解决的问题就不重要),做了啥,怎么做(解题思路和过程,优雅精巧聪明解还是其实没解决问题)、做完以后咋样(影响范围,是否闭环)
    • i. 如果答得还行,可追问思想实验,复盘再来一次机会,还做不做这个决策,为什么,怎么改进
    • ii. 也可以问关于这个case,你想到的问题/更好的解决方案,看看候选人怎么看,有没想过这些,有没超越你的认知
  • 看数能力:一定不能假设工作经验多/工资高的候选人就默认懂很多基础问题,我们就遇到过:
    • 产品经理面试对于感性理解问题都说得很好的,结果问啥是留存不知道,如瞎编一个次留1%,甚至自己就是做数据后台的产品经理,自己完全不去看;
    • 招聘的HR问关键漏斗转化率完全没概念的
    • TL对团队月均offer和入职搞不清的;
    • 数据分析师/UG/优化师对核心基础数据指标对不上,比如A*B=C的,你把ABC分别问了以后自己算一下,发现对不上,你再问他为啥对不上,他就说噢噢可能记错了那是xxx,或是你估计说错一个数问刚刚你说的A是不是A撇呀,他也会说是😅
  • 诚信正直:不懂就说不懂,团队产出就说是团队产出
  • 沟通能力:总分总简洁到位,还是罗里吧嗦没重点
  • 逻辑能力:是否自洽,能不能真正归因;别小看这个,很多人都在瞎归因,经不起推敲
  • 看成就动机:看他被什么驱动(drive),这很关键,是知人善任的重要抓手,如果恰好和这个岗位需要所匹配,为上乘
    • 可以总结一下你理解候选人为什么觉得这个case有成就感的地方(如涨幅大/成长快/项目复杂性高/需要协调推动的部门多等)去问候选人是不是这样,有可能不一定理解对了
    • 如果不管说啥都👀都没光都不high,那可以pass;注意是面试过程中个体时间线上比较情绪/状态差异,每个人性格不同,不需要预期手舞足蹈很兴奋

选问题——我们现在有个问题xxx,你怎么看/建议?

如果case讲得比较好,可以追问这题,看候选人解题思路如何,有没有一些自洽/超过你认知的见解

可以暴露出来公司的真正问题,降低候选人入职后的落差感

要招多好的人?

是够用就行还是尽量好?很多老板/leader嘴上说当然招尽量好的,但身体很诚实一直招的是够用就行

  • 巴菲特说,不想持有10年的股票,也不要持有10天。我觉得招人也是一个道理,特别对于重要岗位,不想一起工作3年的人,也不应该招进来3个月试试看。

  • (1)从0到1,P/MF前阶段,核心团队找能招来的最好
    • 看业务核心是哪几个岗位,这几个岗位的负责人尽量Ability强,通才优于专才,素质优于经验和技巧,聪明想干事业的年轻人远优于油腻/丧失信仰的职业人。认可你这个人/你们团队,比认可事儿更重要。因为这个阶段往往不会那么顺利,往往不是ups and downs, 是up and down down down down😂 业务都甚至可能会调整。如果候选人只是为了钱/快速增长来的,那一旦不如预期增速容易鸟兽散
    • 找你喜欢的人,看着顺眼聊得来的人,最简单的检验方法是看你想不想下班以后和他出去喝一杯。之前周航说「你只能管理你喜欢的人」,因为在工作过程中,你的微表情经常偷偷出卖了你
    • 如果是创业公司,找真的想创业,探索,做好心理准备,甚至是失败过/挫折过的最好(失败过,但是苦大仇不深的最好),公司就像一个社区产品,早期员工等于种子用户,如果苗子不对,是长不了大树的。OYO中国找了很多贵的人,砸钱不眨眼,然而结果做得非常差,因为贵不等于好,贵也不等于不油腻,公司核心的种子用户不对,后面长出来的就不可能好
  • (2)从1到100,放量增长阶段,找超过想象力的最好的!
    • 通常大家还是被想象力限制住的多。永远不要被薪水/对方现在的职级限制想象力去接触好的人,人再贵也比投放便宜,何况还都可以谈;人职位再高,也有看机会的一天。根据工种不同,越是创造性岗位,好的人比普通人的价值高的倍数越多。比尔盖茨说过,软件时代,就是S级人才是普通人才的很多倍,因为边际效益高。字节从比较早期开始就经常动不动挖小公司CEO,这一点真的很值得敬佩
  • 📌自测题
    • 一个岗位有两个候选人,面试观察 Skill 和 Knowledge一样,一个工作经验1年,一个5年,应该选哪个?
    • 一个岗位有两个候选人,一个1年工作经验,面试观察 Skill 和 Knowledge 比较低,Ability强;一个5年工作经验,Skill 和 Knowledge 比较强,Ability 弱,应该选哪个?

给多少钱

用投资的心态去想这个问题,投公司最重要的是看商业价值企业文化,看的是未来现金流折现,那么投人(招人)要看什么?要看ASK,看能力和意愿,看的是为未来产出价值折现。我们之所以开的工资不如股票价格那么高PE(市盈率倍数),是因为未来产出归零(人才离职)的概率通常会比股票更高。

按照上述逻辑,Ability(原生通用爹妈给的能力)是最重要的,特别是自驱力,那么在同等条件下,比市场价高一些的价格给到自驱和潜力高(未来产出价值折现高)的人,ROI是比为Skill(短期可以习得的经验)买单而更高的。这样也会更有可能吸引到好的人和让他工作产出更稳定。

  • S/A级人才付溢价绝对值得,因为通常未来产出价值更高;
  • B/C类人才的隐形成本是降低人才密度而提升的管理成本、可能过一段时间跟不上发展需要替换的招人成本、耽误业务发展的机会成本,给业务挖坑后面一堆人给他填坑甚至是负向收益。

越早期,雇主品牌越弱的公司,付出的薪酬成本越高是正常的。我有个很好的猎头公司 ITerGet 老板朋友@张正泉 分享过一个33岁的候选人面临的真实case,在大厂3.7万月薪和小厂10万月薪中纠结,非常有趣又残酷。创业公司高管和老板们一看都觉得很震撼,感慨创业公司的钱真不是钱啊!但是你再带入这个候选人心里想一想,快到35岁了,可能要稳定,要简历好看,没去过大厂想看看是啥样想学习下,很常见。

注意不是要无脑用钱砸名企/名校背景的人,段永平说过,捷径是最远的路。

比如OYO中国、乐视和当年的Groupon中国都是典型反例,疯狂用高薪反而容易反向筛选到贪财短视,而非鸿鹄之志者。因为钱而爱上你的人,哪天觉得你没钱了,通常会先走一步,很难一起穿越周期。

对于关键岗位,应当多为Ability买单付溢价,少Skill和Knowledge买单。部分特别需要长期习得经验或市场稀缺的岗位除外。

📌 候选人定薪/定级

  • 核心/高杠杆岗位:70% Ability + 20% Skill + 10% Knowledge
  • 基层/执行岗位:20% Ability + 70% Skill + 10% Knowledge

如何提升影响力

主要渠道:

  • 技术博客:流量
  • 自媒体
    • B站、头条号、抖音等
    • 公众号、知乎等
  • 开源项目:公布到Github,多少颗星星
  • 发明专利:国内专利、国际专利
  • 顶会论文:ACL、CVPR、EMNLP、AAAI等
  • 知名竞赛,如:MCM、ACM、Kaggle、天池大赛等
  • 行业论坛:QCon、InfoQ、AI大会等
  • 书籍:

  • 图片格式(路径中不能有中文!)

技术影响力提升途径

已有经验?
技术人的方法论
wangqiwen
2020.7.4
完全自建
没有
做得怎么样?
调研报告
文献综述
评测报告
可以优化吗
直接用
适配优化
不错
能不能直接用?
部分可用
不行
需求
项目排期
工程落地
稳定安全
不能
可以
不可以
提供方
反馈

个人技术积累

技术影响力
技术博客
技术竞赛
论文
专利
实战
技术交流
自媒体
头条号
B站
Kaggle
ACM
MCM
CSDN
知乎
个人博客
YouTube
InfoQ
Qcon
AI培训
顶会论文
书籍
开源工具
Demo
如何提升技术影响力
wangqiwen
2020.7.4
国内
国际

技术&业务&管理

技术
业务
管理
骨干
技术lead
项目经理
总监
技术&业务&管理

管理者的工作内容

  • 管理者的目标和工作结果主要体现在两方面:
    • 做事:成本、效率、质量。
    • 带人:人才、梯队、成长。
  • 太抽象?其实管理者大部分工作都在选择和权限,主要包含以下几个方面:
    • 有限资源的限定下,选择最大化的产出方案。
    • 做出符合当前环境的技术决策,帮助公司产品取得成功。
    • 用方法和工具不断优化和提升生产效率和质量。
    • 图解:
      • 公司 A 在创业期,还没有稳定的市场和客户,这个时候技术管理者的决策要倾向成本+效率,技术团队偏向全栈型,工作流偏敏捷,快速交付功能获取用户和市场的反馈用于升级和迭代产品。
      • 公司 B 在成熟期,有固定的市场和客户,行业已经没有新的蛋糕,这个时候需要比拼的就是效率+质量,技术团队偏向专家型,注重产品质量和客户体验用于形成行业口碑和用户粘性。

技术leader要具备什么样的能力

  • 技术 Leader 需要哪几个比较重要的综合能力:
    • 技术能力和基础知识(能看懂技术表象背后的原理)。
      • 工作内容大多包含:技术选型,技术方案评审,代码审查,技术氛围的营造。
      • 非技术背景的leader,可能无法和技术团队建立共识,沟通成本极高,最终让团队变成一个非常低效的组织,人浮于事
    • 沟通表达能力(逻辑,同理心,情绪控制)。
    • 业务抽象能力(架构和演化)。
  • 如何锻炼这些能力?
    • 吃透基础技术和弄懂技术背后的原理

      (万丈高楼平地起,再流行的框架和技术,剥离华丽的外衣也离不开操作系统,网络,数据结构这些原理型的知识)。

    • 了解细节,永远在写代码

      (不熟悉代码就无法提出真正可落地的方案,就无法感知技术团队的痛点在哪里,也就无法团队提高效能)。

    • 持续的学习,持续的为团队带来新的知识和理解

      (技术 Leader 已经是团队技术问题的终结者,不可能再上传递了,所以不要成为技术团队的天花板)。

    • 有一个真心帮助大家的心态(帮助大家成长,提高效能,最终组织效能也得到提高,实现共赢的局面)。

工程师→leader的转变

  • 工程师到团队 Leader 有哪些转变
    • 工程师视角
      • 这个功能怎么做?
      • 需求写完,今天的工作就完成了。
      • 业余时间只看技术相关的内容。
      • 看看今天领导分配了什么工作给我。
    • 技术 Leader 视角
      • 现阶段要做什么?
      • 团队未来向哪里发展?团队成长不如预期怎么办?公司今年的业绩指标如何可以完成?
      • 除了技术,还需要沟通,判断,组织,协调,看方向的能力。
      • 规划 Q1 季度的工作目标,分解到团队成员去实施,保证工作内容和每个团队成员的能力相匹配。
    • 相对于工程师工作内容的“明确性”,管理者的大部分工作是“不确定性”的,而且没有尽头,也没有一个明确的时间用于标示“完成”状态,这对于习惯“确定性”思维的工程师来说,挑战极大。
    • 比喻:写代码时候的感受是一人吃饱全家不饿,轻松且自由,现在感受是既当爹(做事),又当妈(带人),而且还上有老(上级),下有小(团队),感觉压力山大!!

如何营造团队氛围

  • 程序员的工作大多是本质知识工作者,管理学大师彼得德鲁克说过:“对于知识工作者是无法进行严密的督导
  • 提供一种积极,主动,自驱的工作氛围给团队,让团队在这种土壤里面逐渐形成高效能团队
    • 员工在不同的环境,有不同的产出
    • 发现懈怠的员工,不仅要从员工身上找问题,还可以去思考看看是不是我们周围的人,事,环境,工作方法,价值观等地方找出问题。
  • “橘生淮南则为橘,生于淮北则为枳”
  • 高产出员工的两个特质是:
    • 能力(专业知识,技术能力)。
    • 意愿(团队文化,价值观,喜欢的氛围)。
  • (1)外部激励
    • 安全感和成就感(稳定的工作环境,完成有难度的挑战,及时反馈 BIA)。
    • 学习和成长环境(和优秀的人共事,感知到自己成长)。
    • 和管理者定期沟通(让员工感到自己被重视,收集员工建议并且做出工作上的调整)。
  • (2)自驱力凝聚力
    • 很多企业都期望员工可以有 Owner 精神,但是如果想要团队保持足够的自驱力,管理者可能要思考是否对团队做到以下几点:
      • 给予员工自主性(工作内容上的自由度,工作方法上的自由度,工作时间和地点上的自由度)。
      • 成长(明确的工作目标,内容有挑战,工作发挥其优势)。
      • 意义和使命(共同的目标和愿景,价值观)。
      • 信任和放权(共同面对挑战,团队内的对抗活动)。
  • (3)沟通技巧
    • 《圣经·旧约·创世记》第 11 章通天塔的故事
    • 如果人们不愿意,或者不会沟通,那么就很容易产生分歧,误解,从而导致大家分裂,大家的目标就会失败,那么管理者很多事情是需要通过沟通传达,让团队达成方向共识,齐心协力,最终完成企业的目标。
    • 良好的沟通能带来什么?
      • 管理者对团队的总体认知和判断力得到提升。
      • 和团队成员之间建立信任和默契(信任的前提是充分的沟通,信任程度越高,沟通成本越低)。
      • 高质量的沟通可以帮助管理者在团队建立和累积影响力。
    • 注意事项
      • 认清个体差异(每个人的生活环境不同,对于不同的角色要学会用不同的沟通和表达方式)。
      • 基于目标沟通 (明确各自沟通的意图和目的,减少不必要的误会,避免情绪对抗)。
      • 多用我来回放(可以把:你是不是这个意思,换成你看看我理解的是否准确)。
    • 沟通技巧的核心在于学会倾听,对于还未掌握沟通技巧的同学,推荐一个沟通工具 3F 倾听,照着做也可以称为沟通小能手。
  • (4)情绪控制
    • 聊到沟通不得不聊情绪控制,为什么管理者要避免情绪化,学会控制情绪 ?
    • 大脑皮层处理本能情绪的优先级是高于理性的,例如愤怒,恐惧,饥饿等,所以经常看到被本能情绪覆盖的人,往往会失去某种理性。
    • 沟通时注意控制情绪,保持理性。发脾气是本能,控制脾气才是能力。
      • 冰山图
    • 出现“部门墙”的情况就是因为之间没有共同的上级,也无法相互影响。
      • 相向为竞,同向为争
      • 能力复用,真正共建。
      • 更合理的方法:公司有没有现成的解法?多大程度上复用?能不能改进?技术共建,相互促进
    • 遇到这种情况可以通过如下几个切入点去达成沟通的共识:
      • 人格:有口皆碑的人品和正直的人格可以让别人更加容易信任你说的内容,并且被你影响。
      • 历史表现:你曾经成功完成过相同的事情,就是成功案例,可以让别人更加容易相信你。
      • 影响力:你是行业的知名人物或者是团队公认的专家,权威的力量。
      • 逻辑:你的内容前后呼应有着紧密的逻辑,可以增加说服力。
      • 激情和情怀:心怀某种远大的理想主义,并且有使命感有激情,比较容易获得人们的帮助和认同,可以参考锤子手机的成功案例。
      • 互惠:明白对方的需求,沟通的目的是建立在满足双方的需求上。
    • 容易踩的坑儿
      • 沟通给人贴标签,对人不对事(例如:你这个人怎么这么笨,这点事情都做不好)。
      • 没有管理自己的情绪,负面情绪对团队造成影响。
      • 沟通没有闭环,消息和邮件发出去就默认对方收到了。
        • 沟通有没有闭环对应计算机网络中的 TCP 协议(可靠网络传输)和 UDP 协议(不可靠的网络传输),建议大家在沟通中尽量多的使用 TCP 协议。

管理者自我成长

  • 为什么说管理者要比团队拥有更快的成长,因为管理者是团队的天花板,你不成长则团队不会成长。
  • 那么管理者的自我认知首先要体现在哪些方面?
    • 认知:管理者的价值是体现在团队业绩上,不要跟团队抢功劳。
    • 心态归因于己,归功于外,有错都是管理者的错,有功劳都是团队的努力。
    • 担当:不要推卸责任,就算是客观原因,也要反省和复盘避免,而不是把责任推给外部。
  • 三十左右刚刚成家的管理者,可以抽出的时间基本是少之又少。
  • 如果还想在赛道上赢得竞争力,就要保证自己有足够的时间和身体的健康
    • 运动(每天定期的运动,可以让你保持一个持续充沛的精力,也更加容易专注)。
    • 饮食(健康饮食,少吃多餐)。
    • 睡眠(早睡早起,不要熬夜)。
    • 健康(定期检查,避免久坐)。
    • 情绪(放松,感恩,好心情)。
  • 持续努力的目标是有两个:
    • 软技能的提升:产品思维,项目规划,带团队,带人,沟通,执行力。
    • 硬技能的提升:架构,设计,算法,网络,操作系统,编程语言。
  • 很多人总是有误解,认为已经是团队 Manger 就不需要去做具体的执行工作的,起码这一点对于技术管理是行不通的。
  • 技术管理者要一直写代码,因为
    • 如果不了解技术细节就无法做出有效的决策
    • 管理者如果脱离技术,也是很危险的一件事情,因为市场对管理者的需求并不多,市场需要更多的工程师去写代码,管理者更多的价值是依附于企业,其很多业务知识也并非可迁移的技能
    • 管理者放弃技术的话可谓是“自废武功”,也会让自己陷入一个很尴尬的境地,上不去,也下不来。

总结

  • 做技术还是管理都不是很重要,找到自己最大的价值才是最重要的。
  • 不要被别人走过的路限制住,也不要被职业限制住,没有谁可以定义你的发展。

  • 中国的官本位思考挺严重,很多人以为做管理就是当官,但是在软件行业其实并不存在这一现象。
  • 大多数互联网公司都是偏向扁平化管理,管理者在工作中并没有本质上的不同,而且管理者的工作更多的是偏向“打杂”(工程师视角)。
  • 如果抱着当官这种心态去做管理,初衷就已经错了,先在这里劝退,因为最终也可能会走向失败。
  • 管理者更多的是要有利他精神空杯开放的心态,真正愿意去帮助团队成功,通过成就他人来收获成就感。
  • 关于技术管理的道理长篇大论说了很多,道理都很简单,能不能走好管理路,还是要在“事上练”,自己感悟出来的道理才能真正的为自己所用

招聘 (STAR法则)

在招聘面试中,有一种目前常用的面试方法,叫STAR法则

  • STAR是单词SituationTaskActionResult的首字母。

STAR 法则四要素:

  • Situation:事情是在什么情况下发生,基于一个怎样的背景;
  • Task:你是如何明确你的任务的;
  • Action:针对这样的情况分析,你采用了什么行动方式,具体做了哪些工作内容;
  • Result:结果怎样,带来了什么价值,在整个过程中你学到了什么,有什么新的体会。

STAR法则自从2008年在《高效培训》一书中被提出后,就被广泛应用在培训和面试领域。STAR法则在实际的面试过程中,有两种常见的用法,分别适合单面和群面。

  • 第一种适合单面,即通过STAR法则询问候选人的工作经历。
    • 面试官可以仔细、深入地询问候选人其中一段最贴近招聘岗位要求的工作/项目经历,要求候选人详细地描述当时的环境(Situation)、工作目标(Task)、具体的工作事项(Action)及最终获得的成果(Result)。
    • 在面试过程中,面试官应对自己特别注重的方面进行追问,从而获得对候选人更全面深刻的认知。一个好的候选人往往需要提前准备好阐述工作经历,面试过程中认真聆听问题,清晰明了地回答问题,并在回答中展现候选人的工作态度和能力范围等。
  • 第二种适合群面,即通过STAR法则开展无领导小组讨论。
    • 面试官(们)可提前设计好一个讨论场景(Situation)和最终目标(Task),要求多位候选人自行进行讨论,并得出最终结果。在无领导小组讨论过程中,面试官可以观察每位候选人如何不断向目标靠近(Action),并最终获得了什么结果(Result),从而挖掘候选人的能力范围。
    • 面试官也可以在讨论结束后要求每位候选人再进行自我阐述,佐证自己对候选人的判断。

STAR法则浅显易懂,而且对面试和简历都有非常直接的指导意义。而笔者认为:STAR法则同样适用于产品设计中,如果遵循STAR法则,我们的产品设计和交互设计会做得更好!

STAR法则对产品设计的思考

在设计功能时,我们同样需要考虑用户场景(Situation)、功能目标(Task)、用户行为路径(Action)和最终产品效果(Result)。STAR面试法则,是从四个角度去描述一份工作/项目。而STAR产品法则,是从四个维度去思考并验证一个产品功能,STAR产品法则应当贯穿在产品设计到上线后的整个过程当中。

如何成功搞垮一个团队

【2021-2-4】管理者如何快速搞垮一个团队

  1. 控制欲爆棚
    • 对项目的进度事无巨细一律插手,对团队成员的工作时间、执行方法、思想动态一律控制。
    • 这种领导极度缺乏安全感,控制欲极强,他们的内心充满自卑胆怯。生怕员工哪方面超过自己,哪方面对自己形成挑战。
    • 在他们手下干活,毫无成长不说,还得提心吊胆不知道哪句话哪个动作就触犯了领导敏感的神经。
    • 讲个真实的小故事吧:洋哥有个读者和领导拍照执意要站最中间,触犯了大忌讳。随后被连续穿小鞋,三个月后愤而离职。
  2. 甩手掌柜
    • 这种领导,官本位思想严重,真把自己当一个大官了。高高在上只负责发号施令,只安排工作不去检查Review,也不给下属提供支持和资源。
    • 出了问题?那当然是下属的锅!事情做崩盘了就牺牲一两个下属,推出去斩首示众,然后继续做甩手掌柜。
  3. 毫无诚信
    • 明年加薪是他们的口头禅,给下属的承诺从来只是一句空话。当然他们也没欺骗下属,明年嘛没毛病。
    • 等到下属抗议之际,他们会搬出各种大道理,诸如:公司现在还在困难之际,你怎么这么看重个人利益?我都把你当兄弟了,你就别跟我谈利益。你是组织重点培养对象,要学会长期主义!
  4. 形式主义
    • 他们喜欢看下属加班奋斗的样子,谁敢早走?那一定是工作不饱和有严重问题,要马上安排一场严肃的one on one。
    • 他们喜欢精美绝伦的PPT,并坚信不会画PPT的架构师都是辣鸡。他们喜欢听漂亮话甚至是拍马屁,毕竟沟通都不会的下属,肯定不能重用。
    • 他们偶尔还会朋友圈纵览群臣,看看哪些下属在发加班动态,时不时点个赞,表示已阅以示鼓励。那些天天发生活动态的下属?工作状态一定有严重问题!
    • 至于工作结果?他们不太能作出很好的区分,反正表面工作最重要。
  5. 任人唯亲
    • 身边最重要的岗位当然要安插多年的亲信了,甚至七大姑八大姨弄进公司来也是极好的。
    • 至于干活很牛逼的人?让他们继续干活不就好了。人才对公司而言最重要,什么是人才?那一定是听话的心腹。
    • 听话的心腹好处多多,你让他往东绝不往西,至于一些隐蔽的小事更是需要他们来执行。
  6. 刚愎自用
    • 所有人都会犯错,尤其是下属容易犯错,至于我?从不会犯错。我说的话就是圣旨,你们执行就好。
    • 这类领导的权威不容许半点挑战,即便方案有问题,最好别反驳,反驳就是想离职。既然想离职?那送你一程好了。
  7. 玩弄权术
    • 有些管理者,对权术的熟练运用简直是一种天赋。他们能容忍甚至重用品行低劣的下属,只是为了力量的平衡。
    • 有的时候,他们还会故意制造下属之间的敌对情绪,适当制造矛盾以防止各种「势力」产生不利于自己的联合。
    • 他们翻脸比翻书还要快,忽然将其下属捧上天,忽然又将某下属按下地,还要用脚摩擦。

互联网怪相

人浮于事

  • 不停的开会、讨论,没时间写代码
  • 2-3个人干活,十几个人领奖

  • 团队或部门里的人员越来越多,整天都在开会,都在互相解释,互相争吵,会扯淡的人越来越多。那还有个屁的效率。

不停重构

互联网研发人员常见的想法:

  • 自己开发的模块,懒得写注释,总觉得很简单,是常识,没必要写;接手新模块时,又抱怨上任文档不全,没有注释,一边苦苦思索,一边骂娘。。。
  • 每次交接就意味着信息大量丢失,文档(有就不错了)一般只有项目的1/3,口头什么的,最不靠谱了
  • 接手别人的模块时:
    • 能不动就不动,免得踩雷伤着自己
    • 实在不行,就走钢丝,小心翼翼修复
    • 有抱负的人,重新造轮子,按自己的习惯重构。
      • 衡量项目收益(ROI)时,往往不认为重构,不会给太多精力,总是默认系统是正常的。
      • 所以,向那些敢于顶住压力,重构老古董的人,致敬!
  • 等到交接出去,又被人重构。。。

文化

  • 如何委婉的给程序员提bug?聪明且傲娇的群体
    • 方式一:
      • 提问:你的程序有bug
      • 程序员:①你的环境有问题吧?②傻逼你会用吗?
    • 方式二:
      • 提问:这个程序与预期有点不一致,你看看是不是使用方法哪里有问题?
      • 程序员:草,是不是哪里出bug了!

技术文档

  • wiki
  • 模块代码:readme文件、requirement.txt、install文件

机器学习基本流程

  • 分为三个步骤:
    • 数据准备与预处理
    • 模型选择与训练
    • 模型验证与参数调优

代码结构

目录结构

什么代码是好代码

总结:

编码规范、高内聚低耦合、可复用、简单易懂易维护、洁癖、其他(注释、打日志、边界条件)

一个模块一般具备以下结构、文件

  • readme.md
    • 模块介绍,包含:业务背景介绍(附相关文档链接),基本功能,部署方法
    • 目标:让小白一眼看明白,减少信息偏差
  • data(非必须):数据目录,包含:
    • train.txt
    • test.txt
    • validation.txt(可选)
  • bin(或src):核心代码,算法模块主要包含:
    • model.py:模型定义
    • feature.py:特征工程部分,离线训练和在线评估都有
    • train.py:模型训练代码
    • predict.py:在线预测(inference,推断)
  • model:模型存放
    • 注意:模型文件一般较大,不放git,另外有文件服务
    • 比如,公司内部用模型平台(支持本地磁盘+hdfs)
  • log(非必须):日志目录
    • 训练日志,如 tensorboard日志
  • conf:配置文件
    • 注:配置信息脱离代码
  • common(非必须):公共库、组件
    • alarm.py:报警模块
    • log.sh:shell彩色日志工具
  • requirements.txt
    • 前置安装包, Python版
    • 非python:如C++对应makefile文件
  • install.sh
    • 部署文件,如环境变量配置(便于导入common库),安装包pip install -r requirements.txt
  • test(非必须)
    • 测试文件,如单元测试(非必须)
    • 数据分析文件

代码评审

详见站内专题: 代码规范及测试

项目管理

互联网项目流程

  • 互联网公司中的人来来往往,大家都在干啥呢? 公司由一个个Team组成,而一个个项目又把不同Team连接在一块。
  • 完整流程

吐槽

  • IT产品速成记
  • 背景:看到一幅图,互联网工作风气,入木三分,由感而发:
    • 好大喜功风气盛,急于求成险中生
    • 不论团队人几个,披星戴月封闭行
    • 一朝成名万般抢,但出事故众人推
    • 无名戳中苦笑点,最苦莫过匠心人

华山论剑

前沿技术
代码库A
代码库B
common库
(1)技术分享
(3)Code Review
范围:涉及线上服务的模块
华山论剑
项目方案
(4)团队贡献
抢会议室
贡献奖
码神奖
大侠奖
乐于助人
内推
代码库C
工程效率
要点:1次/1-2周,轮流主持(抢会议室/掌控进度)
要点:
① 编码规范/高内聚低耦合/可复用
② 云评审,共同成长
③ 委员会把控整体质量
④ 常态化/自动化
cookbook
宗旨:为人民服务
技术委员会
知识图谱
深度学习
专题系列
爬虫
ETL
。。。
开源工具
paper/新技术
wiki/文档/工具
项目介绍/难点突破
Shell/Git/SQL
武当派
逍遥派
逍遥派
华山派
武林盟主
团体奖
其他
积分规则:5-15分
积分规则:1-10分
积分规则:1-10分
少林派
微服务
aisearch
(2)技术评审
技术方案评审异议
提前发现他人模块问题
最新技术引入
ETL
表字段命名
(4)数据规范

结束


支付宝打赏 微信打赏

~ 海内存知已,天涯若比邻 ~

Share

Related Posts

标题:因果科学-Casual-Science

摘要:如何让AI系统具备真正的推理能力?图灵奖得主、贝叶斯网络之父 Judea Pearl 的解法——因果科学

标题:思维认知培养笔记-How-to-cultivate-logical-thinking

摘要:如何培养自己的逻辑思维能力,一眼看到问题本质,发现漏洞,深度思考?

站内可视化导航

文章可视化导读:鼠标划过图形块时,如果出现蓝色光环, 点击即可跳转到对应主题
模型层
模态层
文本生成
图像生成
语音生成
视频生成
扩散模型
NLP任务
对话系统
LLM大模型专题导航
LLM训练流程
分布式训练
GPU
DeepSpeed
RAG
FineTune
RLHF
PEFT
数据准备
模型评估
PyTorch
数据标注
MoE
LLM应用方案
Transformer
GPT-1
BERT
Scaline Law
复杂推理
Function Call
Plugin 插件
小模型
Agent
智能体
LangChain
AutoGen
CoT
Prompt Engineering 
提示工程
APE 
提示词自动化
Prompt Attack 
提示词攻击
多模态
Prompt Learning 
提示学习
Transformers 库
Embedding
分词
预训练语言模型
ChatGPT
NLP模型
ChatGLM
Baichuan
ChatGPT
大语言模型
垂类模型
专题优化
幻觉
PE
推理性能
Prompt优化
Agent框架
模型训练
智能客服
对话管理
文本生成
文本分类
文本匹配
NER
阅读理解
GPT-2
NLP基础知识
聚类
深度学习
机器学习
深度学习
神经网络
神经网络调参
AutoML
强化学习
因果科学
多任务学习
用户模拟器
图神经网络
AGI
脑机接口
AIGC行业
行业知识
AI行业报告
具身智能
ML笔记
应用层
人工智障
大模型时代对话系统
LLM 开发模式
对比学习
计算机视觉
视频理解
推荐系统
文档问答
开放域问答
LLM问题
推理优化
服务部署实验
自动标注
ChatGPT应用
评估方法
目标检测
大模型评测
ChatGPT复现
AI生成
LLM原理
音乐生成
推理加速
LLM端侧部署
OpenAI
AI公司
AIGC 机会
用户画像
大脑原理
回归分析
芯片
在线教育
汽车原理
自动驾驶
异常检测
聚类算法
贝叶斯
元宇宙
新技术
机器人
搜索
可解释性
NAS
元学习
情感计算
知识追踪
互联网金融
房产行业
量化交易
股票
物联网
移动设备
语音生成
模型部署
最优化
排序学习
微积分
知识图谱
博弈论
联邦学习
密码学
流形学习
Python
特征工程
区块链
信息论
概率统计
量子计算
Pandas
Scikit-learn
文本挖掘
神经网络可视化
不均衡问题
精简笔记
文本分类
ML军规
线性代数与矩阵
Go
ML本质
LBS
傅里叶变换
Git
Jupyter
Linux
Shell
Latex
Jekyll
教育
分形几何
SQL
可视化
数据挖掘
vpn
计算机网络
计算机语言
操作系统
图形学
计算机知识脑图
基础算法
算法比赛
Web前端
架构设计
Docker
小程序
测试
面试指南
数学历史
makefile
Linux C
C/C++
设计模式
Tensorflow
Pytorch
Pytorch手册
计算机基础
数学知识
【2025-02-22】
wqw547243068@163.com
图像处理
OCR
智能硬件
传感器
GPT-3
Transformer改进
AIGC
内容检测
端到端对话
LLM发展方向
具身智能
DeepSeek
Encoder模块
(NLU场景)
Decoder模块
(NLG场景)
GPT-3.5
GPT-4
2018年6月

2018年10月
Google
2019年2月
2020年5月
Albert
2019年10月

OpenAI
Agent应用
端侧LLM
训练框架
ME
模型编辑
NL2SQL
推荐系统
LLM推荐系统
机器人
具身智能
模型蒸馏
语音识别
T5
Geimini

Comments

--disqus--