分类: tech

  • 如何当好软件开发小组长(一)

    软件开发企业中,所谓小组长team lead,也叫一线经理,大多数是控制一个项目的开发、发布、质量控制、过程管理、人员分配等等各种事情。我在现在单位就是一个小小的team lead,做的事也是这些事情。本篇博文就我自身经验体会,讲讲如何做好一个小组长。

    1)如何考察组员的绩效?

    这其实是小组长最大也最困难的一部分工作,相对而言,完成项目进度不算是大事。绩效考核关系到组员接下来的工资水平,级别提升,是真正与个人利益挂钩的部分。现有的绩效考核依然是以长期观察为主,以产出结果为主,以努力程度为主。有没有那种天才,一周工作三小时即可呢?也许有,但是我看到的大多数根本没有努力到拼天赋的地步。有的人想法就是过得舒服开心,有的人是要努力挣钱养家,不同的想法决定了不同的工作态度。但是,有一部分人既想着少干活,又想着干俏活,只干出彩的部分。那这时候就要给他们足够复杂的任务,把压力提升一点,让他们从60分的结果提升到80分的产出。

    考察绩效很重要几点,一是跟自己比较,相比去年这段时间,应该有所提升,比如去年还是engineer,今年已经是senior engineer,从job description的描述上,工作能力工作范围都应该有变化,独立工作能力以及辅助其他人工作的部分都要大大增强。二是跟同级别的其他组员比较,当然这只是小组长自己观察的结果,同样级别的同样工作经验的,相比结果如何如何。三是看长期的努力,因为绩效考核基本上是半年或者一年一次,如果这个人只是在考核前努力工作,这种工作态度很不可取。另外要通过数据说话,比如任务的复杂度,完成工作的百分比,可以通过每周状态报告跟踪记录。

    2)如何沟通?

    作为小组长,最重要的工作不是自己去干活,而是给组员创造条件或者阻挡风雨,产出更多的结果。沟通相比编码来说,要更为重要。沟通包括与上级manager的沟通,与美国的高级经理的沟通,与PM的沟通,与其他项目组(或者测试组)的沟通等等。

    由于是外企,英语是沟通的最基本语言。现在拿起电话,基本上就是英语随口就来(吼吼),参加英语会议也不紧张了。其实人就是锻炼出来的,大学生的英语四六级通过,加上一两年的逼迫锻炼,基本上听说都不会有太大问题。

    最快捷的方式就是打电话,打完电话再发一封邮件确认重点。如果有视频,那么会效果更好。其次是通过sametime这种即时聊天,信息量要差一些,但是对于写强于说的中国人来讲要更顺手。最后当然也是最常见的就是发邮件,时效性差,信息量大,而且可以配图加附件。具体哪种方式适合,要看具体的问题和紧急程度。

    如果与组员的沟通,现在大多数是找个小屋子,聊上十几二十分钟。但是软件开发人员一般不愿意直接表达想法,拐弯抹角的,这时候我一般是不管他的内心想法,而是就事论事,讲讲自己的看法,应该怎么做比较好,然后让他说说为什么有什么不同的意见。

    现在项目多了以后,会有几个项目leader,负责各个具体的项目开发,我这里基本上算是救火队员和总控制台。这些项目leader以前也是开发人员出身,没有项目管理经验,没有沟通经验。举个简单的例子,某次单独聊天,我说要给你这项目加个任务,这位leader立刻就说我做不了,人手不够。排除掉真正的人手不够,作为小组长其实很难与manager说我做不到。我于是解释给他听,首先一点作为manager发任务一定是事先考虑过,相信这个项目组能完成这个任务,这是大前提。在这种情况下,草率的说“我做不到、做不了”其实是项目leader不成熟的表现。为什么做不了,从manager这里有什么可以帮忙协调的,比如说手头几个任务,是不是可以排排优先级推迟一两个,都可以商量讨论。

    没错,team lead最重要的日常工作就是商量讨论,而不是下命令。哪些有问题,哪些很紧急,排出优先级,找不同的人商量开会定结果要资源等等。另外作为项目leader和team lead最重要是有独立工作能力,不能“等、靠、要”。等,是指任务到手上,就是自己的事情,不能说“我发邮件给某某了,现在这事是某某的了”,而应该一直追踪事情进展状态到有结果为止;靠,是说自己业务上技术水平上有依赖思想,我做这个你得给我什么培训你得教我什么,不是说有培训不好,在培训的同时或者没有培训的情况下,尽可能从现有代码文档中找到线索,这时候我们问出来的问题就比什么都不知道强很多,而且对方也会感觉我们的问题在点上;要,是指需要美国的技术经理或者更高一级的经理下决定,否则事情就没法进展下去,不知选择哪个方案了,或者是你让我做什么我就做什么,不多做一点,这种独立思考和决策能力其实是大连这种地方最缺少的特质。

    先写到这,有时间继续写下一篇。

    另外在豆瓣创建了一个豆列“软件开发小组长必读”,http://book.douban.com/doulist/2429763/ 供大家参考。

  • 到公司第一件事是什么?

    This is email to whole team about “how to work better”

    当你到公司打开电脑后第一件事是什么?

    如果你的答案不是检查outlook今天的Calendar,建议把这件事作为首要任务,尤其是上午要做什么,更是很重要。比如我今天安排,上午一个面试,一个与performance review有关的培训,一个与lead的会议,这几件事都很重要。

    另外我们要注意与onshore的会议时间,会议电话id,有没有sametime会议链接,需不需要电脑。如果需要电脑,我建议有一个人提前15到20分钟去配置一下。如果是视频会议,那可能就要提前30分钟。另外相关人员准备一下材料,不要到时候临时去电脑里搜索,都拷贝到桌面,直接可用。如果这个人在线,可以ping他一下打个招呼。

    然后就是查看邮件,有的需要回复,有的只是参考。需要回复的一定要记下来,比如立即回复或者下班前给出结果。对于负责某个项目或者某整个项目的人来说,收到重要的邮件要立即与我沟通协商,该如何回复,如何make decision。

    邮件也最好用OneNote分分类放到不同类别下。

    看完邮件,没什么需要立刻回复的,这时候可以去泡茶喝水,稍微放松一下,然后开始一天的工作。像我基本上早上十到二十分钟会浏览一遍邮件,然后再找时间仔细看。

    最后很重要一点,注意身体健康,要吃早饭,可以到x号楼,稍早一点,既不用担心压车,又是一个很好的习惯。

  • 大连开发组开发流程及注意事项 – 2012-12-19

    1,Desktop大连开发组的开发流程如下,没有例外
    开始阶段:风险评估,技术难点研究,通过邮件或者会议,确定需求分析。项目Lead需要确定我们得到明确的截止时间,需要保证我们能在预定时间内完成。
    设计阶段:研究设计文档,小组设计评审,具体任务分派,应该保证项目中有新老人员搭配;
    编码阶段有:项目进度报告,每日代码审查。
    收尾阶段应该有: 小组代码审查;需求验证;正式测试;项目总结。产生结果:项目代码发布,小组代码审查文档,测试结果。

    2,每个项目要确保至少有一个Senior成员参与到需求,设计,编码,测试过程当中,保证新老搭配。这个Senior不需要具体编码,但要负责保证从头至尾跟随项目,保证流程按预期进行,指导开发人员,及时发现问题解决问题。

    3,每个项目,SA以及Senior成员应该作为第二测试人员出现,从用户角度测试,不需要遵循测试计划订好的测试方案。

    4,每次正式的小组代码评审,必须有XX, XX和我其中一人参与。

    5,如果任务比较复杂,问题比较棘手,研究了半天时间没有解决方案。请马上联系我或者项目Lead;如果大连组内解决不了,再求助Onshore team。先发邮件说明问题,紧急任务应该马上开会保证及时沟通得出结论。

    6,项目流程方面,如果需要有例外情况,比如不写什么文档,不做测试不评审,请事先通知我或者项目Lead。

    7,在开始阶段对最后整体实现效果有大致理解,可以预估技术难点所在,并且实现进行研究和求助。对于项目可能有的需求变化有一定的预估和计划。在项目开始阶段或者空闲阶段应该研究技术难点。

    8,每项工作应该有结果产出,代码或是文档,或者是周五做一次技术分享。学习应该有文档总结,项目有流程设计文档,代码或测试文档。

    9,代码review不要在下午三点半以后还checkin代码(可以留到第二天上午),如果有例外,应该通知代码审查人员,保证能预留出审查时间。代码应该直观易懂。代码格式应该符合英语常用语法格式,或者跟随onshore同事样式。我们写的每行代码必须能解释清楚,根据哪个需求来的。对于代码审查中发现的问题,必须逐条回复(改或不修改),确保没有遗漏,Group review需要填写正式review结果文档。

  • 开发组开发流程及注意事项

    这是我的方法论,在所谓敏捷之前,先教会团队如何走路,如果按照一个正常的软件开发流程来做事。

    =======================

    1,开发过程中注意要遵守以下流程,没有任何例外。负责feature的开发人员应该从接手任务第一天开始,每天更新project status report。

    开始阶段:风险评估,技术难点研究,通过邮件或者会议,确定需求分析;
    设计阶段:研究设计文档,小组设计评审,具体任务分派,截止时间确认;
    编码阶段有:Daily Project status report, 每日代码审查;
    收尾阶段应该有:Group code review;需求文档校验;测试计划及结果;项目总结。

    2,如果任务比较复杂,问题比较棘手,自己研究了半天时间没有很好的解决方案。请马上联系我或者咨询组里其他同事;如果组内同事也解决不了,再求助Onshore team。先发邮件说明问题,紧急任务马上搭建会议保证及时沟通。

    3,项目流程方面,如果需要有例外情况,比如不写什么文档,不做测试不评审,请事先通知我或者项目负责人。

    4,在开始阶段对最后整体实现效果有大致理解,可以预估技术难点所在,并且实现进行研究和求助。对于项目可能有的需求变化有一定的预估和计划。在项目开始阶段或者空闲阶段应该研究技术难点。

    5,允许犯错,但是要确保同样错误不要再次出现,从问题中吸取经验教训。

    6,每天的工作都应该有结果产出,代码或者是文档。学习应该有文档总结,项目应该有流程设计文档/代码/测试文档,项目进度有每日进度报告。每行代码在checkin之后的当天时间, 都应该有两个人review通过。

    7,代码review原则:不要在下午三点半以后还checkin代码(可以留到第二天上午),如果有例外,应该通知reviewer留出审查时间。

    代码应该直观易懂,不要额外解释,不用过多注释说明。代码格式应该符合English正常语法格式,或者遵照以前onshore同事代码样式。每行代码必须能解释清楚,根据哪个需求来的。对于Peer review和Group review中发现的问题,必须逐条回复(改或不修改),确保没有遗漏,Group review需要填写正式review结果文档。

    8,在你写代码之前,确保自己已经:a)了解所使用技术的大致用法。b)读过这项技术的大体教程或者代码实例,可以用最简单的能体现设计意图的代码完成大部分功能点。c)以前没有遇到的新项目的设计方案,确保设计方案与我沟通过,由我负责技术决策。

    请避免以下情况发生
    1) 将就完成,马马虎虎,不求甚解。– 在写代码之前问问自己,真的清楚知道在为什么需求编写什么模块的代码么?
    2) 需求不清楚,也不与onshore沟通澄清,在任务不清楚的时候就开始动手编码。
    3) 没有设计讨论,自己觉得没有问题,直接开发。有问题,不做优先级和风险评估,先开发了再说。
    4) 代码不是每天checkin,累积三五天;需要checkin的时候,一次加入大量代码修改。或者checkin以后不作代码评审。不注释,命名不规范,不关注静态分析或者调试中出现的异常log信息。
    5) 代码写完了,就认为是项目完成了,没有设计评估没有文档没有测试。
    6) 只有最后阶段才说明有问题,在开始时不考虑如何技术实现或者觉得不会有问题,不做风险评估。
    7) “我觉得没问题,但是也没有检查代码和需求。”“代码为什么好用?不知道;出问题的root cause?不知道”“这段代码干什么用?别人就这么写,我不知道,没研究过”“这个技术上肯定实现不了,没法做”

  • 欧美外企程序员如何学好英语

    英语的重要性越发的凸显,这已经不是想不想学的问题,而是不学就没法往上走,英语会成为最大的限制。

    基于此,我也在尽量坚持学英语,以下是一些方法,与大家共享:

    1)Podcast播客,手机都有这类软件,比如苹果的itunes里带有的podcast,或者安卓系列的doggcatcher。播客的优点在于不需要额外的去看,只要听就好了,所以我选择的也大多数是音频形式的播客。
    这里是我推荐的几个音频:
    BBC的Business Daily,6 MinuteEnglish,The English we speak,Global News。虽然是英音,但也非常练英语听力。
    NBC Nightly news,这个可以用来泛听。
    Business English Pod,这个非常推荐,
    English as second Language Podcast,非常推荐
    NPR Planet Money podcast,可以用来泛听
    CNN Radio News,用来泛听。

    视频方面推荐两个,一个是CNN student news,另外是TED演讲。这两个来源的特点是都有transcript,长度也适中。

    2)第二个方法是看美剧或者看技术类视频,美剧由于娱乐性过强,感觉不是太有效果,技术视频比较不错,推荐大家用这个办法。
    推荐看iqiyi.com的美剧,可以选择关闭字幕,比如老友记、广告狂人都比较经典。视频的话,建议大家可以安装一个vpn,上youtube直接看,或者vimeo也不错。

    3)翻译,看到好的技术文章,翻译成中文,或参加某个书籍的英文翻译,很有帮助。