关于作者：Reddit联合创始人Aaron Swartz今年年仅26岁，是一位知名工程师、作家。14岁参与RSS1.0规范定制，并因此成为W3C RDF核心工作小组成员。参与了Markdown、Infogami、Demandprogress、Reddit等公司、组织的创办，早在2000年就开发了“theinfo”百科全书（知名百科全书Wikipedia创办于2001年），同时他还热衷参加众多其它社会活动。
需求很重要
好的产品源于需求。虽然潜在用户很重要，但迫切的需求对于产品来说更重要。用户急于填补这方面的需求，所以在他们发现你的产品时就会迅速使用你的产品。如果你是为了一个人的需求做产品，那你至少会有一个忠实用户，但如果你想以60亿用户为目标，很有可能会最终一无所获。但通常是你满足了一个人的需求时也会同时满足很多有类似需求的人，或者只需要做简单的改变。
最重要的是你自己有这样的需求，对这个需求深有体会。如果你没有这样的需求，退而求其次，你可以自己去尝试以一种能激发这种需求的方式生活，虽然和真正需求不完全一样，但至少和有此需求的人能有所共鸣。
有时候你也许需要将你的需求增加一些特性，因为人们也会对自己可能的需求感兴趣。要确保你的需求是否是真正的需求，所以你至少要找到一个跟你有同样强烈感觉的陌生人。
光有需求还不够
光有需求肯定不够，你还需要一个好的想法来满足需求。认真地看看你的想法，它真得能满足需求吗？要记住，很多想法很糟糕是因为他们没能察觉到这是一个不满足需求的想法。你应该从需求导出解决方法，而不是反过来为了实现自己的想法胡诌一个需求。
不是说一个想法一定不能解决多个需求，但好的想法的评判标准在与是否能完美地解决需求。
但是不要着急想这该如何实现，如果你真的是一个能给出富有创造力的想法的人，你肯定会在接下来的世界里不断地冒出稀奇古怪的新特色、附加功能和用途。但这些都不重要，除非你现在就实现它们，否则它们只会让你分心。所以请先将它存在“列宁文档”（“列宁文档”是指包括从核心功能到更抽象的特色想法中的多数派版本maximalist version）里。
也许你再也不会看这个文档，但除非你把这些想法记下了，否则它们会不停地骚扰拟合你的同事。
如何招聘正确的人？
说到同事，你毫无疑问需要一个团队来解决一个问题。在寻找同事的时候，你首先需要确保三个条件：
即使能够招到满足这三个问题中两项的人可能也会让你心满意足！但这实际上是大错误：足够聪明但是完成不了任务的人没法当你的雇员，即使不去聘请他们，你也可以把他们当做朋友一起讨论问题；能完成任务但是不够聪明的人做起事来很低效，他们能完成任务，但是总是在走弯路，聪明的人会对此难以接受，于是会挤出时间来帮他；但无法和你一起工作的人肯定是不要与之共事的！也许你会想：“这只是工作，反正我也不必和他成为朋友。”但实际上和无法交流的人一起工作是非常痛苦的，你们无法互相纠错也无法互相帮助。
传统的招聘流程包括：
我认为这是一个糟糕的聘用系统，能从简历中看到的东西太少了，而在采访中提难题很容易是人紧张，在压力下很难完成编程。在这样非常正常状态下的工作是没法反映一个人真实水平的。用问题决定面试结果是残酷的，那些出题的面试官也不一定能在第一次看到这个题目的时候就想到解决方案。
相反，问他们三个问题。找出他们能完成所有任务，问他能做什么？如果有人真的能完成所有的工作，那他可以现在就开始。如果有人擅长完成任务，他不会逃避。好的程序员不会缺少经验，因为现在任何人都可以在自由软件项目中得到实战经验。所以只要让他做一个Demo就知道他的水平如何了。代码是否简洁？是否清楚？是否优雅？是否可用？是不知你正在寻找的东西？
要想知道一个人是否聪明只需要和他随意交谈。尽可能地降低压力：在咖啡厅见面，让他明白这不是面试，尽可能地休闲和友好，就像一次朋友之间的聊天。这样可以很容易地判断这个人是否足够聪明，就像我们一直在判断某个人是否有吸引力一样。
最后，确定你们是否合适一起工作。有的人很聪明，但是他的一些小怪癖让人难以接受。所以在聊天后，你可以邀请他一起吃饭或者和同事们一起在办公室打游戏，这很容易看出一个人是否对你的口味。
在正式雇佣之前，你还需要再确认一遍自己有没有被欺骗。你可以调挑选项目里的一些独立组件让他实现。
当然，也许你会问“为什么不先试用他一个月呢？”这根本不起作用！你会让他不断地去证明自己，这是非常残酷的，而且往往会适得其反。而且在试用结束后，即使他并不合适，你也不一定下得了口辞去他而影响接下来的工作。
现在开始假设
你现在已经有了自己的团队，该是做实事的时候了。是时候开始你的远大梦想了，你肯定不希望多做无用功，所以最好去找到一条最简洁的实现方案。所以你首先提出几个假设，假设很重要，因为每一个解决方法都来自假设，如果这些假设不成立，那么解决方法肯定也是不会成功的。
写下这些假设，并且挑出最重要的。这点非常重要，如果这个假设是错误的，那么我们所有的工作都将付诸流水。所以我们需要做一些实验来证明这是真实可靠的。
因为针对不同的猜想，实验代码会需要不停地改动，所以在此加入一些控制器是不错的选择。
团队和任务
一旦你确认假设是正确的以及最简洁的解决方法和一套明确的评价标准，开始建设的时候就真正到来了。你首先需要挑选一个可靠的产品拥有者，这是你的产品的“乔布斯”，他们有权决定产品的每个细节来确保产品的一致。
你还需要制作一张卡片来描述你的的建议以及你的评价标准，简单地建立一个任务管理系统。根据重要度将一堆任务卡片排序，当你的设计师在完成一项任务的时候就从最上面抽走一张卡片，然后由拥有者决定详细的设计（按钮放在哪儿？它究竟写着什么？）。但产品拥有者决定了具体的设计后就可以开始把任务交付给程序员了，并与他们共同实现实验。
实现过程中免不了会遇到一些实际问题，可能会需要多次修改设计，这时候还需要产品拥有者重新进行校订。
开发与测试
在开发中使用自动化测试是件好事，这样就能很容易地发现是否有错误发生。你觉得已经完成时也可以使用自动化测试来确保完全通过。当然，你需要确保自动化测试覆盖了所有控制和功能。
编程是一件很费心力的工作，所以程序员结对编程往往能更高效——一个输入，另一个观察并评论。（有时候 一个人写测试，另一个写代码来保证测试通过很有趣。）
当然你并不需要一直两个人一起编程，但你得保证有人来评估你的更改。你需要在提交代码之前审阅差异变化。
如果你正在开发网络服务（比如Web应用），你应该把它当做十二因子应用（Twelve-Factor Application）来设计。
十二因子应用的十二条原则如下：
部署要注意些什么
开发者应该在代码经过测试后提交到版本库中。如果代码会改变支持服务，这应该通过迁移来实现。迁移会描述如何制造或者回滚这样的改变。当新版本的软件部署后，所有没在运行的迁移开始运行，并同步这个版本的支持服务到它所依赖的代码里。回滚使得迁移也回滚，这保证支持服务和代码始终同步。
几乎所有的代码都提交到开发主线。这避免了不同分支痛苦的合并过程。因为所有大的变化都应该当做实验，如果变化未完成或者未准备好，可以通过禁止大部分用户来关闭它。当代码已经完善，更多的人就可以进入到这个实验群体里，开关也就因此可以永久地移除了。
确保每一块添加进产品里的代码都经过了产品拥有者的检查，他们需要控制产品发布。对实验的评估可以先从项目拥有者开始渐渐增加用户，直到所有的用户满意为止，此时才可以将实验中的控制器代码移除。
怎样发布更合适？
有人会建议你使用好莱坞式的试行，提前几个月公布发布日期并大肆炒作。这也许很适合好莱坞，但它并不适合软件发布，因为你的产品不会在剧院，而是在网上发布！你不用担心一周后剧院就不为你宣传了，只要在网上，你可以一直做推广，慢慢积累你的用户群。
除非你是个难得的天才，否则软件在推出当天肯定还是会遗留很多之前没有注意到的bug和概念错误，而现在数以百万计的用户会使用你的产品并遇到错误。
相反，你应该把发布当做是另一个实验，随着产品的进一步完善慢慢增加用户数量，GMail就是一个不错的案例。