英文原文：pokayokeguide.com，翻譯：王然@CSDN
關於作者：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就知道他的水平如何了。程式碼是否簡潔？是否清楚？是否優雅？是否可用？是不知你正在尋找的東西？
要想知道一個人是否聰明只需要和他隨意交談。儘可能地降低壓力：在咖啡廳見面，讓他明白這不是面試，儘可能地休閒和友好，就像一次朋友之間的聊天。這樣可以很容易地判斷這個人是否足夠聰明，就像我們一直在判斷某個人是否有吸引力一樣。
最後，確定你們是否合適一起工作。有的人很聰明，但是他的一些小怪癖讓人難以接受。所以在聊天后，你可以邀請他一起吃飯或者和同事們一起在辦公室打遊戲，這很容易看出一個人是否對你的口味。
在正式僱傭之前，你還需要再確認一遍自己有沒有被欺騙。你可以調挑選專案裡的一些獨立元件讓他實現。
當然，也許你會問“為什麼不先試用他一個月呢？”這根本不起作用！你會讓他不斷地去證明自己，這是非常殘酷的，而且往往會適得其反。而且在試用結束後，即使他並不合適，你也不一定下得了口辭去他而影響接下來的工作。
現在開始假設
你現在已經有了自己的團隊，該是做實事的時候了。是時候開始你的遠大夢想了，你肯定不希望多做無用功，所以最好去找到一條最簡潔的實現方案。所以你首先提出幾個假設，假設很重要，因為每一個解決方法都來自假設，如果這些假設不成立，那麼解決方法肯定也是不會成功的。
寫下這些假設，並且挑出最重要的。這點非常重要，如果這個假設是錯誤的，那麼我們所有的工作都將付諸流水。所以我們需要做一些實驗來證明這是真實可靠的。
因為針對不同的猜想，實驗程式碼會需要不停地改動，所以在此加入一些控制器是不錯的選擇。
團隊和任務
一旦你確認假設是正確的以及最簡潔的解決方法和一套明確的評價標準，開始建設的時候就真正到來了。你首先需要挑選一個可靠的產品擁有者，這是你的產品的“賈伯斯”，他們有權決定產品的每個細節來確保產品的一致。
你還需要製作一張卡片來描述你的的建議以及你的評價標準，簡單地建立一個任務管理系統。根據重要度將一堆任務卡片排序，當你的設計師在完成一項任務的時候就從最上面抽走一張卡片，然後由擁有者決定詳細的設計（按鈕放在哪兒？它究竟寫著什麼？）。但產品擁有者決定了具體的設計後就可以開始把任務交付給程式設計師了，並與他們共同實現實驗。
實現過程中免不了會遇到一些實際問題，可能會需要多次修改設計，這時候還需要產品擁有者重新進行校訂。
開發與測試
在開發中使用自動化測試是件好事，這樣就能很容易地發現是否有錯誤發生。你覺得已經完成時也可以使用自動化測試來確保完全通過。當然，你需要確保自動化測試覆蓋了所有控制和功能。
程式設計是一件很費心力的工作，所以程式設計師結對程式設計往往能更高效——一個輸入，另一個觀察並評論。（有時候 一個人寫測試，另一個寫程式碼來保證測試通過很有趣。）
當然你並不需要一直兩個人一起程式設計，但你得保證有人來評估你的更改。你需要在提交程式碼之前審閱差異變化。
體系結構
如果你正在開發網路服務（比如Web應用），你應該把它當做十二因子應用（Twelve-Factor Application）來設計。
十二因子應用的十二條原則如下：
1、整個應用的程式碼儲存在一個版本的控制庫裡。如果你為軟體的不同部分準備了多個版本庫，你應該把他們當做是不同的應用，而他們之間互為服務。如果你將多個應用加入了同一個程式碼庫，你需要找出它們共同的依賴庫，並將它們分到兩個程式碼庫裡。
2、明確宣告依賴。在Ruby裡你可以使用Gemfile，在Python裡是requirements.txt，等等。本地你可以使用bundler和viirtualenv這樣的工具來隔離環境來保證沒有使用任何未宣告的依賴。
3、所有配置值都應該當做環境變數儲存。這裡包括所有不適宜公開的東西：密碼、金鑰以及其它在部署間各不相同的東西包括資料庫地址以及管理員賬戶等等。
4、所有支援服務（如資料庫和記憶體裡的快取）都視為服務。對於本地和第三方服務沒有任何區別：他們都通過網路訪問。
5、程式碼分三個獨立步驟部署：編譯、釋出和執行。
6、應用應該當做一系列無狀態程式執行，所有程式都可以在任時候關閉。
7、應用應該是完全獨立的，通過IP埠和外界通訊，而不應該存在於某些大型程式裡。
8、應用應該有很多程式型別組成，並且可以擴充套件更多程式型別。
9、程式應該是可任意使用的，你可以在任何時候啟動或停止它，而不用擔心任何破壞。
10、開發和產品間的隔閡應該儘可能地的小——相同的支援服務、依賴、團隊應該在兩處都被使用。
11、日誌應該是無緩衝的和標準輸出的事件流。
12、管理任務應該當做是一次性的程式。
部署要注意些什麼
開發者應該在程式碼經過測試後提交到版本庫中。如果程式碼會改變支援服務，這應該通過遷移來實現。遷移會描述如何製造或者回滾這樣的改變。當新版本的軟體部署後，所有沒在執行的遷移開始執行，並同步這個版本的支援服務到它所依賴的程式碼裡。回滾使得遷移也回滾，這保證支援服務和程式碼始終同步。
幾乎所有的程式碼都提交到開發主線。這避免了不同分支痛苦的合併過程。因為所有大的變化都應該當做實驗，如果變化未完成或者未準備好，可以通過禁止大部分使用者來關閉它。當程式碼已經完善，更多的人就可以進入到這個實驗群體裡，開關也就因此可以永久地移除了。
確保每一塊新增進產品裡的程式碼都經過了產品擁有者的檢查，他們需要控制產品釋出。對實驗的評估可以先從專案擁有者開始漸漸增加使用者，直到所有的使用者滿意為止，此時才可以將實驗中的控制器程式碼移除。
怎樣釋出更合適？
有人會建議你使用好萊塢式的試行，提前幾個月公佈釋出日期並大肆炒作。這也許很適合好萊塢，但它並不適合軟體釋出，因為你的產品不會在劇院，而是在網上釋出！你不用擔心一週後劇院就不為你宣傳了，只要在網上，你可以一直做推廣，慢慢積累你的使用者群。
除非你是個難得的天才，否則軟體在推出當天肯定還是會遺留很多之前沒有注意到的bug和概念錯誤，而現在數以百萬計的使用者會使用你的產品並遇到錯誤。
相反，你應該把釋出當做是另一個實驗，隨著產品的進一步完善慢慢增加使用者數量，GMail就是一個不錯的案例。