目录
1、问题描述
介绍下工作中你认为比较困难的问题
2、问题分析
大部分技术问题没有所谓难不难
我们很少做技术创新或者技术攻坚,只是应用现有的技术做产品或业务,因此遇到的问题要么被人都遇到过,要么就是自己使用不当;因此解决此类技术问题无非就是学习技术,找开源,找资料,找牛人。
3、解题思路
那如何理解困难的问题呢
通过遇到的困难,来体现问题难,而不是单纯的技术本身有难度。所谓困难应该结合环境,分为困难2方面:
非技术困难;项目周期短时间紧,人员少,工作量大,多部门协调,设备紧缺等。
技术困难:性能瓶颈,技术本身复杂,场景多,异常处理复杂等。
解决这两个方面的困难需要不同的能力,最考验人的综合素养
4、举例分析
4.1、描述问题
描述问题现象(体现技术难点):设备网络不同,在串口输入ifconfig命令后设备卡死,无任何异常打印,复现概率低。
描述问题背景(体现非技术难点):当时项目快发布,时间很着急,产品线研发总监每天都要求我们汇报进度和讨论。
复现概率能确定问题难易程度,问题再难,只要必现,我一行一行加打印也能解决。
4.2、解决办法
关于技术问题本身:
a、找领导或者专家提供排查思路,吃饭走路都一直在思考排查方案,问题可能的原因。
b、实践:根据思路熟悉程序,找问题点,增加调试接口,数据打印。
c、协调cpu厂家一起讨论,提供思路。
d、找复现规律,提高复现验证的效率,同时也是为排查问题提高线索。
e、解决问题的同时思考规避方案,兜底方案。
关于流程本身:时间太着急,所以尽量自己找领导协调人分工:
a、协调测试同事配合进行测试,我出程序,他测试。测试同事找复现规律,提高复现概率。
b、每天和领导汇报和讨论,太耗费精力,所以每天excel进度记录主动上报;
怀疑点,验证方案,方案实现,测试人员,验证结果,完成时间点。
c、给厂家或者客户提供些方案进行问题排查,主要是让客户忙起来,给自己争取时间。一方让客户觉得我们在全力投入;最重要的是等客户的测试结果,改变客户的行为模式,让客户参与进来,体会到做测试需要时间,一起解决问题;而不是客户什么都不用做,只知道天天催。