负责产品内容的人该怎么与开发者合作？

您的工作是负责网站或 app 的内容吗？是否需要经常与设计师、产品经理或工程师合作呢？过去两周，非死book 产品设计总监 Julie Zhuo 写了两篇文章 〈 写给产品经理与工程师：如何与设计师一起工作 〉、〈 写给设计师：如何与产品经理一起工作 〉，告诉大家「产品开发」的三大支柱（设计师、产品经理与工程师）之间要怎么合作。

　　而另一位曾任职 Apple、非死book 的 Nicole Fenton 这篇 〈 Working on Content with Developers 〉 则是谈负责内容的人该如何与开发者一起工作。Nicole Fenton 在 非死book 的工作既不是产品经理也非工程师，而是负责「content strategy（内容策略）」，小至用字遣词，大至网站内容的产生、管理与消费。（有兴趣的读者可以参考这个访谈，听 Nicole Fenton 谈自己在 Apple 跟 非死book 负责的工作与相关经验。）

　　以下就是 Nicole Fenton 给负责内容的人要怎么与开发者合作的建议：

　　如果您要负责产品的内容，那么就必须与开发者密切合作。这表示您的工作不仅只是传递文件而已。您必须了解开发者、与他们沟通、一起工作，您负责为他们的工作（写程式）做好准备。毕竟，产品开发的过程一定会影响产品的表现。

　　我先勾勒出几个具体的作法，让您先跟团队试试看；这些建议并非一体适用。一切取决于您自己，就像时尚教父 Tim Gunn 说的：「to make it work.」

　　准备

　　在您开始制造内容之前，先跟团队做好整合。跟他们一起坐、一起吃午餐（或是喝酒，这点取决于你们团队的文化）。看看他们彼此是怎么相处的，然后加入他们。

　　取得工具

　　开发者一般来说都用 IRC 沟通——不管是加入程式码、追踪 bug，或是在测试环境中检视工作成果。询问、取得你们团队所用的工具，让开发者不必迁就于您，工作起来可以更顺手。

　　IRC

　　大部分的开发团队使用 IRC（Internet Relay Chat）来沟通。IRC 是一个持续的聊天群组，不管有没有登入，您都可以加入某个聊天室（编按：但是聊天前要先设定匿称）。

　　要设定 IRC，先询问团队的伺服器位置，请他们协助您。可以下载 IRC 软体，例如 Mac 上的 Colloquy、Adium，或是 PC 用的 Trillian。

　　聊天室的东西肯定很多，您不需要去读全部的内容，重要的是跟团队成员保持联系。

编按：除了 IRC，现在有许多团队也用 HipChat 这样的工具交流，像是 GitHub、Heroku、MailChimp、UserVoice 和台湾的爱料理都是用 HipChat。不过就像 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。挑一本书、动动脑，以下是几本值得推荐的书：

• 《Dreaming in Code》
• 《Getting Real》或《Rework（工作大解放）》（编按：后者与程式比较无关，但非常值得一读）
• 《HTML5 for Web Designers》或《CSS3 for Web Designers》

　　参与社交活动

　　下次参加网路人的会议时，跳过一些您最喜爱的讲者，看看开发人员间的对话。您也可以去找一些同领域人的聚会。

　　做好充分准备

　　要有弹性。内容就像程式码，是流动的。改变您的流程以适应您的团队和客户。运动一下自己属于策略的肌群，像是：

　　下一次产品发表后，总结一下自己是如何看待它的。

• 与您的团队一起分享、调整您的时间表。
• 着手开发前，先理清内容的优先顺序。
• 用草图或是 wireframe 展示真正内容的样子。
• 确保细节不会在「消防演习」中遗漏。

　　跟您的开发团队成为好哥儿们。您对这些关係投注的心血最终会有所回报。平衡沟通、耐心与尊重，你们便能共成大事。

来自: http://www.inside.com.tw/2013/08/27/working-on-content-with-developers