人员配备 第八章
不需过早招聘太多员工
慢慢加人迅速发展
初期后期都并不一定要壮大队伍。即使你接触过100个顶级人才，一口气把他们全招来也并不是什么好主意。没有办法能让这么多人迅速的融入到统一的企业文化中去。你将遭遇令人头痛的人员培训、性格不和、沟通不畅、发展方向不同等诸多麻烦。
所以不要随便招人。真的。不要招人，另想办法。让你陷入烦恼的这件事是真正必要的吗？你不做又会如何呢？能不能用某种软件或者改变做事方法来解决呢？
ge前执行总裁Jack Welch每次裁掉一个人之后并不会马上招人来顶替他的位置。他想看看在那个职位和人员空缺的情况下能支撑多久。我们当然不主张用裁人来验证这个理论，但是我们的确认为Jack的做法有一定道理：你并不需要你考虑中的那么多人手。
如果没别的办法再考虑招人。但是你应该清楚知道你需要什么样的人，怎么向他介绍工作任务，以及具体要他负责解决什么样的棘手问题。
Brooks的原则
给延期的软件开发项目添加人手只会更加拖延进度。
—Fred Brooks
编程与莫扎特的安魂曲
一个优秀的程序员在完成单个工作任务时不存在因沟通和分工而产生的额外开销。而五个程序员坐到一起完成同一个任务的时候必须分工合作，那将花费很多 时间……用很多一般的程序员而不是几个足够好的程序员将产生的真正问题在于：无论让他们干上多久，也绝对没有优秀程序员干得出色。五个Antonio Salieris也永远写不出莫扎特的安魂曲，哪怕给他们100年的时间。
—Joel Spolsky, Fog Creek Software的软件开发人员 (摘自Hitting the High Notes)
摸底
先和候选员工在测试项目中协作
看作品、简历、例程、工作经历是一码事，和他在一起工作是另外一码事。只要有条件，应该和准团队成员一起去“试试车”。
在聘用人之前，我们会给他们一个小项目琢磨琢磨。我们能从中看出他们怎么管理这个项目，他们怎样进行沟通，他们具体怎么做等等。和他们一起设计或者编写几屏代码能看出很多东西。你能迅速摸清和他们是否心有灵犀。
这种事规划起来比较难，但即使只能拿出20或者40小时来做也比没有强。适合不适合都能看得很清楚。如果不适合，先摸清情况能给双方避免很多麻烦和风险。
小处着手
从分派一个小的测试任务开始。不要一股脑把你的工作任务都拿出来。给你的新虚拟助理一两个测试项目来做，看看化学作用如何发生。开始的时候，大家很容易在和和气气的氛围中忽略掉潜在的问题。记住这只是在试车。
—Suzanne Falter-Barns, 作家和创意专家
(摘自How To Find And Keep The Perfect VA)
行胜于言
根据对开源社区的贡献选择潜在的技术人才
典型的通过学历、简历等方式来招聘技术人员在很多方面都是很愚蠢的。应聘者毕业于什么学校、学习成绩如何真的那么重要吗？一份简历或介绍信真能信得过吗？
开源社区是为那些需要招聘技术人员的人准备的礼物。通过开源社区，你可以在很长的时间跨度里跟踪某人的成果和贡献，无论好坏。
这意味着你能以他做过什么而不是说过什么来判断他是否合适。你可以通过考察真正重要的方面来做决定：
- 工作质量
很多程序员说的时候口若悬河，实际去做的时候却错漏百出。通过开源社区，你可以直观的了解这个人的编程技巧和素养。 - 文化视角
编程就是做判断。很多很多的判断。判断力遵循于这个人的文化水平、价值观和观念。考察候选人在编码、测试和社区讨论（争吵）中作出的具体决定，看看他在文化上是否和你有共同点。如果没有共同点，每个决定都将引发一场争论。 - 热情程度
根据定义，参与到开源项目至少是需要一些热情的。不然为什么他要在屏幕前浪费业余时间？对开源项目的投入程度就能看出候选人对编程的热衷程度。 - 执行力
如果完不成任务，再聪明的头脑、再合适的文化倾向和再高的热情也带不来有价值的软件。不幸的是，很多程序员都做不到这点。应该去找那些热忱工作的人。要做比买卖的时候，需要有这样的人——这个人要把货带出门，而且他也愿意去做。 - 社会经验
和人一起共事很长时间，一起经历过紧张和悠闲，一起经历过起起落落，才能看出他们的真实性格。如果他缺乏教养，没有社交技巧，把他排除掉。
说到程序员，我们只聘用通过开源社区认识的人。我们认为其他任何方式都是不负责任的。我们聘用Jamis是因为我们关注过他在Ruby社区的参与程度和发布成果。他在前文所述的各个方面都做得很好。不需要次要原因，我们只评判真正重要的——他的工作质量。
不用担心团队成员“课外活动”的活跃度带走他们的注意力和工作热情。有句老话是这么讲的：如果你想做好一件事，去找你所认识的最忙的人。Jamis 和David两个都是对Rails 社区有重大贡献的人，同时，他俩还驾驭着37signals的技术部门。热爱编程并且能干活的人就是你真正需要的团队成员。
对开源社区的热情
你最希望从新员工身上看到的就是他对自己工作任务的热情，而最能看出这点的办法就是在开源项目中去追溯他的提交记录。
—Jarkko Laine, 软件开发人员
(from Reduce the risk, hire from open source)
寻找全面发展的人
选择能快速学习的多面手，而不是专攻一面的专家。
我们从来不会用一个信息架构师。那实在太狭隘了。对于我们这样的小团队，招技术层面那么窄的人没用。
小团队需要能扮演不同角色的人。你需要会编程的设计师。你需要懂设计的程序员。每个人都应该对怎么构建信息（无论它指的是什么）有自己的想法。每个人都应该思路清晰。每个人都需要能和客户打交道。
而且每个人都需要能”在路上换档“。要记住小团队经常需要迅速改变前进方向。你需要有人能持续的调整和学习，而不是固步自封，只会干一件事。
热情是装不出来的
选择快乐的和技术水平中等的，而不是令人不满的专家
热情，是无法伪装的。招人的时候，不要认为你需要一个技术大师或者技术名流。他们往往自以为是。一个水平说得过去的快乐员工胜过于愁眉苦脸的专家。
寻找充满热情的人；寻找你信任他可以独立完成任务的人；寻找在发展缓慢的大公司受过折磨，并且渴望新环境的人；寻找为一起去建造你正在建造的东西而感到激动的人；寻找对你所厌恶的事物同样感到厌恶的人；寻找为入你的伙而感到兴奋不已的人。
为提问加分
留意候选人是否对你的项目提出很多疑问。热心的程序员总是想尽量去理解存在很多疑点的问题并快速提出可能的解决办法和改进方案。阐明问题能产生一种 认识：项目的做法很多，但基本上取决于你对你的Web应用如何运作的想象。当你深入到细节，你能感觉到这个人是否在文化水平上符合。
—Eric Stephens, BuildV1.com
炼字师
招文字功底好的人
如果你在琢磨从几个人选中挑出哪一个来填补空缺，选文字功底好的那位。无论他是设计师、程序员、市场人员、销售人员还是其他，写作技巧都很有用。简洁高效的写作和文字编辑能力可以带来简洁高效的代码、设计、邮件、即时信息以及更多。
这是因为要当好写手并不只是堆砌词藻。好写手懂得沟通的技巧，他们让事情易于理解，他们能站在别人的立场考虑问题，他们知道什么是可以忽略的，他们思路清晰。而这正是你需要的才能。
条理清晰的头脑
好的写作风格是头脑清晰的指示器，清晰的头脑能有条絮地梳理信息和论点，还能帮助（而不是逼着）其他人去理解。这种技巧能渗透到代码的编写、口头表达、即时通信（对于那些远程协作的人来说），甚至更深层次的职业素养和可靠性等领域。
—Dustin J. Mitchell, 开发人员 (摘自Signal vs. Noise)
有清晰的文字才有清晰的思路
清晰的文字能带来清晰的思路。表达它的时候你才知道你对它了解些什么。好的写作风格也从一定程度上反映出人的性格。让读者省事，而不是给自己省事。
—Michael A. Covington, 佐治亚州立大学计算机科学教授
(摘自How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily
