亞馬遜「文件優先」的文化,在業界已算是廣為人知。大家從科技媒體聽到的只有「開會前先讀文件」這樣的重點而已,但其實「文件優先」的文化不只是讓會議的效率更高,更讓亞馬遜的工作產出比其他人有著更高的完成度。
在亞馬遜中,要開會是一定要先有文件的,沒有文件的話是不能開會的。這個文化的落實程度,是已經融合在工作系統中的。當預約了會議室後,系統會直接附上表單,供預約者去撰寫這次會議中,與會者所需要看的文件。文件的格式不管是「6頁式(Six Pager)」還是「新聞稿/常見問答(PR/FAQ)」,基本上都是在描述一個問題的環境或來龍去脈,裡面也可以含有一些圖表,重點就是要讓與會者能有效的掌握問題的聚焦範圍。最有趣的不是文件長什麼樣子,而是文件怎麼被使用。會議一開始就是約10–30分鐘的閱讀時間,即便文件再怎麼長,內容最多就是6頁。與會者再怎麼多,也一定會排入足夠的閱讀及討論時間,閱讀時間就是會議時間的一部分。
作者是在AWS Container Service的資深工程師,以他在亞馬遜以外的工作經驗,他花不少時間寫好的會議文件,通常是3個下場:
- 沒人真的讀過文件,他得在會議中全部重新解釋一次。
- 雖然有人讀過文件,但他們是在會議前一天或前一小時讀的,所以有些細節已經模糊。
- 有人讀過文件,而且能在會議前提出問題,並在信件來回中進行問答。
最多的當然是第一項,當然這也是最沒有效率的那種會議。
在文件優先的會議模式下,作者分析了以下幾個最大的好處:
- 主持人在解釋問題的過程,不會再那麼緊張。而且整個問題描述,所提供的資訊,要討論的題目都會比較完整且不帶偏見的。
- 由於與會者是用「自己語調」在讀取資訊,所以比較不會受主持人的口音,語速或肢體動作所影響理解程度。
- 文件是「不插電」的,沒有需要投影機,設定臨時異常,或是解析度不佳的問題。
- 有豐富的產品文件資源在每次開會中產出,不只是產品最終給用戶看的文件,或是產品演化的歷史,都有完整保存下來的記錄。
- 在文件能提前釋出的前提下,即便沒辦法準時與會,與會者也可以自己先行閱讀,再於正式討論的時間加入即可,而不會無法參與討論。
- 由於是在討論前才讀文件,所以與會者對問題的背景,自己的觀察及可能的解決方案都是最清晰的狀態。
對想導入「文件優先」的企業來說,最大的技術困難點可能就是寫作。工程式一向不善於有效的表達他們面對的問題及自己的想法,這造成他們和他人溝通上很大的障礙。在亞馬遜有許多內訓課程,來教導工程師們怎麼成為一個好的文件寫作者。這樣的文化薰陶及要求下,就像Steve Yegge在「
你應該寫博客」裡不斷強調的,對工程師的實力養成有莫大的助益。
作者曾經被導師這麼告誡:「如果沒有文件,事情就沒有”完成”」。就像開會這件事,在沒有文件的情況下不能進行,是一樣的道理。文件在產品思維(Product Thinking)上也提供了更多面向,也更深度的思考。在他的職涯中,雖然他已不親自實作功能,但來自於他自己的想法,用戶的反饋,都會將其文件化,討論,實質的對產品造成影響。即便是一些小的靈感,功能試作,或是要迭代的目標上,也都是先有文件才有實作的。僅管文件的寫作是一件不容易的事,閱讀更不會是有趣的事,但文件一直都是重要決策的重要部分。
亞馬遜在遠距工作的基礎一直非常紮實,除了許多方便的通訊工具及架構設計以外,很大一部分也來自於「文件優先」的文化。許多時區不同的工作者,基本上都是仰賴完整的文件,在非同步的狀況下以最有效率的狀況進行討論。大家也都有一致的共識: 因為大家都投入了時間,所以更不要浪費別人的時間。
小結
在之前寫過的「
「遠距辦公」的效率不是來自於方式,而是態度」中,其實就發現到「文件」其實是知識工作者一種工作態度表現。在看到亞馬遜決定用API串連公司內部所有服務,造就了後續「外銷」的AWS服務產品後,再深入看看它們「文件優先」的開會要求,就不會覺得那麼驚世駭俗了。會而必議,議而必決,大家沒有同樣的問題背景,沒有足夠的知識素材,又要怎麼做得到呢?開會前花30分鐘很浪費時間?花了一個鐘頭卻無有效共識的結果,我想是更貴,也令人喪氣的結果。