知名項目管理軟件 Basecamp 團隊出了一本書It Doesn’t Have to Be Crazy at Work（《工作何須賣命》），講述互聯網創業和做產品的方法論。本文是根據這本書的內容有感而發，來跟大家討論下Basecamp的理念，以啟發和幫助我們設計、管理和開發出更好的產品。
這是一條基本原則：做出優質產品的要義，不是在每個遇到的問題上都投入更多時間和資源，而是減少人為製造的障礙，讓創新流程暢通起來。
我相信，隨著技術進步，我們將來只需要做少量工作，但可以做得更聰明、更好。不過，過去這些年我也發現，我們會在工作流程和決策流程上，添加很多人為製造的障礙，最終導致開發的產品和服務也變得複雜。
會議總是越來越多、越來越長。團隊在變大，流程也在變複雜，在每一步上花費的時間和資源都更多了。每年，我們都會引入更多管理工具。我們號稱追求簡潔的產品，但忘了怎麼做出有用的產品。我們想要創新，但又死板地根據既定的路線圖來開發產品。其實，已經有很多頂尖的公司找到了更好的方法來設計和開發產品，減少在每一步上的浪費。
最近，我看完了 Basecamp 團隊成員寫的新書 It Doesn’t Have to Be Crazy at Work（《工作何須賣命》），在書中，他們分享了很多實用的和「看起來不合常理」的知識和建議，都是關於如何運營一家公司、管理產品和團隊等方面。對於那些希望開發優質產品，做一家好公司的人而言，Basecamp 的公司和產品本身，就是最好的例證。
我個人很讚賞 Basecamp 的很多理念，這本書整體上是在向人們闡釋，如何設計出更好的產品。我總結了其中感觸最深的 4 個原則，相信這些原則，可以啟發和幫助我們設計、管理和開發出更好的產品。
1. 好主意要想透
通常，當大家想到了新的主意（這裡主要指做產品）。接下來的流程是，約個會議，邀請決策者參與，把這個主意講給大家聽，如果前兩分鐘沒被打斷，而且每個人都對這個主意感到興奮，然後就會開始來實現這個主意。但是，這種情況很少見，更常見的情況是，一個新主意剛講出來，就會被其他人打斷，告訴大家為什麼這個主意不行，這就是問題所在。
更好的方法應該是，首先在組織一個會議之前，你應該把想到的主意寫下來。這一步，保證你的主意可以清晰地表達出來。然後，在開會之前，把你想到的主意分享給所有與會者，給大家考慮的時間。這時候不需要反饋和互動，只是需要提前考慮這個主意。給大家時間，把事情想清楚。
接下來，開會的時候，誰都不許打斷髮言者。等發言者講完，大家才能發言，以及給出建設性的反饋。這裡的反饋，指的是能指導發言者或者基於講話內容展開或補充信息，而不是要把這個新主意滅掉。
之後，等開完了會，你就能花幾天甚至幾周時間，來把這個主意想清楚。之所以花這麼多時間，是因為這樣才能充分結合會上大家的反饋，進行重新思考。
為什麼不直接在開會的時候把主意想清楚，從而節約時間呢？
因為當你把所有關於這個主意的討論和想法都考慮進去的時候，你就很難真的獨立思考。這種會議，通常會陷入每個人都試圖維護自己觀點的爭論中。所以，你一個人在會議之後獨立思考，結合大家的想法，把主意想透徹是更好的方式。
來自皮克斯的智囊團會議：
這種方法有點兒像皮克斯的 Braintrust 智囊團會議。在皮克斯開始準備一部新電影的時候，他們就會組織智囊團會議。會議的目標是，放下自己的公司角色，在會議上為展示主意的人提供有指導意義的反饋。
智囊團會議不是用來批判為什麼這個主意不行的，而是說：
智囊團會議是希望每個參與者，都能提供他們的觀點，這個觀點需要能幫助演講者擴大視野。目標是能從不同的角度，增強演講者的認知。
在智囊團會議上，不能存在權威。這一點非常重要，因為演講者或者分享主意的人並不必須聽從反饋意見。在智囊團會議之後，由他自己決定下一步做什麼。這種會議不能是至上而下的，不能有人講要做這個、不要做那個。通過在智囊團會議上去除權威，大家就有了創造新事物的靈活性。
開智囊團會議的時候，皮克斯不想要客套話，而是希望大家來提供真誠的和深度的分析。智囊團會議是希望給演講者提供幫助的，沒有各自發表利己觀點的議程。相比而言，我們普通的會議中，常常會出現競爭性的環境，大家會拿自己的想法和別人的想法做對比，無形中將會議的討論氛圍變成勝負爭論。
2. 三人一組的好處
Basecamp 有一項很好的實踐，就是三人一組進行產品開發，這三人通常由兩個工程師和一個設計師組成。這種方式，可以減少決策流程中的阻礙因素。這種方式還有很多好處，最基礎的一個是，團隊人越少，每個人就會越投入。在開會上花的時間少一些，減少溝通中的誤差，更快做決定，以及佔用更少的資源。
不管是創業公司，還是大公司，三人團隊適合各種階段和規模的公司。三人團隊的方式，不只是 Basecamp 在用，耐克公司也在用。在此前的文章中，我舉過例子，關於耐克的一個優質產品是如何從三人團隊中誕生的。
耐克的 HTM
HTM 是耐克從 2002 年開始的實驗性設計項目的名字。HTM 這個名字來自最早的三人小組的名字首字母，他們是：Hiroshi Fujiwara, Tinker Hatfield 和耐克的 CEO 兼設計師 Mark Parker。
HTM 的角色是什麼？
三名設計師和主要的決策者進入一個房間，把日常工作丟在一旁，專注於對現有產品設計的重新審視，以及開發新的產品。這也是一個，關於設計師與公司 CEO 一起工作，而非只是聽從命令的好例子。
因為只有三人一起工作，所以他們可以充分利用全部時間，加速創意產出流程。在傳統公司的運行流程中，很難實現這一點。耐克這種規模的公司，從開發到上市依然能實現快速流程，對其他公司而言是難以想象的。
如果增加到 4 個或 5 個人又能怎樣呢？
簡單來說，人越多，障礙就越多。如果你的目標是減少障礙，那麼增加更多人就會引起問題。人一多，就需要有人來管理團隊。但如果是三個人，溝通就可以很暢快，擁有更多時間專注於創造，減少打擾，從而創造出優質產品。如果增加更多人，一定會在流程和彙報中損耗精力，從而讓事情變得更復雜。
小團隊可以做大事，但是大團隊做小事就比登天還難。三人一組坦誠以待，減少溝通障礙以及促進工作協調。
——《工作何須賣命》
當然，三人團隊在開發新產品或功能的時候，也會遇到挑戰，但這就是「限制之美」。很多人會想當然地以為，畫布足夠大，你才能畫出更好的作品。但是每個創意工作者都明白，並非如此。過多的自由度往往導致中庸。沒有邊界，就失去了尋求突破邊界的刺激。一個有創造力的人，並不會讓有限的資源，成為創新和創造偉大事物的障礙。
3. 什麼都不做也是一種選項
人類的天性是不喜歡改變，並且抗拒改變。對於產品也是這樣。尤其是當我們想讓用戶使用我們最新發布的版本，但他們不想要或者不需要新版本的時候。
比如：你正要發佈一個產品的新版本，但很多用戶對舊版挺滿意的，並不需要新版本，那該怎麼辦？大部分公司從來不考慮這件事，因為他們就覺得新版更好，怎麼會有人不想升級到新版呢？
我們看看 Basecamp 是怎麼做的，當 Basecamp 重新設計他們的 app 時，他們思考一個問題，如果用戶習慣了使用舊版本，不想遷移到新版本該怎麼辦？因為從舊版升級到新版需要遷移數據，轉換格式，適應新的界面風格。於是，他們決定不強制遷移，對於已有用戶而言，升級與否是個可選項。這樣他們就能節省時間和資源，同時讓客戶感到愉快。
有時候，你必須認識到投入同樣的時間不等於得到同樣的結果。什麼都不做，有時候也是一種艱難但正確的選擇。
——《工作何須賣命》
不只是 Basecamp 如此，還有一個我親身經歷的例子是 Freshbooks，他們提供面向小企業的收據和會計解決方案。作為終端用戶，我體驗了一次升級服務。
當他們改進產品，發佈新版本，他們把升級作為可選項。用戶可以在任何方便的時候選擇升級到新版本。更重要的是，他們允許用戶自己在新舊版本直接切換，而不會造成數據丟失。這樣用戶就能充分體驗到底哪個版本適合自己的業務。這樣做，減少了客戶的焦慮，為他們節省時間，讓他們感到愉悅。
對我個人來說，我是在體驗了一段時間新版本之後，正式遷移到新版來完成工作。前提是我對新版本進行了充分的瞭解，我知道還可以退回到舊版本。
4. 上線產品，然後從中學習
我曾經寫過很多次，我們在工作中很容易迷失在流程裡，在某一個問題上花費太多精力。投入更多時間，更多資源，更多人力，更多測試，更多爭論等等。然後，我們就忽視了按照預算和時間交付產品，然後發佈到市場上，從中學習的方法。
如果你想知道自己開發的產品是否受歡迎的真相，你必須把產品發佈出去。你可以測試，你可以腦暴，你可以爭論，你可以做調查，但只有把產品發佈出去之後，你才能知道下一步該做什麼。
——《工作何須賣命》
相反，很多人會把時間花在無止境地討論：我們是否部署了正確的功能；這個特性能否讓我們的產品變得與眾不同；這個功能的演進路線應該如何等等消耗精力的事情。你可以持續質疑，你現在的做法或者設計是否正確，是否交付了用戶喜歡的東西。
但是，除非你把產品發佈到市場上，你永遠都不會知道結果。做更多的用戶調研，在實驗室裡或封閉環境做更多的用戶測試，這些事情都不能讓你瞭解產品是否真的做對了。
任何行業都會發生這種事情，不管是拍電影、開發遊戲，如果不發佈出去，你就不知道人們是否喜愛它。你可以開很多內部會議，進行多輪討論，但這些都是主觀的，很容易產生錯誤的結論。
只有當用戶主動購買或使用了你的產品，你才能知道真正的答案，其他事情都是在模擬和空想。
Basecamp 的同事做得更絕，在產品發佈之前，他們不會向客戶展示任何東西。他們不做 beta 測試，不會詢問客戶是否願意購買，或者詢問用戶對產品的想法。他們就是發佈產品，然後讓市場給出答案。
你會錯失細節，錯過重要的東西，但這些都不是重點。這些風險在任何階段都存在。所以，為什麼明明可以開發產品、發佈產品並從中學習，而非要浪費時間去爭論呢？
我和一位在遊戲設計行業的朋友交流過這個話題。我們討論了，那些設計出有史以來最偉大遊戲的設計師，在產品發佈之前並不知道會發生什麼。當然，很多東西可以幫助遊戲設計師降低失敗的可能性，比如：經驗豐富的技術人員、引入心理學專家、過去發佈的產品、過去學到的經驗等等。但是，如果不冒著風險發佈出去，就永遠不會知道這些經驗是否有效。
總結起來，當你想要開發出色的產品或功能，並不是瘋狂賣命就行。如果你只是在每個遇到的問題上都投入更多時間和資源，最終只能開發出中庸的產品。只有專注於真正重要的事情，主動減少人為障礙，才有機會開發出色的產品。
作者：Eugen Esanu
原文：https://uxplanet.org/principles-for-designing-better-products-349f463c9ee5
譯者：HQ，公眾號：產品那些年，社交道路上不斷前行的創業產品汪。
本文由 @光澗實驗室 翻譯發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議