人人都爱写总结, 却少有人做计划

  

  每到岁末,人们都会不约而同地、自发地写各式各样的总结。上个月,也就是 2018 年的最后一个月,园子里各处散落着无数篇年终总结贴。看过一些篇章,都写得挺好的。

  转眼 2019 年已经运行了大半个月了,忽然意识到,似乎没人晒出自己的新年计划。可能零星有几篇,但和上个月蔚然成风的总结热比起来,九牛一毛了。

  有人会说,个人计划有隐私之嫌,不合适晒出来,所以就算有,也是 " display: none ".

  不错,但回想之前铺天盖地的总结文章,很多人都是足够赤诚地把自己过去一年扒了个精光、敞开心扉地晒,既然舍得把自己的过去一五一十地交代出来,那自然也可以取其同等密级的未来做个猜想吧。如果这样的计划也不便透露的话,那为什么愿意晒总结呢?

  当然了,却有不便透露的信息:比如来年跳槽的打算、删库跑路的方案、换个小三的想法、破坏某人家庭的预谋,等等…… 这些就自己捂好了。

  有时间和精力对过去总结,甚至写出很好的文字并热心分享,却没有关于未来的计划,至少没有独立可见的文字篇幅。这是一个普遍现象,不仅仅只存在于园子里,推广到别处也都差不多。
  这是个有意思的现象,不免胡思乱想了一通。

  个人以为,计划其实比总结更具有建设性
  计划是主动的,总结是被动的。计划首先意味著你有目标,有了目标,才会有决心和动力。人们常常讲求方法与效率的重要性,固然不错,但在方法之前,是方向。“对于盲目航行的帆船,什么风都是逆风。”
  打个比方,以理财中的储蓄为例——很多人应该有过这样的体会:如果每个月给自己设定一个固定储蓄目标,每次领到工资的第一件事就是把目标金额先存好,一年下来,你确确实实会有笔存款。而如果没有设定固定储蓄目标,只是设想等到月底将当月剩下来的钱进行储蓄,那最有可能的结局就是——月光。待年终总结,储蓄失败。
  花钱也一样,很多人都有记账的习惯,但如果希望管控自己的消费行为,预算的作用比记账大多了。那些只记流水账,却不做预算的人,往往会周而复始地感慨“这个月又花了好多钱,下个月再不能这样了。”而如果你认真做了预算,你就心中有数,在每次消费时,会犹豫本次消费是否“合理”,这多出来的一点犹豫,就起了管控的作用。未雨绸缪胜于亡羊补牢,更何况那些亡了羊却补不牢的时候了。

  由上面的,联想到一个更加普遍的现象,有些人会在年终总结的末尾,用大约10%的篇幅罗列出明年的愿望清单,然后就当做是计划了。把目标当做计划,这是误区。

  比方说,一次军事行动,要摧毁敌方的司令部,这是目标。如果你把这当作行动计划,就带兵去打,那你的兵死得有点冤。再比如,立了一个Flag,来年要把前台MM追到手,这只是愿望。具体怎么追?才是计划。
  做计划实际上是对过程管理,当你有了目标并对此做出了计划,意味著你至少是有过思考的,这就走心了。而仅仅只有目标,那就只能走肾上腺素了。
  思考是一种神奇的力量,在思考的过程中,会强化目标的概念,加深对目标的理解,经过思考,你会确认目标,收获决心和动力。这里不一定非得完全靠自己冥思苦想,完全可以借助他人的智慧辅助分析。思考的结果会对行为产生指导,通常,你会获悉完成目标所需的步骤。
  步骤,就是算法,就是解决方案。
  从这点来看,相比写总结,做计划的技术难度要大。这可能也是“多总结、少计划”这个现象的原因之一。写总结是对已发生的事情进行回忆,只要记忆没问题,平铺直叙都能成文,尤其是流水账一般的总结,根本不用动脑子。而做计划,包含了对未来的预测,这就难多了。但所谓的建设性,也就体现在这里,正是因为要克服困难,才使得产出有了价值。我很喜欢一句英格兰的谚语:“Where there‘s muck, there‘s brass.” 一直做容易的事情,是不可能有进步的,要想管理人生和未来,怎能不舍得下工夫。
  阻碍人们认真做计划的另一个原因,那就是常常听到的“计划赶不上变化”。这个在 IT 界,简直是家常便饭,今天做的计划明天就得改,于是计划就显得没什么作用了。

  但个人以为,越是“赶不上”变化,越需要有计划。怎么说呢,两点体会,权当胡诌。
  第一点,当你没有计划的时候,乱七八糟的事情会特别多,但当你有了计划之后,很多意外的事情会减少。听上去有点玄学的味道,但也不是完全没道理。

  拿我自己来说,我是一个有“拖延症”的人。当我有了一个目标但没有制定计划时,我十有八九会拖延,一边拖延,一边做了很多其它不相干的事情,这些其它的事情可能就会给我带来额外的麻烦,对我实现原本的目标产生干扰。但如果我做了计划,分解目标,制定时间表,我就能有效地治疗“拖延症”,因为我时刻都处在自己构建的过程管控中,每一步的衔接都有安排,这样我的注意力就容易保持集中,甚至全程高能。而我发现,精力涣散最容易发生在当你不知道下一步该干嘛时

  第二点,确实存在变数很多的客观场景,在这样的险恶环境中,你更应该加倍地做计划,改计划。一方面,这是唯一让你在风云变化中能有所依靠、有所参照的资本。就好比,需求的变更是无法避免的,但我们可以做好需求管理,至少知晓变更的发生,这同样也是一种经验的积累。另一方面,在迭代计划的过程中,熟能生巧这个规律会让你逐渐得心应手地面对变化,除非你是傻子死不开窍另当别论。永远不要低估积累的力量,你努力应对变化,慢慢地,你就能驾驭变化,变化就不会成为干扰。能力就这样成长了。
  

  说到计划,自然要说到“时间表”这个概念,做计划的方法很多,无一例外会涉及到时间表。脱离时间的计划是伪计划,因为人的时间是有限的,而且很多事情是有时效性的。
  这就需要估时。
  也是个棘手的技术活,毫不夸张地说,这是世界性难题。所以如果你总是估不准,完全不用自卑,全世界都一样。当然,办法还是有的,事实上,根据不同的计划范围,我们并不一定需要很精确的估时,过日子又不是开火车。
  大约 20 年前,大名鼎鼎的 Joel Spolsky(稍等,也许你没听过这个名字,但我100%肯定你用过他的产品 - Stack Overflow, 如果你不幸没用过这个网站,那我200%肯定你用过他的产品 - Excel)总之,这位大人物在 2000 年写过一篇博文 "Painless Software Schedules ", 介绍了一套他自己的“软件开发时程”方法论。虽然有些久远了,甚至作者自己都修改了文章的开头,提醒读者他已经有了更好的替代方案,但这并不影响该方法的价值,而我自己在学习了他这套“过时的”解决方案之后,一直将其用于自己的工作、生活中。
  概括来说,该方法的核心思想有两点:目标分解 & 估时修正
  目标分解是做计划的基石。罗马不是一天建成的,大事化小是所有干大事的必经之路,这也是强迫你认真做目标分析的手段,合理的分解只可能建立在对目标的充分认识之后。
  分解的颗粒度要足够细。因为原文讲的是软件开发,所以作者明确提出,在编程中,任务要按“小时”来评估,而不是按“天”。这个单位的变化很重要,单位大了,误差就大。按照作者的经验,超过 16 小时的任务都应该进一步拆分,因为在这个时长之上,意味着你并没有真的想清楚要做的步骤是怎样的。说得直接点,就是在糊弄人。
  当然,我们在做个人全年计划时,不必生搬硬套拿小时做单位。这里的要点在于计划要足够细才有意义,至于说具体细到什么程度,这个其实需要根据自身经验去琢磨。非要说有什么窍门的话,也许拿大众的普遍标准再进一步就可以了,比如大家都按天算,你就试着按小时计,大家都按月算,你就试着按周来计。群众的眼睛也许是雪亮的,但群众的做法通常是平庸的,所谓脱颖而出,往往就是在大众平均水准之上再进一步,你就先进了。
  在计划初期,你会有一个初步估时,随着进度的发展,比如到了中间阶段,可能发现之前预估的时间不对,这时你需要写下第二次估时,最后当完成任务时,再记录下实际耗时。最终,你会得到 3 个时长:第一次估时、第二次估时、实际耗时。
  一开始,你可能(几乎肯定)这三个时长看上去牛头不对马嘴,随着不断地纠错、修正,从过去错误的估计中总结经验。第二次估时会和实际耗时越来越接近,再后来,第一次估时和第二次估时也会越来越接近。到那时,你对于估时的判断力就练成了。
  简单的手法,坚持做,就会产生神奇的效果。

  ”人一能之,己百之,人十能之,己千之,虽愚必明,虽柔必强。“ 这是这个道理。(语出《中庸》)
  

  该方法让我很喜欢的另外一个重要原因是,作者用来实施这套方法论的工具很亲民——电子表格。易用的产品才会有市场,易实践的理论才容易推广。再则,一份 Excel 文件,很易于交流。若干次项目中,当我把充满详实数据的 " Schedule.xlsx " 发送出去,会从老板和客户那收到信任的回复。
  管理要出活,量化是关键。当别人在定性分析阶段时,你定量解构出工作包,水平就跃然纸上了。尤其是对于许多没学过真正管理学的一线码农转型做管理的人来说,量化是入门管理的捷径,其它的门道水太深,也学不来。

  

 

  关于 Painless Software Schedules 完整的介绍可以参见原文链接

  说到使用 Excel,顺带说说另一个“喜闻乐见”的概念——甘特图(Gantt )。
  但凡提到计划,几乎必有甘特。尤其是在 PPT 当中,敢情不拉一张甘特图,你这项目管理的专业度都要打折扣。制作甘特图有很多专业工具,比如 Microsoft Project, 以及那些需要投入一定学习成本的资深产品。作为一名半路管理工作者,我在绝大多数的情况下,就用“Excel手绘”,简单明了,方便快捷,重点是学习成本为零。

  要说Excel能完成的工作,比想象中多

  我曾经就这个玩意和我的一个好基友聊过“这破图除了好看有啥卵用?”然后被教育道:“你不当老板所以这图没用。对于大领导来说,人家每天日理万机、分分钟多少万进出的,想最快地了解项目计划,甘特图就是最直观地工具了。”
  所以,说到底,格局啊……
  顺带说一句,我这位基友最近刚刚拒了微软,入了阿里。我不禁问他,举国上下不都在裁员吗,你怎么还跳得这么任性?他说,企业只要发展,有裁员就会有纳贤,对于企业来说,只是结构调整罢了。跳槽的人,一般都不会大声嚷嚷,而裁员更容易制造舆论效应,所以你要是天天盯着媒体看就觉得这世界活不下去了,但其实优胜略汰一直都存在。

  随着去年底的一波裁员潮,几乎整个冬天都弥漫着一股名叫“中年”的危机。说到“中年危机”,这是一个老生常谈的网红词汇,这话题要展开来说可以无穷无尽。

  其实,不是年轻没有危机,只是中年没了借口

  无论中年、青年还是未成年,危机一直都在。只不过年轻可以挥霍,可以犯错,甚至一错再错,但犯错终究要受到惩罚的,到了中年,周遭的客观环境忽然间都不给你退路了,就危机了。

  潮来时肆意妄为,当潮水褪去,才发现自己在裸奔,于是怪大海无情,但有水的时候为什么不早穿裤子?

  人无远虑、必有近忧,居安不思危,不裁你裁谁?

  不是我故意要把话说得难听,因为现实就有这么难看。
  危机的背后,是能自主选择的选项越来越少,路越走越窄了。如果在年轻的时候早做打算,虽不一定就能掌握行业方向,看清产业布局,但你会保持职业规划的敏锐度,发现机会的概率就大。生机大了,危机自然就小了。
  

  张爱玲曾说:“出名要趁早。”

  何止是出名,哪怕只是为了避免失败,都要趁早准备。

  我们都是笨鸟,不过是谁先飞。

原文地址:https://www.cnblogs.com/sherrywasp/p/10301241.html

时间: 2024-10-03 23:00:25

人人都爱写总结, 却少有人做计划的相关文章

NoSQL初探之人人都爱Redis:(3)使用Redis作为消息队列服务场景应用案例

一.消息队列场景简介 “消息”是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,“消息队列”是在消息的传输过程中保存消息的容器. 在目前广泛的Web应用中,都会出现一种场景:在某一个时刻,网站会迎来一个用户请求的高峰期(比如:淘宝的双十一购物狂欢节,12306的春运抢票节等),一般的设计中,用户的请求都会被直接写入数据库或文件中,在高并发的情形下会对数据库服务器或文件服务器造成巨大的压力,同时呢,也使响应延迟加剧.这也说明

NoSQL初探之人人都爱Redis:(1)Redis简介与简单安装

一.NoSQL的风生水起 1.1 后Web2.0时代的发展要求 随着互联网Web2.0网站的兴起,传统的关系数据库在应付Web2.0网站,特别是超大规模和高并发的SNS类型的Web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题: (1)对数据库高并发读写的需求 网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求.关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求

达芬奇画作赏析 为什么人人都爱达芬奇?

为什么人人都爱达芬奇? 达芬奇出生于1452年的4月15日.他不仅是一位才华横溢的艺术家,也在解剖学,工程学,生物学,数学以及建筑学中有所建树.他的发明创造与探索发现远远超出了他所在的那个时代.正如达芬奇所说:“最崇高的快乐是享受探索世界的乐趣.”BBC Culture 开辟了一个栏目让观众谈一下他们最喜爱达芬奇的哪幅作品,并且解释原因.以下是读者的回答. <女子头像>(La Scapigliata) 来自希腊的Fani Tsoukala from Athens,说道: “她就像一位女神,低头

NoSQL初探之人人都爱Redis:(4)Redis主从复制架构初步探索

一.主从复制架构简介 通过前面几篇的介绍中,我们都是在单机上使用Redis进行相关的实践操作,从本篇起,我们将初步探索一下Redis的集群,而集群中最经典的架构便是主从复制架构.那么,我们首先来了解一下神马是主从复制架构? 1.1 源于关系数据库的读写分离 随着网站业务的不断发展,用户量的不断增加,数据量也成倍的增长,数据库的访问量也呈线性地增长.特别是在用户访问高峰期间,并发访问量突然增大,数据库的负载压力也会增大,如果架构方案不够健壮,那么数据库服务器很有可能在高并发访问负载压力下宕机,造成

【转】 NoSQL初探之人人都爱Redis:(4)Redis主从复制架构初步探索

一.主从复制架构简介 通过前面几篇的介绍中,我们都是在单机上使用Redis进行相关的实践操作,从本篇起,我们将初步探索一下Redis的集群,而集群中最经典的架构便是主从复制架构.那么,我们首先来了解一下神马是主从复制架构? 1.1 源于关系数据库的读写分离 随着网站业务的不断发展,用户量的不断增加,数据量也成倍的增长,数据库的访问量也呈线性地增长.特别是在用户访问高峰期间,并发访问量突然增大,数据库的负载压力也会增大,如果架构方案不够健壮,那么数据库服务器很有可能在高并发访问负载压力下宕机,造成

【转】NoSQL初探之人人都爱Redis:(3)使用Redis作为消息队列服务场景应用案例

一.消息队列场景简介 “消息”是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,“消息队列”是在消息的传输过程中保存消息的容器. 在目前广泛的Web应用中,都会出现一种场景:在某一个时刻,网站会迎来一个用户请求的高峰期(比如:淘宝的双十一购物狂欢节,12306的春运抢票节等),一般的设计中,用户的请求都会被直接写入数据库或文件中,在高并发的情形下会对数据库服务器或文件服务器造成巨大的压力,同时呢,也使响应延迟加剧.这也说明

第二篇:人人都爱Protocol Buffers

protocol buffers是google提供的一种将结构化数据进行序列化和反序列化的方法,其优点是语言中立,平台中立,可扩展性好,目前在google内部大量用于数据存储,通讯协议等方面.PB在功能上类似XML,但是序列化后的数据更小,解析更快,使用上更简单.用户只要按照proto语法在.proto文件中定义好数据的结构,就可以使用PB提供的工具(protoc)自动生成处理数据的代码,使用这些代码就能在程序中方便的通过各种数据流读写数据.PB目前支持Java, C++和Python3种语言.

【head first python】1.初识python 人人都爱列表

#coding:utf-8 #创建简单的python列表 movies = ["The Holy Grail", "The Life of Brain", "The Meaning of Life"] #可以放在同一行,但分开会更易读 #和数组一样,列表的项从零开始 print movies[1] #>>>The Life of Brain print movies #>>>['The Holy Grail',

【转】NoSQL初探之人人都爱Redis:(2)Redis API与常用数据类型简介

一.Redis API For .Net 首先,不得不说Redis官方提供了众多的API开发包,但是目前Redis官方版本不支持.Net直接进行连接,需要使用一些第三方的开源类库.目前最流行的就是ServiceStack.Redis这个开源项目,其在GitHub上的下载地址为:https://github.com/ServiceStack/ServiceStack.Redis 进入下载页面,点击“Download Zip”按钮,即可下载该API包.解压该Zip包后,其实我们所用到的只是其中的几个