其他 怎样带领好一个 Rails 团队?

wangxinrubyer · 2012年03月28日 · 最后由 jean 回复于 2012年07月11日 · 6791 次阅读

因为一些变故,鄙人需要扛下一根大梁。----组建一个 ror 开发小团队。鄙人不才,没有带过人的经历,既然抗下来了,也不愿辜负老总的期望。故在此虚心向各位带过人的老前辈请教,希望您们能传授点经验。鄙人在这里将感激不尽!!!

为了能思路清醒,我就把问题列出:

  1. 怎样才能成为一位优秀的项目管理者?
  2. 怎样才能带领好一个团队?

PS:

  1. 自己是新手,所以问题的问题可能会有些抽象宽泛,因为抽象宽泛所以才希望能得到您的指引。
  2. 希望是您个人的经验之谈。

36kr 里面不是有很多相关的文章吗?如何当好项目经理。先去搜搜看看学习学习吧。

问题好大,拆一下吧,比如

  • 如何设定团队目标和愿景
  • 如何招聘到好得员工
  • 如何跟同事相处
  • 如何制作项目计划
  • 如何保证按时交付
  • 如何激励团队成员
  • 如何让员工有归属感
  • 如何在工作中提升个人能力以及修养
  • ......

如何把自己管理好。 如何提高自己。 如何帮助别人。

#9 楼 @wangxinrubyer 我给的是答案。

没有非常具体的方法,只能靠自己能力的提高,当然,看一些项目管理,职业经理人方面的书籍也是很有必要的,最好公司有培训;管理人比管理事情要复杂的多,保持足够好的沟通是做好管理的一个必要条件。

去年和朋友一起创业,将一个 Java 团队转成了一个 ror 团队。项目按时上线。

ps 别做纯粹的管理者

#4 楼 @yuan 嗯,共同思考!

#5 楼 @zeeler 谢谢,我记下了。

#6 楼 @suxu 我之前也是做 java 的。现在的情况和您相识。谢谢您的建议。

@wangxinrubyer 站在老总的角度来看,你帮他赚到钱了,你就是优秀的;站在队友的角度看,你帮他们提高生活品质了,你就是好。

那要怎么赚钱?

业务、报价之类能够带来直接效益的工作可能不归你管,得先想想怎么省钱。以最少的人在最少的时间内做最好的东西,那就看看团队规模、工作效率、项目质量怎么调整。

团队规模

规模与项目大小有关,不能一概而论,总的来说人越少越好,沟通起来更高效。在人员配备上,要有梯次,高级 m 个,中级 n 个,刚毕业的也要有。人员的素质要多留意那些即会提问题又会帮着解决问题的人。

工作效率

要达到最快的速度把东西做好,你得充分了解队员的水平,难度最大的你自己扛了吧,次难的、简单的以梯次分配给相应的人员。还有些功能只需要做一次的,例如登录校验码、源码加密等,交给自己或者高级;更多的功能第一次做的时候花的时间会多一些,以后照着做就快了,例如第一个 crud 功能,第一张报表等等,这些也都交给自己或高级。 另外,任务分配下去后,要持续跟踪,跟踪方式可以通过要求写日志(很多人不喜欢,但我觉得对自己也是很有帮助的,关键在于队员的心理愿不愿意公开自己何时何刻在做什么。写的话推荐使用 teamcola),或者每天查看提交代码日志。 还有,一定要要求队员在遇到问题没有头绪解决的时候,先想办法处理,但是不能超过两个小时,一超过就不要自己独立解决了,上报,由你来处理,避免进度已经滞后,你问他,才知道出现棘手问题。 你还要告诉其他协作团队,现在你负责哪一块了,以后在这方面工作有需要的情况下,不要直接找你的队员,要以你为统一的对外接口,避免一些繁琐的事情打扰到队员正常的开发工作。

项目质量

先分为功能做得对不对,和做得好不好。 要避免需求与实际出来的软件不一致的情况,就要尽早的把东西做出来,先拿去用吧,而后的迭代的周期最好不要超过二周。 做得好不好,也就是缺陷多不多,你要紧盯缺陷列表,分析出为什么为出现这个 bug,哪些 bug 重复出现。但尽量不要针对出现 bug 的队员,而是整个团队总结,避免下次出现。人总会犯错的,关键是出错后的总结和改进。 为了保证较短的迭代周期,你还得紧盯自动化测试,以最大化减少测试人员的测试时间,让他们把关注点放在业务上。

要怎么提高队员的生活品质?

这个就不多说了。留意每个队员的追求不一样,有多年工作经验的和刚毕业的就有很大的不同,尽量满意他们这些需求。

最后,恭喜你开始新的尝试。以后的工作就不仅仅是 code 的,会有很多杂七杂八的繁琐的事情,保持良好的耐心吧。管理的工作不代表拥有更多的权力,而是更多的责任。

楼上说的太好了,喜欢

#12 楼 @saberma 的回答太棒了!做点补充性的工作:D

问题可以拆分成三个环节:价值创造、价值评估与价值分配。

价值创造:我们干出了什么干货?

也就是人力资源常说的,职责清晰,目标明确以及岗位匹配,等等,你随便挑一本管理的书,类似术语与方法论太多了。选一个自己相信的就行了,不要纠缠哪个方法论更好更坏。人的知识结构是有缘分与成长周期的。你相信的,执行下去,就比没有任何管理方法论强。

在这个环节,最需要注意的一些问题是,

团队内部知识的沉淀

比如,团队可以多在一起吹牛与闲聊,但是,牵涉到工作环节的流程,还是尽可能用邮件、wiki 等文字的形式沉淀下来。

这样,新手上路,会有较多的文献可以参考。

当团队成员有离职的时候,如果内部的邮件与知识管理系统沉淀很多,新手上手非常快。

帮老板省钱很重要

这点上,团队领导者的意识不如老板强烈,往往只看到薪酬支出,但是实际上,一个稳定的员工的支出,你必须用薪酬的 2-3 倍去计算。有的工作可以外包,有的可以通过开源库来解决,还有的工作可以通过让朋友或者社区成员帮忙解决。都是办法。

创作是更好地批判

省钱不是创造价值的办法,加班更不是创造价值的办法,而是如何避免浪费,产出高创意、成功率偏大的成品。这点上,领导者的职责很重,比如,尽可能加快自我学习的速度,当团队开发者在某个功能上耗费过长时间,可能就有问题了。很多时候,当创意产生偏差,可以用更换空间、时间的办法来解决,比如,不在办公室办公。不在白天办公。

价值评估:团队成员干的怎么样?

使用 github 来评估

这点上,对程序员来说,其实是很容易的。尽可能采纳 github。比如,我们所有商业项目都托管在 github 上。

然后进展一目了然。有空可以看看我之前那篇关于 github 的文章,里面提到了一个评估工具。

区分对待:新技能学习与出成果

对于刚开始项目启动,团队成员磨合不同,与团队老成员,要注意区分对待。

比如,在学习一种新的开发技能,例如 ios 开发,此时,更应注重学习的过程,第三方库的积累、标准流程的沉淀。

而在技能已经初步具备的情况之下,此时,更应注重速度与干货的诞生。就是,不要玩虚的,而是看什么时候及时交付。

拖延?

从我的多次经验来看,技术人员往往高估自己的能力,以及对需求的理解,基本上,拖延已经是定论了。

所以,一定要尽可能裁剪需求。当拖延发生之后,也予以一定的理解。但是,此时,不要让这种拖延影响到整个团队的士气,更不要让它形成一种心理惯性。将它的范围控制在能够承受的范围以内。

同时,开始思考如何避免拖延,制造惊奇。

价值分配:我们如何分配收益?

就是分钱了。当年在管理咨询公司一直干的是偏这块的:D

薪酬制度,简单来说,公平、公平、公平。

一个基本的做法是采取岗位薪酬制度 + 绩效奖金的做法。

奖金可以以时间为周期,也可以以项目为周期,更可以以节点为周期。

但是,多数小公司,包括我自己带的团队,资源很有限,往往是一直在投入,而暂时没有实际收益,此时如何处理?

沟通很重要。

沟通清楚,然后不瞎承诺,而是让大家了解相互项目的真实情况与实际收益以及可能的前景。并且提供力所能及的、朋友性质的帮助。

基于这些,团队成员会做出自己的判断。毕竟,不是人人喜欢大公司的流程与复杂的人际关系。

在这点上,我格外佩服我一个哥们,他 2003 年开始创业,做到今天,仍然不大,但是技术人员仍然是最初跟随他的那个。

当团队突然之间小发了一笔的时候,千万别只自己拿钱,而让大家拿不到钱:D

如果你必须将这些钱投入到团队下一步发展上,也必须沟通清楚,并予以阶段性的奖励,如果钱实在太紧,下一步发展很重要,此时,组织大家去玩一趟,很 happy:D

另外,还有一点特别重要,就是价值分配,不仅仅局限于钱。一些采访机会、演讲机会、培训机会,都很重要。这些是在帮助团队成员塑造个人品牌。

记住,技术团队领导者往往是一个一个利润中心,你承担的职责就是拿资源、快速迭代干出干货,然后分配资源。由于我所在行业的特点,需求点多,但是还是市场早期。因此,我甚至期盼,未来,我们的每个技术团队领导者成为一家独立的联盟公司的合伙人。

因此,我格外欣赏 rework 的信号公司与 ARA 这家全员持股的公司。

http://www.ara.com/Careers/working_at_ara.htm

#12 楼 @saberma 经验之谈,够精华!

感觉时精华贴。

很多观点值得参考,共勉

@saberma @ouyang 感谢 2 位分享 都值得细细品味 目前我遇到最大的瓶颈就是高层过分关注节约开支,以行业起伏为理由 拒绝为团队成员提高生活品质 说白了就是工资涨的少点 请问该以何种心态对待这样的问题哪?

#12 楼 @saberma 非常感谢您的回复!

精华贴,很多观点都在实践中印证

@wangxinrubyer 是 GZ 公司的?

我觉得最好的方法是 reflection——

我现在在带队,很多时候都是回想以前我的 TL 做的哪些事情我觉得是好的,或是不好的——从而纠正自己做事的方式和态度。

另外,我在 blog 上写过两篇有点关联的文章——

如何招募程序员:http://fredwu.me/post/16510145575/on-hiring-how-not-to-annoy-developers Agile 不只是个幌子:http://fredwu.me/post/20058808238/agile-is-not-a-sham

#26 楼 @wangxinrubyer 我会认真拜读的,谢谢。

我提个不同的看法:只要是产品方向正确,每个阶段的预期目标 (用户量等) 都能达到,不愁团队难带。 否则不管你怎么忽悠,人家该走还是走,该打酱油还是打酱油。

发钱的团队好带。靠兴趣而集结的团队难带,就像梁山 108 个好汉,都有点性格,有没有朋友有这方面的经验求分享?

需要 登录 后方可回复, 如果你还没有账号请 注册新账号