如何多线程工作 如何学会多线程工作?
发挥失常也是正常
往往在一开始的时候,多线程工作(Multitasking, or Human Multitasking)可能会让我们有这些感觉:思路没有头绪,连续几天都手忙脚但又说不上来自己究竟在忙什么,做事的效率和速度不尽如人意,品质可能也有折扣,甚至出现一些错误。
而像诸如沮丧、焦虑、烦躁的情绪,也是不少人面对多线程(或多任务)工作初期会出现的心理反应。我还遇到过这样的例子:有位同事专注做一件事的时候专业水平很是了得,可一旦双线多线作战,就整个发挥失常,顾得到左边就顾不到右边,工作一直出现小纰漏。
所以在探讨任何问题之前,即便自己觉得多线程工作有点吃力,拿捏不好,也不要在心里质疑否认自己的能力水平。因为我们,至少绝大部分的我们,都是凡人,没有天赋异禀,在一开始面对多线程的时候出现上述现象都是自然的和正常的。这无关我们的认知水准,或工作学习能力,这只是关乎我们处置任务,拿捏事物的方法和手段。
多线程不是多线程
虽说我们称其为多线程,但事实上,我觉得,在每个具体的时间段里,我们还是在像从前一样,在一个较短的时间段里完成一个单独的任务。
比方说,这周末有四门考试,我平时又没怎么听课,所以要在这一周里要同时预习(美其名曰复习)这四门功课。看,一个典型的四线程的任务。但我们真正做的,并非摆四本书在桌上“同时”读,而是花几个小时读这一门课,然后花几个小时读另外一些课,一门课一门课换着读,甚至一门读完再读下一门。
再比方,今天我得做个实验,有另外一份报告要写出大纲,下午有场会议也要做准备。这些事,其实也并非真在齐头并进、并肩行走。说到底,不管怎么去安排,还是要一个一个,有前有后的来。没有人会傻到(或强悍到)边写报告边做实验边参加会议。
所以说到这里,我觉得出现了第二个很重要的认识,就是,没必要、也不要真的在同一个时刻做很事,一件一件来。这种道理很常见,例如开车时不要打电话,例如走路不观景,观景不走路,等等等等。
这样一来,既然我们还是在像从前一样单线程的做事,每件事的时候应该不难保持住自己昔日专注于单独一件事的时候的高水准。
时间管理的方法们
呃,回答问题的人尚不具备专业的管理学知识,所以下面这部分观点和解释可能有失偏颇。
各式各样各代的时间管理理论看起来有一个相似的诉求:心里要有计划,要给自己的任务或子任务列一个有顺序有轻重的清单,然后有规划地去完成他们。
列任务,分任务
可以把没那么庞杂的几件小任务写到便利贴记事本上,提醒自己不要忘记做其中的任何一件,如果记忆力足够好,记在脑子里也没关系。
值得写下来的内容包括,但不限于:这一个任务已经做完了哪一些?还有哪些要接着做?有什么小问题是尚未确定但千万记得要及时解决的?卡在什么环节上了吗?如果卡住的环节无法解决,后续的哪些事会受到波及牵连?完成任务的过程里有没有什么事情是值得和同学同事老板主管汇报分享的,好让他们对进度和境况有更好的认识?
思考这些问题连三分钟都不要,但好处是能让我们在几个任务间切换的时候,明白什么做好了,还要做什么,有点像是戴明循环()里的Check Point. 临走前检查一下,看有没有什么遗漏的。
所以能避免这样一种尴尬情况:时隔几天以后恍然大悟,哎呀,当时怎么把AAA忘记了(或怎么忘记考虑BBB这个因素),现在这个项目(或实验、设计)木已成舟,马上都要交付给客户了(或汇报给教授、主管了),这可怎么办?修改起来肯定伤筋动骨。时间线,日程表
也可以想一想日程(时间、进度)规划,或者在手头的日历上标注一下重要的时间点。
当然不必完美计算好分分秒秒,因为计划永远赶不上变化,但可以帮助自己在重要的时间节点审视一下自己的进度,帮自己评估一下日后同类型的事务大概需要花上多少时间,是不是跟自己原本想象的那样。因为有时候我们“以为的小事”要花超过我们预想的时间和精力去做,而“以为的大事”又没有想象中那么劳心伤神。
另外,如果情况有变、计划有变,看一看日历,也好让自己思考接下要怎么修订自己的计划才合适。这可能会避免出现:哪知道当时做CCC的时候出了那么多小问题,那么麻烦,一拖再拖,现在好了,只能简单应付一下DDD这部分,然后赶快把结果草草交出去。轻重,缓急
接下来就是最好用的方法:就是想一想任务们的优先级,给他们分清主次啦。
ABC分类( )就很流行,但是我觉得艾森豪矩阵(Eisenhower Matrix )的思路更清楚实用,艾森豪把事情分成重要和紧急两种维度,做事的优先级顺序大体上是先做重要并紧急的,接着是重要但不急的事(例如关键的决策,任务的核心事物,研究里需要花精力思考的问题),然后到急事(更容易理解的说法是干扰,interruption),最后做无关紧要的小事。
这个优先级的顺序并不是说做事的实际顺序要这样,他并不是说一定要把重要并紧急的事先做完,也不是说重要的就一定要放在急事前面。而是说,我们尽量不要让优先级比较低的事,对优先级比较高的事造成过分的干扰。是说,务必把心思放在重要的事物上,把他们做好,千万保证重要事项的工作质量,因为他们是如此重要,是不能容忍差错和纰漏的。
而那些急事,比方突然打进来的电话,恰好送达的快递,你当然可以选择放下手头的事去接电话收快递,反正也就是分分钟的事,但是如果你正在会议里做严肃讨论,你正在做实验里最重要的观测,那你也可以暂时不去理会这些干扰,请他们稍等。按自己喜欢和习惯的方法来
上面的方法们提供了一些思路来帮助我们自己完整地去认识手上任务的具体内容,来厘清手头任务间的虚实和轻重。这些方法没有谁比谁好,谁比谁先进,谁比谁更实用,自己平时做起事来大可不必每天专拨时间来列清单、写日程表、作优先级矩阵图,就像前面讲过的,如果心里的线条已经很清晰,如果记忆已经很完善,那全放在自己脑子里也无妨。
上面三种方法的目的只是为了帮助自己把多线程工作这团乱麻拉直、理顺,所以无需拘泥于其中任何一种形式,不管自己是喜欢写纸条画日历,还是用软件规划进程都没关系。对自己来说,哪些方法更有效,更习惯,怎么样梳理事物更符合自己的思维方式就按照那样来。
自己思路到底有什么好理顺的呢?
随手举一个例子,比方我突然被指派在两个月内写三篇论文,要怎么办怎么写?在写到第二篇论文的时候,实验结果总是不尽人意,究竟是该专注解决问题,还是先放下赶快做第三篇?第三篇的价值高吗?还是说第三篇只投给不甚重要的小会议?感觉第三篇很快就能写好啊!但转念一想,说不定很倒霉写到一半又在实验上出问题怎么办?什么是最坏的情况?就算按最坏的情况来,我有能力按时完工吗?还是第二篇才是课题的核心部分,如果没有了第二篇,那第三篇就没什么意义呢?要是这时候恰好教授回复了第一篇的修改意见,要先读读看吗?是只读一读还是顺便把修改也完成呢?每篇的截止期分别是什么时候,我心里清楚吗?月末还要好好过个圣诞节,就算做完第二篇或第三篇,教授届时会有时间有功夫读一读初稿吗?我之前曾经跟教授沟通过这件事吗?教授知道实验卡壳的事吗?他的想法是什么?如果他届时都没空闲看初稿,现在赶工也是白费,那日程要怎么规划才有意义?
这些问题可以无穷尽的问下去,每一天过去有一些问题就会有答案,每一天开始也会生长出另一些新问题。当我们置身各项任务的沙漠里不知何去何从的时候,上述的那些手段,能给我们的决策提供一些思路(例如,什么是最重要的有意义的事?什么问题是无关紧要,可以妥协的?),能让我们对周遭的境况有更明确的认识(例如,卡死在哪里?有什么潜在的问题?),能提供一些可行的方向(例如,我要先解决什么,后处理什么?),也弥合了我们在不同任务间切换的时候产生的思维的空白(例如,上次这个项目做到哪里了?接下来该干什么?有什么要及时更正完善的?),还能提醒我们记起不经意间忘却掉的重要信息(例如,交付结果之前自己审查过了吗?有的参数中途被修改过了,至今还没有重新做校验实验。),提示我们不要放过可能埋下隐患越滚越大的小问题。
确保品质的笨办法
如果害怕在无数任务之间来回切换会降低准确率或者工作品质,戴明循环是个不错的确认方式。戴明循环是指Plan计划,Do做事,Check检查,Action改良,四个步骤,然后是下一轮的重新Plan……其实我们大多数人平日里本来就是这么做事的,操作起来很容易。
如果手头有太多事占据我们的大部分脑力,以至于真的顾东忘西的时候,就要把自己嵌入这个循环里,每做完一小部分(或者是一大板块,甚至整个任务),在对你的工作点“确认”键之前,在把设计、报告、产品交付给别人之前,先要进入检查环节。随便你,可以做详尽检验,但如果时间不够,也可以粗略的核实最重要的框架,最最粗略的检查至少要保证交出去的作品不出“大错误”,“方向性错误”,“本质性的错误”。
检查发现的任何问题,要修正改良(Action),如果已然来不及更正,那至少在后续的工作里弥补。如果日后还有类似的工作,那么有一个不错的方式,就是曾经觉得需要改进的地方,在日后的检查(Check)环节里专门看一看,有没有犯之前的错误。这样前事不忘后事之师,同样的错误永远不会犯第二次。
根据以往的经验对日后的新任务再次进行PDCA的往复循环,这个循环就会越来越严谨越来越完善。
没有误会的沟通
深陷多线程任务的时候,还要记得及时地有建设性地与他人沟通交流。不要因为时间紧迫就只顾默默低头做事而忽略了和对方的信息交换,更新。
沟通上的误会,严重的会所带来重复工作(rework),因为沟通而导致的重复工作实在是太令人懊恼了,绝对应该避免。
上面的漫画虽然不是针对时间管理的课题,但反映了很常见的沟通问题。对每一项任务,在答应下来的同时,务必尝试弄明白对方究竟想要的是什么?
例如,EEE同学,你能把这个实验简单整理一份报告让我看一看吗?
发问的是指导老师吗,还是实验室管理员,还是同门师兄弟?想一想你沟通交流的对方,他们究竟是谁,指导老师想要看到的内容,和实验室管理员需要的内容在侧重点上不太可能是一致的。如果你详尽介绍了实验结果的发现,但是对方(例如管理员)可能只是想了解一下实验器材的使用情况罢了,如果真是这样,那报告就显得很没意义,说不定是要花时间重做。
即便是指导老师本身,他究竟是想通过报告看实验的过程,来审查实验是否有漏洞呢?还是想读一读结论数据了解一下科研的进展?还是想把报告当成一份论文草稿的框架?这些问题答案不一样,报告的写法和重点都应该是不一样的。反过来,如果懂得对方的心思,那就省却了很多精神,不必全盘用力,只需要把气力花在对方想要的那一部分就对了。
很多人提出要求和安排任务的时候,都像上面讲的一样简单直接:“你可以去做一做FFF吗?”“请把GGG拿给我。”“明天我们谈一谈HHH的问题吧。”他们往往不会在语言里介绍自己究竟想要什么,所以我做FFF的时候,到底是要缜密精细地做,还是粗略迅速地做?我去拿GGG的时候,一起把JJJ也带过来会不会更好?他是想咨询HHH的问题本身,还是通过HHH的经验为KKK的问题做一些铺垫?相应的,我要为这次对谈做哪些方面的准备?
“你究竟想要什么?”这个问题是可以问,也是值得问的。
另一种沟通上的问题就是没有及时和伙伴们分享进度,也没有及时知会他们任务遇到的问题。
我们都不是一个人在做事情,及时更新进度,通告自己的进展,言明自己遇到的障碍,都好让对方及时作出反应。沟通本身是个大课题,大概也并不是时间管理方面所专门探讨的,所以也不多扯。
最后,我觉得好像没有什么特别的“训练方法”或者“培训课程”来锻炼多线程操控的能力,多线程的工作的能力只是日渐积累的厘清各项大小轻重任务关系的能力,并能在身陷繁杂具体的任务时,思维上能偶尔抽身、退一步、审视一下全局能力。
其实也没什么奥妙,没什么高科技,大概像老话讲的,做得多了做得久了就好了,熟能生巧,水到渠成。想想每日生活,一天下来要上班要做饭要开会要见客户要买家用要买食材要接送小孩要探望父母要吵架要约会要运动要娱乐,其实我们大家人人都在多线程啊。
更多阅读
多线程的使用(Delphi) delphi多线程实例
TThread在Classes单元中声明,直接从TObject继承下来的,因为,它不是组件.TThread是个抽象类,所以不能创建TThread的实例,而只能创建其派生类的实例.利用TThread类来编写多线程应用程序的一般步骤如下:[步骤一]从TThread类派生出一个
linux 下多线程编程 linux下的多线程编程
共13章:第一章 线程基础multithreading可以被翻译成多线程控制。与传统的UNIX不同,一个传统的UNIX进程包含一个单线程,而多线程(MT)则把一个进程分成很多可执行线程,每一个线程都独立运行。阅读本章可以让你理解:Defining Multithreading T
php进程后台调用(多线程/进程) php 多进程与多线程
php进程后台调用http://blog.iyi.cn/start/2006/11/php_6.html这两天在研究php模拟多线程的问题,碰到一个问题就是无论exec、popen、还是proc_open都会造成等待,也就是阻塞式的调用,而我想要得是无阻塞的调用,让程序在后台执行就可以解
Linux下Qt多线程编程 linux下的多线程编程
作者:武汉华嵌技术部以下和大家分享Linux平台下Qt两种多线程编程的方式:1、使用Linux平台下的线程函数。以下是给出的代码片段://此处为连接信号和槽,通过Qt界面中两按钮来控制两个槽函数connect(pthred1start, SIGNAL(clicked()), this
由StreamWriter.WriteLine引发对C#多线程的深入思考 c streamwriter
http://www.cnblogs.com/linecheng/archive/2011/09/19/2210952.htmlC#中使用Monitor类、Lock和Mutex类来同步多线程的执行:http://