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

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