工作中我们会遇到各种各样的问题，有时你被卡在某处，非常迫切的想要某人帮助你，可对方问东问西就是不愿意帮助你。这是怎么回事呢？
为什么没人愿意帮小倩
小倩是一名很有经验的测试工程师，她想在缺陷管理系统中针对某个软件项目做一个配置，为每个Bug添加必填的一个自定义字段，可试来试去就是做不到。
于是她打开百度，搜索答案。她花了一天时间，换了14个关键词，翻看了400多页搜索结果，也没找到自己的问题该怎么解决。
第二天一大早，小倩来找后台服务开发组的小黄帮忙。小倩和小黄工作交集比较多，关系不错。
小倩：“小黄，帮我看看缺陷管理系统呗，有个重大问题。”
小黄：“那系统是开源的，不是我做的呀。”
小倩：“可你是做开发的呀，对软件比我熟悉，帮我看下，问题可严重了，只有你才能搞定。”
小黄：“可是我根本不熟悉那个缺陷管理系统啊。”
小倩：“看一看么，看看就熟悉了。”
小黄：“我这手头上有个急事，老顾让我改的广告系统，明天必须要上线，我还没弄好呢，等我弄好了再说。”
小倩：“那你什么时候弄好广告系统？”
小黄：“明天吧。”
小倩：“那我明天再来找你啊。”
▼
过了一天，小倩来找小黄，没找见，问小远，小远说，小黄请假，去云南旅游了。
小倩心里埋怨小黄不靠谱，可没办法，问题还得想办法解决，于是她就想请小远帮忙。
小倩：“小远啊，你能帮我个忙吗？”
小远：“什么事情，你先说说看。”
小倩：“也不是什么大事儿，就是缺陷管理系统，我想——”
小远听到“缺陷管理系统”几个字，打断小倩的话说：“缺陷管理系统啊，我不熟悉啊。要不你问问你们经理乔娜？那是她搭的系统，她最熟悉了。”
小倩不是没想过问乔娜，可是自从“乔娜抢了她的经理位子”后，两人关系就比较尴尬，她怕乔娜这次会因为这个问题瞧不起自己。她也想过问测试组的另外两个同事，可她们两个都刚进公司没多久，问她们又显得自己水平不够。
▼
小倩回到工位，又试了两个小时，还是没搞定。琢磨了一阵子，她决定去问乔娜。
小倩：“乔娜，方便吗？帮我看个问题。”
乔娜瞥了小倩一眼，小倩感到这一眼里满含深意，她心想只要乔娜说一句不好听的，自己就立即怼回去。
乔娜：“方便。什么问题，你说，只要我知道的，一定和你一起研究。”
小倩：“就是个配置。”
乔娜：“什么配置？”
小倩：“缺陷管理系统的配置。”
乔娜：“缺陷管理系统的什么配置？”
小倩：“Bug字段的配置。”
乔娜：“你要配置什么字段？”
小倩察觉出乔娜的语气有点儿不善，心里莫名升起一股怒火，脸上有点挂不住了。她摆摆手说：“你不愿意帮忙就算了，我自己搞定！”
说着，小倩转身走了。
乔娜看着小倩的背影，摇了摇头。
▼
小倩先后找了3个人，非但没能得到有效的帮助，还落了满肚子的气。
然而实际上，问题并不在她请求帮助的对象身上，而源于她请求帮助时犯了两个基本的错误：
- 没有找到合适的人来问。比如她问小黄、小远就不大合适，虽然他们是研发，但并不熟悉缺陷管理系统。
- 没有说出具体的请求。 小倩问乔娜时，迟不迟没有说明她遇到的具体问题，使得乔娜一次次的询问，最终弄得不欢而散。
小倩的这次求助，是一个反例，实际上，只要我们找到合适的人，并说出具体的请求，一般都可以获得帮助。
下面我们逐一分析一下。
找到那个对的人
遇见问题，只有请求知道答案的人的帮助，才能最快解决问题。所以，我们首先要做的事情就是——搞明白谁最可能知道答案。
比如小倩遇到的缺陷管理系统配置问题，搭建缺陷管理系统的乔娜，就是最可能知道答案的人。而小黄、小远，则是不大可能知道答案的人。
那么怎样才能梳理出可能知道答案的人呢？
最基本的方法，就是利用技能和经验来匹配。
这种方法要求你熟悉团队内、公司内各位同事，了解他们擅长什么、做过什么。然后，分析你的问题，看看是哪个方向的，找到与这个方向契合的同事。
假如你自己找不到合适的人，也可以直接请教上司。上司的知识面，往往比你要宽一些，很可能知道你所不知道的一些东西。
再退一步，如果上司本人不能提供直接的帮助，他也有能力推荐合适的同事给你——因为他更了解自己负责的团队成员的情况。
这是寻找合适的请教对象的三种方式。
回顾小倩的求助过程，她在找最可能知道答案的人这一环节，出了问题。如果她能放下自己心中对乔娜的芥蒂，很可能就会在第一时间得到帮助，而不必等到小远来告诉她。
说出你的具体请求
找到合适的人之后，在请求帮助之前，一定要：分析你遇到的问题，具体化你的请求，使得你一说别人就能明白问题是什么。
如果我们的请求模糊不清，别人就不知道我们想要什么，就无从入手帮助我们，甚至会因为无法评估要付出多少努力而选择回避。
比如小倩找小黄帮忙，一直不说问题是什么，只说问题很严重，这样子小黄就很为难——因为不知道问题是什么，就无法判断自己能不能解决、需要花多少时间来解决，所以小黄就只好婉拒小倩的请求。
再比如小倩找乔娜帮忙，乔娜问了三次，小倩都没能准确描述自己的问题。
既然具体化请求如此重要，那怎样才能做到呢？这里有两个要点：
- 界定问题
- 拆解出方便回答的小问题
首先，要界定问题是什么。以小倩的问题为例，它可能是下面的哪个？
□ 自定义字段怎样设置为必选
▼
假如小倩的问题是第一个，那至少有两个解决方向：用自定义字段或者修改默认字段的名字。这需要小倩先做一些尝试，然后再来决定走哪条路，怎么求助。
假如小倩的问题是中间那个，那就是缺陷管理系统的配置问题，熟悉系统的人可以帮她解决，或者她查阅帮助文档也可能解决。
假如小倩的问题是最后一个，那可能就还有其他的解决办法，比如规范作业流程、引入激励机制。
大家可以看到，不同的问题，解决策略是不一样的。假如你弄错了问题，就没办法找到你想要的答案。
▼
界定完问题，接下来就是要评估问题的大小，如果问题比较大，那就进一步分析，从大问题中拆分出阻碍你前进的小问题，向别人请教这个（些）小问题如何解决。
像 “如何给Bug设置一个非标准的必选字段”这个问题，就可以进一步分析。一分析你就会发现，有两种方式可以实现：自定义字段和默认的必选字段。再接下来可以一一实验，有一条路通了，问题就解决了。
假如两条路都走不通，那就先选择某一条路，拟定问题，请求帮助。比如小倩研究后发现，默认的必选字段是全局的，修改后会影响缺陷管理系统中的所有项目，只能通过自定义字段来实现，那她的问题就演变成“如何给Bug增加一个必选的自定义字段”。
这个问题，又可以拆分成两步：增加自定义字段和设置自定义字段为必选。小倩很熟悉自定义字段，那她的问题就变成了“自定义字段怎样设置为必选”。这就是一个非常具体的问题了，她可以拿这个问题，去请教乔娜或熟悉缺陷管理系统的其他人。
关于如何具体化请求，我们再举一个开发新人小杜的例子。
老顾分配了一个Bug给小杜解，希望他通过解决这个Bug，快速熟悉项目。
小杜领命去做。
过了半天，小杜来找老顾，期期艾艾地说：“老顾，我不知道怎么做。”
老顾说：“什么不知道怎么做？”
小杜挠挠头说：“就是，有点无从下手的感觉。”
老顾说：“什么叫无从下手？”
……
▼
小杜遇到的情况，是很多开发新人都会碰到的：拿到一个任务，根本不知道如何下手。但如果你采用小杜这样的求助方式，那遇到质询就是很自然的事。
首先他的请求——“我不知道怎么做”，真的是非常模糊，被请求方，根本不知道他遇到了什么问题需要什么样的帮助。
所以必须要先界定问题，看看自己的问题是什么：
- 不了解这个Bug怎么回事
- 不知道这个软件的开发环境怎么搭建
- 不知道这个软件的测试环境怎么搭建
- 不熟悉业务，理解不了软件的应用场景
- 不知道如何重现Bug
- 不知道找谁确认这个Bug
- 不知道怎么用git拉取代码
- 代码编译通不过
- 编译出的程序跑不起来
▼
可能很多人遇到像小杜这样的问题，一下子就懵了，想不出来第一步应该做什么，更拆分不出来方便回答的小问题。
这往往是因为没有建立起分析问题的框架或缺乏经验，不知道怎么“破题”。此时可以稍作调整，以获取框架或流程为第一个阶段的问题。
比如小杜可以问老顾：“老顾，咱们解决Bug的一般流程是什么？”
这样老顾就可以告诉小杜：“先和测试人员确认Bug的具体情况，接着确认代码版本，然后拉取代码，尝试修改代码解决Bug，自测，提测新版本……”
小杜得知这个做事流程后，就可以先做第一步：与测试人员确认Bug。
此时如果这第一步，小杜还有各种“不知道”，就比较容易拆分出很多具体问题，比如编号9527的Bug该找哪个测试？怎么在缺陷管理系统上查看Bug？
带着这些问题去找人问，就很容易获得帮助。
小结：做好两步，快速获得帮助
现在我们知道，要想获得别人的帮助，一定要最大限度地降低别人伸出援手的门槛。
所以，当我们在工作中遇到各种各样的问题和障碍，需要请人帮忙时，第一步，一定要自己先动脑思考，准确界定问题。
第二步，把大问题拆分成别人方便回答的小问题。
带着已经分解好的问题，找到拥有相关知识、技能和经验的人来问，这样成功的概率就会大大提升。
暂无评论，点击讲两句