GitHub的產品設計

peku發表於2012-02-22
Github

無疑，當今軟體構造最困難的一方面當屬產品設計。與其比起來，技術、招聘、籌資、美學設計以及出版微不足道。當我在談論產品設計的時候，我是指這樣一種過程，在這一過程中你決定你的產品要做什麼和不做什麼。我有一次突然想到，我們在GitHub把產品設計做得非常好，不如讓你們對我們的產品設計流程稍作了解並且為解釋這個流程如此高效的原因提供一些啟發。

我得提醒你，我並不是一個“產品設計師”。在GitHub，我們不提供頭銜——我們讓員工自己挑選自己的頭銜。我喜歡稱自己為～設計師，因為我大部分工作是集中精力瞧瞧和體驗我們的產品。但話又說回來，我把過去一週的時間花在了構建一個可以追蹤和分發二進位制檔案以及更新我們的一些化簡函式以便可以支援更新版本的MongoDB的應用程式。所以，對，我是～設計師。不過也許這樣說我便可以承上啟下了。

人人都是產品設計師

在GitHub，人人都是產品設計師。為了把我們的產品做得更好，我們只僱用我們信任的聰明人。在這裡沒有產品經理指揮你的工作。開發新特性不需要通過行政上的簽署。行政人員、系統管理員、開發人員以及設計師都一樣參與構思、開發和移除產品特性。

讓“產品設計師”或者首席行政官在那裡嚷嚷他們將要“專注產品設計了”，對我來說這些沒有多大意義。難道你們不正是在聘用使用過你們產品的聰明人嗎？難道你們不相信你們的員工嗎？難道在你們公司工作的每一個人不想讓你們的產品變得更好？難道這沒有讓所有人在每時每刻都充當了產品設計師？

基於以上這些，我在面試時（或者對那些不知道他們正在面試的人）提的問題中，我最喜歡的兩個是：

  1. 你想在GitHub裡看到什麼？
  2. 你認為哪些特性被我們搞砸了或者應該移除掉？

這可以顯示出人們的激情以及立即凸顯你們有的問題。有些人就是對於你們的產品有跟你們不一樣的遠見，這又有什麼呢。

瘋狂地記下想法

我們的內部百科充滿了想法。舊想法。爛想法。好想法。半生不熟的想法。關鍵是我們有一個可以分享我們的奇思異想的聖堂。這一頁百科討論了比較檢視，其最後成為了Pull Request 2.0——可以說是我用過的最好的程式碼審查工具了。

大部分時候，有些人增加的想法並不是原創的。而是我們私底下討論過的，在其它產品看到過的，或者也許是對於我們自己的思考。但這無關緊要——看到其他人寫下了跟你一樣的想法會讓你對那個想法倍感興奮。隨著其他人也跟著說他們樂於看到那個特性，對這個特性的興奮感也會越來越強烈。最終，你們有4個工程師在晚上11點半的時候在搗鼓某樣東西，因為你們急切地想要看到它的實現。

持續試驗且重複

現在我們的主程式碼庫有65個分支。這還不包括其它十幾個合起來共同呈現什麼是https://github.com的程式碼庫或者139個在我們組織下面的程式碼庫。不用說，在這些分支裡有大量的特性、抗特性和半成熟想法。有時它們是真的很棒但不是功能化的特性，有時它們又是真的很醜但完全功能化的特性。

我們總是傳送拉請求（pull request），把它們搬上舞臺，詢問別人的看法。在會上談論某個特性和制定某個規範是一件事情，而編碼實現一個可以工作的原型是一種更有效率的方式。我們總是不停地在僅提供給員工使用的產品裡執行試驗性特性。沒有比真正地在使用某一特性這一方式能夠更好地檢驗這個特性是否真正適用。

一旦某個特性推出了，準備好讓使用者使用了，那麼會有100%的可能會有人想要改變此特性的某些方面。因此我們重複——修改、推廣，在拉請求裡討論——不斷重複直到好到可以給公眾使用。

這樣，我們的拉請求通常都是壯麗的史詩。事實顯示拉請求能夠完美地試驗新特性，同團隊討論這些特性，以及讓別人幫助你釋出它們。看看這條拉請求，我們用它來發布我們組織的資料。（有趣的軼事：這條拉請求是在我們釋出pull request 2.0之前就做出來了——我們持續不斷地使用試驗性特性）

摒棄特性

你不能夠運營某件產品然後假裝成你的所有想法都是完美的。你是會有爛想法，不適用的想法，以及該被丟掉的特性的。不要害怕摒棄想法。你花在某些東西上的是時間是毫無意義的。把作品丟掉並不會讓你損失任何東西——你是在選擇不讓你的產品變得更爛。

我們做的第一版的https://jobs.github.com根本沒有跟我們第一天釋出的東西共享哪怕一個功能。這次我們沒有重複——我們直接拋棄了這花了我們幾個月的作品，因為我們意識到它很爛。我們開始發揮我們的創造力並且意識到我們無法找到不必惹惱我們的使用者而能夠賺到錢的方法。所以我們拋棄了那個想法然後重新開始——即使我們本可以釋出它並且立即開始賺錢。

你釋出某些特性，因為你為它們花了時間和金錢，這是懦夫的藉口。摒棄特性要有種——長點吧。

時刻爭論

我們的工作環境並不安靜。我們有時在酒吧裡爭論，有時在篝火會上爭論，有時在電郵上爭論。不管是新僱員還是CEO們，都一樣。這不是針對個人的——這都是為了使我們的產品更好。如果你不是被迫而合理化你為產品做的選擇，那誰會說你正在做好的決策？

跟你的同事爭辯並不是什麼壞事情。這不是在創造一種消極的工作環境——而是幫助你做出好決策的工具。做一個無聊的拉拉隊長，對所有人歡呼他們的想法棒極了，這是有害的、短視的。爭辯然後做出好決策吧。

跟你的使用者談談

我花了一天裡好大一部分時間通讀我們的支援站點，郵件列表，twitter上的反饋，以及關於git和GitHub的博文。聆聽我們使用者的聲音極其重要——他們總是有很棒的想法。有時他們也有讓人震驚的極好的想法。比如Tom寫道的：

別給你的使用者他們要求的，給他們想要的。

我們也花了大量實實在在的時間跟我們的使用者在一起。我們在舊金山有每月一次的見面會，並且你可以很好地保證任何正在旅行的人會主持這種見面會，不管他們在哪座城市。線上的人會很瘋狂。當你面對面地跟某些人交談著的時候，你會很難形容那種瘋狂。這不得不讓人思考他們要說的且讓他們想到在產品背後有鮮活的人。

“情人眼裡出西施”

我們知道，產品設計不僅僅是增加和移除特性，它還是使用者怎樣感知這些特性。誰會在乎，如果某些分析師認為你的公司做得不錯而使用者不這麼認為？

弄篇好博文解釋一下新特性絕對是致命一擊。這允許我們框出新特性以及解釋我們的想法。這也可以展示出我們的釋出記錄——我們總是努力試圖釋出和向別人講述這些東西。

如果你像Twitter一樣兩年一次重新設計你的整個產品，那就是一件大事情了。如果你的使用者百分之百不喜歡它，你會讓他們發瘋的。但是如果你每兩個月釋出一些新東西，你的使用者不喜歡其中的10%——那他們總的百分比還是正面的。

同時，我們還知道我們不做的跟我們正在做的一樣重要。我們不釋出路線圖或者在時間表裡承諾新特性——我們少承諾多兌現。我真的覺得這就是為什麼總的來說我們的使用者會對我們的產品設計感到滿意。

別給你的使用者他們要求的，給他們想要的。少承諾，多兌現。

原文：Product design at GitHub

歡迎參加iTran樂譯4期！

相關文章