由前 Facebook 技術長泰勒（Bret Taylor）和前 Google 員工吉比斯（Kevin Gibbs）開發，被喻為比 Google Docs 更適合團隊會議的文件協作的線上溝通軟體Quip，近來在國外相當受到歡迎，目前 Quip 已獲得 4,500 百萬美元投資。

工程師劉愛蒙（Edmond Lau）在他的書《The Effective Engineer, Engineer at Quip》中，揭示Quip如何運用13位工程師創造跨越八大平臺（web, Mac, Windows, iPhone, iPad, Android phones, Android tablets和Apple watch）的產品，同時還能維持所有系統正常營運。該公司的客戶群有Facebook、Pinterest、CNN、Instagram等。

如果必須不斷修復所有八個系統的漏洞，那麼公司的發展只會嚴重拖累，鑒于此Quip很捨得在資料蒐集和軟體設計方面投資。

例如，Quip用自動生成數據序列碼完成許多例行程序，經由Protocal Buffers讓資訊能夠自動以網路程式語言寄給在地客戶，并同時傳送給JavaScript的設計師。如果使用的是語言特定數據結構或是JSON，反而會使溝通平臺既乏味又容易出錯。

Quip網羅了一組資深團隊，大部分的人擁有六年以上的工作經驗，約一半的人則在圈子里打滾10年以上。公司幾乎不用花時間訓練員工，也較能避免犯錯，還能快速完成網路版面測試A/B Testing或其他系統監控，畢竟這已經是第二、三遍執行該程序了。

工具的好處能夠日月積累，在Quip，透過許多工具讓公司發展地更快速。例如，將漏洞聚集起來的儀表板、審查應用軟體情形的工具、分析符碼與抓取普通錯誤的掛鉤以及一些能夠自動處理例行任務的程式。公司也設有內部工具，它讓Quip與客戶之間的溝通更方便，我們總能在短時間內回覆每位客戶的提問。

Quip有堆積如山的待審和改進清單，但時間和資源卻非常有限，因此勢必要避免做白工，“認清我們不要做的”就和“做我們該做的”一樣重要。在這方面，客戶的意見回饋很珍貴。在A/B Testing中，Quip努力將意見分化成較細且可測的眾多假設，藉此辨識出哪些是不必要的設計。

寄信和開會是工程師典型的溝通方式，所以Quip決定不採行這兩樣做法，只有在遇到緊急狀況才會寄信提醒同事。另外，每週只招開一小時的全體員工集會，彼此分享工作進程或是做一些demo等等。比起開會，Quip更傾向于設定議題，如此便能聚焦事件，并迅速結案。

在日常的溝通里，當然用自家設計的的文件檔案、列出任務清單、顧客意見和進行交流。也替Pager Duty、Zendesk、Twitter、GitHub等打造類似的內部溝通系統。

例如，若有位推特使用者貼了一則@QuipSupport的訊息，Quip就會掃瞄公司里的推特頻道，并找出問題癥結，最后向一位Quip工程師確認該錯誤是否為新型漏洞。由于信件中的訊息很容易遺失或阻絕，反觀Quip的文件能夠輕易地在團隊中轉貼，每份依附在文件夾里的評論和討論也都保有歷史紀錄，隨時查看都不成問題。

文章來源：機房監控 http://www.28ut.com