6 加餐（二） | 工作遇到不懂的问题：何时可以求助，如何正确提问？
你好，我是乔新亮。上周末，咱们专栏编辑找到我说，有一位 2020 年毕业，刚刚入职两个月的热心读者正被一些问题所困扰，希望征求下我的意见。
问题大致如下：工作时，经常遇到不懂的事情，大部分是技术相关的问题。想要提问，却不知道什么问题能问，也不知道怎么问比较好，担心别人因此质疑自己的工作能力。长此以往，工作效率低下，有时整整一周，手头的项目都没有进展，领导问起来都不知道该怎么回答。
我看了之后有些感慨，技术新人刚刚离开学校，有这些困惑很正常，因为提问终归是一件很麻烦的事儿：你一定不想问些过于简单的问题，那样会被人看低和讨厌，是基本能力匮乏的体现；但又不能不问，迟迟解决不了的问题，会让你在周会上更加尴尬，对个人成长也大有影响。最好的情况是天生牛人，3 岁就会写代码，独立解决一切问题，但这不可能。
类似问题又不一定是“初学者”才会遇到 —— 我曾遇见过许多“不会提问”的人，他们有的是程序员、架构师，有的是技术经理、技术总监，几乎遍布整个职级体系。令他们疑惑的可能不是技术问题，但“不会提问”的本质却始终没有改变。
因此，在争得当事人同意且不泄露隐私的前提下，我想基于这些年来的所见所闻，谈谈自己的看法和心得。
我麾下的管培生如何提问
遇到什么问题可以求助，如何更恰当地提问？我认为，原则上讲，任何问题都可以用任何方式提问。这里没有法律规定或道德限制，每个人的行事风格也不同，并无对错。就像*同志说的，不管黑猫、白猫，捉到老鼠就是好猫。
但无论是我自己，还是我所认识的技术大牛、技术管理者，都比较讨厌不加思考、张嘴就问的人。我们不妨换位思考一下，如果是你自己频繁遭遇这种情况，情绪上的不耐烦倒在其次，更深层的感受是：自己的时间和精力都没有得到尊重。
至于那位同学所说的，“整整一周都没有进展”，又有点矫枉过正。根据我的观察，如果技术新人花了一整天都没解决掉一个问题，那么大概率就是解决不掉了，要及时提问，避免造成项目延误。
那么答案就呼之欲出了：工作遇到不懂/不会/不明白的问题，一定要提问，但要思考之后再问。
这里就涉及到两个关键点：提问之前如何思考，以及思考之后如何提问。2015年-2019年，我在苏宁担任技术副总裁，期间曾经带过一名管培生做架构设计，他的提问就让我印象比较深刻。（注：管培生，即管理培训生（Management Trainee），是一些大企业自主培养企业中高层管理人员的人才储备计划。通常是在公司各个不同部门实习，了解整个公司运作流程后，再根据其个人专长安排。）
刚入职时，他的提问技巧也比较初级，因为我总是会反问他：关于这个问题，你是怎么想的？为什么要这样思考？如果答得不好，我就会批评他。
几次三番后，他逐渐养成了比较优秀的提问习惯：
- 永远带着白板和白板笔，随时准备将别人的答案融入自己的体系内；
- 半汇报半提问，提问一定带有属于自己的观点；
最重要的是，围绕架构类的工作内容，他学会了按照固定的模式提问：
- 当下有哪些待决策的问题，影响了哪些业务？
- 谁或哪个部门提出了这些问题？
- 其他人有哪些解决方案上的建议？我们认为存在哪几种方案？
- 方案一、方案二……分别有哪些优势和劣势？
- 我们建议选择哪种方案，会带来什么样的影响？
对于架构师来说，这其实是个经常用到的标准模板。而后，如果中间某一步出现模糊、不确定、不理解的情况，才是提问的正确时机。
以上关于架构方案的提问，没接触过的同学可以再琢磨琢磨：这些其实是将做技术决策需要经历的思维步骤细化，并公示出来了，这就是思考的样子。如果更进一步，脱离架构问题的限制，上升到更高、更广的维度，你或许就能学会如何正确提问。
思考是提问的绝对前提
对于绝大部分技术问题，在横向维度上，我自己一般会按照如下步骤去思考和做决策：
- 将复杂问题拆解成足够细化的模块；
- 针对每个模块，判断自己是否有足够能力实现；
- 根据拆解情况和实现方式，制定一种或多种技术方案；
- 对一种或多种技术方案进行快速而谨慎的验证；
- 用财务思维考量技术方案背后的成本和效益；
- 对技术方案的选择、实施进行决策。
在垂直维度上，各个步骤的难度又有所不同，我一般将其分成三大维度来理解：
- 初级问题：一般都是纯粹的技术实现问题，只是复杂程度不同；
- 中级问题：复杂度上升，开始涉及到多模块、多业务部门甚至是跨公司的协调，一般需要经历立项会；
- 高级问题：需要协调多方资源，站在公司整体层面，为公司利益负责而解决的问题。
随着难度、复杂度从初级到高级的提升，思考的步骤和难度也有所变化。比如，对于初级问题来说，拆解的过程并不复杂，技术方案相对单一，涉及财务思维的考量也较少；从中级到高级，各个步骤的难度都在大幅提升，前文我提到的管培生同学的提问，就属于中级问题。
另外，许多技术人晋升管理岗后，感觉部门间充满了推诿、扯皮现象，很烦。但这类现象的本质，其实是问题的复杂度上升了，协作环境没有突然变差，你只是缺乏解决问题的方式。
当思维沿着上述步骤前进，就是思考，在任何一步阻塞时间过长，都可以进行提问，这就是提问的时机。换句话说，思考应当是提问的绝对前提，在没有经过思考的情况下，我是绝不会提问的。
提问时，要将你的思考成果和思维路径说清楚，这就是提问的正确方式。比如你是怎么理解和拆分这个需求的？如何评估拆分后的可实现程度？具体是哪里出了问题？这样，对方会感觉你是有备而来，尊重他人的时间，不是伸手党，更愿意解答你的问题。
不过，我个人很少在工作中询问基础技术问题，比如编程语言的问题、某个库或类的使用方法等。我建议大家也要尽量靠自己解决，用好搜索引擎和知识产品，很多问题是可以被勤奋解决的。
夸赞、请客以及开会
掌握了上面的提问方法，就能得到别人的诚心教导吗？以我的亲身经历和观察来看，意外还是经常出现。
这类意外大多可以形容为“三言两语就被打发掉了”。对方有没有真心教你，其实提问者心里往往最清楚。可能是因为企业文化出了问题，或是因为大家都太忙了，总之，就是没人愿意认真解答你的问题。
如果你刚刚走到思考的第一步，在问题拆分阶段就被难住了，愿意帮你的人可能就更少。原因也很简单：通俗地说，这等于你根本摸不到头脑，对工作任务完全没思路，教起来肯定也更麻烦。
当然我们也不是完全束手无策，有一副见效慢但成本低的药方叫做：成为“夸夸党”，长期维护同事关系。比如，当你阐述完自己的思考，又得到了解答时，要适当地夸夸别人：“哎呀，我思考了这么久，你这么快就解决了，你太厉害了！”
更行之有效的方法是请客吃饭，维护好同事关系，适当地进行社交活动。技术人往往不擅、不喜社交，其实特别吃亏。年轻时，我也从不主动请人吃饭，最近几年才意识到社交的重要性。
当然，我从不觉得以上夸赞、请客都是虚情假意、别有用心。别人为了帮助你确实付出了时间，能够解答你的问题的人，确实要更厉害，那你为什么不去表扬表扬别人呢？
另外，我觉得为了寻求知识而请人吃饭更像知识付费。许多朋友都还年轻，没什么社会资源，不能为他人提供更高维度、更有价值的利益交换，你能做的仅仅是请人家吃个饭。换个角度讲，年轻时，工资都不高，也别太在乎钱。除开孝敬父母的部分，剩下的为知识而付费有什么不好？
如果有人指责你是在拉帮结伙、巴结领导，也不要太在意。任何行为都可以被赋予各种意义，我相信，只要你内心确实以学习为目的，随着时间的流逝，事情一定会回到本来的模样。
随着能力的提升，当你开始遇见中级乃至高级问题时，还可以通过召开会议来提出问题。在会议上提出自己的思考，组织大家发表建议和想法，就技术方案进行讨论，是一种更有意义的学习和提问方式。
当然，如果你认为他人应该为你解答问题，应该帮你跨过技能门槛，这一切是理所应当的，我也无话可说 —— 部分优秀企业确实具备这样的企业文化，乐于助人也确实是优秀的文化传统，张嘴就问也能过得不错，这是事实。
但我不会选择做一个“伸手党”，至少这对个人成长极其不利。另外需要注意的是，如果你缺乏独立思考的能力，多半无法通过优秀企业的面试，谈何企业文化。
结语
说了这么多，我觉得有必要最后重申一下：世界上没有能够适配任何场景的标准答案。客观来讲，任何时候、任何问题都可以提问，甚至不存在合理性的问题。
但我更愿意遵循以上提问方式：基础的问题自己解决，有难度的问题思考后解决，用为知识付费的态度来请人吃饭。
因为这一切都有一个基本的前提：将时间线拉长，站在整个人生的高度上， 用宏观视角看待当下。
当视角拔高，我发现这种提问思维对自己未来的职业发展大有好处，足以使自己受益终生；相反，他人的非议和金钱上的开销则不太重要，因为从长远看来，非议会消失，金钱的损失则微乎其微。
希望这些思考也能对你有所启发，从而更快、更好地迈上人生的下一个台阶。
