远程协作是一个听起来很酷的词，就像谈恋爱一样，听起来总是觉得它和浪漫一词相关，但实际进行起来却由于各种原因感觉不是那么浪漫。那么，我们这次就来分享一下远程协作过程中的浪漫和苦闷，以及我们在两者之间的取舍。

远程协作，我们也把它叫做“云办公”，好处是自然可以想象：

节省办公室租金（ HR 曾好几次跟我说公司办公室位置不够了，把我从这个地方赶到那个地方。）

工作环境自由/高效/免打扰（云办公的含义是，你可以选择任何地点进行办公，不一定是要在家里，可以在办公室，也可以是咖啡厅甚至酒吧，去此时此刻任何让你感觉到舒服的地方，只是无论你去哪里，你的同伴都很可能还和你保持“远程协作”。）

节省路途时间，可以拿来工作，也可以拿来陪家人（我们组有一个同事就是因为家里太远了，每天可以节省 3 小时来回时间，在家办公更适合他）

更有可能招到更好的人才（有不少人才因为地域的限制而被放弃，这是非常可惜的。我们的设计师就是因为在杭州，不需要到上海来才加入。）

那么，在这些“诱惑”之下，我们是如何在工作中保持持续的跟踪和反馈的呢？我们使用了一些很酷的在线工具！

我 们团队麻雀虽小但五脏俱全，全端工程师、设计师和产品经理全部齐全。因此，在做一款基于 Web 的产品方面是一个比较齐全的组合，不需要借助多少外界，四个人凑合在一起，除了干活就是沟通。各自隔离开来，是为了干活更高效，沟通也是为了干活更高效， 只是殊途同归。沟通和隔离，本来是相互矛盾的，只是借助在线工具之后，两者的矛盾程度降低了，在某些方面反而相互促进了（比如在需要用文字表达的时候，相 互隔离又保持一起在线可能会更高效，更容易让大家专心思考并无障碍的表达自己的观点）。

首先，前期需求的沟通。 我们花了大量的时间（大概两三天）来寻找一款好的远程语音或者视频通话工具，最好是兼具屏幕共享的。体验过太多类似产品，以至于我们发现很多该领域的创业 公司。网络带宽条件越来越好，移动端的兴起，以及浏览器技术越来越先进，导致该领域涌现大量的创业公司，比如最近被 Slack 收购的 Screenhero，远程视频会议领域之王 WebEx 出的新产品 Cisco Spark 等等。最后，我们选择了 Skype，它在语音通信质量方面胜过其它国外的同类创业公司。我们另一个远程团队使用的是 QQ 语音，效果也不错，只是我们一开始没有尝试。该领域的其它产品包括 sqwiggle、Room、Moxtra、Talky 和Kato。

其次，需求文档的撰写和矫正讨论。 文档共享方面我们有很多方式，因此也有很多选择。比如，你可以以文件的形式共享在 Dropbox 上，也可以提交到 Github 上，当然 Google Docs 的形式最好，可以共享编辑和添加注释，只可惜被墙了。最后我们选择了没有被墙，在产品体验上也更好的 Quip，这是 Facebook 前 CTO 创业做的一款产品。这款产品一改古老的 Docs 风格，不以分页的形式展示文档内容，在编辑和在线沟通等体验上都好过其它产品，是我们的最佳选择。国内的同类产品叫石墨。

再次，设计稿的共享。设计稿的共享也有很多形式，最简单的就是使用 Dropbox 这种工具来同步，也可以发到 Slack 上去。我们使用了在线白板系统 Frontify，可以在线对共享稿的细节进行勾画和讨论。

然后，项目管理。Trello 无疑是整个项目管理的中心，产品的规划、任务的分配，都在 Trello 中记录。只可惜我们团队的开发不是很规范，产生的内容没有多到任何细节都覆盖，因此在 Trello 上只是零散的记录一些关键功能的开发，以及视觉走查和功能走查的 Bug。为了保持 Trello 的整洁而不会杂乱无章，我们把设计稿和需求文档的讨论放在别的更专业的工具上（Quip 和 Frontify），只在 Trello 上贴这些相应资源的链接。使用 Trello 管理的重点不在于添加内容并消灭，而在于分解工作、约定规则和常规工作流程，并严格执行。在这方面 UserVoice 有一篇文章值得参考 How We Use Trello & Google Docs to Make UserVoice Better Every Day: http://community.uservoice.com/blog/trello-google-docs-product-management/

最后，琐碎沟通。 就像七牛早期只使用 Gtalk 进行沟通一样，Slack 取代了 QQ 成为我们最常用的沟通工具。我们作为小团队，在工具选择方面达成一致的代价非常小，并且 Slack 相比 QQ 具有非常明显的优势，比如我们记录了从项目开始到现在为止完整的沟通过程，所有的吵架记录都在。我们使用远程协作，大家在物理上都相互隔离了，它最大的优 势在于不轻易去打扰别人。Slack 作为通知中心在跟踪队友进度方面起到了非常大的作用，这种跟踪是以跟踪者选择性的收取相关信息来进行的，而不是一问一答的形式。我们用 Slack 来收取 Github 的提及记录信息，使用 Slack 来收取 Frontify 上设计稿的更新记录，收集 Trello 上的项目进度信息。

以上，是我们在远程沟通过程中使用的工具，看起来很酷，但如果一个产品的打造过程只由这些冷冰冰的工具组成，那团队不一定能够走到现在，或许早已经解散。

远 程工作的终极理想是解放每个人的生产力，让每个人可以在适合自己的情感和现实状态下尽可能发挥自己的才能完成极其专业性的工作，不必困于一处。但这毕竟只 是理想。团队之所以称为团队，是因为大家习惯了在一起。我们之所以使用这么多协作工具，是因为大家希望保持沟通。对于聚集在办公室的团队来说，这是天然的 优势，他们可以在不满的时候朝对方一笑继续接受之前不满的事实继续干活，而不是不断的沉默让你问一句答一句，抽一鞭走一步。事实上，我们在前期需求沟通的 时候遇到过巨大的困难。

我们遇到的第一个问题是，前期沟通频次控制不够好。 前期我们以为有 Skype 持续在线语音沟通就够了，但是后来发现这样更浪费时间，如果大家都只在自己电脑面前干坐着而没有更多想法，只会浪费时间。我们的改进方案是，各自先做相应 的思考，然后每天不定期进行简短的沟通，达成意见的统一。再后来需求沟通完成后，各自进入具体的工作，每天不定期的沟通就会对大家造成更多不良影响。于 是，我们就开始定规矩，每天早上 10 点准时开早会，时间不定，每天尽量只需要实时沟通一次（其它琐碎的事情在 Slack 上沟通）。除了早会之外，每周一 10 点准时到公司开周会。项目进行到后期，工作上的内容大多可以通过在线沟通解决，但周会的意义在于保持组员见面联络，让大家在情感上感觉到这个团队的存在和 使命。

其次，文字的沟通容易吵架。Slack 虽然有丰富的表情，但跟 QQ 和微信不一样，不太符合中国人的习惯，作为技术人员，我们在讨论工作事情时候也更习惯于用纯文字进行沟通。有时候如果多方意见不统一，就很容易造成至少两 方在玩文字或者逻辑游戏，打口水仗，情况恶劣的可能会影响大家的心情。这在专业性极强的工作内容中是没有必要存在的，我们无非是为了做一个工程做一款产 品，不是为了显示自己的智商有多高逻辑有多强。为了坚持自己的主观看法而去吵架不叫有情怀，以为对方伤了自己的自尊再去伤对方的自尊不叫出息。假如真的在 文字聊天的时候吵起来了，最有效的挽留办法不是继续为自己“辩护”，而是打开 Skype 或者电话沟通，甚至直接让大家跑到办公室统一意见。当然，这些都只是具体的操作，每个人应该在心里记住的是，我们之所以讨论不是为了吵架，不是为了秀智商 的上限或者下限，而是为了做一款更好的产品。不忘初衷，方得始终。

最后，主动和自觉非常重要。 我们说过远程协作可以不受办公室其他同事的打扰，但却免不了你自己所在环境的打扰，特别是独处的时候免不了自己内心的打扰。比如，有些人特别是 leader 可能会无形中感觉压力大，会感觉恐慌。如果是创业，可能会有意无意关注一些竞争对手，他们可能是真实的，更多情况下是假想的敌人。这时候，主动而自觉的和 队友沟通就显得非常重要。沟通形式多种多样，比如按时完成符合对方预期的工作就是一种很好的沟通，结果即为互动。再比如，工作内容之外生活内容的沟通，很 容易在远程协作团队中忽略，特别是同性之间，物理上的隔离很大情况下就意味着生活内容的隔离。我们需要背靠背的力量，来排除一切干扰，缓解各种有意无意情 况下产生的压力。

Github远程协作

1.github简介

网址：https://github.com/

关键功能

Gist：代码片段的托管。

News Feed：所跟随用户的最新动态。

Issues：事务管理。

Pull Requests：github主要流程。

Unwatch：接受对某个项目的通知。

Star：设置对某个项目的持续关注。

Fork：将别人的项目克隆的自己的用户名下。

Repository：仓库。

SSH：为了使用Github的远程，一般会在本地配置ssh，以避免每次对github的修改而重复的输入github用户名和密码。

sh-keygen -t rsa -C "littlejixing@163.com"（-t：指明所要创建的密钥类型，-C：添加注释）

ssh key：88888

ssh-agent -s：创建密钥管理器

ssh-add ~/.ssh/id_rsa：添加密钥进密钥管理器（这一步可能会有报错“Could not open a connection to your authentication agent”报错原理尚不清楚，如果有哪位高人知道，小弟跪求指点。stackoverflow中有相关解决方案，但试过对于我来说都不受用。我自己的解决方案是使用Git GUI生成ssh key进行提交，后续操作亦可进行）

id_rsa中的密钥至github中的ssh key，关联本地git和github账户：ssh -T git@github.com

2.远程协作的主要命令

git clone： 获取一个远程仓库。

git fetch：获取远程仓库中的所有分支和数据，但不更改本地仓库中的版本（HEAD，master）指针，如继续操作需要调整HEAD指针（git merge/git reset/git rebase）。

git push：将本地数据推送到远程数据库

git pull：相当于git fetch 和 git merge的和操作

git tag -a v0 -m "tag for v0"：创建了一个tag，但是git push无法将tag推送到远端服务器。

git push --tags：向远端服务器推送tags

git branch -d [分支名]：删除分支

git push --deleted origin [分支名]：删除远程仓库中的分支

git push origin :[分支名]：使用一个空的分支替代远程仓库中的某分支=删除该分支。

吐槽一下吧，在windows系统下用运行git bash真的有好多bug，先说两个如果有同道中人遇到会解决的烦请告知于我，不胜感激。

命令行运行过多后，会出现结果无法显示的情况，需要执行clear清屏后才会恢复正常。

当一条单行信息过长而无法显示完全，将会出现输入异常bug。

3.github的pull request流程

pull request流程（github远程协作的关键流程）

fork操作：用户a觉得用户b的仓库A不错，同fork可以将仓库A的当前版本到用户a的名下。

git clone：用户a将fork至自己名下的仓库a下载至本地。

git push：用户a对仓库A进行若干修改和完善的操作后，提交至自己的远程仓库。

pull request操作：首先进行自主的差异比较，然后create pull request将自己的修改发送给用户b。

merge pull request：如果用户b觉得用户a提交的pull request没有问题，则可进行提交。

用户b如果有异议也可留言告知用户a。

获取所fork的远程仓库的最新版本

git remote add [所fork的远程仓库别名] [所fork的远程仓库地址]

origin 自己账户的远程仓库（有push权限）

所fork的远程仓库 （无push权限）

链接: https://fly63.com/article/detial/99