本文面向分布式环境下企业级应用的实施过程中，Onsite实施团队和Offshore研发团队之间的有效协作。大家可以想象这样的场景：实施人员部署研发团队提供的服务到客户现场，在部署和试运行过程中难免会出现这样或那样的问题，这些问题有非技术的也有技术的，而实施团队通常无法处理类似技术方面的问题，这就需要实施团队和研发团队之间进行有效协作确保问题得以解决。所以这是一个发现问题、解决问题的过程，由于是在分布式远程环境下，沟通不畅给问题的发现和解决带来了正常研发过程中所无法想象的挑战。本文对上述场景下如何应对协作过程中的困难提几点思路并对工作展开的有效模式进行探讨。
一.几点思路
保持敏锐：对实施而言，一个细微的、不起眼的、不影响使用的问题，日后可能造成大错，且很难排查。所以实施过程中没有问题是小问题保持理性：对于那种诡异的错误，真的有那么巧吗？通常不会，因为程序的事情实际上很简单，不是对就是错保持平衡：不要过于追求完美，要在完美和时间之间达成一种平衡保持勇气：在现场，勇气第一。遇到困境，一时想不到妥善的处理方法，不如直接动手做，或许会柳暗花明缩小范围：现场问题不外乎应用服务器（Tomcat、Jboss）、数据源（数据库和接口）、UI相关（无响应/页面操作逻辑）、和网络相关（WIFI/与服务器的局域网）的问题安排顺序：遵循帕累托法则，尽量做到频繁发布，注意跳出问题的死循环二.Log的重要性
Log的作用是解决问题，至少定位问题。Log通常会涉及到服务端的功能，但客户端同样也是需要日志管理的一大方面，因为往往客户端界面上出现的页面操作逻辑性问题更加难定位，而且难于调试，所以要尽量把客户端的用户操作行为记录下来作为发现和排查问题的一个突破点。下面看关于Log使用上的两个示例，这两个示例都在是实际实施过程中碰到的比较典型的问题：
问题1：报表的访问，获取数据慢Log：报表后台平均需要500ms的时间去获取
关键词：响应时间 缓存
解决方案：记录日志，利用AOP 或Filter，配置统一的接口性能跟踪找到性能差的接口，通过引入缓存后，平均为30ms
问题2：现场环境报表列表显示错误
Log：Log显示返回的数据有特殊字符，导致前端数据处理错误
关键词：特殊字符
解决方案：通过在前端代码中加Log功能后，发现数据有特殊字符，增加一段特殊字符的处理代码
三.数据源是基础
这里数据源泛指数据库、接口、第三方服务等各个方面，在企业级应用中，数据库视图等是广泛使用的一种数据集成方式。数据规范化是快速实施的前提，实施难度上通常不是因为技术上的问题而是沟通、协调上的问题，所以我们的思路有以下三点：
提供规范文档，一些最基本的字段只要通过掌握通过数据库查询，即可解决问题梳理接口诊断方案，对实施过程中容易出现的问题有方法和流程进行快速定位准备接口Checklist，确保接口开发人员对照Checklist中所有的规则和注意点完成开发工作，在完成Checklist的对比之前不能将接口开放出来
四.开一张好票
团队中通常会使用一个Ticket系统作为问题跟踪的基础，开票指的就是现场实施团队往这个系统中添加一个Ticket作为研发团队的输入。
开票前的思路是：用户为什么提出这个要求（管理用户的期望值）；用户什么时候需要问题的解决/解答/完善；我如何把关（管理团队的期望值）。开票之后，再回过头看看：用户的意图表达清楚了吗（input）；具体的要求表达清楚了吗（output）；别人能看懂我的描述吗；项目上的轻重缓急表述清楚了吗。
五.再论工具的作用
在我们一个项目的开发实施过程中，现场实施团队问题反馈数量为34个，需求优化18个；而研发团队服务发布数量为ipa包22次，war包9次。如何有效的管理这些需求和服务发布，工具是必要的。除了上文提到的Ticket系统外，我们使用OneNote进行现场环境信息的实时同步，使用Jenkins进行客户端ipa包和服务器端war包的自动化构建以及版本控制，这些工具都为确保过程的正确性和高效性提供了保障。
六.信息透明性
信息透明的方法论是：对内信息100%透明；对外信息选择性透明，但一定不能100%透明，效果示例图如下：
要做到信息透明，关注以下几个方面：
保持记录：很多问题，通过重启tomcat和数据库等，就能解决。但是，一定要记得把问题记录下来用户参与：对用户而言，如果有计划，按计划同步信息；如果没有计划，按功能同步信息；如果有条件，用户参与部署明确的团队成员角色、统一协作平台、每日例会和需求梳理会议、发挥开发人员主动性等思路和工作方式都能提高分布式环境下信息传递的透明性
七.小结
本文是对项目实施过程中一些团队协作方面的总结，关注发现问题、解决问题的思路，内容比较零散但一些思想和工作模式应该是通用的。
