編者按：Basecamp的產品哲學是小而美。這種哲學不僅體現在他們的產品上，也體現在他們的管理上。鑒于經常有人問自己公司是如何決定做什么以及如何決定怎么做的，CEO Jason Fried決定寫一篇文章專門來談這個：項目以6周為限，團隊臨時組建，最大規模不超過3人，每次周期都可以靈活組合，不設專門項目經理，不跟蹤時間進度……跟典型的公司組織和項目管理方式相比稱得上是小清新了，也許初創企業可以好好借鑒一下他們的做法。當然，這種做法本身也需要與時俱進，Jason Fried說得很好：把公司當作產品來對待，你就會時刻考慮對它進行更新換代。
我經常會收到這樣的問題：“你們這幫家伙是怎么工作的？你們是怎么選擇做什么的？你的團隊有多大？你的工作是怎么組織的？”我已經在一些小型研討會或者一對一面談時講過這方面的細節了，但是全面闡述需要專門騰出時間來寫一篇文章。
經過10年的優化之后，我們開始著手這件事情。就像我們的產品迭代一樣，我們公司的運作方式也在不斷更新。我們把自己的公司也看成是一個產品。當你開始把公司視為產品時，你就會開始以全新的方式對它加以改進。我感覺“我們是怎么工作的？”這個產品我們現在正處在的5.2版（注：這樣的話大概每2年就換一版）。
我們是怎么工作的呢？下面就來看看：
以6周為一個周期
我們大概每6周就開始新的產品工作周期。這個周期包括有兩種類型的項目：
-
大項目（Big Batch）：大項目是規模較大的功能或者東西，可能需要整整6周來完成。6周的周期里面我們一般要做1、2個大項目。
-
小項目（Small Batch）：小項目做的東西規模較小，往往是調優、小調整，添加容易，應該1天到2周之內就可以完成。在一個周期里面我們一般要做4到8個小項目。
為了讓大家感受一下什么樣的項目是大項目和小項目，這里有一個我們內部項目周期發布的具體例子。
一旦6周的周期結束，我們都要用1、2周的時間修補一下東西，或者選個自己想做的寵物項目做一做，然后在開始下一個周期之前修整一下。給環境切換留出充分的時間。我們還會利用這段時間梳理下一個周期要處理的問題。主要是這些事情。
注意，這不是sprints（沖刺）。說實話我很鄙視這個詞。Sprint和工作走不到一起。這不是要你有多快跑多快，而是要你冷靜工作，保持節奏，然后在這個過程中做出明智決策。不要搞暴力破解，不要到頭來讓所有人都累得夠嗆。
6周……如果做的東西太大6周的時間不夠用怎么辦？
我們相信幾乎所有事情6周的時間都可以出一個版本了。當然，偶爾也會有少量事情會突破這一限制——比如深度的研發項目，我們此前沒有碰到過的全新技術等。但我們已經發現幾乎所有重要的事情都可以在6周或者更少的時間內完成。而且可以做得很好。
這件事情可能做成的秘密是我們所謂的范圍錘煉（scope hammering）。面對手上的一大塊大理石，我們要考慮如何進行雕刻，用鑿子把不必要的東西鑿掉，盡可能做出最好的6周版本。一切都與仔細審視功能，找出真正的精髓有關。不是它可以變成什么樣，而是應該變成什么樣。
在把任何項目納入產品周期之前，我們已經搞清楚了這個6周時間做出的版本應該是什么樣的。規劃并不在這個周期的時間范圍內——所有的規劃和考慮都是在pitch階段進行的。也是在一支團隊準備要開干之前完成的。這樣的話這整整6周的時間都是用來實施和執行。沒有一分鐘是花在巨大的不確定性上面——我們試圖確保在開始之前所有的大東西都已經了解透徹了。
誰來干？
每一個大項目都要分配一個團隊來完成。所以如果某個周期我們有兩個大項目要進行的話我們會讓一個團隊負責其中一個項目，然后讓另外一支團隊負責另一個項目。小項目全部都是由一個團隊來完成。在整個周期內所有團隊都是一起工作的。
視工作類型不同，一支團隊由2、3個人組成。要么是一個程序員加上一個設計師，要么是2位程序員跟1位設計師搭配。就這樣。沒有4、5、6人組成的團隊。我們要做的所有事情必須由最多3人組成的團隊來完成。
我們認為3這個數對于大多數事情來說都是最理想的——超過這數字會導致復雜性的指數增長。
而團隊都是臨時組建的。在一個周期開始之前，我們會詢問每一個人未來6周他們喜歡干什么樣的工作。團隊要么是圍繞著興趣領域組建，要么根據他們的優先選擇來分配人。在一個周期結束之后團隊往往就會調整，這樣每個人都有機會跟不同的人共事，但有時候他們也會一起工作好幾個周期。這方面并沒有什么嚴格的規定。
我們有沒有專門的項目經理？
沒有。項目由團隊的設計師領導，但是設計師與程序員之間有著非常緊密的工作關系。所有事情都是一起干的。
不管角色如何，每一個人都在同一個地方工作，在同一個地方溝通等。對于我們來說這個地方就是Basecamp 3。當所有人都在同一個地方時，每個人都知道東西在哪里，事情到底怎么回事，而且每個人都可以自給自足。把工作、溝通和管理分散到不同工具/產品進行會1）非常低效；2）對于整個團隊來說很難看到全局情況。
我們跟蹤時間嗎？
不。我們不考核效率，不進行實際與估計時間的對比。我們有6周的時間來完成一件事情。這段時間內怎么來完成這件事情完全由團隊自己決定。
重要的是我們不會等到最后才發現時間不夠用了。我們會一直關注做了什么事情，還剩下什么事情，還有多少時間。范圍總是在變——如果時間不足的話我們就把范圍縮小，如果時間比我們預想要充裕就把范圍擴大點。這是一個協商的過程。這中間的流動性很大。不變的是截止期限——啟動6周后必須交作業。
想法從何而來？
我們沒有專門騰出時間去想點子。也沒有專門的一群人去想點子（注：大企業往往有企業發展部或者企業策劃部）。所有點子都來自我們，來自我們的客戶。想法總是動態的。我們時刻都會有新想法冒出來。在這個創意的海洋里有些想法會漂到岸邊。這時候我們就會更加仔細地留意一下。
推銷創意
當一個想法感覺足夠成形了，接下來就要把它推銷（pitch）出去。Pitch是對問題的完整定義，也是對問題解決的初步建議。
下面是一個pitch的實際例子，通過它你可以看看它的一般形式。我們不會自己來講——我們的pitch都是寫出來然后發布到Basecamp上面供大家評審的。
為什么我們的pitch不是口述的形式？理由有以下幾點：
-
我們覺得把東西完整寫下來更好一些。這樣的話做pitch的人才不會被打斷。他們的故事才可以如自己所愿得到完整的展現。
-
此外，我們認為把東西寫出來可以讓你對它有更深入的考慮。
-
我們是異步通信的忠實信徒（注：這一點可以參見《群聊的正確使用方式》，Jason Fried在里面詳細討論了Slack半同步半異步機制弊端）——先寫下來，再給別人一點時間去消化。實時的溝通，不管是面對面還是虛擬的，這種同步性的安排其實效率是非常低的。
-
最后，雖然這是以消息的形式在Basecamp上面發布的，但所有的回復和隨后問題都是自動附在原始帖子后面的。這使得圍繞著pitch的所有溝通全部都是集中在一個地方，在一個頁面上的，這樣每個人都能看到同樣的故事。事實只有一個版本。
你們怎么決定做哪個項目？
每個人對此都很好奇。說實話，這更多是藝術而不是科學。想法從各個地方冒出來，但把想法變成產品周期的最終決定權落在我（CEO）、David（CTO）以及Ryan（戰略）3個人手上。在周期開始前的1周左右，我們會對Basecamp上面發布的所有pitch進行評審，同樣也會分享我們的一些看法，往往還會對項目選擇進行激烈討論。然后我們通常會進行30分鐘左右的會議（在Skype或者Hangout上面進行），再吵一輪，然后做出最終決定。
點子能否過關取決于很多變量——pitch的完整程度如何，客戶的痛點在哪里，我們想要嘗試的新點子在哪里，什么地方做的還不行需要修訂，我們要做的商業案例是什么等等。但無論決定該如何，好消息是6周過后我們又可以開始新一輪的工作。所以如果這次pitch沒有入選的話，1個半月之后還有再次被考慮的機會。
產品周期是如何發布的？
一旦周期確定下來，并且所有工作都編排到大小項目里面了，我就會寫一篇公告發布到Basecamp內部的“Building BC3”項目上。Building BC3項目是Basecamp相關的高級產品工作的主項目。是我們討論全局性事務、分享pitch、討論想法、安排產品周期等的地方。這里是一個產品周期通告的例子。
實際工作是怎么組織的？
每一個大項目都會有自己的Basecamp項目。這里是一個大項目的模板例子。注意：Blackburn是本次產品周期的名字（我們用山來對周期進行命名）……
有關Template是模板的每一項任務、討論、注釋、公告、期限、筆記以及聊天都在一個項目內進行。
而一個周期內的所有小項目都放到一個Basecamp項目內。以下是Blackburn周期的小項目例子：
每一個小項目都以獨立待辦事宜清單的形式進行管理。下面就是Blackburn周期的4個小項目：
每一項設計任務、變成任務以及QA事務都放到一個待辦事宜清單里面，清單以我們要做的功能名字命名。這樣的話整個團隊，無論其角色是什么，都可以知道是什么意思。
你們QA是怎么做的？
我們的QA團隊有兩個人：Ann和Michael。他們會到處看看進行中的不同項目，或者接受團隊邀請來對東西進行檢查或者復檢。我們發現，他們介入得越早越好。QA一樣是6周的時間窗口，這樣的話才不會到最后一分鐘才發現問題。所以我們不會等到最后才開始QA。至少大部分時間不會。
你和David如何參與？
幾乎每一個面向客戶的項目或產品更新我和David都會有一定程度的參與。
在早期我會跟設計師一起探討想法，然后在項目過程中幫助提煉和簡化。文案方面我也會幫設計師一起考慮，確保我們的措辭有意義。設計評審不是批判，而是解決問題的討論。
David幫助程序員制定進攻計劃——考慮模型的問題，保持我們對性能和速度的關注，并且協商技術妥協，從而保證6周的時間窗口不會超時。
如前所述，我們還參與到在產品規劃階段——也就是想法介紹以及確定特定周期的工作。我們跟Ryan密切配合，仔細考慮每一項功能，全面審視產品，確定該做什么以及什么時候做。
當然，事情不僅這些……
我已經試著把主要的東西都列出來了，但不敢保證沒有紕漏。遺漏的地方當然會有——產品工作有很多視情況而定的時刻。但希望這里所列東西已經足以讓你對我們在Basecamp是怎么工作的有了基本了解了。
京公網安備 11010502049343號