問：「搭建開發者社區的工作一定要由開發者來完成嗎？」
這樣的問題，我已經聽過無數次了。這個問題會出現在每一個社區群組中，而提出這個問題，通常都是那些想要在科技行業闖出一片天地，但是自己又沒有技術背景的人。他們不確定自己能否在科技行業生存下去。
我一行代碼都沒有寫過，而我卻成功成為了Estimote的社區佈道者。我們是一家專注於移動開發者的初創企業。一路走來，我學到了許多經驗，所有以社區運營為職業的人，都會覺得這些經驗非常實用。我們都在以產品為中心，召集更多的開發者，我們不僅可以使用這些經驗，還可以一起對它進行討論、推廣，並且不斷的做出更多貢獻，讓經驗越來越豐富。以產品為導向的社區，就像是蜂巢一樣，所有人都在為一個共同的目標貢獻自己的力量。大多數時候，我們的工作重點其實並不是技術自身。
我也並不是唯一一個非技術專業出身的例子，就連SendGrid和Twilio這樣以打造開發者社區而出名的企業，其社區團隊中也有非開發者出身的成員(hi Tim, hi Lisa!)。
我們就再來討論一次這個問題：要想搭建開發者社區，你自己必須是開發者出身嗎？
不，但是你要學會像個開發者一樣思考
就算你不會用代碼進行思考，但是你應該學著像開發者一樣思考。
從事任何職業的人，都有自己的習慣、術語以及看待世界的特別方式。你的任務是要打造一個能讓開發者感覺到賓至如歸的地方。當然，任何一名開發者都有自己的特性，但是你見過的開發者越多，你就會發現越多他們的共同點。他們總是會說著同樣的東西，比如pull request、forked repos和API tokens等。沒錯，你需要學習這些東西。不要給自己找藉口逃避。
很多開發者都非常癡迷於效率。他們腦子裡想的都是系統、辨識規律，以及對各種問題都進行詳細的分析。
這樣的描述有點太空泛了？沒錯。在一定的數量級內，這個描述是準確的。但是如果有人跟你說，他能用幾句話解釋開發者（或是設計師/記者/建築工人）的思考方式，請你一定不要相信他。
學習開發者的思維模式，沒有任何捷徑可尋。唯一的方式，就是與開發者進行對話。
和公司內的技術團隊一起吃飯，參加他們的會議，關注Slack/HipChat頻道的新動向，與負責用戶反饋的人一起進行討論。你也可以在公司外部尋求學習的機會，例如參加你所在城市內舉行的科技大會，在tack Overflow上關注與你社區有關的話題標籤。
一些話題你可能完全不理解，例如「你創建過的最複雜的C語言代碼是什麼？」。你其實並不需要把這個問題理解的過於透徹，在閱讀的時候，你只需要看著別人討論的細節，從中找到快樂。這些做法都能讓你成為一名更好的社區運營人員以及技術佈道者。
不，但是你需要了解產品
所有社區的核心都是人。但是開發者社區的核心除了人之外還有產品。開發者社區憑藉特別的工具或是目的，將開發者吸引在一起。就算你不能成為使用這些工具的專家，你也應該要成為解釋它們的專家。
你可以閱讀一些成功的故事，以此來了解那些最佳的實踐，以及開發者在哪些情境下會使用你的工具：如果你所在的公司還沒有發布這些內容，你可以請客戶成功團隊/商業開發團隊/其他社區的運營人員和你進行分享。你還要了解產品的演變過程：查看舊帖，並且閱讀產品的更新日誌。
了解了產品和用戶，你就可以展示相關的案例研究，回答一般性的問題，並且鼓勵人們通過自己寫內容來為社區做出貢獻。鼓勵其他人做出貢獻，是最為重要的一點。當社區的成員感覺到你在乎他們時，他們就會為你的工具寫指導、針對你的產品安排聚會。如果你的產品是開源產品，他們甚至還會幫你修復bug，他們會皈依你的產品信仰。
如果確定自己是否已經足夠了解了公司的SDK和API？比較好的方式之一，就是看看當一個人在部署某個產品功能遇到問題的時候，你是否可以告訴他在產品說明文檔的哪一頁可以找到答案。這意味著，即使你自己不會使用產品，你也已經熟悉了產品，並且知曉問題的根源處在哪裡。很明顯，如果你能夠做到這一點，足以證明你不是在憑運氣解決問題。軟件一直在改變，尤其是在這個所有人都在強調敏捷和每日更新的時代。也就是說，你之前所學的，也會馬上過時，因此你需要不斷學習。
在Estimote內部，我們建立了兩週一次的「stack review」活動：開一個簡短的會議，確保每一個人都學習了最新一次的產品Release。這個會議最多只需要20分鐘，但是它能讓我們確保每一個人的步調一致。
由於軟件產品的變化速度快，因此當你不理解或是不記得某些東西的時候，不要灰心。一個公司內，就算是開發者也無法全部搞清產品的所有細節，即使產品是他們自己開發的，沒有什麼可自卑的，軟件產品過於複雜，一個人不可能憑腦子記住巨大的代碼庫。當你遇到問題的時候，你只需要讓自己知道該向誰請教就好。
如果你所在的公司使用了Confluence或是Asana這樣的協作工具，你應該為產品維護一個帶有技術細節說明和FAQ的文檔。
如果你公司沒有使用協作工具，你可以使用Google Doc。要注意的是，一定要有專人負責對它進行更新。過期的文檔比沒有文檔還要糟糕。
不，但是團隊中需要有開發者
在面向開發者的領域內，任何社區團隊都必須要有一名開發者。起初，我們的團隊並沒有全職的開發者。這樣的模式維持了一段時間，我們在世界範圍內的活動內維持了一定的曝光量，我們不斷地改善內容，並且提供了高質量的客戶服務。
但是我們馬上就遇到了瓶頸。我們支持黑客馬拉松活動的能力有限。再編寫技術性內容的時候也感到力不從心。那些困難的支持請求會拖延好幾天的時間，因為團隊優先處理shipping問題，然後才輪到troubleshooting，這部分支持請求佔全部請求的10%。
在我們找來了會寫代碼的技術佈道者之後，整個團隊都變得更有效率了：客戶支持、內容、活動、反饋收集、開發者關係等，我們在社區眼中變得更加主動、可接近。
給團隊配備一名具有專業能力的成員，能讓團隊的效率呈幾何級數增長。如果你想讓你的開發者社區團隊從「不錯」變成「牛掰」，你就要給團隊配上一名開發者出身的技術佈道者。
Estimote Community 團隊 (從左至右), Wojtek, Witek (團隊領導), Ula (社區經理), Piotr (技術佈道者)
不，但是自己學學編程也沒什麼不好的
你們可能覺得我是在說大話。畢竟，我已經承認了自己從來沒寫過代碼。怎麼說呢？我們經常給別人出主意，但是自己卻很少真的這樣去做。所以我勸各位去學習，不要重蹈我的覆轍。
很有可能，通過學習你也無法成為一名優秀的開發者。但是你並不需要成為一名優秀的開發者。
你都不需要自己去開發產品。你去學習編程，是為了讓你打造出一個開發者社區，讓你更好的像個開發者一樣去思考。即使是最基礎的編程知識，也能大大的幫你理解社區，以及你的產品的用意。要想參與到開發者社區中，這是一項最基本的知識。
除了編程之外，你也可以學習其他東西。面向開發者的產品，其用戶除了寫代碼之外，還會做很多其他事情。如果你和我一樣，對Xcode和Android Studio世界就是沒有好感，你可以在其他領域內進行學習。讀讀產品管理方面的書籍，上一些UI設計的課程，學學UX，這個世界上有數不完的東西等著你去學習。Coursera、Udemy、iTunes U和大量的博客都為你提供了各種各樣的智慧，這些東西都是你夢寐以求的學習資料，你要學會善用它們。
最重要的是：學習領域內的知識。只要放開眼界，不再局限於社區搭建知識，學習其他一些知識能讓你更輕鬆的搭建起開發者社區。在相關的領域內擴展你的知識儲備，它能讓你更流暢的和社區成員進行對話。
有沒有例外？
確實有這樣一些開發者社區團隊，最初的時候我覺得他們一定都有著相當豐富的開發者經驗。例如Docker或是MongoDB這樣的公司。它們的產品技術性都非常強，提到它們你就一定會想到技術代碼，就像提到Estimote就一定會想到微定位、提到Twilio就一定會想到文本信息，或是提到Oculus就一定會想到電子遊戲一樣。
但是在研究了他們對「社區管理」職位的要求之後，我發現這些職位並不要求應聘者有技術背景。或許這沒有什麼值得驚訝的。如果你想要搭建一個開發者社區，直接去做就好了。你不需要成為Linus Torvalds，一樣可以成功。
作者：Wojtek Borowicz (Wojtek is the community evangelist at Estimote in Krakow, Poland.)
原文：How to Become An Awesome Developer Evangelist When You’re Not a Developer
轉載自：DevRel 開發者關係－非開發者如何成為優秀的技術佈道者
譯者：魯行雲
轉載請註明：開發者關係 »
