希望在转角

刚刚度过了一个充实的一周。

有一批10人规模的实习生到公司报到,按照公司的惯例,任何进入公司的人必须经过公司的Training Project, 所以需要有Trainer。而这次的培训主管由我的主管担当,主管需要两名培训助理,而我也有兴趣在培训上面,于是便在日常工作外开展了培训这条分支。

由于天生有老师的血统,所以我自己比较有信心和愿望将这次培训做好。总体来说,主管和另外一名助理在技术方面的基础好一些,他们主要负责技术上的指导,而我的目标就是关注实习生的价值观的形成和正确工作方法的培养。在实际中分工却没有这么明显,我也负责技术的讲解,甚至要单独准备一节重要的课程。刚进来的实习生带着很多校园气息,工作方式不太规范,这正是我要着手抓的。有天晚饭后回来花了一个小时独自看了那十个人的Daily Report,把所有的错误和不规范的地方总结出来,第二天跟大家讲解清楚,并鼓励实习生们一起设计Report模板,按照一致性(Consistency)的原则,统一的格式发给所有Trainer。实际效果还不错,从第一次接到他们的Report开始,只用了两天的时间大家的格式风格全统一了,尽管实际还是有小错误,但是基本的邮件写作规范意识已经形成。这点在前一次培训时他们则花了一个星期多才纠正到位。

培训中也有角色扮演,白脸和黑脸。其实这次的3个培训人员全都是白脸类型,比较nice,不容易发火,不喜欢训斥。我被另外两位一致要求扮演黑脸,尽管我不太擅长,因为和我的风格不太一致。在实际中,我也会严厉批评犯错的实习生,特别是涉及到违反核心价值观的行为,不过主要是就事论事,我不喜欢对人本身太多指责。我的理解是每个人都有潜力的,与其强权要求他做什么,不如在可控制的范围内鼓励让他做主,发挥他本人的主观能动性,尽管结果可能没有我直接告诉他的好,但是这个过程会让他成长。这一点在我自己的项目团队中我就一直是这样的。但是配合今年团队主题,我更加强调执行力和对细节的把握,我不希望一个邮件的写作问题会拖沓很长时间,所以一旦发现邮件中有先前强调过的问题仍然发生,直接要求其重发。如果一个邮件基本格式和礼仪都不能写好的人,我很难相信他的代码会写得怎么样。第一次犯错叫不知道,第二次犯同样的错误叫不小心,第三次再犯那就是故意的。于是黑脸,一顿训斥,同时对表现好的一番表扬,结果下来,这样程度的黑脸得到了大多数人的理解,而且保证了执行力。

在谈谈项目这一块。我所在的项目一直有技术含量不高的诟病,可是最近客户决定借着3G和苹果的势头顺势而上,转向苹果系列的开发(iPhone&iPod),我们的工作内容就从一个连CSDN上都找不到的程序语言转换为全世界最热门的编程语言之一(Objective-C)。我一直死守到现在也终于看到了这个项目组的前景,前几天中午吃饭,有一个同事开玩笑说想进我们的项目组,因为想玩iPhone。我惊呼:这是我到这个项目组一年半第一次听到有人想进我们的项目组。其实我知道,在这一年多以来,不断有同事被调出,这里之前就像一条路撞墙了,待了一段时间技术再成长不了了,可是现在我在墙边看到了转角,转角后看到了希望和前进的方向。我们项目组的故事就是公司一个真实的“丑小鸭”的故事,而它给我们最大的启示就是面对丑小鸭,要多给它信心和耐心,并坚持不断创新和改变,从绝望中找寻希望。借此,我也要投入时间在这个新知识点的学习上了,至少我找到了技术的方向。(可我自己的2010目标不会变)

在谈谈生活。生活上的东西总不太敢多谈,因为主动的人肉防御。这个话题最近又呈现出来,特别是当一个平凡的人在他她它生活的小圈子里面比较出名的时候,就会遭遇到人肉搜索。坦白讲我自己也人肉过别人的QQ号,不过我是好人(囧),我只做些方法上的演练,再加上自己的保密意识很强不会泄漏自己获得的信息,更不会无聊地骚扰对方(没那雅兴没那时间)。可是毕竟有人会,所以如果有这些人进入了主人的视野,那么将他她它Block掉是当务之急,另外就是可以下意识地减少一些自己的暴露隐私的内容,避避风头,同时增加安全选项,可以防止不太认识的人获取信息。信息安全很重要,至此真的很明白。

才发现写一篇博客真的需要很长时间。。随笔Over.

技术是死的,人是活的

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

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

1. 不要让技术指导业务

这里的业务不仅是指商业上的业务逻辑,也包含常理的意思。技术人员在讨论问题的时候往往容易陷入一个比较荒唐(ridiculous)的思路:先想技术的实现,然后再想业务逻辑。

这里有两个例子:

a). 某业务讨论会上,在场有DEV和QA。我们对某种屏幕跳转方面的逻辑不是很清楚,而且需求说明(FRD)上又没有指出,于是大家都在说自己的观点。某QAMM说话:我觉得应该是从A屏直接跳到B屏,当时用户完成了某种操作之后。。这里的record还没有创建。。那么肯定要先到B屏才能完成record的创建工作。。。我不得不站出来打断,等等,你是在分析业务逻辑,不要把技术的层面加进去,这会形成混沌(chaos)。你作为QA你的业务层面比DEV高,你就只站在用户的角度去分析这里的用户体验应该怎么样,然后我们DEV再来分析技术上的实现问题,技术上不能实现再说,而你不要帮我们分析技术的可行性,尤其是当你在分析业务的时候。

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

b). 技术上的DEV之间的讨论。对整形数组进行排序,排序规则自便,只要求客户和我们排序方式一样即可。比较两个整形之间的大小我们通常用>, < , == 之类的运算符,这也符合常理。可是某DEV认为,现在已经有现成的比较字符串的ASCII码进行排序,何不如把整形转成字符串然后用ASCII码进行排序。争论了半天,终将其说服:用整形大小排序比较符合常理,而且设计实现非常简单,并不会耽误我们很多时间。如果为了节省这么一点时间或者因为偷懒而用现成的string算法来排序,诚然是可以的,因为只要求客户和我们排序方式一样,但是会令人感到奇怪,这个非常荒唐。而且从技术角度来讲,这样的算法效率性能并不好。

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

先想技术的实现,然后再想业务逻辑。这种本末倒置的思考方式是被必杀的。当然也有例外,比如业务逻辑用现在的技术实现不了,或者用的代价太大,那么可以反过来通过思考技术实现来引导出来一个大家可以接受的业务逻辑替代方案,然后跟客户交涉:您的“业务逻辑实现”(注意是业务逻辑实现,不是业务逻辑)稍微改动那么一点点,可以加快项目的进程,从而让您省钱。

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

DEV之间讨论技术方案:一种方案是用三个参数的函数,另外一种是用两个参数的函数。其中都要有个描述排序规则的函数地址作为参数,第一个方案通过第三个参数描述是倒序还是正序,第二个方案则需要写两个函数来实现正序或者倒序。据某DEV说,第二种方案根据设计模式来(未证实),实现正序倒序与排序原函数分离。我要大家扪心自问一下:到底是哪种方案方便?第一种对于每种类型或者每个对象只用描述大小关系即可,而第二种设计模式主张的,需要描述正序或倒序。第二种方案每遇到一个排序需求就得写两个函数来实现倒序顺序,而且大量重复代码,只是返回值不一样。那要是作为一个公共方法,遇到一个大型的系统,那不写死了。

这里不是否定设计模式,而是希望灵活运用设计模式,毕竟在商业软件开发中要注重成本。同样的道理,用最简单代码实现的最优算法不一定好,团队其他成员都无法理解,给后期维护带来隐患。中国别的不多,就是人多,用if else堆来实现逻辑大有人在,虽然很丑,但是很实用。

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

3. 最难的是承认错误

DEV之间讨论技术方案:某DEV想从数据库里面取出数据,放在一个内存的临时空间,然后遍历这个临时空间,再放到我们的目标临时空间。我认为很奇怪,为什么要放中间一个临时空间而不直接取出数据放到目标临时空间呢?他认为他可以用3行for循环代码简单的实现,而直接放要hardcode太丑了。。我说你这样影响性能,特别是在移动设备上,而且你的方案需要在前期hardcode 20行的数组来实现也很丑,最主要的是这个思路太荒唐了。不服,怎么都不服,于是叫来主管做评判。。评判很快出结果,于是某DEV推翻了以前的作品重来。。翌日,跑过来跟我说,改动之后性能果然提高了很多,而且代码更精简。。。

技术人员都有个心理:在技术上不服输,坚持自己的观点。这点挺好,但是如果在事实摆明的情况下依然坚决捍卫自己的代码,那就是不明智了。其实犯错很简单,因为是人只要活在这个世界都要犯错;不犯错也很简单,在自己容易犯错的地方多注意点,多检查几遍;最难的是当自己的错误被别人指出来后,勇敢并大气地承认错误,并推翻自己之前的方案重新来过。

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.

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

 

申请假期其实是博弈

快过年了,公司照例有很多人在申请假期。

公司员工都这么想:把年假和春节连起来,就可以大概放半个月了。而平时短短的年假加周末根本不能请到这么长时间,长假期也就可以考虑长途旅行了。

公司管理层都这么想:都请年假了还怎么做事,而且一大半人都请年假会有风险(risk),如果项目新来需求没人能扛起来怎么办。尽管员工之间商量好互相有照应(backup: 请假时找别人顶),但是还是要留缓冲(buffer)的啊。因为管理层直接对项目负责,所以理所当然会多为公司考虑。

一般来说,公司管理层和员工都知道对方怎么想。而我们的请假是要走流程的,主管->经理->总监,一层层报批上去,如果最后同意,然后再正式写流程进系统。于是博弈开始了。

员工这一层写申请,总会写他想申请的最大的天数。他尽管知道这申请极有可能被主管这一层否决掉,但是抱着试一试的态度去提交申请,因为大不了被打回来然后再重新写一份申请去尝试。

通常一个项目组中员工之间会互相讨论,相互协商制定一个感觉“让上级感觉OK”的方案,然后有一个人去把每个人的申请合在一起上交。那么这个人拿到这个申请也在想主管会不会同意,如果不同意肯定会问责他。所以他会先看申请方案,但是会痛苦地因为同级之间的关系而不能轻易将别人的休假否定掉,不然以后在一起工作就很多麻烦。于是也抱着试试的态度给主管,大不了解释一通然后再次提交。

主管拿到员工的申请,就不会首先想细节方面的以天为单位是否工作冲突,而是首先想整个团队的总申请休假天数会不会被经理接受。如果不被经理接受,哪怕互相照应的人(backup)可以把风险控制到可以接受的程度,依然会否决这次团队申请假期方案。否则会被经理问责。

再往上就不用说了,大同小异。

我们如果纵向看员工,(主)员工,主管这层关系就会明白,往往在这样条件下博弈是没有意义(meaningless)的。关键就在这流程上,流程严格地规定了层层报批,所以基本上中间的“侥幸”成分已经被消化干净了,反而会带来一些上下级关系上面的紧张和不和谐。

要解决这样的问题,多方不如都退一步海阔天空。
员工多理解下公司领导们的担心,年假就不要一次都请光了,特别是在团队中担任重要职位的员工就更要知趣了,有些话和道理不用讲太明白。
一个团队中有新员工和老员工同时在的,新员工可以主动在协调中让步下,下次休假可以轮到你。
管理层则多思考和调研下风险性,毕竟协调好员工和项目之间的博弈是管理层的职责所在,取得平衡的意思不是完全保证没风险,可以协调诸如休假前员工自己多加加班把之后的风险消化掉,相信这种加班员工也是很愿意的。

感叹一句理解万岁,大家便都可以开心和谐地过假期。
 

2010新年目标

 个人在2010年决定向管理咨询方向发展。

管理咨询的基本技能:逻辑+演示。清晰的逻辑是一个咨询顾问的本中之本,在内容上的循序渐进,滴水不漏则是专业性的体现。再完满的逻辑观众接受不了还是没用,而演示则是让观众更好的接受,并且留下深刻印象的法宝。

未来会更多地与人交流,lie to me里面的看人识人技能再度被提上日程,学习看人识人方面的技巧最好的办法就是与更多的人接触,并且在做演示的时候灵活运用。这也是为以后做销售做好铺垫。

2010年全年主题:敏捷(Smart)

2010年全年基调:潜龙勿用

先谈个人发展:

1>. English:除了能够基本用英语传递信息之外,还要争取加上语音语调,以及日常表达的通俗形式,让自己的英语再上一个台阶。

2>. PPT: PPT将是2010年训练的重点,训练的项目便是团队的文化建设,职业技能培训为主题的团队课程或者租房信息。一方面是为团队建设作贡献,另一方面是锻炼咨询顾问的看家本领。同时也感觉自己的兴趣爱好在这一方面,当做出能够华丽展示激动人心的逻辑的PPT确实是件让人兴奋的事情。

3>. 读完大前研一的《思考的技术》并发布读书笔记。

4>. 读完《身体语言密码》并发布读书笔记。

4>. 让自己更独立。衣服自己洗,以光谷为基本的base。

5>. 勇敢地走出自己的心里舒适区。做人要刚,处事要圆。09年最大的失败在于做人也圆了,这一点在2010年要改变。

6>. 认清武汉的大部分街道。

7>. 读更多的书。争取一个月读一本书,这样一年至少就是12本。

再谈工作发展:

1>. 将团队建设成为敏捷团队。减少加班时间,合理控制客户,提高执行力。

2>. 争取找领导要一个人过来,让自己变成真正的China principle.

3>. 争取在公司内部慢慢通过培训或者经验分享的形式将自己人脉打开。

4>. 努力表现好好升级。2010年感觉可以在职位上努力跳一跳了。

最后谈感情:

找到一个女盆友。 over。