工作日志:高筑墙、广积粮,练好内功最重要

按:
这是在公司内部社区写的。本意是为别人而写,但我想,它也正好记录了我自己的认识。所以,以后若有类似不涉及公司、产品及同事隐私的日志,也会将其记录在我的个人日志里。

Hello Everybody,

我一直在思考两个问题:
对于个人,我们的技术如何更快地成长?同样的技术能力,如何才能工作生活得更有效率?
对于团队,如何才能更有效地沟通、协作?如何形成舒适的工作氛围?如何达到能力互补,具备强大的整体战斗力?

每当观察到一个相关的现象,我都会把它记下来,待到下周一时与大家分享。可是,看到大家那么严肃的样子,我又反思自己是不是说得太过份了……。

我想,不如我换一种做法,把它写下来吧。恰巧现在是我们年中总结的时机,那么,就从这次开始。

下面是随机记录的一些事情,没有多大的逻辑关系,也不一定是正确的,只是我一时的想法,和大家共勉。:-)

————————————————————————————

珍惜时间:
并不是说大家不珍惜时间,相反,都很努力。我只是感叹时间真的太宝贵。在学校的时候,我们常说青春、青春易逝,那个时候只是在无病呻吟;如今,像是真的能看见时光在眼前流逝。一晃之间,一个星期就没了,一个月也没了,不小心就到了年底。好在我们还没有七老八十,还有一丝资本可供挣扎,我愿与大家共勉:不徒费了光阴,努力使它过得有点意义。倒不是说,要大家多加班,努力工作自然是好事,工作之外有意义的事情也是好的。譬如,钻研跟工作关系不大的技术,或是提高提高自己人文方面的修养。重要的是,我们是清醒的,并且是高效的!

对自己的作品负责:
实话说,这是我对大家不太满意的地方,特别是两位新同事。你们已经转正了,我希望你们在学校或者别的地方养成的敷衍的习惯,能够到此终止。
一件事情交给我们,我们就要对它负全责。首先思考,应该采用什么方法,有多少种可能,它们的优缺点是什么,怎么选择。考虑了,拿不定主意,那只是经验的欠缺;但如果什么都不想,就等着别人来给我们画好条条框框,那就太没有追求了。
特别是,做完的东西,自己要把好关。这个作品,它代表了你的态度品味、技术水平,你自己是否满意?举个明显的例子:代码评论那个,难道开发完了,不会自己试一下的!?要知道,我是真心地相信它完成了,实实在在地在使用,并不是来做边界测试挑刺的,结果第一次用就出了问题。类似这样,我拿到手里随便看一下就发现无数问题的例子太多了……。
我们是一个靠谱的团队,这是得到公司其他部门认可的。我希望,靠谱的人不要做出不靠谱的事来;更希望,这个靠谱,不是经过我加工出来的。每个人,他的作品直接拿出去,都应该是自豪的、经得起推敲的。

细节的讲究:
我看到很多重复的、无意义的 commit log,有人可以解释一下你为什么这么懒吗?我看到有文件名是 js.js、css.css,请问,取个有意义的名字真的这么难吗!?不光如此,也包括目录名、类名、方法名,以及很多其它的细节。将各种细节问题揭示给大家,确是我的职责,但我更希望大家自己能有发现这些细节的眼光。

学习借鉴、拓展视角:
有时候,我们做的东西在公司内部或者市场上已经有可借鉴的案例。大家不妨多参考一下。当然,并不是说看得越多越好,重要的是我们看的时候要有思考。先要有自己的构思,在构思的过程中,就可能会对产品的概念、特点、设计、实现技术、实现形式等等产生疑问。带着我们的疑问去看案例,才能“内行看门道”,否则只是流于浮表,看了也白看。对于案例中与我们想法不一致的地方,应该思考它为什么这样设计/实现,哪种方式更优。以及案例整体的逻辑结构、用户体验等等,是否合理,是否有改进的余地。
另外,有的产品会在宣传中声称“遵循国际xxx标准,实现国内yyy规范”。我想,应该有这个敏锐,第一步就是去搜这所谓的标准、规范到底是个什么东西(如果还不知道的话),它针对的是什么行业、试图解决什么问题、大概概念是什么、有什么启发、是否适合我们、是否要具体跟进……。这对拓 宽我们的视角是很有帮助的。

抽象能力、把握全局:
作为一名程序员,如果搞不懂某项具体的技术,自然是很不爽。但我们也很容易陷入技术的细节当中,以致只见树木不见森林。抽象能力,是我们应该自我训练的重要能力。除了基本的对事物的抽象,还有对复杂系统提纲挈领的理解。了解一个软件产品,我们首先需要了解它对用户意味着什么、具备什么功能;然后,从技术架构上,大体上分为几个部分。有了大的概念之后,再进一步深入技术细节。这样,系统总体上是什么样子、我们当前处于哪一步,在脑海中就有一个清晰的印象。

主动反馈:
有的同事,好像从来不曾主动向我反馈过他的工作状态。你现在在做什么?有什么进展?遇到了什么问题?……。我已经在工作流程和其它地方强调过多次了,我的职责要求我知道整个团队现在处于什么状态。告诉我一下工作进展,没那么难吧?你不说,我只好去问了。其实我不想问的,我不想给大家太大压力。下回,当你觉得我老逼问你,很讨厌的时候,请反思一下,你是不是太久没让我知道你的进展了。我觉得 leask 同志有时候做得很好,吃饭的时候简单交流两句,即交流了工作,又有了闲聊的谈资。工作中有数不清的细节,如果靠一个人,一个个去检查,会累死人。希望大家在自己的工作责任范围内,做到主动反馈,给我留点时间做别的事情。

积极讨论,踊跃发言:
头脑风暴的时候,就是要随便说,想到什么说什么,大家不用那么严肃。。。平时多思考、多积累,当你有了自认为很好的想法的时候,就会自信很多。有时候就算是不太合适的方法,说不定也能启发别人的思路呢。我的经验,我经常会在讨论中蹦出不错的想法,这些想法并不是讨论之前准备的,而是在讨论中受了别人的启发。

不是搞定一项技术,而是解决一个问题:
解决方案,用来满足用户需求的一个方案,说白了,就是解决一个问题的方法。技术,都是试图用来解决具体问题的,当我们面对技术迷雾的时候,不妨问自己一句:我要解决什么问题?这并不一定是纯业务的,技术上也一样。
比如我们前段日子搞 NBGit,其实 NBGit 并非我们的目标,我们真正的需求,是建立一套规范合理、简单好用的 Git 工作流程。有了这个概念以后就知道,我们不能简单地宣布 NBGit 不好用,放弃之,我们必须得寻找到一个好用的方案。NBGit 的作者若遇到问题,需要跟它死磕到底,直至觉得无法解决,放弃项目,终止;寻找 Git 工作流程解决之道的人,只要发现有更好的办法,马上可以放弃 NBGit,放弃之后也并非像前者一样,是任务的终止,他需要确定新的方法。
我知道,搞技术的人,对所谓的业务、解决方案都很头疼,觉得拐弯抹角,不直截了当。这是另外一种看问题的角度,习惯之后,我们就能从另外一个角度看到另外一种风景。也会发现,跟非技术人员交流,变得简单了很多~。

不要未加工的资料:
有时候,我需要大家帮忙调查、对比一些技术/工具,可是结果有时有点无语,是原生生地从 Google 抄下来的资料。我自己不会搜么?优秀的做法,是认真去看这些资料,看明白咯,搞懂咯,写出你的理解。它们各自有什么优势、劣势,建议采取哪个方案,为什么,它的优点有多大的意义,缺点应该怎么避免……?

理清逻辑,找到问题的根源:
同事之间多讨论是好事情,更好的,是我们在讨论之前先把问题想明白。有时候,我们把同事叫过来,却又说不清楚自己的问题。最好,在讨论之前,先自己跟自己对话,或者假设桌上的笔筒是你的小听众。把问题的逻辑搞清楚,我要做什么?做了什么?怎么做的?遇到了什么问题?有什么可行的方法?怎么选择?……若是问题太多、脑子太乱,就拿出纸笔把它写下来。
我想,我这些字大家很可能轻轻地一看而过。但是如果你没试过,我强烈地建议你试一试。我的感受,这个方法简单却很管用。很多时候自己跟自己一对话,逻辑清楚了,问题就随之解决了;有时候脑子里想不明白的问题,在纸上简单地写一下,结果就很明了。

总结 而非 汇报:
总结是为自己而做,沉下心来,安静地思考自己的成长。
有些同事,贴一段代码就算完成任务。代码,版本库里不是有么?重要的,是要解释清楚。假设你面前是一个完全没听过这个概念的人,整理好你的思路、说辞,要尽量让不懂的人看后觉得清晰明了。这样,我们写的东西对团队其他成员才有帮助。更重要的,是在这个过程中,理清楚自己的思路、加深对技术的认识。这对我们的逻辑概括能力、总结表达能力也都是很好的自我训练。

把工作安排得井然有序:
有时候,我给大家说的是一些比较大的任务,实际上可以细分成更具体的内容;或者,你自己在开发过程中又想到了很多的问题。光靠大脑是不够的,太多太乱太疲惫、丢这忘那。我建议大家在项目管理系统中记录下来,建一个任务,分派给自己。这样,有多少事情、状态怎么样,一目了然。当然,是记在 issue tracker 里,还是记在本子上,要看个人喜好,但是没有记录肯定是很容易出问题的。我个人,是把所有想到的事情记在 issue tracker 里(大家可以去围观),但把当前最重要的两三件事情记在本子上,摊在面前。

提问题、证实自己的想法:
老总说的听说读写几个方面,我觉得都很实在、很有道理。其它几个属于个人素养,需要自己慢慢悟。我觉得听这方面,提问题的方法,尤其有现实意义。我们已经出现过几次这种情况:我说的时候对方表示很好,做完了却发现不是我想要的。当你不太有把握的时候,不妨多问几个问题。是不是我理解的这样?几个问题下来,我们就能达到理解的一致,或者发现存在的误差。

注重积累,Wiki 是不断改进的:
我们的 Wiki 现在已经有了不少内容,但请不要觉得 Wiki 写完了就完成任务了,若是发现有可改进之处请毫不犹豫地更新!特别是在我们工作的过程中,重复处理 or 重复回答的问题,记在 Wiki 里沉淀下来也许是个不错的方法~。

愉快的心情、健康的身体:
我是个爱运动的人,可是安排得不太好,实际上运动很少,肩膀和腰都经常不舒服。大家好像比我更少运动,时间久了也会不舒服的。我有时候去游泳,完了之后觉得浑身通畅,像是小说里说的打通了任督二脉。建议大家,根据自己的爱好,做个规律的运动计划。共勉!:-)

记录的主要的内容终于写完了……,个别具体的事项再当面讨论。

stay hungry, stay foolish!

————————————————————————————

既然说是年中总结,我也总结一下自己半年来的主要工作

团队建设:
从人员的招聘到相互的了解,团队的风格,以及思考各个成员及团队整体的能力塑造。我的指导原则,是要以个人鲜明的影响力保证团队在一条正确的道路上快速前进;同时做到中庸与无为,即,在具体的工作中淡化个人的作用,给团队其他成员发挥能力的空间。

工作机制与工作流程:
我们工作的各个环节,基本上都形成了适当的机制。除了开发,其它像招聘时的面试、笔试、评价这样的行政工作,我也都总结出了通行合理的做法。使得第一遍做过的事,以后在此成果与经验基础之上,用少得多的时间即可完成。努力的目标,就是使我们的工作流程,在“最优的机制+最优的工具“的帮助之下,达到“优雅、高效、智能、惬意“。

需求理解与技术设计:
这指我们已有的三个产品。

广泛涉猎:
作为职责,我可以不进行具体的开发,但如果我对产品与相关技术没有整体的把握,则是失职。涉猎的内容,有的是与产品技术直接相关的,有的则是更底层的基础技术,或是大一点的概念如企业IT建设的方方面面,都是我关注的内容。技术之外,像需求、规范、设计等等也是涉猎的内容。视角的广度与深度,决定了决策的优劣。作为个人目标,我希望自己能做到:一手拿RFC、一手拿国家发展计划纲要;脑袋里构思出一套解决方案,一半想的是纲要里的战略需要、一半想的是RFC 里的技术实现。。。

总的来说,这半年来,虽然细节上做得还不尽完美,但实质上没有遇到大的挑战。所需的种种能力,都是自己多年来努力培养的目标。

————————————————————————————

我对自己不满意的地方,是整体的工作效率不够高,自己寻找原因

客观原因:
如身体、距离、设备等,不细述。

并发而琐碎的工作事项:
相对来说,以前主要还是搞技术,具体的技术,一沉进去就是数个小时。现在,更多的是一些小块的工作事项。频繁地在任务之间切换,一会是技术问题、一会是业务问题,以及一会思考团队、一会执行行政任务,适应起来还是有点问题,有时候把自己搞晕了,不知道在做什么。

偏重逻辑的思维方式:
有时候需要参考一些文章,类似企业IT战略、产品的介绍资料之类的。这样的文章往往写得十分的概念化,几年前初看这种文章时,我会感到非常气愤,觉得全是废话,直接说用到了什么技术、什么标准、什么工具不就得了吗?!现在好多了,能够平心静气地看下去,试图从中挖掘出一些有价值的观点、策略或技术。但有时候还是会头大。

行政工作:
行政工作耗费了我比想象中多很多的时间。除了必要或者不必要的往复交涉,以 Word 为核心的工作流也是一个原因。大部分同事交上来的资料,或者管理部发过来的模板,格式都不够好,而我又不希望从我手里出去的东西有太大的瑕疵。我以前不太用 MS Word 的,因为以上原因,不得不在页眉、行距、表格属性……以及各种疑难杂症上耗费了不少时间。希望我们的工作流产品完成之后,能先在自己公司成功部署。Web 化是我的目标,它不仅仅简化了表面的格式设置,也为数据的收集、搜索、统计等再利用提供了方便。

————————————————————————————

完了。感谢阅读(滚动到最后…)!

  1. 还没有评论

  1. 还没有引用通告。