职场中被拒绝帮助的为什么总是你

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