时间的回报

回报加速定律

在2017年咨询师会议上,我们提出了“智能原生”的口号,自然会去想人工智能未来会怎么样。其中一个令人恐慌的预测是“奇点”,奇点的意思是有一天电脑会比人聪明一点点,然后会更加极速的发展到比人聪明很多,直到完全控制人类。奇点预测背后的原理是Ray Kurzweil在2011年提出的回报加速定律(The Law of Accelerating Returns)。

回报加速定律通过分析人类文明的发展历程,发现人类发展不是线性,而是指数发展。原理也很简单,即发展的回报会加速发展。

最有名的例子是摩尔定律,芯片运算能力每18个月翻一番。10年前iPhone刚刚发布,摄像头只有200万像素, 现在新一代的旗舰手机一般都会搭载2000万像素的摄像头。10年前最先进大型机的图像识别技术可以分辨出兔子和茶壶,而且准确率还不怎么高,2017年新一代的iPhone X已经能离线进行脸部识别。

2017年的电脑智能水平大概比昆虫要高一点了,因为有了先进的电脑等设备(生产力提高),使得生产更先进的设备加速(生产效率提高),预测2022年比老鼠聪明,2030年比一个人聪明,而大概到2050年将比所有人类都聪明。

​(图片来自:http://t.cn/RQSRzFR

加速回报定律可以说是系统正向反馈循环的一个洞见。比如马太效应,在《圣经·新约》的“马太福音”第二十五章中有这么说道:“凡有的,还要加给他,叫他多余;没有的,连他所有的,也要夺过来。”。通俗讲就是有钱的更有钱,没钱的继续没钱。还有比如滚雪球也是同样的意思,亚马逊所信奉的飞轮理论也是差不多的意思。

系统反馈循环有正向,也有负向反馈。

技术债与破窗理论

我们在给客户做敏捷转型技术咨询的时候总是会遇到技术债的问题,即系统中的烂代码和强耦合。

技术债,这个词是个很伟大的发明,只是很少有人能理解其中的含义。只是把它当做烂代码的另一个代名词。

技术债的产生源自人的能力不足或者因为资源有限赶进度而牺牲代码质量,技术债并非完全不好。这跟公司或者个人负债是一样的,可以通过承担负债获取短期收益。然而不幸的是,因为低估甚至不理解技术债所产生的代价,人们往往会选择即使在有资源的情况下仍然忽视技术债、并且不偿还。

烂代码之所以叫技术债,是因为会随着时间会产生额外的代价。今天写一段烂代码不及时修复会引出更多的烂代码,因为后来写代码的人会仿造之前的代码,或者为了绕过烂代码而产生额外的烂代码,使得整个系统陷入烂代码泥浆。我们客户的很多系统寿命不超过3年,不是因为业务变化,而是系统实在太烂无法维护了,只能重新做一个。

讲技术债也许太技术了,另一个很通俗的例子是破窗理论。讲如果一栋大楼的一个窗户破了不及时修复,会引起边上的窗户加速破损。我最近就遇到一个类似的例子,一个公共场所边上的角落有一些垃圾,过了一会有人拿着垃圾四处找了一下没找到垃圾桶,就把新的垃圾丢带了那个角落。如果这个角落一直没人清理,可以想象不需要一个星期就变成垃圾角了,甚至有人会大老远跑过来把垃圾往这个角落扔。

我觉得不理解或忽视技术债的人不是因为不懂技术,而是因为不敬畏时间的代价。

(图片来自:http://t.cn/RQS8QVp

关于系统反馈还有一个很热门的话题,也许跟时间只是恰好有关,即天才一万小时定律。

一万小时天才定律

一万小时定律解释天才之所以卓越非凡,并非天资超人一等,而是付出了持续不断的努力;只要经过1万小时的锤炼,任何人都能从平凡变成超凡;要成为某个领域的专家,需要10000小时,按比例计算就是:如果每天工作八个小时,一周工作五天,那么成为一个领域的专家至少需要五年。

这个同样基于统计的定律非常有意思,我觉得也很有用。人们常常会低估或者忘记回报加速定律、技术栈/破窗理论中时间的作用,对于一万小时天才定律往往只关注时间。世界上有太多人在同一个领域日复一日年复一年工作五年、十年、数十年,然而专家还是只是少数人。原因是什么呢——缺乏正向反馈回路。

收尾

前面讲了三个跟时间相关的系统回路定律,时间的回报有可能是正向也可能负向,更可能会加速。


更多精彩文章,请关注微信公众号:软件乌托邦

Share

不一样的入职之旅

不一样的旅程

ThoughtWorks,新加入的应届生将获得为期五周的出国留学机会(ThoughtWorks University,简称TWU),社招加入的小伙伴将会参与为期三天的TWI。除此之外,公司还将提供诸如NHO、Session、Workshop、Buddy/Sponsor、TL、极光计划(领导力)等数不胜数的培训。所有这些培训都将让你的职业之旅变得不一样。

而更不一样的是,ThoughtWorks北京办公室联手思沃学院推出了一个本地化项目人才培养计划,针对某本地项刚刚入职的5位新人(应届生)进行 “封闭式” 脱产培训。旨在通过为期四周的高强度培训,帮助新人快速融入到项目中。作为教练,我来说说它到底不一样在哪里。

受思沃学院“以学习者为中心”的教学启发,我给此次培训起名为 以学习者为中心的项目驱动培训,一来培训目标很明确 – 让新人更好更快地上项目实战,二来以项目为驱动力的培训是一种强有效的能力培养方式。

不一样培训体系

不同于象牙中“以老师为中心” 的填鸭式教学,以学习者为中心强调的是以学生为中心的启发式教学。然而,初出象牙塔的新人可能仍然保留了较为强烈的学生 – 老师的象牙塔意识。所以作为教练,我们首要任务是识别出他们的意识形态,并帮助其调整。

整个培训贯穿了一个宗旨 – 让新人通过培训后能够更快、更好地为项目做贡献。在大目标的指引下,制定合理且可以落地的验收标准,以可验收的目标为导向。

ThoughtWorks的特色文化(敏捷)时刻在督促我们:在培训过程中坚持持续、反馈、优化、并将敏捷实践渗透到培训中。同时,通过教学过程的反馈环来强化技能成长。别出心裁的是,我们推崇辅以运动健身来提高培训的可持续性和高效性。

以学习者为中心的项目驱动培训的培训体系涉及以下几大方面:

意识形态的更新

意识形态,某种意义上又回到了认知的问题。对于刚从象牙塔中走出来的新人,他们对学习的认知会直接影响他们的学习方式和学习效率。

削弱象牙塔意识

之前当小Buddy的经验告诉我,刚步入职场的新人思维中往往充斥着较强的象牙塔意识。典型的表现是在遇到问题后的第一反应是跟老师索要答案,而非自己先冷静下来去跟问题对话。作为教练,如果每次遇到这样的求助都无条件的给予帮助,只会助长其这种意识。面对这种问题,我们会采取以下措施:

  • 拒绝出现老师词汇。从平时语言交流形式上淡化老师还在的心里暗示,以此帮助摆脱依赖心理。
  • 传授解决问题的套路。扭转他们的意识,在这个过程中需要通过一些新的工具去帮助他们养成新的习惯。

关于解决问题的套路大致可以分为如下几步:

  • 冷静下来与问题对话,了解问题是什么(核心)。
  • 找出关键错误信息,尝试独立解决(利用互联网/问题库)。
  • 如果在预期时间内没有解决,尝试寻求他人帮助,并带上自己的调研结果。
  • “放弃”。当上述三条都没有奏效的时候,起身活动,让大脑放松后再开始。

削弱象牙塔意识是一个持久战,我们会在培训过程中不断地加以引导。比如,在遇到这种现象时可以反复问他们:问题的关键信息是什么?可不可以快速验证一下你的猜测?应该去哪儿找到答案?谁可以提供帮助?通过这些问题激发他们去思考改变。

建立Owner意识

左边做减法,右边做加法。此时应该抓住机会培养他们的责任意识。像 Retro、Code Review、Standup 这些日常敏捷实践可以交由他们去主导。而一旦作为Owner,他们除了能自己快速地掌握,还会去思考其背后的本质。更重要的是,Owner意识的提高会驱使他们不断地自我学习,突破自己,追求卓越,给他们未来的成长打好基调。

明确且可验证的目标

某些项目(Account)在培训新人的时候,针对检验目标,通常是抽象模糊的,比如 能够进行良好的团队协作。对于培训,在开始之前我们得回答两个问题:新人将具备什么能力?能通过什么检验?这两个问题本身没有标准答案,我们会把握住一个核心点:基于项目的需求因地制宜。所以,目标的制定需要PM/TL的参与,我们邀请了PM/TL以及长期从事应届生培训的思沃学院的老师共同来落地这些目标。下图是针对5位新人制定的目标和Checklist:

有了目标,还需要一个循序渐进的培训计划针来达成目标。在做计划之前,教练会先画出一条技能培养主线,后续的每日计划沿着主线推进,并根据知识点的依赖性安排先后顺序。

关于目标,我们会做到公开、公平以及共享,即让每一位新人明确培训的目标。

围绕项目的技能树

教练在培训开始前花时间将项目上相关的技能进行梳理,并通过一些工具(比如思维导图)可视化出来。下面是我们项目的技能树:

下一步是要针对这些技能划分优先级,通过不同的Flag标记出来,比如图中橙色星星表示在培训中重点讲解和实践的,红色星星需要了解,蓝色会被提及。构建项目技能树可以遵循一个方针:技能树的枝枝叶叶都源于项目,两个关注点:关注技术栈 & 关注业务分析

那么如何让新人消化并吸收技能树枝叶的营养对教练来说是一项具有挑战的任务。除了需要大量时间去准备,还要非常用心,但也不是没有套路可循。

教学反馈环

针对每项技能的教学,教练会按照 讲解 -> 演示 -> 练习 -> 巩固 -> 拓展 -> 反馈 -> 分享的模式展开。

讲解。授人鱼不如授人以渔,最好的方式是莫过于让新人掌握技术框架的实现原理。比如在讲解Spring IOC的时候,可以使用Java反射、注解来实现一个IOC容器。然而,在较大的时间压力下,新人接受度达不到预期的效果,这就要求教练要学会讲故事,借用通俗的比喻来介绍知识点,通过必要的可视化工具(比如时序图)来提高讲解接受度。

演示。教练提前准备一些演示习题,在讲解完后通过习题来演示技能的应用。

练习。Time-box限时编程练习,建议使用表格记录下新人每次完成时间。通过反复的限时练习来培养他们编码的感觉并形成肌肉记忆,不用在意他们优秀的记忆力,因为后面还有验收环节。

巩固。布置一定量的课后作业,一方面是为了巩固学习,另一方面是不让他们松懈。实践证明,适当的忙碌和压力能够增强新人的安全感,但要当心过于繁重的作业影响睡眠和第二天的培训。

拓展。这是激发新人自我驱动去扩展知识的好机会。比如,绘制概念图 – 在绘制概念图的时候会扩展学习不少相关的技能。

反馈。针对编码训练,教练会通过验收习题(不同于练习题和作业)来Time-box获取小伙们对知识掌握的反馈。验收习题会 回归项目,从项目代码库中找出相关技能应用场景来验证。

分享。分享作为一个附加环节,针对重要知识点,我们会鼓励新人进行Session分享,在分享过程中检验学习成果,同时可以激发他们集体思考和讨论。

上述的反馈环帮助教练高效地传授和验收知识技能点,同时也对教练提出了较大的挑战,如何让这个过程发挥更好的效果?如何准备有针对性的习题?如何将习题有效的串起来? 等的都需要教练花大量时间去思考和总结。最后,提倡在整个教学过程中:多用肯定词,少用或尽量不用否定词

持续改进的反馈

持续改进是ThoughtWorks的优良传统。很多时候我们在收集/给予大家的反馈,目的是让自己和对方更好地成长。这在培训过程中也不应该有例外。在开始阶段新人的反馈意识并不强,教练会有意识地给予引导,引导他们去提出有效的反馈。对于教练,我们将尝试以下几点:

  • 提醒新人随时针对培训和教练提出反馈,以及互相之间给予和收集反馈,提高他们的反馈意识。
  • 肯定和赞美新人的进步和良好表现,提高他们的自信心和积极性。
  • 及时指出新人的不良编码习惯和学习方式,纠正他们的编码习惯,千万不要错过这个良机。

对于新人,他们同样可以给出有效的反馈:

  • 对培训整体的适应程度,帮助教练调整培训强度和进度。
  • 对知识点讲解的接受度,帮助教练优化知识讲解的方式。

除了及时的反馈,定期的Retro也是有助于持续改进的优秀实践。

特色的敏捷文化

敏捷跟ThoughtWorks关系就像社会主义跟中国的关系。

以敏捷著称的ThoughtWorks,敏捷是我们的特色文化,就像家常便饭存在于日常工作中。所以在培训我们不是把敏捷挂在口头上,而是让它们渗透在各个环节中。教练自身要对于日常的敏捷实践了如指掌,并能够担任敏捷教练职责。

Standup、Code Review、Retro、TDD、Pair、IPM、Kick-off、Desk-check 等敏捷实践都可以植入到培训中。关于这点,要把握的核心宗旨是:敏捷无处不在。教练在开始担任敏捷教练,之后交由新人去主导,让他们逐步具备成为敏捷教练的能力。

需要特别强调的是 TDD 和 Code Review(TDD 没有作为Check point)。TDD 对于新人会有较大的挑战,甚至引起一些抵触心理,但它非常值得为之付出努力。而 Code Review 是一个发现和纠正新人不良编码习惯的好时机。这两点对于他们日后成为优秀的程序员至关重要。

《我在ThoughtWorks中的敏捷实践》一文对敏捷实践做了详细的介绍。

保持运动健康的状态

作为程序员,辛苦是不可否认的事实,如何在辛苦的状态下持续快乐下去(痛快)。我们得拥有一个健康的体魄,并且不要吝啬让身体回归自然 – 生命在于运动。

说到运动健身,大家第一反应可能是健身卡、速干衣、跑步鞋、蛋白粉、功能饮料等。有人会雇专业的健身教练指导,我更建议将运动融入到工作生活中。如果能将久坐8小时之后去健身房锻炼1小时转换成8小时每隔1小时运动7分钟,便可以杜绝腰椎盘突出、颈椎病、肩周炎 等职业病。

在培训过程中除了保持合理的节奏,预留出休息活动的时间,我们会在办公室空旷区域开展集体的运动,比如平板支撑、开合跳等。更重要的是,加强身体锻炼有利于教练授课的可持续性和高效性。

我在《改善程序员生活质量的3+10习惯》中提到的一些小的习惯可以帮助你保持健康的状态。

不一样的宗旨

以学习者为中心,它与象牙塔中以老师为中心的填鸭式教学区分开来,如何找准这个中心,我们始终把握住以下三点:

  • 教练应尽量少讲课,多去引导启发学习者去思考和学习,并提供足够的辅导,通过必要的测试来收集和给予有价值的反馈。
  • 学习者应清楚学习理由和学习目标,并明确自己的目标(具体、公开、共享)。旨在提高学习者对学习目标的重要性认识,从而进行有效的自主学习。
  • 教练通过必要的课堂知识分享,并充分赋予学习者选择学习的权力,培养他们对自身学习成长的责任意识。

期待不一样的你

ThoughtWorks,学习是一件终身大事,培养人更是我司的立足之本。以学习者为中心能够激发学习者高效学习成长,以项目为驱动力,有助于打造一个短期内专注度极高的目标。

如此不一样的职业之旅,我想你一定会喜欢,如果你已经心动了,赶紧行动起来吧。聚集了一群优秀小伙伴的ThoughtWorks期待不一样的你。


更多精彩洞见,请关注微信公众号:思特沃克

Share

请停止结对编程

(根据真实事件改编,情节有所夸张,请勿对号入座。)

这是一个风和日丽的星期五下午,Ben和Martin本应该在Costa咖啡馆喝一杯下午茶,一起聊聊周末的计划,然而PM的一个微信通知打乱了这一切。原来产品出现了一个bug需要紧急修复,下班之前必须要搞定。两人收到消息疾步走回到岗位,也没了心情去喝刚泡好的咖啡,连忙打开邮箱查看问题报告。

开始

Ben:看来这不是一个很大的问题,就是处理一个来自于远端服务的异常。现在的情况是BFF(backend for frontends)在内部的远端服务有异常,会将异常直接返回到客户端,这样只要一个保单出了问题,前端所有的保单也都没法用了。

Martin:那怎么解决?

Ben:感觉可以在异常的地方加一个异常处理。这个涉及到RxJava和Java8的stream特性,我不是太熟悉,要不我们一起Pair吧

Martin:好。

两人喝了一口炙热的咖啡,摆好键盘鼠标,打开了IntelliJ工程。几分钟后,这个故障重现了。

Martin:可以重现的故障通常比较好解决。我们在这里先弄个try…catch试试。 两人似乎很有信心,然而重启项目后,故障并没有按照预期停下来。

Ben:hmm,这里为什么停不下来呢?

Martin:可能是RxJava的延迟处理,没有正确的捕捉到。这样,你在这里再写一个逻辑,然后在这里设个断点……

焦急

在这个过程中,Martin只是对着屏幕指指点点,时不时看看手机、在微信上聊聊天。Ben对RxJava并不是很熟悉,他想紧紧跟随Martin的思路,然而增加多个逻辑以后,依然都不能解决问题。15分钟已经过去,Ben这时候心生怀疑,是不是哪些地方没弄对?

Ben:我们理一下思路看看?

Martin:恩,来吧,一起看一下代码。

Martin领着Ben一起看了一下代码,并且一直在旁边指点Ben进行单步调试。由于RxJava的延迟特性,使得断点很难设置。而抛出异常的调用栈会出现在某些莫名其妙的地方,这让他们根本不知道把try…catch放在哪里才能奏效。

Ben:可能是要这样,在这里加一个OnError看能不能解决。

看似问题能够解决,其实是又一次的失败。在两人的激烈讨论中,时间过得很快,一晃眼已经是1个小时以后,咖啡早已经凉了,然而两个人完全没有心情,甚至都忘了咖啡的存在。

Ben对Martin的解决方案越来越没有信心,两人开始重新讨论起解决方案。然而方案是越讨论越复杂,看起来想在下班前解决这个问题是不可能了,通宵是必然了。

简化

Zen是组里的Tech Lead,今天在忙另外一个事情。这个周五真是不得安宁,恨不得想到美国去过过昨天。

Zen听到两个人的讨论,虽然并不了解这个问题的细节,但直觉上认为是跑偏了。马上提醒Ben和Martin:

这不是一个很难的问题,我感觉你们想复杂了?是不是走偏了?能给我说一下你们怎么想的么?

被Zen打断的Martin说了一下之前的解决方案,也说试过了其他的方案了,都不行。由于Zen对这个事情也不是很了解,所以只是提了一个醒:

“Keep it simple,别把事情整复杂了。”

两个人的讨论依然在继续,Ben有点无法跟上Martin的思路,艰难地写着代码,但每次都不对。Pair的气氛犹如冬日里冰冷的咖啡一样凝结,不知道孰是孰非。Ben已经有些不高兴,Martin则依然在一旁指指点点但并不动手。

Zen一看表已经3点钟了,又插了一句嘴:

Martin,既然你对这个更熟悉,你来操刀吧。你来写代码吧。

可能由于之前的讨论过于激烈,Martin反驳Zen:

我们在Pair啊,他对RxJava不熟悉,我应该指导他。我看着他写就可以了。

Zen说,

你们的解决方案是什么,给我看看。

解释了一通以后,Zen也没有更多的想法,就让他们继续吧。但Zen建议道:

在这个紧要的关头,我们应该改变一下Pair的方式。现在不是教授知识,而是要高效的解决问题。在这种压力的情境下,你可以直接实现自己的思路,带着别人飞就好了。

分歧

Martin稍微冷静了下,拿过键盘,继续开始修复问题。Ben这时候在一旁观察,也适当的休息一下,之前手忙脚乱的按F8、F9的神经也得以缓和。

Ben:看来还是不行。我们再理一下代码吧。

Martin:你说的这些我之前都试过,都不行,要这样才行。

Ben:我说的是这样做的,既然我们还没讨论清楚,我们再来看一下代码吧。

两人拿出了纸和笔,对着屏幕一边画一边讨论,然而Ben并不认可Martin的方案,说要采用另外个方案。Martin则坚持认为这是一个可行的方案,得试试。Ben拿过键盘,准备按照Martin的方案写代码,但心里面颇为不爽,一直在想说服Martin采用他的方案试试。

怒气

到此时,时间都已经不知不觉过去两个小时了,然而问题似乎离真相总是忽远忽近。两个人已经疲劳不堪,再加上解决方案的不一致,两人的言语中开始显露出一些怒气。

Zen在运行测试的空档,打断了两人的对话,建议道:

既然大家已经产生了分歧,要不然两个人分开,各自实现一个,看谁能够先实现,然后再来讨论。

Martin对于Zen并不认同,认为Zen指责他和Ben没有Pair好。

Zen解释道:

其实我听出了两人意见的不统一,言语中已经有一些怒火,这样下去Pair的效率很低。首先,大家带着不爽来干活,互相质疑。更关键的是,解决问题已经用去了两个多小时,大家都比较疲惫,可以适当休息。我让你们分开的目的是让大家冷静一下,在不受打扰的情况下工作一段时间,可能会不一样。

冷静

Martin回到了电脑面前,按照他的思路一步一步做下去。Ben去上了个厕所,倒掉了那杯冷冰冰的咖啡,泡了杯热茶。回到电脑前专注的重新按照他的思路一步一步走下去。

其实两个人已经接近了真相,只是这之间不停的对话把注意力消耗殆尽。两人企图达到一个统一,然而口头的对话并不能解决问题,反而暂缓了这个过程。

10分钟后,Ben兴高采烈的说已经搞出来了一套可以运行的方案,叫Martin一同过来看看。Ben的临时解决方案比较简单好理解,但并不完美。熟悉RxJava的Martin指出了一些可以改进的地方。

然后两人又开始了新一轮的Pair,重新将这个方案完善。有了这个基础的解决方案,两人都很高兴,是朝着一个正确的方向大步向前。

尾声

下午6点半,虽然比正常下班晚了半个多小时,但还好整个解决方案都正常了,交付的任务也顺利完成。

Ben和Martin都总结道,我们应该停止结对,当:

  • 两人的思路不统一但无法说服对方时:我们可以考虑分开一阵,安静一下,各自用可运行的代码来证明思路的可行。这里只需要相对粗糙的代码即可。
  • 时间已经超过番茄时间而感到疲惫时:人的专注力是有限的,在Pair时非常累,特别是在能力方面存在较大差距的时候。在这时候我们可以试试番茄工作法,让大脑得到休息。
  • 注意力不集中或者有其他事务要处理时:在Pair的时候,彼此要尊重对方,不要玩手机、看其他无关的网页,除非事先取得别人的同意,否则就要等到停止结对、处理完事务后再继续。

更多精彩洞见,请关注微信公众号:思特沃克

Share

成熟开发者的“元品质”

有时候我回首望过这些年走过的职业路径,从开发到测试,参与技术社区,兼职编辑,到今天这样一个“跨界”的角色,心中没有放下过的一直是对开发者这个身份的认同。

我喜欢跟有技术内核的人在一起,击键如飞,改变世界,内心沉浸,性格单纯。虽然会觉得忝列其中而觉羞愧,但这也是我“跨界”的基础,久而久之,反而会有新的发现。

目睹着周围的同事们越来越年轻,他们有冲劲,无限的精力和好奇心,像是随时都会在我面前宣布他们终究要把我远远地甩在时间的后面。但我也不断地发现,他们在走的路以及会落下去的坑,都是那么熟悉,好胜之心,求快求新,很多东西浅尝辄止,拿着锤子四处找钉子。

也许这就是人生吧,甚至无关乎职业,人注定要在不断体验失意和收获教训之后,才从无知无畏走向敬畏和宽容。

但我周围仍旧存在这样一些开发者,他们除了那些通用的开发者品质外,更显从容和优雅,对软件,对世界,对内心有更成熟的理解和认知。他们“上得厅堂,下得厨房”,面对高大上的客户可以雍容不迫,撸起袖子干活也可以尽显极客本色,更重要的是,他们更懂得自己的存在是为了改善这个世界上另外一个地方一些人的命运,并从未停止去追逐。

所以我在想,除了那些通用的开发者品质,是不是可能还存在一些品质,可以让我们的开发者快速地成熟起来?除了要对新技术和趋势保持敏感,对工具和语言保持兴趣并熟练掌握,趁着年轻一年又一年挥洒不尽的精力和时间之外,还有没有一些品质存在,是年轻的开发者可借以成熟的路径,或者可供参考的方向?

我愿意把这些叫做成熟开发者的“元品质”。

有人文心

行业的隔膜加上互联网的便捷,让现代的年轻开发者不用顾及太多专业外的知识,就可以在比特海里畅游不停。我们可以在虚拟的世界里,完成我们几乎所有的生活和工作所需,一切伸手可触但圈子却越来越小,不经意间把自己禁锢在一个以为可以自给自足的小世界里。

这样失去的是对周遭环境和人的感知,失去的是对更大世界现实感的体会,失去的是对自我能力和未来的认知(高估或者低估),还有对自己能改变周遭甚至世界的可能的探知。

读史,读传记,读一切可以让自己有人文心的信息,可以感知自己的渺小,这样不会再有无知的虚妄无畏,也可以知晓未来通向的方向和自己的未来之路。

有宽容心

很早之前看过一本书,《做单》,作者是IBM的金牌销售胡震生。书里详述了他作为销售的经历,抛开那些触目惊心以及不断刷新我认知的销售经过之外,让我体验最深的,是他作为销售人员所体现出来的对他人的宽容心,和对人性的敬畏心。不管对待自己想要拿下的客户,还是面对自己团队的同事,用自己的包容处处为之着想一一化解掉对方的猜忌和不满。而最后单子做成只是产生的副作用而已。

当开发者需要去承担更大职责,或者被置身于一个比独立开发更加复杂的环境时,所面临的局面和接触的人都发生了很大的变化。工作方式和风格的不同所产生的摩擦会容易让我们失去耐心。只包容自己,无意识下伤及合作伙伴的行为,会被简单地斥以情商低。

而多方共赢,甚至牺牲自己成就他人是最难的吧。从更高的层面来思考整个系统的运作方式,以及不同利益相关者的需求,结合从他人出发角度,来寻找多方共赢的可能方案。

不管是客户,还是自己团队的同事,想想他们的诉求,工作上的诉求,私人的诉求,是否跟我们自己有更大的重合面。而寻找到了就是幸运,加持以耐心和包容心,这才是我理解的成功。

有勇气

有勇气,不代表无知者的无畏,而是代表在面临困难或者诱惑的时候,对自己原则的坚持和自信。

我见过很多次,开发者在面临客户的威逼利诱时候的不知所措,在面对遗留系统代码,不重构,不测试,不尝试的推脱:

因为这个迭代太紧张,因为客户很着急。

偷懒和没有原则,失去的不仅仅是自己练习实践的机会,还有将来被各种理由裹挟的可能,更重要的是距离成为一个具备独立思考力和可被委以重任的开发者也越来越远。

会写作

不只是我自己,越来越多人开始意识到,在现在这样注意力容易缺失,四处追求快速的环境下,开发者更容易堕落成简单的问题解决者,而不是有系统思考能力的设计者和决策者。

我们更像是缺乏一种摆脱现实窘境(欲罢不能,饮鸩止渴)的方式,而在寻找之后似乎都指向了同样的方向——写作

一个人再怎么呼吁也是苍白的,让我们看看更多的人怎么说,下面是我很认可的几个:

回到写作这件事情,抛开那些“总有一天”才能实现的好处外,眼前的好处无外乎就是帮助我们记录理解消化沉淀学到的知识了。不过我们的内心里总有一个声音反复出现:反正书看了,Session听了,感觉知识已经学会了,那还值得花时间写么?我用这个时间多学点东西不更好?

你越是不开始书写,总是拿有限的思维缓存去默想一个问题,就越是没有内容可以写,如果你逼着自己将一些不成熟的想法写下来,看着自己写的内容,试着进一步拓展它们,就有可能在理性的道路上走得很远,很远。

我喜欢写作,并认为写作是最好的学习过程,它像是设计思维里知识漏斗的颈,把你以往的、现在的、以及新发现的知识融合在一起,汇聚成落在纸上的文字,这是我一直保持写作热情的秘诀。

愿意思考的人很多,很多人比我想得更深入更广阔,但愿意写出来的人不多,这太可惜了。其实写作是个熟练工,哪怕一开始没有感觉,写写就会有感觉的。我希望有越来越多的朋友认真写作,既为自己营造了高质量的社交,也让这个世界更美好。

我们可以看到写作对于我们个人由内到外的很多方面,都有积极的意义:

  • 帮助提升思考的能力
  • 提高学习的效率
  • 打造个人在专业性上的名声
  • 延伸人脉和职业发展的可能

而这些意义,又有哪个不是开发者需要的呢?

最后

人活着的意义和人生的价值就在于提升心性、磨炼灵魂。

——《活法》


更多精彩文章,请关注微信公众号:软件乌托邦

Share

IT工程师的自我管理

工作多年,我们见识到了很多厉害的人,他们可以兼顾家庭和工作,合理安排自己的事务和时间,能冷静的处理突发事件且理智的做出决策,把所有事情安排的妥妥当当。最初我以为这种能力来源于性格、情商甚至是天赋,因为并没有看到任何一本书来教人们做到这些,直到我把视角从普通的生活移到工作中,才发现原来一个能把生活安排的井井有条的人,在工作中往往也是优秀的管理者。

管理项目或公司和管理生活有很多共通之处。有些人天生做的很好,但是像我这种普通人则不然。庆幸的是,我们依然能找到一些可行的方法和工具来做的像他们一样,在这篇文章中,我会尝试把公司项目管理的各种方法应用到个人生活中,我划分了不同的小节(收集反馈、决策、时间和任务管理、情绪管理)来阐述这些问题和解决方案,在每个小节的结尾,也会附上我使用过或者推荐的一些工具。

收集反馈和接纳自己

在ThoughtWorks,我学到了一个非常有用的方法,并且可以用到生活中。我们称之为“Feedback”,中文含义为反馈。在公司,收集“Feedback”的精神无处不在,完成一个项目、甚至完成了一次公司内部活动,都会有同事发出调查表单或者邮件来收集意见和反馈。反馈,可以给我们提供改进的方向。

在团队里面,领导或者同事确实会站在不同的角度给予你“Feedback”。在此之外,也可以尝试自我反馈,甚至主动向别人索取反馈。我定了一个日历,来提醒自己在每周一晚上对反馈进行整理。在这小段时间里,让“我”不单单是我,想象自己是另外一个独立的个体,方能更客观和理性的认识自己。

在收集反馈和自我审视当中,非常重要的一点就是客观的接纳自己,从心理学的角度看,更好的安排和管理自己的生活也应该从接纳自己开始,接纳自己的优点或者缺点才能积极的坚持和改变,把一副一般的牌打出精彩效果,这就是管理的哲学。接纳自己的过程和项目经理第一天接手一个遗留项目的感受是一样的,无法改变的东西很多,例如deadline、经费,而能改进的东西更多,像团队热情、开发效率和交付质量等。

优柔寡断、缺乏专注,但是也对很多东西充满热情;和人聊天不够站在对方考虑,但有时候也会幽默;拖延,但是还算勤奋。

这是我给自己的评价,通过这种审视和接纳,我应该能回答一些问题:自己不能改变什么?我能改变什么?哪些事我能做的更好?更进一步,也可以从自己有什么价值、优势和劣势、未来的计划和发展方向、风险怎么管控和人际关系等方面审视自己。

我买了一个白板贴到家里墙上,用来写一些需要经常提醒自己的内容。很简单的一个物件,你可以在淘宝上买到,卖家一般还会赠送黑板擦和白板笔。可以记录你想到的每一个idea和自己的计划、任务清单,甚至给自己写一个座右铭作为自己的slogan。白板在公司非常常见,放在家里可以作为自己的可视化工具,通过写下需要的思考的问题可以打开一个“上帝视角”,帮助我们更为客观的思考。

像公司一样决策

一直很好奇大的公司甚至政府是怎样做出好的决策的,普通人往往是在心里合计一下,然后拍个脑门就成,然而决策每天都在发生,小到出门要不要带伞,见女朋友需不需要买礼物,大到购置资产,投资理财,结婚买房等。“拍脑门决定”显然不是适用于所有场景的。

这里想提一个有意思的东西——易学,周易的功能之一是被古代政府用来决策事务,我曾经了解过一门叫做《奇门遁甲》的易学,这种方法是绘制一张格局图,用天干代表你周围的人际关系、资源,而“甲”就是自己,“遁甲”的意思是需要把自己放到一个客观的位置上来看待,方才能清晰的看待形势和做出正确的决策。

现代管理学中同样对“决策”十分重视,有很多书来阐述这个问题,甚至专门的决策学。其中有一个简单思维工具叫做SWOT,SWOT分析法(也称TOWS分析法、道斯矩阵)即态势分析法,20世纪80年代初由美国旧金山大学的管理学教授韦里克提出,经常被用于企业战略制定、竞争对手分析等场合。

举个例子来说明如何使用这个方法,如果我们需要考虑换工作(毕竟换工作对于任何人来说都是一件重要的事情),根据SWOT我们可以绘制一张表格来对比:

最后需要注意的就是别忽略沉没成本在一次决策中的影响,沉没成本是一个经典的经济学概念,通俗来说沉没成本就是已经投入的资源。比如一项商务谈判,前期付出的越多,后期也就越难放弃。有意思的是,沉没成本在恋爱中的效应同样明显,爱一个人越多,投入越多,则越难割舍。

对于一般来说,这种分析已经让做出选择的各项因素非常清晰,如果还是问题更加复杂,我们可以为每一项增加权重来做更为细致的思考,当然也更加复杂和浪费时间。因为做出决策本身也是需要成本的,当然也不应该在决策上花了太多的时间,没有完美的决策,简单的事情还是拍脑门儿吧。

任务和时间管理

时间就像海绵,挤挤就有的。我宁愿相信这句话是谎言、鸡汤和毒药,如果时间可以被挤出来,无非两种情况,其一是其他的安排或者娱乐时间被无情的侵占了,其二是你做事的质量被降低了,如果你在洗碗,那么可能不会洗的太干净。

时间需要被管理,任务需要被有序安排。大量的时间管理书籍证明了这一点,去年流行的《暗时间》写的非常好,书中讲述了作者大量的经历和管理时间的方法。

我更愿意把时间管理和任务管理结合到一起,在工作中我们的项目经理也是这样做的,任务管理是项目经理非常重要的一部分,不过我们用的是针对项目的敏捷开发/瀑布流方法,更为复杂和需要团队参与,对于个人而言需要更简化的方法,分为几个步骤:

  1. 任务拆分。拆分任务使得任务变得更简单可行是众所周知的方法,在笛卡尔的《谈谈方法》中,拆分已经被当做西方哲学和做事思想的内核。
  2. 评估价值。“评估这项任务是不是真的有价值去做”也许是浪费时间的行为,为什么还需要去做。然而我之前做了很多这种无用的事情,还不如打一把王者荣耀。
  3. 优先级排序。我们要把时间挤挤留给优先级高的事情,那么首先我们需要对任务进行排序。
  4. 时间控制。每个任务需要预估时间,以便于我们留出一段合适的时间用而不至于被中途打断。

为了管理这些任务,在公司我们有看板,对于个人而言推荐使用一些Todo List 工具。我偏向使用Chrome 上的插件,工具越简单越好,当然很多笔记工具都带有TODO列表。比如印象笔记、有道笔记,或者任何支持Markdown语法的编辑器,如果没有找到合适的工具,给自己桌子上贴一张便笺也行。

如果TODO列表工具有提醒的功能就更完美了,如果没有可以使用一些提醒工具,比如iPhone的手机提醒、Mac上的Calendar APP、适合国人使用习惯的QQ邮箱甚至提醒到微信和手机短信。

在做事的时候,专注可以提高效率,因此一个很有名的工作方法叫做番茄工作法被提出来。这种工作方法因一个番茄形状的厨房用定时器得名,手机上有大量相关应用可以下载。使用该软件可以让你在专注工作25分钟,随后有5分钟的休息时间,但25分钟内你需要保持高度精神集中,了解更多番茄工作法可以阅读《番茄工作法图解》一书。

(图片来自:番茄工作法图解)

知识体系和储备

我是一个程序员,程序员都有一个焦虑,那就是总有一大堆新的技术和工具等着你去学。几个月前我尝试思考如何解决这个问题,随着IT从业者工作的时间的增加,年龄渐长,同时还要面临家庭和其他方面的事务,越来越不可能把所有精力投入到技术的学习中(毕竟还要学习如何预防颈椎病)。

通过观察一些技术强势、但业余爱好也开展的红红火火的IT大拿,发现几点非常有意思的事情。

不同技术创造的价值不同。我们经常谈论是需要专才还是通才,是需要精通某项技术还是博古通今,这种思考方向还是略显片面。无论是刻意还是偶然,有些技术能学习投入更少但是赚更多的钱,学习技术也需要眼光。不得不承认,从一般趋势下,web前端需要了解一堆繁杂的知识但是没有java等后端开发薪资高。

知识像一棵树,需要具备一个体系。这条经验不仅仅适用于IT行业,我们在学习某些东西时,会去网上寻找各种知识清单、书单、技能图谱,我在之前的文章中也介绍过IT行业相关的图谱。对于人脑而言,记忆和学习是线性或者网状的,这也符合我们的认知,零散的知识非常容易遗忘。构建体系的知识,我强烈推荐画图,无论是思维导图(Xmind、MindMap)还是鱼骨图、组织架构图和韦恩图都是很好的方法,甚至构建自己的技术雷达。

(构建自己的技术雷达)

知识需要储备、学习需要有文档产出。在完成一个项目或调研后,公司都会产出一定的文档,每个专业公司都有这样一个资料库,当我们遇到问题的时候可以从中找到相关信息。在工作中我曾经用过禅道、金山云、confluence等,相比之下,禅道不仅仅是一个文档管理工具,更是一个项目管理工具,而金山云文档搜索功能略差,confluence则是一个专业的团队文档管理工具,但是需要付费。

对于个人也一样,学习任何东西都需要有产出,在记笔记之外,写作是一个不错的方式,开通博客或者专栏来让学到的知识能够更好的沉淀,因此我整理了一个在线写作平台的清单:

国内篇

国际篇

就文档管理而言,如果不希望自己的文档被发布出去,或者认为某些资料不是通常意义上的博客,使用Wikidot编写自己的Wiki来管理文档也不错。如果是程序员的话直接使用Github做文档管理或者给自己搭建一个Wiki,也不是非常难的一件事。

我自己偏爱用Markdown格式来管理自己的文档,因此创建了一个代码仓库用来放置所有文档,然后Hexo发布到github提供的静态资源服务器上供自己查看,有了这些工具和输出之后,我们能知道哪些知识是我们需要的,哪些知识暂时不需要但是在需要的时候能被快速的捡起来。

情绪管理

在第一家公司工作时,我们老板讲了一个故事,曾经因为产品出现问题,很多下级经销商上门闹事要求退款,大多数人情绪十分激动,甚至有人打砸物品,都被老板一一化解。后来来了一个年轻的经销商,笑眯眯的来到公司,淡定非凡,和老板重新聊合同和赔偿的事务,这个人看起来并不生气,只是索取了大量相关资料。据老板讲,这个人应该在收集证据和资料用于后面走法律途经,因为是我们理亏,所以老板做出了让步、答应了他全部的退款条件。

我不知道人类演化出“抱怨”“气愤”“愤怒”等情绪的意义在哪里。当我们在工作中遇到麻烦,第一反应是抱怨;当别人指出我们的错误时,往往第一个动作是怼回去;遇到矛盾,我们会被激怒。但是当我们回顾这些行为本身,会发现抱怨对工作毫无益处,怼回别人的意见对自己也并没有帮助,即使在一场战斗中被激怒的一方往往会处于险镜。

我曾经看过一本书叫《不抱怨的世界》,书中提到一个很好的方法来减少抱怨:佩戴一个手链或者手环,当你意识到自己在抱怨时,交换手环到另外一只手,通过这种微小的心理暗示来矫正自己的不良过激反应。

生气是人的本能,没有谁能完全控制自己,一个好的建议是当我们感到愤怒的时候,请不要做任何行动和决策,先让自己安静下来至少30分钟。心理学上对于不良情绪的管理建议不要对抗不良情绪,而接纳和发泄是更为可行的办法,避免形成强迫行为,我们的目的不是消除负面情绪,而是不让情绪影响到决策,然后使用其他途径进行发泄和疏导。

写在最后

很多时候,管理这个词用到个人身上略显奇怪,对大多数人而言,管理知识如同屠龙之技。其实当把管理的各种方法用到生活中,管理并不是权利、控制和压迫,而是理性思考、引导和推动。管理并不一定是对下属,甚至可以管理上级、爱情和家庭,用各种可以学到的方法、技巧把生活打理的仅仅有条。就像古人“修身齐家治国平天下”,“修身”不正是管理自己么。限于篇幅,我们能从公司运作和管理的哲学中学到更多,希望后面有机会分享给大家。


更多精彩洞见,请关注微信公众号:思特沃克

Share