阅读 801

打造高效小团队 - 敏捷协作 && 态度的重要性

年底了,今天站在一个 leader 的角度去看下面几个问题,和大家交流分享下软技能,如果你只是一线开发人员,千人千面,虽然不一定准确,但希望也可以做个参考:

  • 为什么我干的活比别人多?
  • 我的付出会获得回报吗?
  • 开会真的有意义吗?
  • 分组的好处在哪里?有缺点吗?

站会

规则

两个月前,由于某个项目需要快速迭代,成立了两个小组专门处理,先放两张两张站会规则「电子版找不到了我拍了张打印版」:

看起来还是很清晰的,大家凑合看吧,正如我上文所说,我们这套「站会小组」已经试用了两个多月了,优缺点各有下面给大家介绍一下。

小组分配

与以往的开发模式不同,以往只可能是:

  • 1、与产品碰需求,预估时间,确认纯开发时间
  • 2、N 个前端人员 + N 个后端人员进行协作开发
  • 3、待测试 测试 完成

其实上面的 1 没什么问题,关键就是 2、3,比较浪费沟通成本,甚至有的事情花在了「找人」「找问题」上面了,测试、前端、等不知道这个 api 是谁开发的,测试有问题抛给前端,前端不知道具体找哪个后端,抛给后端不知道具体找哪个前端。谁做到什么进度也未可知,那么这个小组的成立就是解决这几个根本问题。

每个组:前端 + 后端 + 测试 + 产品

所以我们为项目X 成立了两个组:A组 + B组

每个组:两名前端 + 两名后端 + 一名测试 + 一名产品

注意:每个组之间没有竞争关系,更多的是互相帮助的合作关系。

每个组各自协商定好各自组内的最合适的时间,比如 A组 每天12点开站会,B 组 每天下午2点休息后开站会,「站会」比一定非要站着,每次最好不要超过15分钟,所有的规则细节你都可以在上图看到。

分组收获了什么?

我们这样分组,项目 X 的快速迭代变得更加高效,我们不需要为共同发愁,每天碰15分钟不管是组员还是「分配者」都轻易掌控项目在组内的进展

对于组员「开发」来说

前后端找接口,对接口,不再是头痛的问题,前端可以更好地规划每天的任务,今天我「画UI」 明天上午 「对接口」,每天预留几个小时时间应突发状况比如:临时需求、临时开会、以及紧急的BUG等

对于组员 「测试」来说

一般我会让测试人员做每天站会最后的总结,开发梳理完昨天的内容,今天要做的内容,测试最后会说昨天测试了哪些功能,有何问题,是否需要开发今天进行调整,是否紧急,根据开发昨天说的内容来通知大家今天测试哪些,出了问题也好直接找直接负责人免得打扰其他人

对于组员「产品」来说

产品每天跟会,组员有问题及时解答,当时的疑问当时就为他们解惑,若有些产品都没考虑到的大问题,也给了他们时间进行调整修改,免得项目接近尾才暴露问题导致项目延期。每周五进行下一个周的任务讲解。

对于 leader 来说

真真正正做到了,项目的进度一览无余,没个人干什么做什么都一清二楚,每个人的工作量、工作能力在此时也完全暴露出来。此小组的任务以 「看板」的形式展示了每个人的任务难度 + 工作量,对于年底结算、kpi 有所帮助。每周三还有每周总结会,可以修改调整每个组的问题。

总结

成立小组让每个人的时间都接近饱和,以往浑水摸鱼的人不在了,不管是有能力不干活的,还是没能力的,都在此时不敢懈怠,我们不加班「泡班」,但是希望大家在上班的8个小时全心投入,赢得属于我们自己的自由时间。

缺点

看到这里其实大家心里都有数,缺点就是:「时间饱和」 大家比以前忙了,有压力了,明天站会说什么需要花点时间准备了,不能再上班摸鱼了。

打分,需要知道每个人心中不管是前端后端测试,对于某个任务的心里分数,期望是好的,但是由于大家举着卡片一起打分这种方式,大家觉得过于:形式主义,效果不太理想:

打分经常打出超出预期太多的分数,大多是开发打的,相比之下测试、产品打得分反倒符合我的预期,设身处地去想想也能理解,所以「打分」不了了之了,有时间的时候我会自己去「看板」上打一打分,不在征求大家的意见。

我认为比较成功,在我看来,没人有丝毫负面情绪,大家每天有说有笑的开完每一天的站会,做好每一天分内的事情。

组内成员的观察

组内合作,工作量全靠自觉自己领取,可能都是老员工大家也算给力,也都比较给我「面子」,每个人领取的任务上量 * 工作难度 全都符合我对每个人的预期。个别成员甚至有所超出我的预期(有个意外下文说)。

还有我对「研发」工作的开发者能力、效率、定位等经验心得总结也在下文一起说。

实习生的考验

上文说的意外,我们组内其实有个试用期的加入,职能是前端。

初来两周,站会基本不说太多话,问他的领导被告知是新来的,刚入职一个月,给点时间(怀疑脸,并没有什么值得花半月去了解)

第三周,基本能开口说话昨天做了什么,今天做了什么,比如昨天对了 xxx,今天做xxx优化,“什么优化” :“光标xxx input 事件的调整。” “。。。”

站会就是这样,你每天没产出什么,是编不出来,经不起推敲的。看板上任务很多,全凭自觉,且他所做的与业务无关无需了解太多时间,对此我已经对他有了个初步的 “懒惰印象”

我找了小组后端进行确认,委托前端的 leader 找他谈了谈。

懒惰这种东西就像是瘟疫,他会快速的在小组内流行起来,让其他拿着相同薪水的同事心里非常的不痛快,我不想让这种负能量的事情发生。

往后两周其实依旧没有起色,临近年底了,我也不想做恶人,我只能如实写出评价,祝君好运。

组员的一点心得

这么多年工作我发现两种类型的人:

  • 面试一般,入职远大于期望
  • 面试极佳,入职平平常常

有些人就是面试答得一般,但是试用期发现:态度很好,很积极,做事效率快,甚至交予的任务回家也干,上班基本做完了,让我有点感动,回想起我以前也是这样的,我虽然知道可能是「试用期」的因素,但是也非常难得了,态度是很重要的,我一般 关心一下, 看看代码质量、逻辑。适当增加一点任务,提前转正,也在我心里留下了一个好印象,日后有些独立的大块需求,我愿意放心交给他们去做。年终自然也会按公司制度多劳多得申请涨薪。

至于入职平常的一类人,其实是无奈的,如果他不经意间过了试用期那就更加无奈,完成一些我期望的工作即可,没有过多要求,一起开心共事就好,主要看其态度,如果态度极好主动要求加料、或参与某个产品的设计等,也会让人刮目相看。

切记:消极、负能量、懒惰、不与他人沟通。

另外有问题与同事多问,多聊。如果你也是工作积极,leader 会分配多点一点的任务给你,说明可能是:

1、你贵 2、他想提拔你

鉴于各个ledear心思不一样,自己斟酌吧。

不管怎么样,注意态度!注意态度!注意态度!莫要消极对待。

试用期的抉择

我和公司另外一个leader看法不同,我倒是觉得他更有道理,不过我更想为长远考虑。

他的做法: 给试用期的同事多分配一些工作!让其饱和,观察能力和效率,差不多了就转正,不行就换掉。

我的做法: 告知需求,一起听需求,告知他我对这个需求的看法,注意点,技术栈,刨去熟悉的时间,我给一个我期望的他绝对能完成的时间。全凭他自觉,

  • 若超了

我仔细看看代码,考虑考虑是否再给机会

  • 若一天不差完成了

看看代码已计提交历史是否游刃有余,判断下潜力,我也一天不差的三个月转正。

  • 若是提前了很多天

我真的遇到过,有个同事我 9.30 号给的任务,预计10天,一块需求,也差不多了,结果可倒好,10 月放完国庆,上班就告诉我写完了,我看了看代码基本没啥大的问题,调整下,一个多月就给转正了。若是试用期打压太重,纵然完成了,我怕日后戾气太重。

每个 leader 都有自己的「眼睛」盯着你,并不是要大家多努力,而是奔着自己的目的去干活,若你就想混混就行,注意别踩红线,混着就行。

如何巧妙和同事沟通

todo 单抽下章

如何向同事提问

todo 单抽下章

如何与 leader、cto 沟通

todo 单抽下章

原文:github.com/pkwenda/Blo…