Trello、Lyft 團隊也愛用,ReadMe 要解決開發者的「API 文件恐懼症」

| |

ReadMe 的創辦人 Gregory Koberger 在向別人介紹他的公司時,常遇到有人問他說:「你一定是太喜歡寫技術文件(Documentation),所以才想要以這項目當作你的創業點子吧?」畢竟將個人喜好跟創業相結合,聽起來就是個再完美不過的職涯選擇。但 Koberger 在介紹 ReadMe 的文章中曾提到 ¹,他其實是因為太討厭面對技術文件,所以才創辦了 ReadMe ,想一勞永逸解決自己與其他開發者在處理技術文件時的各種困擾。

技術文件,已成為 API 開發與使用最關鍵的一環

隨著 API(Application Programming Interface,應用程式介面)在軟體開發扮演的角色日漸吃重,越來越多的服務與資料透過 API 相互流通與連結。一份好的技術文件,不僅可以減少開發人員在串接 API 時所耗費的心力,也讓用 API 提供服務的公司能吸引到更多的使用者,進而擴大公司的營收及市場占比。

根據《2019 API 現況報告》²(State of API 2019 Report),這份針對 API 開發者與使用者(編按:本文中的「使用者」指的是使用 API 服務的開發者,而非一般的服務使用者。)所做的調查報告指出,使用者在評估 API 的時候,最在乎的就是 API 技術文件的優劣。像 ReadMe 這種用來撰寫 API 技術文件的工具,也是最多人(55%)在開發 API 時會使用到的。而與 2016 年所做的調查相比,API 技術文件的工具的需求成長也最為快速。

ReadMe 的首頁截圖

ReadMe:要讓 API 技術文件好看又好用

於 2014 年創立的 ReadMe,其主要功能是提供工具給開發者,讓他們不僅能有效地產出與管理易懂且好看的技術文件頁面、監控 API 被使用的情況。ReadMe 也為開發者提供更全面的顧客服務工具,與使用者間建立更緊密的關係。事實上,ReadMe 的公司取名也非常直白: 其英文原意就是說明書。而在 GitHub 上,開發者通常也會將專案的說明寫在 Readme.md 中。

創立至今,ReadMe 已擁有超過 3,000 名企業/個人的付費用戶,其中包含 Lyft、Trello、Box 等知名企業。ReadMe 更在 2019 年 8 月,於 Y Combinator 的協助之下,獲得知名創投 Accel 領投 900 萬美元(約新台幣 2.75 億)的 A 輪募資,累計募得 1,010 萬美元(約新台幣 3.1 億)。ReadMe 更表示他們近幾年已成功獲利,本次募資是希望招募更多人才,並提供更安全的服務環境,吸引更多大型企業的使用。

在 Accel 負責本次投資的合夥人 Daniel Levine 表示:「ReadMe 為企業提供的不只是服務,還有策略的層面,他們提供清晰、具互動性且數據導向的 API 技術文件,讓開發者更樂意使用企業提供的 API ,也就意味著能為企業帶來 100 個還是 1,000 個賺錢機會的差異。」³

更容易產出清晰的技術文件,強調 API 使用者社群的維繫

ReadMe 所提供的服務,除了提供 Markdown 的編輯器以及佈景主題,讓開發團隊可以輕鬆地撰寫出好看的技術文件之外,也提供直接上傳 Swagger 或者 OpenAPI 等可產出 API 技術文件檔案格式的服務,讓開發團隊以此為基礎,再進一步用 ReadMe 的服務優化 API 技術文件的呈現。

此外,在 ReadME 的平台上,開發團隊也可以像部落格一樣,修改 HTML/CSS 或 Javascript 來客製化自己的 API 首頁以及技術文件的呈現方式,藉此提升品牌的識別度。ReadMe 也提供全站搜尋、版本紀錄、辭彙表(Glossary)與版本控制的功能,讓使用者不只能快速找到合用的 API 與串接方式,也能對 API 的功能有更完整與全面的理解。

但光是提供漂亮且清晰的技術文件,尚不足以讓開發者願意買單。就我的觀察,ReadMe 與其他技術文件服務平台相比,最特別的是它所提供的社群功能,讓開發者能與使用者維繫良好關係。例如在 ReadMe 的頁面裡,就有類似 StackOverflow 提供技術支援的論壇,讓使用者在面臨問題卻又找不到解答時,可以直接在論壇上詢問,讓開發團隊的成員或是其他人協助解決。同時也有「建議」的按鈕,讓使用者能直接提供修改建議給團隊。

此外,ReadMe 日前推出的新產品 Developer Metrics,要進一步協助開發團隊追蹤使用者的使用狀況。開發者不僅能夠透過 Developer Metrics 追蹤 API 是否正常運作、瞭解哪幾支 API 最容易發生錯誤並修正問題,甚至能在更新 API 內容之時,先釐清約有多少比例使用者會被影響到,並事先通知他們或提供後續的客服服務。

ReadMe 目前並沒有免費版的服務,提供給個人開發者的最基本服務「Pamphlet」每個月收費 99 美元。若希望獲得更多客製化頁面的功能,或者是獲得更多的 API 相關數據,以及更安全的開發者與使用者登入方式,就需要升級到更高級的「Book」或「Encyclopedia」。而 Developer Metrics 則會依照 API 後台紀錄的多寡,依層級收費。

醞釀近十年,一度被 YC 拒絕的創業點子

ReadMe 的創辦人兼 CEO Gregory Koberger 其實早在十年前,就在思考如何優化技術文件。2010 年,當他申請 Mozilla 的工作時,負責面試他的網頁開發團隊的主管 Mike Morgan 就問他「你希望自己五年後成為什麼樣子?」他回憶到當時他就跟 Morgan 分享了他的「LiveDocs」的創業點子:這個產品讓技術文件不只是靜態的文字,而是讓用戶可以與之進一步互動。後來當 Koberger 正式加入 Mozilla 時,主管們也時常關心他的創業進度。⁴

2012 年夏天,Koberger 和朋友就把 LiveDocs 的構想發展成「DocHub」並申請加入 Y Combinator 。雖然他們有成功獲得面試的機會,並緊急在一個週末內用 Scribd 和 Disqus 的 API 做出產品原型,但最終仍被 YC 婉拒。YC 婉拒的理由是因為「他們看不出幫開發者寫技術文件為何是個對的切入點。多數的新創之所以沒有好的 API 技術文件,不是因為他們缺乏產品開發與工程的能力,而是因為他們對細節不夠注意而且寫作技巧不足。問題是出在內容產出的過程,而非缺乏工具。」

DocHub 的產品截圖(截自 Koberger 的 Medium 文章)

當 Koberger 回顧這次的失敗經驗時,他也檢討到自己當時並沒有實際產品可以展示,並且無法清楚解釋他們想要做的是什麼:雖然他知道有件事情必須完成,但他其實還沒有完全釐清問題跟解決方案。但這次寶貴的經驗,也讓他更清楚自己未來的方向。

在 2015 年的冬天,他再度申請 YC。此時的 Koberger 累積了更多的開發經驗,而且 ReadMe 也已上線一段時間並累積了一定用戶。此外,當時的市場環境也有所不同: Twillo 與 Stripe 等 API 優先(API-First)的公司的日益茁壯,讓大家認知到 API 對各行各業的重要性。而以 API 串連為核心的開發環境,也讓技術文件的易讀與否更成為決定企業成功與否的重要環節。

Koberger 認為,這樣的市場環境讓 ReadMe 這樣提升技術文件品質的公司得以誕生,他再也不需要耗費心力向開發者宣傳 ReadMe 的重要性,只要需要跟大家說「這產品能提供 Stripe 等級的技術文件」,大家就會買單了。在具備了天時、地利與人和之下,ReadMe 最終也成功獲選入 2015 年 YC 的行列。

密室逃脫遊戲「新創逃脫」的官網截圖

熱愛業餘專案,下班後還設計密室逃脫遊戲

除了創辦 ReadMe 之外,創辦人 Koberger 其實也做了不少業餘專案(side project),且不侷限於程式開發上。他除了曾與 Y Combinator 的 Sam Altman 合力創作寫給創業者的《Startup Playbook》,由 Sam Altman 撰寫文字,他則是負責繪製插圖。另外,他也跟 Sam Altman 建置「Track Trump」這個網站(目前連結已失效),不僅追蹤並記錄美國總統川普的公開發言,也同時檢驗川普的發言是否有相互牴觸的情況。同時,Koberger 作為重度的 Slack 用戶,他所開發的瀏覽器應用程式 Slackmoji,提供廣大的 emoji 資料庫,可以讓大家直接一鍵下載 emoji 並在 Slack 中使用。

其中他最有趣的業餘專案,應該就是「Startup Escape」(暫譯為「新創逃脫」)這個以新創為主題的密室逃脫遊戲。⁵這密室佈置得像是新創公司的辦公室,除了必備的電腦之外,裡面也放著 GitHub 的八爪貓、Peter Thiel 的《從 0 到 1》等具創業感的素材。遊戲的參與者要在 1 個小時之內找出逃脫密室的方式,一如新創的創辦人們必須在有限的資金內推出產品。而用來逃脫密室的線索也與創業所需的技能相互呼應,共分為程式、設計、開發營運(DevOps)產品開發與行銷。(但遊戲官網表示參與者不需要真正具備相關技能)

Koberger 在接受採訪時表示,「因為他這幾年來迷上了密室逃脫,所以他想要嘗試打造一個自己的遊戲,裡面充滿著新創界才懂的笑話⋯⋯『新創逃脫』就像是密室脫逃版的《矽谷群瞎傳》(Silicon Valley)。」⁶

ReadMe 是否能為自己編寫更美好的前景?

剛募到 A 輪 900 萬美元資金的 ReadMe,也意味著他們在真實世界的新創賽局中,獲得多一點打造成功產品的時間。

雖然 API 的生態圈仍持續蓬勃發展,但與 Postman 、SmartBear 、Oracle Apiary 等提供一站式 API 開發服務平台相比,ReadMe 的最大劣勢就在於它的服務只聚焦在 API 價值鏈中最接近使用者的文件、監控與客服端,並無提供完整的 API 開發環境。因此 ReadMe 需要確保他們所提供的服務,不只減少開發者在管理與撰寫技術文件上的痛苦,還得證明 ReadMe 所提供的介面與服務,真的能幫助開發團隊維繫與使用者的關係。

ReadMe 或許能在時限之內,讓自己從競爭激烈的新創密室中脫逃而出,甚至幫助更多的新創團隊,以更高品質的 API 技術文件在各自的市場中開疆闢土,並讓更多服務能透過 API 流暢地整合,提供給消費者更直觀的科技體驗。


參考資料:

  1. I Hated Writing Documentation so I Founded a Company
  2. The State of API 2019 Report
  3. ReadMe scores $9M Series A to help firms customize API docs
  4. Five Years Time
  5. Startup Escape
  6. Silicon Valley’s Startup Escape Room Is A Love Letter To The Product Hunt Generation

本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出

Previous

《星箭廣播》33 集 —— 科技素養,是在哈囉?

研發鋼鐵人飛行裝還不滿足,新創 JetPack 這回要推出空中摩托車

Next

發佈留言

Share via
Copy link
Powered by Social Snap