負責產品內容的人該怎麼與開發者合作?

您負責網站或 app 的內容工作嗎?是否需要經常與開發者合作呢?過去任職於 Apple、Facebook,負責溝通與內容策略的 Nicole Fenton 針對負責內容的人該如何與開發者合作,提出了一些參考建議。
評論
評論

您的工作是負責網站或 app 的內容嗎?是否需要經常與設計師、產品經理或工程師合作呢?Facebook 產品設計總監 Julie Zhuo 寫了兩篇文章 〈 寫給產品經理與工程師:如何與設計師一起工作 〉、〈  寫給設計師:如何與產品經理一起工作  〉,告訴大家「產品開發」的三大支柱(設計師、產品經理與工程師)之間要怎麼合作。

而另一位曾任職 Apple、Facebook 的 Nicole Fenton 這篇 〈 Working on Content with Developers 〉 則是談負責內容的人該如何與開發者一起工作。Nicole Fenton 在 Facebook 的工作既不是產品經理也非工程師,而是負責「content strategy(內容策略)」,小至用字遣詞,大至網站內容的產生、管理與消費。(有興趣的讀者可以參考 這個訪談 ,聽 Nicole Fenton 談自己在 Apple 跟 Facebook 負責的工作與相關經驗。)

以下就是 Nicole Fenton 給負責內容的人要怎麼與開發者合作的建議:

如果您要負責產品的內容,那麼就必須與開發者密切合作。這表示您的工作不僅只是傳遞文件而已。您必須了解開發者、與他們溝通、一起工作,您負責為他們的工作(寫程式)做好準備。畢竟,產品開發的過程一定會影響產品的表現。

我先勾勒出幾個具體的作法,讓您先跟團隊試試看;這些建議並非一體適用。一切取決於您自己,就像時尚教父 Tim Gunn 說的:「to make it work.」

準備

在您開始製造內容之前,先跟團隊做好整合。跟他們一起坐、一起吃午餐(或是喝酒,這點取決於你們團隊的文化)。看看他們彼此是怎麼相處的,然後加入他們。

取得工具

開發者一般來說都用 IRC 溝通——不管是加入程式碼、追蹤 bug,或是在測試環境中檢視工作成果。詢問、取得你們團隊所用的工具,讓開發者不必遷就於您,工作起來可以更順手。

IRC

大部分的開發團隊使用 IRC(Internet Relay Chat)來溝通。IRC 是一個持續的聊天群組,不管有沒有登入,您都可以加入某個聊天室(編按:但是聊天前要先設定匿稱)。

要設定 IRC,先詢問團隊的伺服器位置,請他們協助您。可以下載 IRC 軟體,例如 Mac 上的 Colloquy、Adium,或是 PC 用的 Trillian。

聊天室的東西肯定很多,您不需要去讀全部的內容,重要的是跟團隊成員保持聯繫。

編按:除了 IRC,現在有許多團隊也用 Slack 這樣的工具交流,像是 GitHub、Heroku、MailChimp、UserVoice 和台灣的愛料理都是用 Slack。不過就像 Nicole Fenton 在一開始的時候說的,不一定所有人都適用,選擇自己跟團隊使用起來最順手的工具就對了。

Issue tracking system

Issue tracking system 可以協助您的團隊管理、排定任務(task)的優先順序。請熟悉團隊使用的系統,以便搜尋、發表、指派和結束任務。要是您負責的內容被當做一個「bug」,請不要覺得被冒犯了。

測試環境

測試環境顧名思義就是為了讓我們在開發過程中測試產品,讓您看到開發中的產品是什麼樣子。每個團隊用的名字都不一樣,例如 staging、build 或 QA 等等。

請確保自己手上有最新版的產品(網站、app 等),這樣才能掌握產品的開發,您或許會需要開發者協助您安裝最新版的 app 到您的手機,或是在瀏覽器上變更 proxy 設定。

學習開發者的「語言」

花時間弄懂團隊的開發哲學和語匯。如果您的團隊採用的是敏捷方法(agile methodology),那麼您就必須了解他們的行話。大部分的 geek 說話其實跟一般人一樣,但是如果您懂他們的術語,就可以節省大家的時間。

同樣的,學著寫一點程式不會怎麼樣。對程式有些基本了解,對您理解產品、產出更實際的內容很有幫助,這對您個人和團隊都有幫助。以下是一些關於團隊參與的建議:

  • 請團隊為您做一次產品如何運作的概述。
  • 學習基本的 HTML 和 CSS,那並不難,別怕。
  • 搞清楚團隊用的後端技術是用哪一種語言開發,並且去認識它。
  • 看個 15 分鐘的 Rails 或 Python 線上教學影片。
  • 跟團隊聊聊他們各自負責的工作有和不同,他們是工程師?程式設計師?還是開發者?

試著去理解他們怎麼看世界、他們是如何熱愛自己的工作。

同步

清楚的溝通是關鍵。請為忙碌的 product owner 做好榜樣,讓團隊保持聯繫。(編按:product owner 是 scrum 開發流程的角色,負責與使用者群體接觸,並決定產品釋出時應具備哪些功能。)

出席

會議對寫作者來說是毒藥,開發者也不喜歡。但如果團隊有每日例行會議或是中午有團隊聚餐,那麼請把這些事列為優先事項。如能參與其中,將會知道產品的開發是如何幫您在開始準備內容之前就避免掉不良的決策。

如果您不用 CMS(內容管理系統)作業,那麼您的內容對開發者會是種麻煩。如果可以的話,直接坐到開發者旁邊跟他們溝通,省去為內容版本做確認的時間。沒錯,開發者很注重細節,但是確認大小寫、標點符號與格式是您的工作。

共享目標與點子

您的表現反映出團隊的「健康」,如果您肯花時間一起討論您的目標和點子,產品也會跟著進步。

弄清楚團隊想做的是什麼,去了解團隊面臨的問題,同時確定他們明白您的計畫,以下這些問題可以協助你們一起研擬工作計畫:

  • 客戶或 product owner 的預期是什麼?
  • 使用產品的過程中,什麼對使用者而言是最重要的?
  • 這個頁面或區塊存在的目的是什麼?
  • 接下來的二到六週要做哪些功能?
  • 產品最難開發的是哪一部分?
  • 有哪些潛在的限制或考量?(例如:政治考量)

不像一般生產線式的團隊,開發者的工作是以客戶或 product owner 的優先事項為主,他們專注的焦點可能每天都在變化。在產品開發之前,先完成產品中內容最困難的部份,並且避免在開發過程中不斷更改。團隊會因此感謝您的超前思維。

軟體開發是充滿創造力的過程;開發者是從無到有把東西打造出來。請尊重他們的時間和專注力,對於彼此都滿意的工作時間與方式達成共識。

填補裂縫

身為一個專業的溝通者,填補成員與大型團隊之間的裂縫取決於您。您的聲音代表著客戶;您是連結組織;您的工作是用字彙為這個世界帶來 愛與 和平與和諧。為了整個團隊,講清楚整個專案的目標、使用者需求,以及那些最重要的細節。如果您無法闡明問題所在,還有誰可以呢?

發聲

必要時,挺身捍衛客戶和自己的工作。

清楚、簡潔

無論您要回報一個 bug 給團隊處理,或是改善更好的使用者體驗,想清楚您要如何表達,並且給出清晰、簡短而具體的指示。

制定一個有彈性、可重複的流程

詢問團隊該如何協助他們的工作,可以的話提出一套標準流程。

製作模板

請那些要求為產品增添內容的人給予所需的資訊:

  • 為什麼我們需要這個內容?
  • 誰是受眾?
  • 這個內容要放在哪一頁?
  • 哪些人會看到這個訊息?
  • 哪些國家或地區會受到影響?
  • 要傳遞的訊息是什麼?
  • 這是優先事項嗎?

這個結構能夠讓您在東西容交給開發者之前,先充實好內容。

將要求具體化

在您要交付一項與內容相關的任務給開發者前,先看看是否包含以下項目:

  • 網頁名稱
  • 適用的網址
  • 要替換哪些東西的指示
  • 螢幕截圖

花時間組織好細節會省去之後確認內容更改的麻煩。

使用友善的格式

確認您的內容是不是可以很容易轉換成程式碼。如果是網頁或 E-mail,我通常會用文字編輯器直接編寫嚴謹的 HTML;如果是原生 app,我會為 app 的每一頁製作包含下列項目的文件:

  • 頁面名稱
  • 有必要的話附上螢幕截圖
  • 內容(例如介面的標籤、連結、正文)
  • 基本的標題格式(例如 h1、h2、h3)
  • 寫給審查者看的筆記(例如專案負責人、法務)
  • 相關錯誤訊息和警語

一份清楚的文件可以加速專案負責人的審核速度,並且釐清一些開發團隊的小問題。當您的內容通過審核,準備放到產品中,記得張貼到整個團隊的資源庫或團隊用的維基頁面,避免用 E-mail 來傳遞任何重要的訊息,以免在混亂中被漏掉了。

勇敢地對不佳的內容說不

無論是來自何人,別害怕對不佳的內容說不。如果內容令人混淆,請與團隊做好溝通,並儘快解決問題。這對於製作(網站或 app)導覽系統、格式、錯誤訊息和 CTA(calls to action)來說特別重要。

更上一層樓

當您的基本供熟練了之後,試著更加積極地參與開發者社群。認識開發者們可以提供您關於商業運作更多面向的觀點,避免您對產品開發做出假設。

做自己的專案

您可以學習 CSS,或是做一個無需整合伺服器端的 Rails app。挑一本書、動動腦,以下是幾本值得推薦的書:

參與社交活動

下次參加網路人的會議時,跳過一些您最喜愛的講者,看看開發人員間的對話。您也可以去找一些同領域人的聚會。

做好充分準備

要有彈性。內容就像程式碼,是流動的。改變您的流程以適應您的團隊和客戶。運動一下自己屬於策略的肌群,像是:

  • 下一次產品發表後,總結一下自己是如何看待它的。
  • 與您的團隊一起分享、調整您的時間表。
  • 著手開發前,先釐清內容的優先順序。
  • 用草圖或是 wireframe 展示真正內容的樣子。

確保細節不會在「消防演習」中遺漏。

跟您的開發團隊成為好哥兒們。您對這些關係投注的心血最終會有所回報。平衡溝通、耐心與尊重,你們便能共成大事。

歡迎加入「Inside」Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數