摘要：本文是对如何制定团队沟通协作的方法的一些思考，适用的团队大概应该在10-30人左右，最好focus在一个产品上，和业务团队有一定地理或者部门距离，不能完全坐在一起工作。
公司各团队间的沟通协作
在管理创业团队的这几年随着团队从纯技术人员组成的开发团队到有市场和业务人员形成的Fully Functional的小公司，最大的感受就是沟通问题的重要性在不断提升，不同的职能背景的出发点往往不同，在开发看来理所应当的事情不一定在市场和业务团队是一样的结果，异地工作的团队就会更加加剧这个问题，尽量设置良好的沟通机制是其他所有协作的基础。
与公司业务人员和销售人员的协作
及时沟通和反馈我们做的是一个跨国产品，大部分用户在海外由业务和客服处理，但是有任何问题都第一时间反馈在公司对应的群组里。这样开发团队尝试介入快速解决，提升用户的体验，如果不能解决也能了解问题发生的用户场景，对开发团队来说比过后冰冷的bug report要体验更深，更有修正的动力，正如YC Startup的《如何做出用户喜爱的产品》里提到Kayak会在开发的办公室放一个客服电话，不过那个极端了点，但可以理解一点。
参与业务流程设计有时候我们对用户知道收集反馈，数据化用户行为来优化，但对自己的业务人员反而不关注或者参与太少。
这 里我的教训就是曾经对一个稍微复杂的线下销售业务流程，我们按照标准的工单追踪模型开发了一整套，但由于实际业务人员使用同类销售系统的经验并不丰富，不 知道如何提需求，最后工单追踪模型开发出来业务人员都觉得用起来很麻烦，增加了很多沟通成本才勉强用起来很简单的功能，开发的时间和业务的时间都浪费了。
后来在新的业务流程里，我们尽量设计很简单的流程，然后让业务人员去使用，然后反馈，开发团队在业务的反馈中再加入流程支持，虽然刚开始难用一些，但一开始订单量也小，有足够流程优化的时间。
周期性会议一定要记会议纪要，并且全员共享会议的内容会分享给整个团队，让大家都知道一周的focus在哪里，有哪些问题正在讨论和解决，更好的协调大家的目标。
我 们的实践是每周开一次所有部门负责人的周会，周会前在Google Doc上准备一个会议记录，主要准备目前正在focus的工作，上周完成的工作，需要讨论的问题和下周准备做的工作。其中上周和本周要完成的工作都是从任 务管理系统Redmine里直接把相应的主要任务项复制过来。对于会上讨论的内容及时在项目管理系统上都开出相应的任务项进行追踪。
我自己是比较反对频繁开会，蛮浪费时间的，但对于跨地域协作的团队来说又是没办法的。
与产品开发团队内部的协作
产 品思路的共享有时候PM会抱怨功能和需求改动无法让开发有效配合，其实大家都是为做产品好，如果每个决定都是透明的，让开发团队知道关于产品和功能来源的 思考过程，用户角色和场景是什么样的，功能的解决方案构思又是怎么来的，开发团队不仅会全力配合，更有可能提出更佳的方案，不要吝啬这个解释的时间。
产品运营数据的共享产品所有运营数据统计工具的账号密码在项目的Wiki内共享，让开发团队可以看到自己的工作和产品之间的正反馈能激发团队的斗志，如果数据不够理想，我想这样的机制也能给运营和开发团队压力，是一个互相激励的过程。
周会纪要的共享跨地域的团队最担心的就是缺乏沟通的开发之后两边重心和步调不一致造成的损失，全公司的周会纪要对开发团队共享能让公司每个一线开发人员也知道产品目前的进程和focus的点。
日常沟通工具
微信微信是整个公司使用的最多的沟通工具，因为产品，业务和客服都需要用微信和用户沟通，方便快速直接的解决问题，但微信缺点也是很明显，一是没有云端聊天记录搜索，二是不方便贴代码。合适业务去实时沟通，并不适合产品开发过程中的即时通讯需求。
Slack 我们为了保证国内和国外都可以使用，之前尝试过Gtalk,Telegram，都还不错，不过直到Slack的出现，实在太杀器了，聊天记录的搜索和贴代 码这两个问题解决以后还通过Channel和集成插件提高协作的效率，我相信有很多文章来介绍各种实用的技巧。
我这边举两个我们正在使用的例子安利一下Slack:
1.服务器异常报警建立一个#Monitor的Channel，服务器运维和相关人员可以订阅，由Slack集成New Relic和其他服务器监控程序，每当有服务器警告或者网络问题，得到报警之后，运维可以及时通过Slack了解，在Channel里告诉大家影响及预计修复的时间。
下图就是个New Relic警告和修复的例子：
2.有新版本发布到测试渠道建立一个#Publish的Channel，业 务和测试人员可以订阅，由Slack集成持续集成平台Jenkins和测试App发布渠道Fir.im，当有新版本发布的时候，自动向Publish发送 新版本更新通知，省的一个个去通知，和持续集成的流程共用就可以实现一键完成发布和通知。下图为现在Fir.im的新版本提示：
Slack丰富的API可以保证有更多的玩法可以自定义自己的开发和沟通流程，我们并没有太多时间探索，希望以后可以尝试。
后记
总结起来觉得虽然理论上看起来都比较简单，不过实践起来确实没有那么容易，比如让业务人员尝试使用Slack这件事我就一直没有完全的实施起来，需要找到足 够的痛点让业务人员和开发人员一样享受自动化带来的好处，这和让用户使用新的产品一样是一个需要摸索和不断尝试的事情，所谓路漫漫其修远兮，吾将上下而求 索…
哈哈.....说到异地，哥突然想到了那遥远的异地恋，这如何做好沟通跟创业是一样儿一样儿的。
IT朝5晚9