Reddit联合创始人教你避免软件开发中的错误

　　关于作者：Reddit联合创始人Aaron Swartz今年年仅26岁，是一位知名工程师、作家。14岁参与RSS1.0规范定制，并因此成为W3C RDF核心工作小组成员。参与了Markdown、Infogami、Demandprogress、Reddit等公司、组织的创办，早在2000年就开发了“theinfo”百科全书(知名百科全书Wikipedia创办于2001年)，同时他还热衷参加众多其它社会活动。和很多其他优秀程序员一样，Aaron也受过牢狱之灾(因下载大量论文被捕)。

　　需求很重要

　　好的产品源于需求。虽然潜在用户很重要，但迫切的需求对于产品来说更重要。用户急于填补这方面的需求，所以在他们发现你的产品时就会迅速使用你的产品。如果你是为了一个人的需求做产品，那你至少会有一个忠实用户，但如果你想以60亿用户为目标，很有可能会最终一无所获。但通常是你满足了一个人的需求时也会同时满足很多有类似需求的人，或者只需要做简单的改变。

　　最重要的是你自己有这样的需求，对这个需求深有体会。如果你没有这样的需求，退而求其次，你可以自己去尝试以一种能激发这种需求的方式生活，虽然和真正需求不完全一样，但至少和有此需求的人能有所共鸣。

　　有时候你也许需要将你的需求增加一些特性，因为人们也会对自己可能的需求感兴趣。要确保你的需求是否是真正的需求，所以你至少要找到一个跟你有同样强烈感觉的陌生人。

　　光有需求还不够

　　光有需求肯定不够，你还需要一个好的想法来满足需求。认真地看看你的想法，它真得能满足需求吗?要记住，很多想法很糟糕是因为他们没能察觉到这是一个不满足需求的想法。你应该从需求导出解决方法，而不是反过来为了实现自己的想法胡诌一个需求。

　　不是说一个想法一定不能解决多个需求，但好的想法的评判标准在与是否能完美地解决需求。

　　但是不要着急想这该如何实现，如果你真的是一个能给出富有创造力的想法的人，你肯定会在接下来的世界里不断地冒出稀奇古怪的新特色、附加功能和用途。但这些都不重要，除非你现在就实现它们，否则它们只会让你分心。所以请先将它存在“列宁文档”(“列宁文档”是指包括从核心功能到更抽象的特色想法中的多数派版本maximalist version)里。

　　也许你再也不会看这个文档，但除非你把这些想法记下了，否则它们会不停地骚扰拟合你的同事。

　　如何招聘正确的人?

　　说到同事，你毫无疑问需要一个团队来解决一个问题。在寻找同事的时候，你首先需要确保三个条件：

　　1、他们足够聪明吗?

　　2、他们能把事情做好吗?

　　3、他们能和你一起工作吗?

　　即使能够招到满足这三个问题中两项的人可能也会让你心满意足!但这实际上是大错误：足够聪明但是完成不了任务的人没法当你的雇员，即使不去聘请他们，你也可以把他们当做朋友一起讨论问题;能完成任务但是不够聪明的人做起事来很低效，他们能完成任务，但是总是在走弯路，聪明的人会对此难以接受，于是会挤出时间来帮他;但无法和你一起工作的人肯定是不要与之共事的!也许你会想：“这只是工作，反正我也不必和他成为朋友。”但实际上和无法交流的人一起工作是非常痛苦的，你们无法互相纠错也无法互相帮助。

　　传统的招聘流程包括：

　　1、阅读简历;

　　2、问一些难题;

　　3、给他们一个真正的编程题。

　　我认为这是一个糟糕的聘用系统，能从简历中看到的东西太少了，而在采访中提难题很容易是人紧张，在压力下很难完成编程。在这样非常正常状态下的工作是没法反映一个人真实水平的。用问题决定面试结果是残酷的，那些出题的面试官也不一定能在第一次看到这个题目的时候就想到解决方案。

　　相反，问他们三个问题。找出他们能完成所有任务，问他能做什么?如果有人真的能完成所有的工作，那他可以现在就开始。如果有人擅长完成任务，他不会逃避。好的程序员不会缺少经验，因为现在任何人都可以在自由软件项目中得到实战经验。所以只要让他做一个Demo就知道他的水平如何了。代码是否简洁?是否清楚?是否优雅?是否可用?是不知你正在寻找的东西?

　　要想知道一个人是否聪明只需要和他随意交谈。尽可能地降低压力：在咖啡厅见面，让他明白这不是面试，尽可能地休闲和友好，就像一次朋友之间的聊天。这样可以很容易地判断这个人是否足够聪明，就像我们一直在判断某个人是否有吸引力一样。

　　最后，确定你们是否合适一起工作。有的人很聪明，但是他的一些小怪癖让人难以接受。所以在聊天后，你可以邀请他一起吃饭或者和同事们一起在办公室打游戏，这很容易看出一个人是否对你的口味。

　　在正式雇佣之前，你还需要再确认一遍自己有没有被欺骗。你可以调挑选项目里的一些独立组件让他实现。

　　当然，也许你会问“为什么不先试用他一个月呢?”这根本不起作用!你会让他不断地去证明自己，这是非常残酷的，而且往往会适得其反。而且在试用结束后，即使他并不合适，你也不一定下得了口辞去他而影响接下来的工作。

　　现在开始假设

　　你现在已经有了自己的团队，该是做实事的时候了。是时候开始你的远大梦想了，你肯定不希望多做无用功，所以最好去找到一条最简洁的实现方案。所以你首先提出几个假设，假设很重要，因为每一个解决方法都来自假设，如果这些假设不成立，那么解决方法肯定也是不会成功的。

　　写下这些假设，并且挑出最重要的。这点非常重要，如果这个假设是错误的，那么我们所有的工作都将付诸流水。所以我们需要做一些实验来证明这是真实可靠的。

　　因为针对不同的猜想，实验代码会需要不停地改动，所以在此加入一些控制器是不错的选择。

　　团队和任务

　　一旦你确认假设是正确的以及最简洁的解决方法和一套明确的评价标准，开始建设的时候就真正到来了。你首先需要挑选一个可靠的产品拥有者，这是你的产品的“乔布斯”，他们有权决定产品的每个细节来确保产品的一致。

　　你还需要制作一张卡片来描述你的的建议以及你的评价标准，简单地建立一个任务管理系统。根据重要度将一堆任务卡片排序，当你的设计师在完成一项任务的时候就从最上面抽走一张卡片，然后由拥有者决定详细的设计(按钮放在哪儿?它究竟写着什么?)。但产品拥有者决定了具体的设计后就可以开始把任务交付给程序员了，并与他们共同实现实验。

原文转自：http://www.ltesting.net