2015-11-02-04-一个问题引发的思考

今天下午发生了一件有意思的事情，整体啊上来讲，我觉得大家还是需要共同提高沟通能力。

事情经过

下午同事小L在群中留言说到问题：进入“信访大厅”的时候，需要先登陆。

当我收到此反馈后，我首先打开项目代码，看了看配置文件，确定”信访中心”模块配置了登录入口。于是我产生了疑问（有登录配置，那就是可能存在配置无法生效的bug？）。

针对此疑问我询问小L：进入”信访大厅”的时候，有没有登录界面弹出？

小L：退出程序后，重新进的时候，没有登录。

此时，我上面的疑问没有被打消，反而多了新的疑问（小L说的没有登录指的可能是：1、进入”信访大厅”，登录界面没有弹出？2、退出app后再次进入，用户不再处于登录状态，后台登录失败？3、是不是小L的手机处于非联网状态，导致程序启动时后台登录失败？）。

从上述3点之中，我挑出了可能性大的第2点继续跟问：清理手机内存，确保完全退出app后，启动app后是否登录正常？

小L回复：登录的，结束应用并清理内存了，从个人中心中看到用户处于登录状态。但是没有默认登录。进”信访大厅-> 网上信访”之后，就需要实名认证。如果先点”预约挂号”，之后进”网上办事”，就不需要再次实名认证。

此时，问题已经更一步发散，没有中心点，我觉得没有必要再通过聊天来解决此问题了，于是请小L有空时通过电话来联系我进一步讨论。

电话沟通，定位问题本质

不久后，我收到电话，通过电话对问题一一落实，终于弄明白整个事情的来源：用户在”信访中心”模块进行了实名认证之后，再次进入其他模块（”网上办事”）时，又需要再次实名认证。当实名认证过的用户，app启动后首次进入”信访中心”也会再次弹出认证，但是当用户进入了”预约挂号”模块之后，再次进入”信访中心”就正常了。

通过此时我得知的最新信息，我在脑海里过了一下，觉得整个前面的问题其实都是为了说明一句话：在”信访中心”实名认证过的用户，进入”办事指南”后，又需要用户再次做实名认证。

我在电话中和小L将我的理解再次完整说了之后，我们终于取得了对问题一致的理解。

问题明确后，接下来是推测问题原因。

问题原因分析

小L的分析是：客户端给服务器没有传送相关用户信息，加上可能还有session连接超时的问题。所以需要客户端小Q先调查一下问题。

于是我问小L：需要着重调查哪个点？

小L：客户端没有传用户登录信息给服务器？

我：据我所知，客户端唯一需要传递给服务器的就是用户的信息id。此id作为用户的唯一识别符号。我简单做一下分析，觉得先不需要小Q来做调查，因为问题症结的点应该从之前商量的接口中找：登录成功后，客户端会从服务端拿到用户的信息id，此id会被认做用户标示，在登录相关模块后就被传送到服务器做识别。在此接口下扩展的业务点，无非就是两种可能性：

1、客户端没有传递信息id给服务端。

2、服务端没有获得了信息id，但是根据id查询用户实名认证状态错误。

解决方法

根据上面分析，我们做如下安排：

小L安全服务端监测客户端上传的用户信息id是否正常，如果正常，就根据id来查询用户的认证状态十分正常。同事客户端做一件事件，在登录”信访中心”模块的入口处，检查上传给服务端用户信息id的有效性。

同时，为了方便调试，客户端将用户信息id打印出来，以便服务端调试跟踪使用。

结果，我在加入调试信息的过程中，按照小L的操作，很快就发现了客户端首次进入”信访中心”模块用户信息id传递为空的情况。定位到了这个点，下来我就叫上小Q一起解决问题。几分钟很快就解决了。

总结

• 沟通和理解。

跟对方聊天的时候，尽量将Context（上下文）带上，有了语境，双方就容易对问题达成一致的理解。

问题的描述也不要太发散，否则会用翻倍的事件来收敛这个过程。

• 文档和规范。

文档就是一种多方协同的标准，跨越了时间和地域的制定。对于模块之内高内聚，对于模块之间松耦合。此原则对于客户端和服务器同样适合。

当遇到问题，先从需求文档、技术文档、业务文档等之中找寻答案。

• 解决问题。

对问题进行再描述，定位和思考的过程也就是问题解决的过程。真正等问题都想明白了，真正动手去解决它，也许花费时间并不长。

• 进一步思考。

团队中每一位成员沟通、思考、归纳整理能力的提高，都会间接推动团队协作效率上一个新的台阶。

好的协作度就是公司机器运作的润滑剂，推动并缩短了产品迭代的周期。竞争力由此产生。

持续地消灭信息壁垒和沟通屏障，让个人能动性充分发挥在创造的过程，而不是被动地陷入维持和护理状态。我们团队的生命力就可以更强，更持久。

加油！