一年后再读《rework》

原创
2015/01/09 08:01
阅读数 838

在kindle里面买的第一本电子书是《rework》,当时难得一气呵成地读完,像找到知音一样的快感。一年后,当我再次把当年kindle上的标注温习一遍的时候,发现读后感与当时大有不同,不知道这是叫成熟还是叫终将成为自己讨厌的那种人。

忘了“现实世界”

“这在现实世界中完全行不通。”当你向人们介绍一个新创意时,人们总是这么说。

这个“现实世界”听起来如此令人沮丧,貌似所有的新创意,新提案以及外来概念总是会在“现实世界”中碰壁。在这里,能够立于不败之地的都是那些人们耳熟能详,习以为常的事物,即使这些东西已经漏洞百出或陈腐低效。

一年前对这段话感觉特别带感,那时候总决定自己的想法都是创新的,都是颠覆的,别人都看不懂我的世界,那一定是别人都在拒绝创新,拒绝颠覆。现在,回过头来却发现自己逐渐成为了维护这个“现实世界”的人。

在公司里的项目是一个HTML5的混合应用,以前没人做而我做出来了,感觉这个东西很超前,很创新,不但应用了最新的技术,还非常节省成本,老板也很接受。往后的时间里,但凡有人提出原生开发的意见我都报以拒绝的态度,依据就是原生开发的成本太高,而且不便于维护两个版本,对于追求压缩成本的“现实世界”而言根本不可行。最终,公司在最近一个项目中,客户声明要求原生开发,最终成为我们项目组失去参与此项目的机会的原因之一。

我,真的变成了那个曾经让自己感觉讨厌的维护“现实世界”的人。

当然,HTML5这种形式,本身没有错,在一些场景下是有充分的价值。我的问题是,一直死抱着这个方案,不愿意尝试不愿意改变,心态上变得过于保守,而失去了机会。

着手做点什么

在你的人生中真正有意义的是你做了什么,而不是你想过什么,说过什么或者计划过什么

所谓成王败寇,不光是你做了什么,更重要是你做成了什么。系统做出来了,收益呢?市场呢?前景呢?都看不到,那还是一边凉快去。还计划反馈开源社区,只能想想罢了。

作出决定就是取得进展

做多少计划不重要,人总是难免犯错。不要因为事前的过度分析和犹豫不决而把事情搞砸。项目周期过长会打击士气。项目开发时间越长,成功的可能性越小。只要有足够的动力和士气,就要趁热打铁,积极决策,果断推进,现在就把事情做出来。

我一直反对什么年度计划。要是能对一年的事情有先见之明,那我觉得我一定成仙了。所以我更偏向年度目标,月度计划。一年里,总得有个目标,有个方向,有个盼头,团队朝这个方向前进,向这个目标努力,也就是所谓的愿景,也类似一种精神寄托。但要细化到具体的计划,时间跨度不宜过长,一个月属于比较靠谱的范围。可以看到很多敏捷团队的迭代周期也差不多在两周到一个月左右。

但是光有目标,没有计划,确实是会令项目组的士气受打击的。我们最近做的一个版本迭代,开发了一个月,测试了一个月,上线又折腾了半个月。等折腾过来后,好像都不知道往后要怎么走了。

质量为王

这与产品包装,市场营销或价格无关。在这里质量为王。

决定因素

业余摄影爱好者总为使用胶片相机还是数码相机而争论不休,却没有人关注拍出绝妙的照片的决定因素是什么。

很多业余高尔夫球手执着于加入昂贵的俱乐部。但是真正重要的是如何挥杆,而不是加入哪个俱乐部。 我以前看到别人随便就挂个单反,也想吐槽一下:不是有单反就能照出好照片。但实际上,我作为程序员的时候也经常为自己用vim而感到自豪,也会轻视用eclipse的同事,按之前的逻辑,用vim也不代表会写出更好的代码。那应该怎么看待这种追求和自豪感呢?所谓工欲善其事必先利其器,当你处于一个专业领域的时候(哪怕你只是业余入门),其实首先都应该选择一个最好最适用的工具,以求帮助你达到最好的使用效果。对工具的追求其实也是你内心对此专业领域提升的一种坚定的暗示,使用高大上的工具并不会令你马上有获得提升,但是会让你在提升的路上变得更坚定,而且更快。

现在很常提到一个名称叫圈子,俱乐部也就是一种圈子。其实圈子和刚才的工具是一样的,加入圈子,并不是代表你就跟那个圈子的人一样等级一样水平了,而是通过加入圈子,形成积极向好的心态,并且通过向优秀的人学习,最终帮助你在提升的路上变得更坚定而且更快。

立马就上线

当我们推出Basecamp软件时,连收费功能都没有完成!因为这个产品是按月收费的,我们明白还有30天的空档期可以用来完成这项功能,于是我们把宝贵的时间用于解决更紧迫的,上线当天就得解决的问题。而30天后才需要用到的功能,可以再等等。

赞同的错觉

商业世界中充斥着各种无用的文件,这些文件除了浪费人们的时间外,一点意义都没有。没有人读到报告,没有人看到图表,无法完成的细则。这些东西做起来颇费工夫,但是人们一回头就能把它给忘了。

如果你一定要说明某事,那就务实一点。不要描述它长什么样子,直接画出来;不要解释它的声音如何,直接哼出来。要尽一切可能去掉那些抽象的东西。

甘于低微

一旦你把事业做大,深入人心之后,就不可避免地要走稳健路线。当你成为传奇人物,你的变得更为保守,更难去冒险。这就是僵化的起点,变革的终点。

在现在这家公司,我是从零开始,所以一开始大家都轻视甚至无视我。我还记得上班第一个月看到隔壁部门经理时候,他对我的态度,不屑一顾。那时候的我虽然弱小,但是无顾忌,抓住一个机会就迅速做大。别人的态度变化是很明显的。但风水轮流转,系统的用户多了,累赘和顾虑就多了,一次版本升级出了bug,就换来一堆投诉;一个不小心生产服务出现故障,更被有心人揪住来打击你。然后各种报告,各种措施,最终结果是你不敢轻举妄动,宁愿少做事,总比做错事好。跟书上说的,一模一样啊。

常规教育不值一提

我从来不把我自己受过的正规学校教育等同于我的受教育程度——马克吐温

人人都得干活

在一个小团队里,你需要的是干活的人,而不是监工。每个人都得做事,没有人可以袖手旁观。

这就意味这你在招聘中要避免招到监工型的人物,这些人喜欢对别人循循教导。对于小团队来讲,监工型的人就是累赘。他们想出各种事情让别人去做,在丢下自己的工作去安排别人时,他们制造出了更多的工作——不管这些工作是否需要去做。

过去我最讨厌监工,他们不编码,他们就指挥我编码。我觉得一个公司,这样的人除了老板,就不要再多一个了。

随着团队的壮大,随着职位的晋升,我逐渐发现如果我还继续编码,项目真的推进不下去。我们始终无法像google,facebook那样,招到最好的工程师,团队的组成大部分还是经验浅的新人,素质也很难保障。有的成员,技术不错,但是喜欢偷懒,安排一件事做完了就算了,就自己去看其他东西了;有的成员,理解能力不行,安排一件事,做出来的跟设想的出入太大,根本不可用;有的成员,没什么方向感,很容易不知道自己应该做什么,然后开始迷茫……如此种种,当我埋头写了一天代码后发现,其他人的状况都很不妙。再过几天,项目已经开始溃烂。这时,我不得不做起监工。我需要每天跟踪成员的工作内容,能者多劳;我需要验证确认成员提交的代码符合最初的设计;我需要提醒成员知道每天需要做些什么,需要在什么时候交付些什么;我还需要做更多,比如版本规划,比如架构设计,比如团队内外沟通,比如写各种文档。真的,无法再每天写代码了。更无奈的是,我逐渐从写不出好的代码,到了写不出代码。

员工不止13岁

接下来我们再谈谈你要花多少时间和金钱来监管员工。安装监控软件得花多少钱?IT员工得浪费多少时间去监控员工,而不是去做更有价值的实用项目?你浪费了多少时间去写无人看到规章制度?看看这些成本,你很快就会意识到:对于员工的不信任才是最大的开销。

展开阅读全文
打赏
0
6 收藏
分享
加载中
更多评论
打赏
0 评论
6 收藏
0
分享
返回顶部
顶部