1.前言
虽然题为培训,但我还是想说一句,程序员其实不需要培训,只需要指点。原因有三:
- 程序员的工作都必须去实践,几乎没有纯理论的领域。
- 由于互联网的开放性,程序员能找到大量的资源自学。
- 随着实践深入,会自然地遇到一些问题。解决这些问题除了靠智力外,大部分只需要知道答案的大致方位就能用时间来消灭掉。
大牛之所以能成为大牛,就是知道了很多答案存在的地方以及发现这些地方的方法。优秀的程序员培训师懂得教方法而不仅是教答案。可惜很多培训师不是这样的,公司内部的培训流于形式,大家听完后就知道这是个很牛b的技术,却不知道怎么令自己也牛b起来。
HR就算懂上面的道理,他们从根本上也没能力推动程序员的内部培训。HR能做的事是帮助管理者在程序员心中培养技术为尊的意识,让他们有动力去自学并实践,并以公司内某位榜样为目标赶超他。
HR无法有大作为,也令大多数公司很少重视培训。因为即使不培训也不会影响赚钱,工作效率的低下可以用加班来弥补。而且项目做到一定程度就会更新换代、推倒重来,原本写得多烂的代码都成过眼云烟。还有就是老员工们都有自己的习惯,较难通过培训来改变,基本都需要有人经常提醒。
在实际中有时候还是需要培训的,这其中多数是因为负责人懒得写文档,或者文档很容易过时而懒得更新,不如口头说一遍算了,╮(╯▽╰)╭。
2.技术培训
按内容区分,培训可分为业务技术培训和软技能培训,还有HR组织的集训。
大家对技术培训的第一反应都是PPT式会议,因为这种形式多,而且也是最最初级的培训。
PPT最大的意义在于做报告,内容凝练而简略,所以受众是没法得到很多的信息的。但是这并不等于没用。PPT式会议和网上的视频教程一样,能帮助零基础的人快速入门。这里需要解释一下何谓零基础,是指对这门知识几乎没接触过,但已有相近的知识。例如已知C学C++或已知C++学Java,也就是说,至少不用在培训中解释何谓关键字或者面向对象。连相近知识也没有的人,应该叫负基础,他们会连PPT式会议都听不懂,还是得回归书本。
书本不仅适合负基础的人,也适合高级读者。因为看书有时间细想琢磨,有助于吸收。专家级则是阅读各种SDK和API文档。大神级的就是看代码看出神的了。
搜遍互联网和各种书籍都找不到的东西,才是真正有意义做培训的,多数跟本公司密切关联:
- 产品的整体架构、设计思路、业务逻辑,迭代历史
- 各类工具/系统(IDE、需求、项目管理、测试与bug、文档等)的使用技巧
- 解bug、做优化等的经验
- 工作流程和制度
- 本部门的知识体系梳理。直接用例子说明是什么吧,请点击《iOS开发知识与能力体系 思维导图》。文章很久没更新,但能说明问题了,相信不做iOS的也能get√到。
能让受众最大程度吸收的培训应该是手把手地教,这个贯穿在设计和编码过程中。本人实践过,发现被培训的人确实能完整地吸收,而且时间长了他会有反馈并跟你讨论,你可能在讨论中反过来也学到东西。当然,这个很少发生在互联网公司里,大家都很忙碌。
3.软技能培训
大家能思考出这部分内容的意义吗?答案我写在最后吧。下面这些都是可培训的。
3.1高效会议
这一节放到前面很重要,因为不少人搞不清几种会议的差别。会议的主持人或主讲人对会议的高效性负有最大责任,如果都用同一种思路来召开,会议就变得没什么效果。IT界“尊崇”的会议是乔布斯的苹果发布会和各种技术大会上的交流演讲,可惜这些并不是公司内部会议的榜样,很多人找错了模仿对象。
会议类型 |
用途 |
特点和要求 |
产品发布会 |
展示新产品 |
算是一种表演,要声色俱全,多媒体设备只是一种道具。 目的是引起轰动,传播的内容要能煽动观众的情绪,不断制造高潮。 |
交流 |
传播自己或本公司的经验 (技术大会属于这个性质) |
展示个人、团队或公司的优秀技术或成果,间接地卖广告 讲授的内容具有高度概括性,不会讲细节 不会很在意观众是否都听懂,甚至怕泄密而有所保留 |
宣讲会 |
传达信息或做动员 |
观众可能是被要求来听的,这在宣讲本质上是一种命令,所以不用在意讲得怎么样
|
培训 |
传播知识,提高工作效率 |
引导听众记忆和会后探索,目标是让听众最大程度地记住传授内容 |
评审 |
对方案的评审 |
主持人讲述自己的方案,听众提出意见和建议 对方案的描述要尽可能地细致,目的是让听众都理解后能发现问题,减少实施过程中的返工 |
总结 |
成果展示、述职 |
为了提高绩效评级,在符合事实的前提下,能怎么吹就怎么吹,你懂的 |
研讨 |
讨论、头脑风暴 |
没有主讲人,而要有主持人。非主持人都可以随意发言,有专人做会议记录 主持人的最大职责是引导讨论有序进行且不偏离主题,并减少争论以至形成共识。 |
例会 (日/周) |
日常的信息交换 |
每个人都可发言,要尽量简短。发言内容只需在场有另外一个人听懂。 产生的问题会后再由各关联者自行讨论,不占用所有人时间 |
在日常工作中,一个会议的性质可能会包含以上多种,主持人需要在不同的阶段完成不同的职责。特别是主持人也是作为主讲人的时候,应该留意场景的切换,如培训完毕后的问答阶段。一般来说主持人都需要做到这几点:
- 宣讲会议议程或子主题,让参会人做好准备配合
- 尽量使会议达成目标
- 按时开始,不超时结束
- 帮助听众理解发言人(包括自己)的讲话内容
- 提醒其他发言人注意时间、语气等。不要因为一个人而耽误了全部人的时间
- 确保重要的人员都到齐
- 引导会议中的讨论达成一致意见
- 记录重要的发言和待跟进事项
3.2培训他人
好的程序员不一定是好的培训师,但好的架构师一定是合格的培训师,因为架构师必须向他人传达自己的思想。
做培训的首要目标是让听众完全吸收你所讲的内容,当然这很难做到,但做得到让人吸收大部分的也太少了。这是令多数公司不重视培训的重要原因,但也不能完全怪讲师,因为好的培训是需要花费大量时间和精力的。如果不是专门设立培训师岗位或者把培训职责写入KPI,没有几个人会对把培训做到极致。看看需要做多少功夫才能做好吧:
(交流演讲的要求比培训低,故也可参考)
会前准备:
- 冥想和模拟训练。在脑子里演练完整个培训过程,或者找个地方(培训现场最佳)对着空气讲。这能减小忘词的概率和减轻现场讲演的紧张感,还能发现培训逻辑的疏漏。如果还不够,可以先让少部分人来听,然后再面向全体。
- 如果怕会上遗漏一些事项没说,应准备一张小纸写上给自己做提醒的话语。非庄重场合写在手机里也行。
- PPT的制作技巧,很多书可参考,不赘述了。特别提醒,如果确认这是一个培训而不是一个交流演讲,PPT上的字不应该追求简略,特别是重要到需要观众记忆或记笔记的内容(也可能把PPT交给他们)。甚至可以考虑用Word或网页而不是PPT。
- 如果要讲到代码,不应该只用PPT。可以直接打开编辑器对着代码讲。在PPT里贴代码段的都是耍流氓,因为代码占用的篇幅大,而且信息量较多,很难短时间理解透。(这时候技术培训不如文档,但现实往往是相反的,本质原因是文档的糟糕。读者看不下去而希望能面授,集体的诉求自然转变成现场培训。)
- 发邮件提醒培训的适用人群。如有需要,提醒参会者提前阅读一些基础知识。
- 保证自己在培训过程精力充沛。为此,喝茶、喝咖啡、做几个俯卧撑什么的都行,用你喜欢的方式。
- 选择观众注意力容易集中的时间段。不饿,不困,不忙等。
- 选择好的场地,帮助观众集中注意力。不吵、无异味、气温适中(空调设好)、座位密度适中等。
- 其实,你穿什么服装都会影响培训效果
进行时:
- 帮助听众保持注意力集中:
- 如果讲授的内容很繁重,可尝试分节,每节40分钟左右,中间休息10分钟。是的,培训的本质是上课。
- 多微笑,声音洪亮。在旁人眼中,此刻的你应该比平常状态更兴奋和活跃。自己表现得越投入,观众就会越认真听,否则会变成一场催眠大会。
- 提到他的名字,让他的注意力集中回来,或让他有更多的参与感。比如“某某肯定也是这样想的”,“某某曾经说(问)过”,“这样就能解决某某的问题了”。
- 注意自己的姿势、手势,甚至发型、服装,不要喧宾夺主吸引走了注意力
- 开始讲述的内容可以不怎么重要,例如做自我介绍或描述一些东西辅助今天培训的主题,帮助听众慢慢进入状态。
- 演讲的技巧:
- 克服和利用紧张与恐惧。要理解这是人的天性,被很多人围观而自然产生的防御心理,实际上这能帮助你更集中注意力做好培训。
克服它们的方法有自我暗示(用特定的话语激励自己,想象过往成功的演讲,想象这只是普通的例会等)、深呼吸、转移注意力(喝口水,摆弄一下其他物品,跟别人说说话等)等。
事实上无论你犯多大的错,观众过几天就淡忘了。
- 不能用提问来考验人,更确切来说不能令被提问者尴尬而导致冷场,别学学校老师那套。提问可用于:现场调查,证明结论;开放式的,没有正确答案;让观众猜测,活跃气氛。
- 重复以强调。讲完例子或论据后重复一遍观点,加深听众的印象。或者更直接地,“这个很重要,我再重复一遍”。
- 不跑题。我就见过“我如何当好技术leader”这个主题花了三成时间讲“我如何当上技术leader”的人。
- 让听众跟上你的节奏。“承上启下,伏笔,呼应”这些写作技巧,在演讲中表现为“前面我们讲的都是理论,下面我们看看如何应用”、“这点我们后面会有详细描述”、“我们前面讲到的XXX在这里就是最典型的应用”。
- 幽默。注意幽默是为了加深记忆服务的,不要最终变成展示个人魅力。幽默感需要刻意地积累,而且要恰到好处地用在演讲上是需要锻炼的。这个学问比较深,不展开了,建议找书看。
- 说服。最佳方式是列举好处,以利诱导,而不是把规矩硬塞入别人的思想。更厉害的方法是洗脑,这个也是可以找书看哦。
- 要会讲故事,在故事中蕴含你观点。故事的形式比理论好。
- 生动,运用打比方和对比、反比。听众一时难以理解你所描述的内容时,可以换一种角度来说。比如向不懂编程的家人解释架构设计是做什么,“就好比设计一辆汽车,要做到零件可拆卸组装(模块化),多个厂家都能帮助生产零件(可扩展性强),开起来省油又马力足(性能高)……”
- 控制会场的一切:
- 利用好你的权力。无论发生什么影响会议进程的事情,如何处理都以你的决策为主。即使你的上司在场也请记住,这个时候你最大。
- 准备面对意外。比如投影仪或麦克风坏了你也能继续做培训;有人问你答不出的问题,你可以找后援团来回答或说会后私聊。
- 现场环境的使用。灯光、投影仪、座位摆放、提词板、遥控器、激光笔、白板等。
会后:
- 收集反馈。提醒大家可以随意批评这次培训中做得不好的地方。
- 注意受众的当场反应
- 观察受众的会后行为,是否有受你的培训影响而有所改变等
3.3写作
这里特指撰写技术文档和报告,其它文档都比这个的要求低。
写作是很多程序员的弱项,除了表达能力基本功缺乏锻炼外,最主要是忽略了文档的作用是给别人看的,不是给自己看的,无论内容多么有意义也得保证用户平均停留时间和留存率。这恰恰是产品经理熟悉的领域,好的文档也是追求用户体验的,所以想锻炼写作的话不妨用一下这个偏方——找产品设计方面的书看看。举个更形象的例子,电商网站(如淘宝)上的宝贝页面也算一个文档,你是怎么被吸引或引导去付费呢?当然,最好的模仿对象应该是Windows/iOS/Android的系统SDK文档。
(本文的主旨是列培训提纲,缺少更多示例说明,不是好的示范哈。培训和写作有部分技巧是相通的,这里不再重复)
保证读者有耐心从头到尾看完:
- 读起来通顺,有一定的节奏感(长短句排布适中,合理使用标点符号断句;不是指押韵,但会有一点点韵律感)。
- 有条理,有过渡,同级的子主题之间不跳跃
- 由浅入深,不会突然遇到理解障碍。想想C++/C#/Java书籍的目录?
- 选择不花眼、不太小的字体,排版好看,不凌乱
- 如果是web文档,要注意让读者不需要点击太多链接,必要时自己总结链接文档的内容。
- 一张图片内不要信息量太大。尺寸不要过大致无法一页看完,或作适当分割;Web文档的大图要做成竖型,不要产生横向滚动条。
保证“傻瓜”也能看懂:
- 朴实。不要用口语,不要带非群众性的幽默甚至没有,这不是在写演讲稿,也不要写成内心独白。
- 别卖弄知识和文采,也不要用偏门词汇和方言,会影响部分人的理解。比如有多少人知道银弹(silver builet)或者“抛书包”的意思?考考你粤语:撞板、撞彩。
- 抽象或模糊的概念和观点有示例做进一步说明。(很可惜,本文因时间关系没做到,那能写成一本书了)
- 考虑读者可能不具备一些基础知识而看不懂,要么在文章开头写明阅读基础,要么在文中加注释阐述。
专业性,保证处女座不会看疯:
- 没有歧义。比如一个新闻标题叫“中国过早拆房1年浪费数千亿”,这里可以有三种歧义:“过早1年拆房,浪费数千亿”、“过早拆房,这一年浪费数千亿“、”过早拆房,每一年浪费数千亿“。改成这样就没歧义了:“中国过早拆房每年浪费数千亿”。
- 简洁凝练,不要废话连篇。用最短的话说清楚问题。在技术领域,还可多用专业词汇来减少长篇描述,比如用“外观模式”代替“新增一个类统一封装这个模块的所有接口,对外屏蔽这个模块的复杂逻辑”。
更高要求的简洁是在语文层面的,这方面的能力很多人在大学毕业就固定下来了,故不想多言,有兴趣请百度。
- 精简掉冗余信息,不是必要的信息不写、简写、写在末尾,减少读者耗费的时间成本。
- 关键的信息处不能有错别字。英文单词拼写也是哦。
- 严谨,严密,有逻辑。不断论证,有理有据,不留疑问,无懈可击
技术文档会被多次查看,保证后续的阅读能迅速找到最可能感兴趣的点:
- 能从几个维度方便查找。可参考论文、书籍的写法,有目录、摘要、关键字、前言、章节、参考文献等。
- 重点的地方可改变字体(颜色、粗细、大小、字形等)
- 按查看频率排章节。某些文档会把思考和论证过程写上去,最后写结论。这也意味着别人查看的时候,鼠标得滚好远,这时可考虑把结论放前面。
- 合理地分章节。这里要很多例子才能帮助理解,时间关系只能讲一个。假如文档的主要内容是“在Windows、Mac OS、Linux下如何使用线程和进程”,那么:
如果为了方便查找各操作系统下怎么使用,各节的标题应该是“Windows下的使用”、“Mac OS下的使用”、“Linux下的使用”,每节都是描述此操作系统下线程和进程的API;
如果为了方便查找线程和进程的使用分别在不同系统有什么差异,那么各节的标题应该是“线程”、“进程”,每节都是同时列举三个操作系统下的API。
- 内容多到一定程度,应分多篇文档。和上一点一样,同样有技巧。比如写Windows SDK的使用,可分为“初级篇、中级篇,高级篇”,每篇都可能讲到绘图框架,但难度不同;也可分为“……,I/O,绘图,网络……”,把所有的绘图框架知识写到同一章。具体的应根据目标读者的需求来划分。
- 如果更新频率较高或是多人合作,能不用画图的尽量不画,或用文字型图(点我看示例)。这样方便维护,无需额外的软件就能编辑。
- 利用好Web文档的便捷性——超链接
链接的目标网页如果不是最上面,应直接链接到锚点,不需要别人再拖动滚动条。
链接过去的文档如果内容很多,一下子找不到你引用的信息,应该自己总结一下或复制核心的内容过来
如何具备写好文档的能力?多练。以及总结你看到的优秀文章的特点。
不过说实话,除非是写用户手册(说明书)的文档工程师,很少有公司对程序员有这方面的要求,或者说国内还没到这个境界。
3.4敏捷教练
Scrum Master是有认证体系的,可以派人去参加外训拿个证书,然后回公司推广。各种理论就不在此展开了,请百度。
补充一个点,教练的人选也很重要。最好是原本就在团队内,但不是团队leader,并且leader有当众声明教练的权责。这恐怕算是中国特色了。原因:
- 如果leader是教练,那么大家都当是命令,会产生抵触心理,也不敢乱提反对意见,达成不了自组织状态
- 如果教练是外来的,碍于情面,很多改革难以指正执行
- 如果教练没有足够的权力(至少能合理地否决leader的意见),那会是个吃力不讨好的工作。想纯靠精神宣导,那是痴人说梦。
3.5沟通交流
在团队合作中总会遇到冲突,优良的沟通技巧能和谐掉很多不愉快的事情。
- 对事不对人,不要对人进行评论。即使对方知道你的原则,也可以是事先再说一遍“我是对事不对人的”。讨论对方做得不好的地方时,应设法降低这种讨论的不良影响,尽量去除对方警戒心以避免升级为冲突。
- 人多的场合,赞扬可点名,指出错误需匿名。
- 幽默。它可以化解很多的问题。
- 措辞。这个最好是向国家机关的发言人学习,但也不要太官腔。举个例子,“不够好”比“比较差”更少一点攻击性。
- 随时敢于承认自己的错误,可以解释,但不要用来推翻结论。
- 微笑。不建议伪装地笑,应发自内心。如果做不到,不严肃即可。
- 理清概念,避免歧义。如果对话中有无法理解的词语,要问清楚什么意思,不要不懂装懂。
- 不轻易打断别人,尊重发言欲。如果不赶时间,即使对方讲的话没意义也等他讲完吧,至少在别人停顿稍长的时候再插入而不要显得突兀。
- 抓住重点。简单的事情不要用一大段话来说。当别人怎么做时,你可以用自己的话概况一遍并请对方确认是这个意思。
- 精确传递信息,不要误传误报。
- 用打比方来帮助别人理解你的话。比如向外行人解释“终于把bug解掉了的感觉”,就像“肚子疼时终于坐到了马桶上”。(哈,相信你会有更好的描述)
- 转折话题时做好过渡,别人未必能反应过来,以为你还要争论。很经常用到的一句是:这部分是对的,还有一个问题是……”
- 控制好自己和他人的情绪,也就是情商的锻炼。实际的锻炼过程是需要经常反思的,没有一个理论能帮助你应对所有状况。
3.6行为规范/职业素养
HR领域的正直、不干违法事情这类东西就摆一边去吧,先说说这里包括什么吧:
- 做有利于团队合作的选择,但如果自己有牺牲也要表现出来。最简单的例子:多花点时间写注释和文档,方便后人维护。
- 忠于自己的专业眼光,不轻易妥协,也不做消极对抗。例如,如果认定这样某段代码会有风险,在未验证前不同意发布产品。
- 承诺的时间点都按时按质完成。
- 传递前辈对你的帮助,激励后辈的成长。
- 坚持学习。本文应该也有引导作用,除了学技术,还有很多可学呢。
- 多观察,多自己解决问题
拥有的知识和技能越多,表现出来的素养应该越高,不再投机取巧。
(技术领域的不提了,比如遵守代码规范,多写注释方便Review和维护之类的)
3.7时间管理
“番茄工作法”和“重要&&紧急”这两个理论应该比较多人听过。但如何正确运用在日常工作中恐怕很多人没头绪。这也就是培训的重点,应结合实际工作举例。这个领域的学问也挺多,鼓励多看书。
3.8事务推进与思考
即使你不是leader,当由你牵头某个事务时就需要应用一些管理方法。举几个例子,不解释了,请点击链接:
3.9职业规划
这种培训少数公司才有,因为懂得越多,越会跟HR作对。呵,心大了就想升职或跳槽了。
问题大概有这些:
- 选什么岗位,要不要转岗。开发、测试、产品经理、管理类等。
- 选什么行业。传统软件型、硬件厂商、互联网、非IT业的IT部门等。
- 选什么技术。前端、后台、移动开发……
- 选什么类型的公司。外企、创业企业、国企等。
- 选哪类城市。北上广深还是二三线?
- 跳槽的时机。
公司组织的培训一般都是某些英雄人物讲自己在本公司的成长经历,受制于演讲水平,效果一般不佳。而且可以说这可能是特殊情况,套在自己身上不合适。所以基本上都需要多听几个人的演讲,由听众自己找出相似的点,这些点比较可能不是个案。
个人自学的话也差不多,多看些职业规划的理论、名人传记、网上写个人经历的文章(如《非计算机类专业毕业生五年程序员职业生涯的回顾和思考》)等。先广泛收集,再从中挑选拼凑出合适的。也可以做做网上免费的职业评测。
3.10外面的世界
程序员可以终身都在学习,即使不跳槽,也要了解外面的变化,最起码要知道同行的情况。这些信息当然是很难打探到或者让对方告诉你了,主要靠同行跳槽过来后做分享。
也可了解下外国本土公司的特点,虽然能照搬过来的东西不多,但能借鉴的也是有的。例如:开发活动的形式本身也在进化,不仅仅是人在追求最大效益;英雄主义的竞争文化,崇尚以一敌百的能力。
题外话:培训自己
软技能都不会给公司带来直接明显的收益,所以大多数公司不会重视培训这些。实际上,软技能可以加倍工作效率,公司和个人是双赢的。就算公司不重视,自己一定要重视,没人培训你,那就自己培训自己。如果技术水平相等、资历相同的两个人选哪个当官,那自然是和领导最亲近的。哈,你觉得和领导亲近不是靠软技能在发挥作用?
软件工程的概念是借鉴工业工程的,程序员要发展也可从很多其它行业获取知识。就像编程能力之于程序员,以上每一种软技能都是某一种职业的核心技能。也许你无法和很多不同职业的人交友,但你能买到所有职业的专业书,这年头真的连如何当乞丐的教程都有。不要等着老师教你,推荐看看HR、管理学、心理学、销售、演艺、人物传记、科普、旅游、艺术设计等领域的书籍。
还有就是,锻炼好身体,革命的本钱啊。