筆者在這邊把自己一些利用google doc來協助產品開發和提升公司遇作效率的經驗，與大家分享。

產品改版點子收集

產品在第一版功能確認並凍結後，其實開發團隊的想法還是會源源不絕的出現，有時候是同事聊天時出現的，有時則是會議中決議要暫緩施行的功能。

這時候就可以開一個google doc分享給開發團隊，大家有任何想法，都可以在上面自由編寫，7*24不間斷。等到要進行產品改版後，產品經理就可以直接參考這份文件，進行下一版本的產品規劃。

行銷點子蒐羅

和產品改版的例子類似，只是差別在於行銷點子的google doc，不只可以分享給開發團隊，更可以分享到全公司。以往，財務部門幾乎沒什麼機會可以貢獻產品行銷的點子，現在透過google doc讓大家都可以貢獻產品的行銷點子，想法會更多樣化和多元化。

文件編撰進度透明化，簡化管理流程

在google doc上編寫文件時，主管可以隨時隨地上去看現在的進度如何，也可以看看編寫方向是否正確，最重要的是，主管完全不需要常常叫部屬過來，問問編輯進度與方向，可以節省非常多時間。

專案規格書透明化，提升顧客滿意度

在做軟體專案的時候，尤其是透過敏捷開發的方法時，在每次的demo和會議後，產品的規格都會一直處在更新和變動的狀態，這時候只要利用google doc編寫專案規格書，每次會議所討論的規格，都即時update上去，利用流程的透明化讓客戶放心。

另外，更可透過revision history的功能，了解到是誰在什麼時候改了什麼東西，做到簡單的文件版本控制，不必擔心任何一方耍小動作，實在是非常方便。

共同編寫文件，減少溝通時間

公司內部常常有機會跨部門合寫一份文件，而且這種文件常常會有隨著時間而增長的特性，例如：PM與研發之間的bug tracking table。透過跨部門維護同一份google doc，PM可以不用等到全部測試完畢再發bug issue，研發也可以先列出來的bug先行研究以節省時間。

不僅如此，大家都維護同一份文件，雙方也能省去許多文件Email過來Email過去的時間和麻煩，實在是非常方便。

Action Item tracking

在每次的會議結束後，或上投老闆口頭交辦任務後，都會產生許多Action Item。會議結束後的Action item可以透過會議記錄追蹤，但是有時候口頭交辦的任務，就是很容易會忘記。所以透過google doc，為每個人設立專屬的Action item list，讓老闆和員工共同維護，這樣一來除了有進度透明化的好處外，更可以讓老闆和員工之間，不會因為任何一方忘記了，而不小心讓事情開天窗。

Open Issue List

常常在討論產品規格或是任何議題的時候，常常都會留下許多尚未達成共識的issue，有的很重要不會忘記，但是有時候卻是很細碎常會忘了，這時候開發團隊成員應該可以共同在google doc上維護一個Open issue list，當時機成熟或是證據比較充分後，就可以進行討論。

這麼做的好處是，當一份Open issue list是大家所擁有時，團隊成員都可以變成是專案的監督者，而不僅僅只有PM監督著專案，大家一起監督Open issue list是否完整，一起監督Open issue list是否已全部解決。如此一來，就能讓專案執行的更有效率。

人脈聯絡清單

不論是好吃餐廳聯絡簿，還是團隊成員聯絡簿，亦或是Vendor或記者的名片，都可以透過Google doc以wiki的方式來維護，讓公司的內外部資源一目了然，不會因為人脈資源的不透明，造成機會的錯失。

結語

使用wiki的前提，就是公司成員彼此的信任，公司內部的成員彼此越信任，透過wiki方式所能發揮的效能就會越高。若是公司成員彼此間不信任，大家都防著其他人暗算自己，不願意分享，處處想占便宜，透過google doc來合作反而不恰當。

大家還有沒有些什麼在公司內部利用google doc的好範例呢？希望大家一起來分享嚕。

--
不想錯過我的新文章：訂閱免費電子報

---

我的線上課：數據化營運、產品增長 和 產品企劃力，歡迎大家報名