所有由圆木菠萝头发布的文章

85后,天蝎座。软件攻城师,挨踢服务生。独立博客。独立电影演员。一个理想主义的务实者。

你要如何衡量你的人生

你要如何衡量你的人生

这本书的作者有个略传奇的故事。当时他写了一本书叫《创新者的窘境》,后来被当时的美国国防部长应邀到他那儿去谈谈他的研究。作者以为会有一些少尉军官或者大学实习生听他的课,可是当他走进国防部会议室时,发现陆军、海军、空军总司令都坐在那儿。

<理论的价值>

好的理论可以帮助我们进行归类和解释,最重要的是帮助我们做出预测。信息和数据只代表过去,根据过去的信息并不能预测未来。你一定不希望经历多次婚姻才学会怎样做一个好配偶,或者等你的孩子都为人父母了,你才学会怎样做个好父母。这就是为什么理论如此有价值的原因:它能解释将要发生什么,甚至在你亲身经历之前就能告诉你将要发生的情况。

<验证理论的方法论>

要探索一个理论是否可信,最好的方法就是找出异常现象,即找出用这个原理无法解释的现象。

比如说,我们先假设薪水是决定工作是否有动力的首要因素。那么我们可以试着找一个反例,并深入挖掘原因。反例之一便是美国军队,在美国军队里面的工作根本算不上什么高收入,而且可能充满风险。但是为什么有很多人仍然想报名去美国军队,其中不乏很多优秀的人才(比如西点军校的毕业生)。原因是美国军队被看作是效率很高的一个组织,并且很多在军队里工作的人都有很强的工作满足感,以及为国家服务的荣誉感。

看来,人们做某件事真正的动因是:发自内心地想去做。薪水,是一个基础因素,不是动力因素。

真正让我们非常满意并爱上工作的因素是什么呢?动力因素!包括:有挑战性,获得认可,责任感,个人成长。大量事实证明,如果动力因素起作用了,你将会爱上自己的工作,即使赚不到大钱,你也会变得积极起来。

<周密计划与偶然机会>

本田公司进军美国摩托车市场,推出一款大型摩托车。当初想法是价格便宜好占领市场。不曾想,美国人骑摩托车通常远距离恶劣条件下跑快车导致漏油,当地经销商不会修所以只好空运回日本再修。如此一来,没有利润反而倒贴很多成本。

除此之外本田还运了些小型摩托车到美国,因为觉得小型车在美国没市场所以只用于员工在市内跑腿。一次偶然的机会,一个员工周末在洛杉矶山上从上而下骑着小摩托,车子一上一下颠簸着,感觉很爽。路人看到了都想问哪里买这样的“越野摩托车”。员工说在美国不卖这个。

结果越来越多的美国人听闻这个消息,纷纷要求本田公司在美国开售这样的车。本田公司起先不太愿意因为这个与“销售大型摩托车”战略相违背,但是随着公司日渐在大型摩托车战略上的流血以及市场对于小型车的需求,公司开始转变战略销售小型车一举成功。

这个故事中,周密计划是“销售大型摩托车”,全部的资源都在支持这样的策略,可是经过再三验证后市场都不买账。与此同时,偶然机会出现了:市场迫切需要要小型摩托车来“越野”。于是本田放下原来的周密计划,然后把握住偶然机会,此时此刻原来的偶然机会也变成了周密计划。

这给了我们一个启示:也许原先你有一个为之努力的理想,但是努力了很久发现成效甚微。不过在为此努力的过程中,你发现了另外一个天赋,或者另外一个机会,让你轻松地便取得好成绩。那么这便是偶然机会,做出决定要不要抓住此机会,从此走上“正确”的道路。

<发现-驱动计划>

这个计划的意思是:哪些假设条件需要得到验证,才能说明这个战略有效。

当你设计一款新软件的时候,或者当你尝试一个新技术的时候,你通常会做一个原型(Prototype),客户看过原型之后同意方案了才开始开发工作。这里原型就是你做的假设,假设客户想要这个,如果客户看了之后真的想要,便证实;否则,便证否,再重新做原型。这样不至于在一开始花大成本做出成品然后再等客户否定。

花最小的代价走通关键路径以此证明方法或者方案可行,这便是奥秘。

同样,当你做出一个决策的时候,你要考虑两个问题:第一,需要被证实的最重要的假设条件是什么;第二,怎么才能对假设做出不昂贵,快速的测试。

<什么是最重要的>

始终问自己这个问题:什么是最重要的。

现今社会,一方面需要脚踏实地不断前行;另一方面,就是要抬头看路,知道什么对自己来说是最重要的,始终记得曾经为什么出发。

我们中很多人都非常取得成就,而事业是最能立刻衡量我们是否取得成就的一种方式。“有时我会强制自己停下,或设置障碍和界限 — 例如:要在每天6点离开办公室,这样就可以在白天有一些时间和儿子玩传接球游戏,或者带女儿去上芭蕾课 — 保持忠于自己最看重的事情上。

<杂记>

随着岁月的流逝,大多数人都把梦想丢弃了。

你醒着的大部分时间都花在工作上,超过生活中任何其他事情所花的时间,这种妥协会慢慢侵蚀你的心灵。

如果你想帮助他人,就要做管理者。如果干得好,管理者是最崇高的职业之一。

我为什么开通微信公众帐号

我为什么开通微信公众帐号

(微信搜索boluotoutalk,扫描二维码,或加微信公众帐号“菠萝头说”)

如果你被”Hello, World”吸引来到这里,说明你正是我的目标读者了,因为至少程序员和从事IT软件开发行业的同学们知道这句话的情怀。

来到微信世界,是一个全新的开始。

时间回到2006年,当时我发现网易有个163日记可以在网络上写点东西,而且在其他地方也可以方便查看,于是便开始了写作。不曾想,这便成为了我的博客菠萝头说的前身。

再后来新浪将博客的概念推广开来,于是我搬家到新浪博客。继续写了一阵子,发现新浪博客的模板网页更换很不方便,于是在2007年暑假干脆买域名,买空间,玩起了独立博客。

独立博客在ASP空间里用着开源博客程序PJBlog, ZBlog,搬到国外PHP空间后投奔了伟大的Wordpress。磕磕碰碰走到现在,博客的内容基调也从原来的生活片段和碎碎念,转到了对工作的总结,生活的感悟以及读书的分享。

工作的总结是“谁动了我的代码”系列,主要是讲述在IT软件开发工程技术领域的小故事以及大道理。
生活的感悟是“随笔”系列,从独立旅行的点点滴滴,到过往的回忆。
读书的分享是“书架不长虫”系列,各种读书笔记,看完一篇相当于读了一本书。

写了将近7年的博客,我也不想闭门造车和孤芳自赏,内心开始向往着分享和交流。可是,现在还有谁会去看博客?我想,微信可能是一个撬动地球的机会。微信犹如移动互联网的翅膀,让博客这种在碎片化阅读时代相对重型的家伙,也可以飞一会儿了。

好了,有读者会说你讲了半天你开通微信的理想在哪里?不会是宣传你的博客吧。当然不是!

这么多年,我在工作中会经常接触一些大学应届毕业生,他们在工作中遇到了很多问题,很多困惑都是我曾经一路走来想过的。在遇到这些问题和困惑的时候自己很煎熬,想通后就变得很轻松。我内心很想帮助这些职场新人,尽自己绵薄之力能够让他们在职场启蒙期走得更好。

微信公众平台,给了彼此一个机会。不同于微博是公开的属性,微信公众平台所提供的是一对一私密对话。你可以直接对此公众帐号输入文字,也可以说段语音,便可以和我交流。你的评论你的问题不用担心你的同事或者上司会看到,所以大家的探讨都会非常轻松。如果得到读者允许,我也会定期将对话中所说的案例公开(隐去私密内容),以便让更多的人为你出谋划策。

不多说了,让我们从这里开始。

(微信搜索boluotoutalk,扫描二维码,或加微信公众帐号“菠萝头说”)

我为什么开通微信公众帐号

菊花与刀

菊花与刀

菊花与刀是一本研究日本文化的书,作者受到美国军方委托,在第二次世界大战的背景下写成。当时的美国军方不理解如何能让日本这个奇怪的民族投降,他们担心日本的武士道精神是否意味着美国需要打死日本所有军人才会结束战斗。

研究文化的方法。
美日两国处于交战状态,意味着必须放弃文化人类学家最重要的研究方法 — 实地调查。作者只能问当时待在美国的日本人,问问他们的出生以及家里发生的事情。

如果研究者仅仅停留在简单地宣传这些差异是如何稀奇古怪,以致认为这是一个不可理解的民族,如此承认差异的存在,这是危险的。人类学家根据其经验证明任何一种怪异的行为都是可以理解的。

研究的前提:即无论怎么孤立的行动彼此之间都会有某种内在的联系,我非常重视把数百个互不相关的琐碎现象归纳为一个综合性的模式。

战争中的日本人

日本人说精神就是一切,也是永恒的。由于勇气和为国捐躯是日本人身上最不缺乏的两样东西,神风突击队从成立到日本投降,用1228人的生命击沉34艘美国军舰。

哪怕敌人的飞机已经接近本土,日本的国内广播还是会说“这早已在我们的计划中”。 只有假定一切都在预料之中,一切都是完全计划好的,日本人才能够继续坚持对他们来说是如此必要的论断,即一切都是他们自己积极希望的,而决不是他人强加的。对日本人来说对他们来说最大的威胁来自没有预想到的事变。

他们认为在世人面前留下怎样的形象是十分要紧的事。所以当日本军舰遭到鱼雷袭击而不得不离舰的时候,要尽可能以最体面的姿势登上救生艇。

日本的这种牺牲精神最极端的表现便是日本人的不投降主义,赤手空拳对大炮也要上,除非投降是日本天皇发布的命令。因为“天皇总是对的”,于是“投降”这样的行为也会成为真理。

日本人的义理

日本人很重视“义理”。什么是“义理”?我的理解是,日本人对待事物“从道义和理论上应该是怎样”的一种维护。

比如战争,日本在天皇旗帜下应该获取胜利,所以哪怕敌军飞机已经在本土上空飞,那,也是我军计划好的吸引敌人飞机到腹地在击毁他们。
比如行孝,因为父母生育和养育了自己,于是自己从肉体和精神上应该都是父母的,父母强加的婚姻也是对的,哪怕内心再不愿意,也要从“义理”上服从。
比如等级,如果你是平民,你比武士等级低,所以你必须极其顺从地忍受携带武器的武士攻击。
比如名誉,如果你是一个老师,学生问了你一个你不知道答案的问题,你需要装作知道,因为老师“应该”知道这些。
比如职业,如果你是一个学生,那么你应该可以顺利毕业,如果你没做到,那么你违反了“义理”,你会在内心极度谴责自己,甚至做出自杀的举动来维护你作为学生的义理。
比如灾难,灾难来临时,任何人类都会有基本的生理和心理恐慌,但是日本人在电视上表现得都很淡定,因为维护“义理”有的时候是禁欲主义,你必须表现出来淡定从容,才能显示自己的强大。

美国人谴责自杀,认为自杀不过是对绝望境遇的一种自暴自弃的屈服,但在崇尚自杀的日本人中,自杀是一种有着明确目的的高尚行为。

这并不是说所有的日本人都会最终做出维护“义理”的行为,但是他们的实际行动总是会受到“义理”的牵扯的。这个大原则可以很好的解释日本人的种种行为。

日本人的报恩

恩,对于任何人来说,都是一件重要的事情,正如日本人常言的:“一个人永远无法报答恩的万分之一”,这些习惯使日本人对其道德债务的尊重能够达到西方人想象不到的程度。

日本人表示感谢的字面意思有“侮辱”、“丢脸”的意思。这就是说,由于你受到了特别的恩惠,你含羞蒙辱,因为你不配受此恩惠。

爱、仁慈和慷慨,我们对其的珍重正是因为他们的给予是不带任何附加条件的,然而在日本他们却必定带有附加条件。在日本,恩,是一种债务。

我是如何独立旅行的

2013年6月摄于威海刘公岛

<引子>
今年出去了两次,独立旅行。以往的旅行,往往不是和同学们结伴而行,就是有朋友在当地接待。

独立旅行,意思是独自去一个完全陌生的地方。

4月份,年假加清明节假期一共有8天,跑去西安和南京走了一圈。6月份,年假加端午节假期一共有7天,慢悠悠去青岛威海转了一圈。

<动机>
也许是连续工作了9个月没有休假,于是想让自己休息一下;

也许是待在一个地方时间长了,想去体验下未知的世界;

也许是想逃离下当下的压力,让自己和这个地方都得到释放;

也许就是想放飞心情;

远行,是最好的办法。

<旅行并非旅游>
邀一群朋友,锣鼓喧天的出发,大多是跟团,陪着一群不熟悉的人并紧跟着导游的时间线,每到一个地方都必人景合一拍照留恋,匆匆忙忙地从一个景点“游”到另一个景点,给亲朋好友一定得带上一大堆当地的特产负重前行,回来后说旅游累死了,但是很值得!

这便是大众意义上的旅游。而我所理解的旅行,便是另外一种方式,尽管和旅游有相似的地方,但也有些微妙的不一样。

或和朋友,或独自,低调而坚定地出发,绝不跟团,陪着熟悉的人或者自己惬意地跟随着自己定制的时间线,到一个很美的地方会拍照但往往只是景点,能够穿越回历史能够身心融入自然,偶尔会带些不贵重也不重的有意义的纪念品,回来后精神饱满重新投入工作和生活。

独立旅行,把自己丢到一个陌生的地方,在那里你什么都不是,从而更放松,也更好地能审视内心,重新认识自己。

<选择旅行目的地>
一般都会有说走就走的冲动。

4月份有8天假,心想留在本地太没劲,但也不知道去哪里。网上一看,发现去西安的机票好便宜,于是在头脑中冒出课本上的兵马俑大雁塔小雁塔后,便定下来去西安。8天去西安也没那么多玩的,起码得再加一个城市……呃,就南京吧。相邻的六朝古都,却从来没去过。于是西安,南京之旅便开始。

本来期望一年只出去一次,和好友的一通电话,偶然得知在青岛出差公司给他租房,一看日历一数年假还可以有个7天假。于是青岛之旅便开始。

<开始和结束>
说起独立旅行,还是需要勇气的,如果是第一次,那注定会有内心纠结的阶段。一方面想去体验下陌生,一方面又舍不得熟悉和舒适的感觉。

让自己破釜沉舟便是先搞定旅行的开始和结束 — 往返的交通。票都买了,看你还纠结啥。

带上一点自信,一点钱,你就不会风宿街头,你就不会饿死,足矣。

<路途和景点的规划>
旅行一般会做功课,但是我不会做足量,因为内心不太想按照别人的攻略从而重走别人的旅途。就像玩一个RPG游戏,把攻略都看完了,那还有什么游戏的感觉呢。

我森森地感觉,玩游戏看攻略,旅行前大量的看游记,内心根本的原因是“怕吃亏”。这么多景点和好吃的,你不一一玩到吃到多吃亏啊,所以时间安排紧点人累点也要一一签到证明我来过。NO!这不是旅行的心态。

所以我一般会随手翻翻游记,看那个景点介绍,然后在百度地图上打收藏标记。这样一轮下来后,我的地图上那个城市就有一些收藏的五角星了。这些五角星的地方,有些必定要去,有些可能去,可能不去。最重要的原则只有三个字:看心情。

<住哪儿>
独立旅行,本来就想找到一些漂泊的感觉,所以住的地方基本和各种星级酒店无缘,越是像家越不去。

我一般会在去哪儿网找团购,或者预定经济型酒店。快捷酒店管家App则是在当地的一个很好的选择。

从西安到南京,为了节省一晚上的住宿,特定预定了一趟在夜间行驶的车次。睡一觉,第二天清晨到南京。于是,睡哪儿除了酒店也可以是交通工具。

在南京,连预定酒店都没有,正赶上清明小长假酒店都不好订而且老贵,心想反正只窝一天,就去学校附近转转。在南京大学体育场旁边的广告版上拨旁边小旅社的电话号码,最后找到一个一晚上70元的有wifi有独立房间的地方。

总之,就算你之前没订到酒店,你到一个城市,别担心会露宿街头,因为……最差你也可以睡肯德基24小时餐厅吧。

<吃货的心>
当然要先做下功课看看当地的美食在哪些地方,然后安排行程的时候稍微把靠美食近的景点安排在晚饭前的几个小时,游玩完了后顺便去吃美食。

旅行时吃美食就有点好,敞开吃,一餐吃个几十块吃好吃爽,反正下次不来了。

<留影>
翻看过很多人的相册,你会发现有些相册很多是人景合一,而有些相册则多半全是景色。

一般来说,大部分人景合一的更大可能性是旅游,而只有景色的更大可能性是旅行。

旅游,在乎的是签到,这个地方我来过,回去后也许在心中忘了那些风景;
旅行,在乎的是经历,江山如此多娇,我愿将此风景永存。

所以我一般照景比较多,我其实还有一个想法,便是将来在旅行中除了照景色以外,与当地的居民合影,或者与路人合影,将来寄给他们。想想真是件奇妙的事情。

<怎么去一个地方>
百度地图!百度地图!也许你会推荐其他的地图应用,但是我不得不说百度地图对于公共交通,以及生活周边的功能使人很方便。

不过如果开车的话,还是选用高德地图吧,高德地图的GPS功能会比百度地图要好。

<怎么玩>
在西安独立旅行时,我沿着西安城墙四面将近13.6公里的周长走了一遍,大概花费3个多小时走走逛逛。为了纪念那天的愚人节,我在沿西安城墙走的时候一直在思考三个问题:我是谁?我从哪里来?要到哪里去?边思考边走城墙,逐渐地,我感觉我穿越回了历史中的城墙……

如果是旅游,情景可能就变成了,导游说大家玩吧,半小时后回来集合。这下好了,西安城墙成了骑自行车看风景的地方,而全然没有了旅行那般神奇的穿越。

总而言之,跟团旅游往往会让你的游玩成了导游时间线中的一个因素,你不随自己控制,他人左右了你的行程;而旅行,便是对自由奥义的诠释,你尽情时可以多留些时间,不尽兴时可以早去其他的景点,随心而定。过程决定着结果,一个累死,一个充实。

<血拼的门道>
在西安,不管是咨询一日游,还是买剪影,通常来讲,你要是什么价格行情不知道,只有挨宰的份儿 — 尽管你可能觉得这个商品已经和理想中的情况非常靠拢了,甚至觉得“好便宜”。

多去逛几家商户吧,在比较中你才知道这个商品的行业平均售价,而且只有你掌握了信息,你才有可能在新的一家商户中拿到“应该有”的折扣。

自我评价我其实不是一个喜欢讨价还价的人,甚至不喜欢在这个上面浪费时间。购物的“货比三家”,实则在旅行中习来的。在西安有几天的行程,第一天逛商店,心想只是看看最后一天再买,然后每一天逛不同的商店才发现里面的门道。

<带礼品>
关于礼品的馈赠,我说一个听来的故事。

在日本生活的人回国,需要给亲戚朋友带礼品,不是高档相机或者手机之类的根本拿不出手。但是在日本,邻里之间,朋友之间经常会互相帮忙,帮忙之后会送一些小礼品,比如糖果,小手帕等等。

旅行中带礼品,带的是心意,为了面子带多带足,让自己旅途身累心累得半死,结果交接礼品之后半个月,则全然无味了。

既然礼品是心意,则需要用心,从而礼品的份量便真的很重。从西安给团队每个人带了一张西安的皮影,针对每个人写了不同的祝福语,花了我好些时间。单个皮影并不贵,但是写上文字后,自我感觉,心意到了。

礼品可以是食物,大家吃完乐哈哈,吃完也就没有什么记忆了;也可以是小物品,这样或许会更长久些,比如上面的皮影。现在还在各位同事的办公桌上,每每看到这些皮影,我就回想到当初去西安的旅行,而他们也会持续记得你给的一份礼物。

<收获>
首先是更好的认识自己。你在日常的生活中往往被贴上很多标签,工作职位上的,生活角色上的。除此之外,你会被工作和生活上的各种琐事缠绕。你到底是谁?在这个世界上几十年的时间里面你想干嘛?你到底为什么而活?这些问题,也许在路上,在一个陌生的城市里,当你什么都不是的时候,会想得更明白。

其次是勇气。独自一个人来到一个陌生的地方,生活一段时间,并且跟这些陌生的空气,水,居住环境和人友好和谐地相处,并融入。这些意味着你要暂时放下你的心理舒适区,离开那些让你熟悉的环境和人,意味着要改变。

最后是对未知世界探索的能力。归根到底是一种能力。走在西安,南京和青岛的街头,我有时候会想一个问题,如果把我丢在这样的一个陌生的城市里,什么都不给我除了给时间,我是否能够逐渐找到满意的工作,找到一群新的朋友,生活得很好。

<尾声>
就这样吧,我想我会坚持旅行,到老。

最简单的时间管理

团队有了一个新项目组,3个开发,2个测试。其中Project Owner是一个开发小伙。前段时间,我发现这个小伙每天下班尤其晚,但其他的成员正常下班,然后又听说他私下说Project Owner不好当,心想要找他谈谈了。

他告诉我,他的工作总是被频繁打断,然后不得不等到大家都下班了才开始做自己的活儿。我说,那起码你要开始学会管理你的时间了。

他的工作内容主要有两个,一个是项目主程,负责开发部分新功能和修复Bug;一个是Project Owner。所谓Project Owner,是除PM之外对项目负责的人,相当于“包工头”。所以Project Owner的工作会包括写日报,制定缺陷修复计划,和其他开发讨论解决方案,和测试讨论需求疑问,写问题列表以及其他项目“杂事”。

所以他的痛苦是,当他扮演主程身份的时候,通常被其他成员“绑架”到Project Owner身份上来做交流,等回到主程身份又重新进入全速前进的状态需要至少15到20分钟。于是,主程的活儿根本干不了了。

时间管理已经是老话题了,而且有非常多的理论。我当然不能跟他一上来做个2小时培训,于是告诉他一些最简单的原则:

首先,要掌握自己的时间,需提高自己的效率,提高效率来自专注 — 同一时间只做一件事情效率最高。

其次,频繁被打断手头的事情,并不意味着处理打断后手头事情能立马恢复全速,每次被打断回来后至少需要15分钟恢复全速前进。

怎么办?设置“时间点”!

让他跟团队成员交流,他有上面说的两个角色,为了保证项目主程能够保持高效并且一段时间连续工作,他不会随时随地突然扮演Project Owner处理大家的疑问,而是设置“检查时间点”。

具体说,每天上午从8点半上班11点半下班,中间9点晨会后,以及11点有两个“检查点”,这两个检查点他会扮演Project Owner的身份来处理大家的各种杂事,处理时间10到20分钟。然后他会安心以主程的身份开发新功能,修复缺陷。他在主程的时候请各位成员先自行处理问题,并等到下一个检查点告诉我。下午从1点半到5点半下班,一般设置1点半,3点半,5点三个检查点。

总会有成员还是延续习惯中间随时随地找他,那么他会立马简单把这个请求写在记录本上,然后说,OK,了解了,我11点去找你可以吗,我先完成手头上的工作。

于是,他作为主程的时间被保护了起来,而各种杂事好像也没有那么紧急需要立即处理,集中时间反而处理杂事效率也更高了。

趁,青春未老

四月底,五月初,我的生活里上演着“青春”的剧本。

首先是团队户外拓展训练。

拓展训练高空项目攀岩与高空断桥,考验的是意志力以及心理承受力。在攀岩壁上,这些平常端坐于电脑面前的IT工程师们,戴好安全帽系上保险绳便嗖嗖往上爬,样子一点不输专业登山者。在高空断桥上,某位同学称心跳厉害想放弃,底下的队员连忙鼓励,下来容易可是会后悔一辈子失去一次挑战自我的机会。最终,他壮着胆子一步一步地前进,最终完成了那次青春的一跃。

限时定向越野,18个景点,按图索骥找到每个景点,并完成景点任务。各种搞怪合影,各种团队游戏,各种机缘巧合,各种体力智力考验在不同的团队中不同的演绎,让大家真切实在地弄懂团队的奥义。

求生毕业墙,4.2m高,50个人要从这堵墙翻过去。每个人都是好样的:第一个翻过墙的人,在真实情况中,他怎知道墙后不是万丈深渊,敢于身先士卒第一个吃螃蟹;人墙的基石,那几个身高大汉,任耳边锣鼓喧天,依然面壁低头成弓步,让团队其他成员踩着他们肩膀上去,他们是团队的中流砥柱;最后一个上去的人,他将前面的逃生机会留给了别人,在墙内待的时间越长越危险,他们高风亮节;其他所有的人,在下面做出救援的动作,以防爬上去的人不慎跌落,他们也是好样的。

接下来便是公司组织的羽毛球比赛。

羽毛球比赛之前的内部选拔赛,32强的争夺晋级。让有实力的选手非内定而是以“自然选择”的形态浮出,一来公平公正,二来让有实力的选手也是热身加速其进入竞技状态。随后,便是开始刻苦的训练了。每天的生活由此变成了,白天上班,下班前下去抢占场地,练完球再回办公室完成当天的工作。乐此不疲地进行了两周,中间还加进了一个拓展训练。身体累并快乐着,时刻感觉青春在熊熊燃烧。

最后的结果,该赢的都赢得轻松漂亮,不该赢的也输得比较体面。我们承认实力有差距,更应该庆幸超越了自我。

再接下来便是电影《致青春》。

一部当年小燕子的导演处女作,让很多人有了关于青春的回忆。里面有句台词:青春是用来怀念的。而我觉得怀念对于我来说言之过早。青春是用来燃烧的,唯有这样未来才能更好的怀念!

对于我们大多数人来说,每天都会浑浑噩噩地过着自己的生活,消耗着自己的青春。曾经的理想与激情,在现实的冲击下支离破碎。人都不愿意改变,都会有惰性从而拒绝走出自己的心理舒适区,从而也失去了成长的机会。

可是,如果趁青春在手中的时候都不好好把握,那么未来还拿什么来怀念呢?

趁,青春未老,勇敢地去做自己想做的事情。这并不是让你放弃现在的所有,而是立足于现在,哪怕现实再不堪,都不会忘记朝自己的理想一点点前进;

趁,青春未老,勇敢地去追求属于自己的爱情。这并不是说在青春里你只会喜欢一个人,而是喜欢一个人的时候就好好爱好好珍惜,最终找到能够相守一生的人;

趁,青春未老,积极地去孝敬父母。这并不是说给父母钱,给父母买好吃的就够了,而是在百忙中抽空陪他们在一起,跟他们分享你的青春,让他们重新青春,这便是更高段位的孝敬;

趁,青春未老,有太多的事情需要去做,有太多的路口需要我们选择。如果每次选择都去计较利益得失,那么世界就少了很多五彩缤纷,未来便少了很多可以怀念的东西了。

临危受命 — 如果再给一次机会

这场战斗终于结束,太多的血与泪。事后,我们团队和公司上下也做了深刻的总结和反思。

PM,天职是管理好项目,所以需要对项目的一切负责。

当项目出现不可消化的问题时,需要及时地Esclation,向上抛出问题警告或者通知各个相关利益人,并积极寻找资源解决问题。切不可隐瞒问题,否则迟早变大灾难。

项目经理有义务保证项目交付成功,同时也具备了管理团队的权力。即使是跨国团队中,PM有权力对非本地团队进行指挥调度,这是再正常不过的事情。不要因为中国人的内敛而在“国际问题”上畏缩。

PM应该全力维护团队的利益。一方面反思和总结团队不足的地方,并对内做出迅速而有效的行动来改变;另一方面不能将责任全部揽入怀中,当客户出现挑衅责怪的时候,PM应该勇敢站出来做一个恶人,因为不能让团队受伤。

用数字说话,可以更好地反映项目的真实的状况,而不是“自我感觉”,感觉着东东不靠谱。

剩下的,就是用教科书般的简单办法去管理团队,保证质量,沟通合作。

……

这场发生在去年7月份的战斗,从结束至今已经有半年之久。在这半年里,我们无时不刻谨慎地对待新项目,因为那次战斗所带来的经验让我们力争不再犯已经犯过的错误。

感谢团队里面的每一个人的支持和付出,感谢开发和测试的大家伙儿在最关键的时候顶住压力在前线奋战,感谢软件开发总监和软件开发经理对这个项目的协助和指导,感谢美国的USP在客户那儿的斡旋协调,感谢美国的USP老大亲临武汉对团队的监督指导,感谢家人在背后的默默支持特别是连续好几个周末不休息,最后感谢当时的那个她在背后的支持。谢谢大家。

这个临危受命的项目已经尘封,新的项目还在开启,而人生也将继续一路前行。

2013.3.2 菠萝头

临危受命 — 黎明前的黑暗

团队继续吭哧吭哧地前进,在经历过功能更新,用户体验更新以及性能更新的阶段后,剩下的Bug让我们看到了最终Release的曙光。一阵邮件和电话会议后,双方敲定了最终Release的日期。

在最终Release之前的三天,我们突然接到一个任务,要求换一些程序UI的元素。此时此刻,我相当不建议接受这个任务,特别是在最终Release的前三天。由于程序UI的界面图片实际是存储在数据库中,新UI的界面和老UI的界面尺寸大小都不一样,所以还需要调整项目的XIB文件以及相关的代码,这些改动在最终Release三天前发生是一个相当有风险的事情。

经过一番争取,产品总监依然坚持需要改动UI,而且这个比任何都要重要,因为客户需要看到新的UI设计,相对于后台客户“看不到”的功能反而变得其次。无奈团队只好接下这个新的任务。

墨菲定律,如果说你真心想避免墨菲定律发生在你的身上,那么墨菲定律就一定会发生在你的身上。

最终Release的那天早晨,团队成员在更新SVN之后发现程序不能成功编译,提示说缺少一些文件。可是前一天的下午我们的Daily build还好好的。调来SVN Check in记录一查,发现当天中国凌晨的时候有美国团队往里面Check in代码。出错的地方就是他们新Check in的代码。

团队计划好当天的下午Release,可是上午还有很多事情需要做,时间一分一秒地过去。一方面,我们紧急联系了美国的产品总监,说明了情况,要求美国的团队立即Check in缺少的文件,使我们可以编译成功;另一方面,中国团队先注释掉必要的代码让编译通过,然后继续工作。一阵折腾,美国团队最后在中国早上的11点左右才Check in那些丢失掉的文件。团队的工作才得以继续。

有一点不能忽略,就是为什么美国团队会在最终Release之前的一天Check in一些代码,并且不知会一声其他的团队,更没有通知项目经理。按理说最终一天的任何Check in都需要通知项目经理,由项目经理综合考虑各种风险才能批准Check in,否则新Check in的代码很有可能产生严重的回归Bug。

可惜理论和实际总是有一段距离,项目经理在中国团队,理论上可以对乌克兰团队和美国团队直接管理,可实际上并非完全如此。乌克兰团队没问题,问题是美国团队直接由产品总监坐镇。产品总监来自于创业公司,本来就缺少大团队合作的经验,两三个人一起做事儿还可以,人一多心里根本没有任何流程的概念。所以很多时候,产品总监会饶过项目经理直接和美国团队说需求,然后美国团队的高级工程师们一起就干了并Check in代码。所以至此,可能中国团队和乌克兰团队都不知道这回事儿,只有当工程师更新代码的时候,才发现Check in记录,于是再反馈到项目经理这里来,项目经理再去调查Check in代码到底改变了哪些功能。美国团队高效率的背后,留给的是跨团队合作的隐患。

早上11点,经过我们的努力美国团队最终Check in那些丢失掉的文件。团队重新打好Build,QA立即去测试新Build后果然发现各种Regression bug。这些Regression bug都似曾相识,以前团队修复过,但是都有复活。很多Regression bug都会直接导致程序崩溃。于是,在这个最终Release Day的时候,程序的表现还不如前几天的了。

之前预测到的各种风险在这一天都直接变成问题,临时改变UI设计样式,前一天不经过任何确认就Check in一些新功能,这些都造成了现有程序的大量Regression bug。同时,在修复这些Regression bug之后,可能会有新的Regression bug的发生。噩梦,总是接着一个噩梦。

接近晚饭时间,大家精神高度紧张一天,我决定还是让大家稍微喘点气去吃个饭。我自己没吃饭,回家冲了个凉,以让自己疲惫的头脑更清醒点,疲惫的身体得到一些放松。躺在阳台的躺椅上,我看着夕阳,心想这段日子终将结束,最后一天还是把团队搞得灰头土脸狼狈不堪,真不知道这是不是最后一天……

闭目养神了几分钟,跳起来,穿上衣服,去了公司。

来到公司后,发现大家都站着办公区停止了工作,似乎在等着我回来。看见我来了,立马跑过来说UI的改动需要回滚,我说怎么了,他们说Bug太多了。我知道,大家在等着我的决定。现在要么回滚所有的UI改动,这几天白忙活,而且美国特别要求的任务没完成,换来的是现在的Release安全了(可能安全了,可能不会);要么坚持继续下去,修复完所有的Bug,然后交付,换来的是极大的风险导致不能交付。

在做决定之前,我还是想先看看现场到底发生了什么,而且在这危急时刻PM需要自己来判断而不是完全根据别人提供的信息来判断。我要求QA给我展示她们发现的一个个Bug,然后我和Dev一起判断这可能是什么原因引起的Bug。当我看完了所有的情况紧急的重大Bug后,我发现真正由替换UI引出的Bug不过一二,其他的Bug来自于非UI替换的组件。于是我做出决定,不要回滚UI改动,继续推进修复完所有Bug完成交付。

回过头来想,为什么当时大家都站在办公区停止了工作,为什么会认为UI的改动需要回滚。我想那个时候,大家跟我在自家阳台躺椅上的心境应该差不多。坚持了大概一个多月没休息,最后一天出了这么多乱子,使得大家士气很低落,于是开始怀疑自己的努力,并且想放弃自己的努力。我想,这个时候就需要PM站出来,勇敢地做出决定,并鼓舞大家的士气。

我召集所有人开会,告诉了大家我们看完了所有的Bug后,真正由替换UI引出的Bug只有2个,说明我们的替换UI的改动还是非常成功的。剩下的所谓的很多Bug,加起来也不过7到8个。很多都是以前修复过的问题不知道什么原因又重新打开了,换句话说,大家都肯定熟悉那块地方的代码,修复起来也不会太难。现场有这么多人,大家加把油,今天最后一天,做完就成功。

其实数据都摆在那里,需要一个人High level的说出来分析给大家听,大家才放心。我并没有“望梅止渴”,我只是在陈述事实。

最后晚上还算顺利,临近12点,基本开始进入交付流程了。我拿出钱,让大家去公司对面买些烧烤和啤酒,大家一起庆祝最后的交付。尽管最后已经快到2点了。

有人说,等下4点有球赛,干脆等下一起喝啤酒看球赛算了。呵呵,一群可爱的人。

最终还是没看球赛,大家各自在香甜的睡梦中,迎接了黎明的到来。

临危受命 — 功能,用户体验和性能

 

自从项目组成功的交付了前几个软件包之后,压力减少了许多。现在的软件看起来还是那么回事儿,而不是像几个星期前那样一堆跑不起来的玩意儿。可是我们的活儿还没完,接下来的几周主要是针对目前的版本做维护更新。

现在回顾起来,这几周的维护更新基本上是被美国产品总监驱动着前进。先后经历了功能完善,用户体验完善和性能完善阶段。

首先说功能完善阶段。一个软件最基本的功能都没能实现,当然不用谈其他的。整个软件团队分为三地,美国,乌克兰和中国。软件有四个组成部分:Server, HH, DB, Web。软件开发阶段的前期貌似没有非常明确的说明团队是按照横向分工还是纵向分工。所谓横向,就是四个组成部分一个团队专门负责一块或两块,不会有一个组成部分同时由两个团队进行维护;所谓纵向,是按照需求功能分,一个软件需求可能四个组成部分都会涉及,那么同一个团队为了完成一个需求会四个组成部分都用到。

现实的情况是乌克兰团队负责HH和Web;中国团队在开发阶段主要负责Server和Web;美国团队负责DB,HH以及Server。所以应该算是偏纵向分工。在开发阶段,中国团队的作用基本上是处理分配过来的任务或者需求,没有一个整块。其他两边的团队也各自为政。最后导致的结果是,貌似每个需求点都有开发,但是又都连接不起来。所以我们的任务是在别人70%的代码上做补充修改。经过分析,其实所谓的需求都不太难实现,只是横跨的组件非常多,而团队之间又缺乏沟通,所以导致很多事情做了但是没做完,半吊子。

好吧,开始工作了。首先,该项目并没有正规完善的功能需求说明书,于是先让QA根据界面设计测试用例,然后让QA进行测试 — 结果当然是Bug一大堆了。于是,在没有功能需求说明书的情况下,开发们可以根据Bug来有目标地进行工作了。(想想极限情况是什么,就是一行代码没写,于是功能说明书就完全以Bug列表的格式展现了)。

此刻最大的变化是,中国团队开始介入HH的开发,于是Server, HH和Web中国团队就都有横跨,这样可以极好地解决跨团队沟通效率低下的问题。这时候有人提议,干脆以后就把所有的模块都接过来得了,免得出现其他团队不好合作的情况。这个建议立即被我们的软件开发总监驳回了,因为从商业上和实际上很难一个团队把所有的模块都接了,另外奢求这样的工作模式实际上是管理低能的表现。

吭哧吭哧地前进,随着主要的功能性Bug被修复,软件也可以慢慢跑起来了。美国产品总监在点击某些按钮时发现结果也可以正常显示出来后,就开始注意用户体验了。

以前三地的团队都是做企业级应用的,和互联网应用不一样,通常企业级应用对用户体验的要求比较少,所以印象中企业级软件的界面都比较丑陋。可是我们做的是iOS,iOS有些基本的用户体验规范,这些用户体验规范由苹果官方出品为的是所有的iOS应用有着相同或相近的体验。在我看来,有些iOS基本的用户体验已经不是传统上的用户体验,而是默认的必须要的功能。

举个例子,某条规范说用户在触发一个事件后,如果结果不能立即出来,应该有某种提示进度的方式。即如果你点击一个按钮,在去下一个屏幕的之前需要等待很长的时间,那么需要设计一个提示框或者转圈指示器显示在屏幕中央,如果没有,那么用户体验是相当恶劣的。

再举些例子,有的时候一些iOS应用就是把用户体验做到极致,比如打开App store,里面介绍应用的页面通常会列出好多应用,而这里的显示逻辑是先加载基本的框架,然后再加载所有应用的文字,最后再加载所有应用的图片。想想看,如果给了一般团队做,估计是对一个应用进行框架,图片和文字的加载,就算多线程也会出现在界面上时快时慢的现象。

吭哧吭哧地前进,对用户体验类型的Bug做了一轮整体的修改,于是软件又看起来更像那么一回事儿了。美国产品总监开始考虑性能的问题。

在我们的测试过程中,发现有些环节的数据加载特别慢,于是调查代码实现,发现加载慢是因为前期设计有问题,设计地非常草率。现在看来哪怕一点点的思考力,就足以解决这些性能问题。换句话说,解决性能问题的根本不在维护阶段,而在设计阶段。设计阶段越草率,后面的维护工作就越麻烦。

所以,在设计阶段就需要开始考虑上线后预告有哪些数据,对每个功能点的开发都需要有足够的思考 — 如果这里有很大的数据量怎么办。进行过这样的思考和不进行思考就显得不一样,甚至代码的实现角度都会不一样。上面的用户体验的例子也可以放到这里作为性能的优化方案来讨论。先UI框架,然后所有的文字,然后所有的图片,就是为了对付图片下载的性能问题,所以把图片的下载放到最后,而把主要的页面框架文字放在前面。

好了,功能也完善了,用户体验也OK了,最大的性能问题也解决了,准备终极Release了吧。

临危受命 — 一次完满的Release

Release,即软件发布,俗称发包。在整个软件开发生命周期中,Release算是最扣人心弦的环节,因为这是整个周期的最后一个环节,而又往往是麻烦最多的环节。

之所以说Release扣人心弦,是因为大多数情况下,项目总是在资源有限的情况下进行的。要么是时间资源有限,要么是人力资源有限,最后为了能够保质保量通常不是以非常”优雅“的姿态,甚至以”狼狈“的姿态完成,最后惊心动魄地“刚刚好”完成任务。

另外一个原因导致Release总是让人提心吊胆是因为这个毕竟是软件开发周期最接近Deadline的环节,所以一旦项目出了一些错几乎没有什么多的机会加以改正,直接会导致项目延期。

从Release的作业内容来说,发布团队需要将一个软件的各个组件衔接起来,再加上项目上的文档,说明,七七八八的千头万绪,一点点的意外和疏漏少则提高所有人的荷尔蒙,多则需要重新来过,所以不得不让人绷紧了弦。

所以一次正常的,在各种资源有限的情况下完成Release,需要一个PM甚至一个团队倾尽全力完成。团队越大,合作起来越复杂,PM在里面倾注的心力越多。

幸运的是,我们依然可以从那些成功的Release中总结一些经验,并形成一个框架模型。不同的项目参考这个模型或许可以让自己相对“优雅”的完成项目的Release.

通常来说,Release环节的进入标志为Code Freeze,即代码冻结 — 所有人不得做代码Check in. 通常这个代码冻结的时间点由PM给出,而定这个时间的标准则是根据项目规模,复杂度决定的。比如,临危受命的这个项目,在交付日当天的下午1PM开始进入代码冻结。下午1PM是怎么定出来的呢?是有经验的项目管理人员,根据这个项目的规模大小,根据一次冒烟测试的时间做出的估算。有的大型的项目估计会在交付日提前两天开始进入代码冻结,因为需要留足够的时间进行交付测试。

交付前为什么要做代码冻结?每次代码Check in,都会改变整个代码库编译的版本。Check in要么是提交一个新功能,要么是修复缺陷,要么是改进代码,任何的代码的改动除了带来本身的价值外,都会引入回归(Regression)的风险。简单地说,任何代码改动可能会带来新的问题,轻则出现新的缺陷,重则整个包打不起来。如果现在已经进入交付测试阶段,不做代码冻结,开发者在测试阶段做的任何代码改动,都会让现在的交付测试报废 — 因为你无法确认这次代码Check in会不会引入以及引入什么样程度的缺陷,所以交付测试需要在每次改动后再重新来过一遍。为了让整个交付程序更加的顺畅而不是一遍遍重新来过,需要做代码冻结。

代码冻结后干什么?当然是打Build,就是把这套软件的各个组件进行编译然后连接成的软件包。这些软件包叫Release Candidates,即“交付候选”,这些候选包会做一轮Release testing确保没有大的问题才能真正Release出去。

Release testing的级别通常由项目经理和QA Leader做出决定,是做一轮完整测试,还是做一轮冒烟测试,亦或是最简单的Bug verification和小范围的回归测试。做此类决定的标准一般有三:1. 交付包的内容。如果这个交付包里有大量的改动,那么还是做一次完整测试好,否则一般改动就做冒烟测试。2. 本次交付的重要程度。非常重要的交付比如要直接上线那么还是需要做一轮完整测试的好。3. 留给做测试的时间。这是一个非常现实的问题,如果交付前期花费了大量时间,最后留给交付的时间不多,那么项目组不得不接受一个现实是没有足够的时间测试而只能妥协做低一级别的测试,从而背上一些交付失败风险,或者项目经理出面协商交付延后,当然这个也会对团队的信誉产生负面影响。

刚刚做完了一次Release testing,QA组发布了一个Bug列表。这些Bug需要在这个版本里面修复掉吗?如果选择修复Bug,那么不可避免地需要一个新的Release Candidates,而且附带有一轮新的Release testing,而且还会有新的Regression bug产生。在争分夺秒的交付时间线里面,每一次代码重新改动都需要仔细考量,因为上面的Release流程耗时很长,但又是必须的。

基于这些想法,所以一次Release testing,通常只会修复P1到P3的Bug,P4和P5的Bug就不用看了。当然项目经理可以对临场的情况做出决策,因为坏情况在于有时候P1到P3的某些诡异Bug修复时间会过长而影响Release,所以最后可能会缩小修复的范围到P1到P2,剩下的作为已知Bug列表报给客户并做出计划什么时候修复。当然,如果P1到P3的Bug太多而导致这次交付基本不可能,那么团队在交付期已无力回天,别怪交付了,好好复盘一下整个的开发过程吧。

最后整个的一轮轮做完,最后一个Release candidates将会作为交付的正式版本发给客户。用7z或者zip等压缩软件,将你的软件精致地打包好,传上FTP或者附件吧。最后一个环节也不要出错,确保你的软件包不会因为网络原因而上传不完整,否则刚才的一切努力在客户那边都白费。

最后的最后便是Release Email, 一般来说一封Release Email会有一个稍微正式的格式,让阅读者体验到“看,这个Release是我们静心准备的”。内容上会包括这次交付有哪些组件,交付版本号,代码SVN存放处,Build的存放处,还会包括一个Release Note的附件。Release Note里面会写这次交付具体有哪些更新;会有已知Bug列表,告诉接包方这个包里面还有哪些Bug,这些Bug计划在什么时候修复;当然还会有下一阶段的计划等等。

经历过上述这么多步骤后,终于可以说这次Release成功,大家可以回去好好睡一觉了。