其他 怎样带领好一个 Rails 团队？
因为一些变故，鄙人需要扛下一根大梁。----组建一个 ror 开发小团队。鄙人不才，没有带过人的经历，既然抗下来了，也不愿辜负老总的期望。故在此虚心向各位带过人的老前辈请教，希望您们能传授点经验。鄙人在这里将感激不尽！！！
为了能思路清醒，我就把问题列出：
- 怎样才能成为一位优秀的项目管理者？
- 怎样才能带领好一个团队？
PS:
- 自己是新手，所以问题的问题可能会有些抽象宽泛，因为抽象宽泛所以才希望能得到您的指引。
- 希望是您个人的经验之谈。
问题好大，拆一下吧，比如
- 如何设定团队目标和愿景
- 如何招聘到好得员工
- 如何跟同事相处
- 如何制作项目计划
- 如何保证按时交付
- 如何激励团队成员
- 如何让员工有归属感
- 如何在工作中提升个人能力以及修养
- ......
没有非常具体的方法，只能靠自己能力的提高，当然，看一些项目管理，职业经理人方面的书籍也是很有必要的，最好公司有培训；管理人比管理事情要复杂的多，保持足够好的沟通是做好管理的一个必要条件。
@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 这家全员持股的公司。
我觉得最好的方法是 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
我提个不同的看法：只要是产品方向正确，每个阶段的预期目标 (用户量等) 都能达到，不愁团队难带。 否则不管你怎么忽悠，人家该走还是走，该打酱油还是打酱油。
