有道雲筆記團隊協做功能是如何誕生的?

有道雲筆記在 2011 年 6 月第一次和你們見面,在過去的 3 年裏,有超過 2400 萬的用戶經過有道雲筆記開始了他們的雲端記錄之旅。而咱們也在思考,雲筆記的下一個創新點在哪?是更炫酷的功能,仍是開拓一個更新的領域?segmentfault

  • 爲何瞄準團隊協做領域

事實上,在雲筆記產品研發的過程當中,咱們調研過一些潛在的方向,也嘗試過很多微創新。真正讓咱們決定雲筆記向團隊協做方向突破的,其實不是有道的任何一位高管,而是用戶。微信

在和用戶溝通的過程當中,咱們發現一些小規模的團隊用雲筆記創造出了不少新鮮的玩法。架構

羅輯思惟團隊是首先引發咱們興趣的團隊。他們對雲筆記的創造性運用給了咱們很大的啓發。羅輯思惟的編輯團隊使用同一個雲筆記帳號,每位編輯創建一個本身的筆記本組整理預料素材,而主編將不一樣團隊成員貢獻的素材整合在一塊兒,造成最終羅輯思惟的節目腳本。框架

隨後咱們爲羅輯思惟團隊開通了公衆帳號,號召更多的普通用戶經過有道雲筆記向節目投稿,通過篩選整理後將優秀內容共享到雲筆記公衆帳號中,公衆帳號變成了一個粉絲作出貢獻也獲得回報的地方。從 2013 年初咱們接觸到羅輯思惟,在使用過程當中他們向雲筆記團隊提出了不少急切的需求,好比設置權限,須要看到修改過程等等。工具

雲筆記以前的版本並非爲團隊協做設計的,因此相似邏輯思惟這樣的團隊使用起來會有種種障礙,但這些團隊願意嘗試新東西,把效率看得很重要,也不受大公司那些條條框框的約束,他們想到不少辦法來規避這些障礙。優化

另外一個例子是 NGO 組織黑龍江青基會。這個只有四五我的的小團隊要同時處理幾十所但願廚房和但願小學的項目進展,對他們來講最大的挑戰在於要隨時隨地協同處理信息。這四五個成員共用一個有道雲筆記帳號創建了一套資料協做機制,平常工做的處理和彙報徹底在雲筆記上進行,即便出門在外也能夠隨時查看項目資料。spa

正是這些用戶富有創造力的操做方式給咱們釋放了一個很強烈的信號:用戶在尋找更好用的團隊協做產品。設計

  • 有道雲筆記·協做是怎樣誕生的

把一個好想法變成好產品是一個充滿挑戰的過程。並且中國用戶的團隊協做方式與國外有着極大的差異,照搬國外的現成產品幾乎不可能。因而咱們開始了漫長而艱苦的快速構建原型、試錯、推翻重建的過程。遊戲

第一階段:2013.3 - 2013.5 嘗試雲筆記共享版圖片

在一開始,咱們的思路是作雲筆記的共享版。咱們在筆記和資料的存儲、管理方面有了必定的經驗,國外同類的雲存儲產品 Dropbox、Evernote 也都作了共享版,或許有能夠借鑑的地方。咱們組建了一支很小的特別行動組(1 名後臺開發、1 名前臺開發、2 名兼職 PM)只用了幾天時間就作出了一個團隊共享筆記本的原型,團隊全部成員均可以添加和修改共享筆記本中的筆記。
請輸入圖片描述
(雲筆記共享版的界面)

請輸入圖片描述
(雲筆記共享版中你們經過更新筆記標題來聊天)

然而問題很快出現了。最初幾天的新鮮勁兒過去以後,參與體驗的團隊成員很快就沉寂了下來。咱們覺得是產品原型太過簡單,因而又快速增長更新提示、提高共享速度,但發現仍然沒有轉機。經過訪談,咱們才意識到簡單的筆記共享,只是至關於讓你們把本身手裏的蘋果扔到一個不會動的筐裏,至於誰扔的,誰咬了一口,都看不到。咱們意識到,對於團隊而言,共享資料的目的並非僅僅爲了存儲和備份,推進項目的進展才是最終的目的。因此這種只能部分取代 FTP 功能的雲端資料庫,用戶固然不肯意用。

此路不通,產品工做陷入困境。

第二階段:2013.5 - 2013.9 從新肯定產品形態

雲筆記共享版的思路被否認後,咱們以爲問題在於用戶不知道共享筆記的內容作了什麼樣的修改。爲此咱們嘗試了下面幾種不一樣的原型來解決這個問題,可是始終找不到讓咱們本身滿意的方案。

請輸入圖片描述
(中間嘗試過的協做產品原型)

困擾中,咱們決定重頭從用戶的場景出發,來定義產品的形態。這段時間我把電話簿、微博微信上創業的、帶團隊的、作管理的、高校裏作教授的好友統統騷擾了一遍,跑遍了三里屯、79八、國貿、中關村、五道口的咖啡館。一番訪談下來發現,你們要的不是一個方便的雲端資料庫,更多的要是一個有效的雲端工做場所。在訪談中,個人朋友們一再提起微信在他們工做中起到的重大做用,以及微信在文檔管理上的不足。咱們意識到,在團隊協做產品中,IM 是一個相當重要的模塊。資料庫+IM 應當成爲協做產品的主要產品框架。

由於 IM 有用戶習慣的交互方式,因此咱們新版的產品原型也試圖在 IM 的標準交互上進行改良。
請輸入圖片描述
(資料庫+IM 的移動端原型)

請輸入圖片描述
(資料庫+IM 的桌面端原型)

第三階段 :2013.9 - 2014.2 找到資料與 IM 的平衡點,爲本身作產品

在此產品基礎上,咱們擴大了團隊規模,加大了開發力度,也引入了 UI 設計。在這個版本中,協做界面被分紅三欄,左側是羣列表,中間是 IM 討論,右側是資料庫內容。資料庫中又分爲筆記和文件兩個類目。用戶能夠在 IM 中討論項目相關的內容,資料的更新參考我的筆記,最近更新的內容排在最上面。
請輸入圖片描述
(資料庫+IM 的首個 UI 設計版)

爲了獲得更多的內部反饋,我要求整個筆記團隊徹底拋棄企業 IM 工具(網易泡泡),轉用雲筆記的協做產品。做爲團隊帶頭人,我解散了全部筆記組的泡泡羣。

但畢竟協做產品當時還在開發中,存在協做 IM 消息提示不夠及時等各類問題。不久以後我就發現,個人團隊成員偷偷的從新建了泡泡羣(只不過把我排除在外)。但若是是關於文檔的交流,你們仍是願意在有道雲筆記·協做中討論的。因此這不得不讓咱們從新思考協做功能的定位。若是說資料庫和 IM 是天平的兩端,第一次的問題是徹底把本身困在了資料庫那一邊,而此次,則是向 IM 的步子邁得有點過大了。

經歷過這輪內測後,咱們意識到,有道雲筆記·協做不是要徹底代替團隊內現有的 IM,咱們要作的協做產品,核心應該仍是資料,在這裏資料不只能夠被管理,並且應該有更增強大的協做編輯能力,IM 討論是輔助討論和實時更新的手段。

在乎識到這點以後,咱們將筆記和文件合併到同一個功能模塊中,並將這個功能模塊置於客戶端界面的中間,突出其核心價值。經過增長多版本對照、筆記和文件評論等功能增強了資料管理和協做能力。在 IM 討論區增長資料新建、修改、刪除的消息通知,把資料庫與 IM 模塊更加有機的結合,讓沉澱的團隊資料真正活起來。 在作完這些修改以後,咱們終於初步達成了「給本身作產品」的目的。

請輸入圖片描述
(以資料爲核心的資料庫+IM 產品結構)

第四階段:封測 2014.2 - 至今 從給本身作產品到給用戶作,與用戶交朋友

接下來,咱們把視角從「給本身作產品」切換到「給用戶作產品」,讓用戶給咱們儘可能多的反饋,而後讓他們愛上咱們的產品。咱們儘快地找到一批會給咱們有價值反饋的用戶。在過去 3 個月中,咱們以 2 周爲週期,優化視覺與交互、修改 bug、完善功能超過 500 項。經過與用戶的深度交流,咱們也得到了一些新的洞察。好比說,咱們意識到在協做辦公場景中,對 office 文檔的支持是很是重要的。根據這個洞察,咱們爲協做產品增長了 Office、PDF 預覽功能,並在近期將提供對 Office 文檔直接編輯(再也不須要下載和上傳)的功能。

請輸入圖片描述
請輸入圖片描述
(有道雲筆記·協做產品內測版界面)

在封測階段咱們邀請了一些團隊來體驗產品,其中有道口語大師團隊、網易新聞客戶端團隊、網易花田團隊、網易遊戲部、網易杭研團隊、網易雲閱讀團隊、網易雲音樂團隊等衆多網易內部產品團隊已經從最初的嚐鮮用戶成功轉化爲第一批忠實用戶。除內部團隊外,一些外部朋友也參與了封測過程,她生活團隊、週末去哪玩兒團隊、卓明地震援助信息中心、黑龍江青基會以及網易校園合夥人大賽的參賽學生等不少團隊,都在協做的使用過程當中給咱們提出了很好的改進建議。

通過 1 年多的反覆演進,有道雲筆記·協做爲團隊用戶提供了羣管理、筆記、文件、圖片的管理和協做、IM 交流和通知等一系列基礎的功能模塊。之因此把產品設計成這樣,源於咱們最初的一個理念:咱們要作的是一個面向大多數用戶的產品。這些用戶迫切須要的是最爲基礎的文字處理軟件、表處理、實時溝通。在比較長的時間裏,咱們不會考慮專門面向某些特定人羣,好比會計、銷售這些垂直領域作專門的開發。

在產品誕生的過程當中最難的不是技術上的問題,而是要準確判斷出哪些功能應該上,哪些要拋棄。個人見解是,研發過程當中固然應該保持專一,要弄明白哪些事情爲何作,哪些事情爲何不作,哪些事情要作透。

  • 產品的取與舍

對咱們來講,原則很簡單,咱們提供的產品應該是爲一線團隊項目推進者服務。

因此咱們要讓資料的共享、編輯、協做變得更加高效、對於項目的討論要更加實時。而過於複雜的組織架構、OA 流程管理、層級權限設計,就顯得沒有那麼重要。這都是咱們不作的事情,由於咱們的用戶都是一些沒有層級觀念的人。他們可能只是幾個想合夥把一件事作成的小夥伴,不須要那些複雜的東西。

咱們但願團隊用戶能夠根據本身的須要和想象去靈活使用有道雲筆記·協做,造成最適合本身團隊的使用模式。而咱們雲筆記團隊也將在內測階段中根據你們的反饋繼續嘗試更多的創新。

歸根結底,一切的一切仍是要回歸到用戶應用的場景上去。這是咱們產品成功的根本和保障。

李彥宏在百度聯盟峯會上談到將來趨勢的時候講到,提高企業內部效率的企業級軟件將是大市場。咱們很高興有更多的企業關注這個機會。對咱們來講,這既是一塊嶄新的領域,也遵循着咱們一向的理念。鏈接人,鏈接團隊,從我的到團隊全面提高效率。

相關文章
相關標籤/搜索