解决问题有技巧，看项目中技术负责人的经验分享

老张在看项目周报，周报中写了上一周的工作完成情况，下一周的工作计划。当老张看到其中关于技术问题哪一部分的事后，上面列出来密密麻麻的十几条技术问题，老张作为项目经理虽然对技术细节不清楚，可通过对其中问题的描述过程来看，觉得其中有一些不对劲的地方。

这个项目的设备刚刚上线不久，其中出现一些问题是在所难免的，设备部分涉及到终端应用、中间件平台、后台服务等多个模块，而这些模块分别由不同的团队负责开发和维护。当出现问题的时候，各个模块负责人均声称自己所负责的系统没有任何问题，那问题是从哪儿出来的呢？

老张把技术负责人找过来，“这些技术问题不能再拖下去了，你把各个团队负责开发和维护的人员叫到一起，给他们做个集中培训和问题讨论，再这么各自为战是解决不了这么多问题的。”

技术负责人接到老张的任务，这么多的技术问题对自己来说也是一个很大的压力，但一个人毕竟精力有限，必须要尽快把压力传递下去，技术负责人根据自己的经验准备了一些问题处理思路的总结和心得体会，准备在会上说出来。

欣尧对于设备上面的平台应用开发采取的是业务外包的模式，当然也有一些欣尧自己的工程师参与进来，面对下面各个业务模块的工程师，技术负责人开始了一天的培训。

“解决问题的第一步是需要详细了解问题的现象和产品架构，把各个模块的分工明确清楚。比如现在这个应用就分为客户端、中间件、后台服务三个模块：客户端提供用户操作界面和结果展示；中间件负责数据传输；后台服务提供业务处理，各个模块之间的分工非常明确。”

“接下来就是找到最有利于定位问题的突破口，这个突破口最好是问题发生的模块，只要仔细检查其输入和输出的结果，就很容易判断问题的来源。比如技术问题列表中，有一个客户端有时上传文件失败的例子，很明显，将客户端作为突破口将是较好的选择。当然，有时候开发团队的配合程度也是考虑的因素之一。”

“如果能够在集成环境下直接跟踪问题的源头，那问题还是很容易定位的，但更多的时候是没有这种环境的。这时候，详细的日志记录将会帮你很大的忙，那么客户端开发人员在问题相关的地方，通过编写代码来生成详细日志，有了日志，接下来就是重现问题，并获取日志进行分析，定位故障原因。当然这中间还有可能因为日志不足以定位，那就需要增加日志记录。”

“最后就是通过日志来定位问题，商定解决方案。拿着这些日志，可以直接与中间件或其它业务模块进行直接沟通，不需要去做过多的推诿，中间件一旦根据日志明确了哪边的问题后，接下来大家一起来讨论解决方案，根据开发工作量，输出短期方案和长期方案。”

培训完成后，技术负责人就开始让大家按照解决问题的思路来对技术问题进行逐一处理，技术负责人统一进行协调，避免了各个业务模块处于问题的拖延和扯皮，经过一段时间的处理，这些技术问题一个个的被解决了。

通过此次技术问题的处理，老张和技术负责人总结了一下项目管理过程中如何去考虑这一部分技术风险的应对：

• 对于项目中的开发人员，当出现问题的时候，就算对自己的代码再自信，也要先自证清白，然后才能说自己的东西没有问题。只有正确的态度，才能尽快地解决问题。自证清白的方式很简单，通过日志（文件、抓包等）明确输出/输出信息的正确性。
• 对于项目管理人员，出现问题时，不要轻率听信任何一个模块的判断，除非他们已经自证清白。定位问题时要能找准突破口，对于定位问题中出现的困难，要能平心静气的处理，特别是要尊重和鼓励开发人员。
• 欣尧公司采用合作外包方式进行软件开发，这已经是一种惯例，但合作人员容易出现变动，这对项目中产品的开发和维护都会造成一定的影响，在项目人力估算的前期或在项目管理过程中，加强对关键人员的培养和备份，会大大改善技术问题带来的风险。