实习项目周会

周五给一群实习生开周会,Candy跟我说让我主持,让我引导一些相对轻松的话题。同时武汉这边的SQA老大也参与这次周会。

虽然话题轻松,但是目的不能太随意,否则扯到娱乐八卦上面也顿时没有价值了。简单的开场白后,我提出这次周会的主题:说说自己对实习项目的感受,和在学校的不同点,以及一些印象最深的事情。就像一个谈话节目,一个主持人,一群嘉宾,开始round table,每到一个嘉宾的时候,他先说自己的感受和想法,然后主持人见缝插针地抛出一些问题去采访,偶尔旁边的Trainer和SQA从中扮演顾问的角色。

这三类人都在实习项目中收获了。绝大多数收获了技术能力,因为在学校里面学到的哪怕皮毛的理论也在交卷时忘光,或者自己在学校实验室捣鼓的代码其实非常不规范;有一部分收获了学习方法,他们知道如何去学习而不是去背书;有一部分原来技术基础好的则收获了文档写作能力。其实总的说来,他们收获的是一个商业软件项目的运作环境和视野。虽然只是一个实习项目,但是作为一个大三或者研一的学生在未毕业之前能够获得这份实战学习的机会是很幸福的事情。

这其实也引发了我的另外一个思考:企业要不要在将来合适的时间将实习项目做大 -- 比如 高校联合培养模式。高校联合培养模式是一个经典的Win-Win模型。

待未来时间和条件成熟,我认为以服务交付为主题的光谷软件园肯定有企业会推出这样的模式,说不定现在就有了。

学而不思则罔

子曰:学而不思则罔,思而不学则殆。

每天团队成员都会发Daily Report,汇报对象是自己的主管,经理和质量监督专员(SQA)。各个团队的Daily Report根据项目不同而风格各异,但一般包括“今天做了什么”(Done),“明天要做什么”(ToDo)。这两个栏目是Mandatory的,就是必须要写的。我们团队还包括两个栏目,“遇到什么问题”(Issue)和“你还有什么想说的吗”(Additional Comments),这两个栏目是Optional的,就是可写可不写的。

一般来说,在工作中,“可写可不写”的意思是“不写”。

写Additional Comments有什么好处:
1. 对自己一天工作的个人总结。
2. 让老板知道自己的状态。

于是,就将团队的“Additional Comments”这一栏调整为Mandatory,必须写。这个成本很小,天天写那么多code,写那么多test case,写几句话,包括思考在内不要两分钟的时间的。

到底该不该发未完成的包

这大概是两个星期之前发生的事情了,这个星期一直很忙,于是没记下,再拖就一个月了,决定今天,现在,记下这个教训。

经验总结,关于该不该发未完成的包:

如果提交对象是非技术型客户,不能发,因为没有任何意义;

如果提交对象是技术客户,谨慎考虑,尽量不要发。如果实在有原因要发,要在邮件写清楚,并且注意把握可能发生的风险。

发未完成的包都会因为误解、沟通丢失等带来各种各样的问题,决定发的人要为此负责。

职场重生

分享一个老鹰重生的故事:鹰的寿命有70年,但是在40岁的时候,它的爪子开始老化,喙变形到阻碍它进食,羽毛又浓又厚。它只有两种选择要么死亡要么重生。重生需要150天,在偏僻的山崖啄掉厚重的羽毛,再磨利老化的爪子和喙,冒着疼死和饿死的危险,可是一旦过去,它就能再翱翔30年!

早点给code请个医生

有这么一个场景:

一位穿白大褂的医生脸色凝重地走进ICU(重症监护室),对躺在病床上的70岁老人的家属说:太太,CT显示您先生大脑里有一恶性肿瘤,不过这个恶心肿瘤现在是可以通过手术来完全移除的。
太太:那好啊,什么时候安排手术?
医生:不过。。您先生岁数太大,身体机能无法承受手术中的创伤。虽然手术可以完全移除肿瘤,但是只怕先生挺不到手术结束了。
太太:那怎么办?
医生:那就保守疗法,将就活着呗,直到自然死亡。虽然会有痛苦和随时死亡的风险,但是比在马上的手术中死亡要好。
太太:……

与此同时。。。

一位穿着衬衫的高级软件工程师脸色凝重地走进办公室,对底下的工程师说:你的代码在项目结束前的Code Review(代码评审)中发现一个严重的性能瓶颈风险,现在体现不出来,但是在客户那边数据到达一个数量级就会体现出来了。。还好我已经有解决方案了。
工程师:那好啊,现在开始改?
高级工程师:现在来不及了,项目已经接近尾声。这个项目必须在明天提交客户上线,现在做出如此多的变动风险太大。
工程师:那怎么办?
高级工程师:先发给客户呗,在Release notes里面写清楚风险。随后我们开始做软件更新,然后再发个Patch过去。不过这段时间成本客户是不会给钱的,而且客户满意度会因为这个patch下降。
工程师:……

上面的两个场景有一个共同的尴尬:有一个解决问题的方案,但是因为时间(或者岁数)的关系来不及执行下去。
引发这种尴尬的核心原因是:发现问题太晚,总是在deadline前后发现。

最近的一次项目尝试使用上面的方案,客户在电话里面说非常满意软件质量。

于是,就出现下面一个场景:

一位穿白大褂的医生表情轻松地走入了病房,对一个躺在病床上的小伙子说:CT显示你的大脑里面有一颗良性的肿瘤,现在用手术可以轻松解决。但是如果现在不做手术,你70岁的时候可能要在ICU(重症监护室)里面度过了。
小伙子:谢谢医生,现在可以手术吗?
医生:嗯,马上!

与此同时。。。

一位穿衬衫的高级软件工程师表情轻松地走入办公室,对一个正在埋头写代码的工程师说:刚才我花了半个小时做了个Code Review Sprint,发现你的代码里面有一处性能瓶颈风险。现在如果不改的话,那么将对以后的代码造成严重的影响,最后到客户那边的大数据负载下会不堪重负。
工程师:谢谢,您辛苦了,现在我可以将改动Commit进去吗?
高级工程师:嗯,马上!

向咨询行业学工作奥秘

2010.5.18日,在公司给工程师们做的培训PPT。

今日事,今日毕

一个人如果没有目标,就会迷失,就会拖沓,就会慢下来。

这句话用在大方面可以上升到职业或人生规划,小方面则可以具象到每天的工作。

对于一个每天都必须要有产出的团队,我们的风格是“敏捷”,我们的目标是把事情搞定。(Get Things Done)

职业规划就像跑圈

前段时间公司总监之一Daniel跑到武汉来做了两场培训,一个是关于怎么做一个好测试,另外一个是关于软件人的职业规划。这里将软件人的职业规划中的要点记录下来,其实这些职业规划的思路不仅仅是局限于软件行业,其他行业同样受用。

1. Passion/Good At/Experienced In/Not Good At

2. 职业就像跑道

3. 安居乐业

4. 姚明身上思考职位选择。

5. 语言和技术的比较

6. 大心脏

7. 经常横向比较。

加班也要从娃娃抓起?!

 这篇文章貌似有点不合时宜,大过年的不谈点喜庆的谈什么职场相关。可是连当今春晚都开始植入广告,讲些网络上的陈词滥调,听得懂的人根本不笑,听不懂的人还是不知道,并不是代表人民众口难调,而是春晚导演点子实在不高,相声变小品小品变广告,以为博得群众热闹,结果迎来一片叹息“我靠”。

其实趁着春节长假节奏慢下来,可以静心去思考一些平常无暇思考的东西。

软件工程师有证没证

证书的作用 -- 有比没有好,但作用不太大。

职业价值判断 --在企业工作的职场人士更重要的是经历。

一辈子做这个会不会累死

世界在飞速改变,不觉得只是因为不知道而已。

加班要从娃娃抓起?

重点是他们花的学习时间多。

技术是死的,人是活的

 

上一周的工作对我很有启发,本来想在周会上分享给大家的,可是后来谈我们的新年目标“敏捷”去了,由于时间关系也没有再多谈一周感悟了。

简单的说这周工作中的思考来自于和团队成员的几次争论,我是站在实用的观点,对方站在技术的层面,总结出来有三点:

1. 不要让技术指导业务

Comments: 从本例中,思考的方式比结果更重要,思考的方式不对即使结果对了,这样的成功也是无法复制的,而且会对未来的设计更大的架构带来隐患。

Comments: 设计方案是给人看的,除非是遇到技术瓶颈不得已用非常猥琐的办法做之外,尽量用符合人之常情的做法,因为技术本身就是对业务的抽象实现。

2. 设计模式不如实用模式

Comments:马谡:书上说的居高临下,势如破竹,我要在山上扎寨。王平:丞相嘱咐过,万万不可啊,人家围山切断水源放火烧山,后果不堪设想。应该依山傍水,当道扎营。请主将三思。马谡:滚。。书中自有黄金屋,书上再找不到比这更好的设计模式了。。。魏军大喜果然围山并放火,蜀军大败,痛失街亭。诸葛亮不得不挥泪斩马谡,战略上退回汉中。

3. 最难的是承认错误

Comments: Engineer protect his idea and the code which has been written, I respect his idea and his code, but I respect the right logic more.

嗯,技术是死的,人是活的。

分页:[«]1[2][3][»]