精华内容
下载资源
问答
  • 对于产品的提问
    2021-02-01 20:13:35

    问题的定义:

    提问的时候,首先要发现问题,如何发现问题,需要定义问题。

     

    提问问题是对学习思考后的产物 再提问题过程中 可以和解答者对问题有更深的认识。也可以作为对学习的校验和扩充

    有提问能力说明在积极主动思考,很多时候提出一个问题比找到答案更重要。

    很多事情都是通过不停提问题而越来越明确

    侧面反应了思考能力和思考的深度

    提问能力是思维,立场,表达能力的集合

    提问问题反应的是一个人我对这个世界的理解,一个看世界的视角,所以能够提出比较好问题的人说明对世界的理解有自己的模型和思考。

    提问是梳理我们认知世界的方式和角度最快的方法,向别人提问,向自己提问。

    好的提问包含了自己的思考,也能促进别人思考

    提问的过程其实就是思考的过程,对问题的探索

    提问能力的基石是理解能力,这基于逻辑、见识、联想和展望。不能提问,多数原因是不理解,或者以为自己理解了。

    主要分为两点,第一是会促进提问人的自我思考意识,有了自我思考对问题本身的印象也会比较深刻。第二是让提问者可以更加了解事情的根本,只有对事情有一定的了解,并且有了自我思考以后,才有可能提出问题。

    从大的角度看,不论科学还是哲学,提问的问题体现出认知的边界,人类最重要的科学或哲学问题也就是人类的认知边界,认知边界不是物化的,没有实体,所以知道一个领域的认知边界也就是知道这个领域的最前沿的信息了。

    从产品和商业的维度看,问题本身就体现出对现状的思考和理解深度,新的想法和问题才能带来新的机会。Think different!

    先发现问题,才能提出问题。所以换句话说,有这么两步:

    1、如何发现问题----这是个智商问题;

    2、发现问题后能否敢于提出问题,或者说如何有效提出问题----这是个情商问题。

    所以,提问题的能力归根到底是对智商和情商的双重考验。

    因为问题本身就是一种对思考的引导:

    1、问题来源于事实与解释之间的不一致性。

    2、提问意味着你看到了不一致性,这可能是因为你看到了事实的新的角度,或者你调整了看事实的范围,或者你发现了新的事实。

    好的提问需要抓重点,能够抓住重点表示你理解问题本身,思考深度和认知都到位,是一项非常重要的基础能力,我是这么理解这个问题的

    有一本书专门回答你这个问题,《学会提问》,这也是我推荐的产品经理入门必读书。

     

     

     

     

    更多相关内容
  • VDA6.3提问

    2015-04-28 08:26:06
    1)PV 过程责任;(2)ZI 以目标为导向;(3)KO 沟通;(4)RI 以风险为导向;(5)阴影部分提问:具有产品和过程特殊风险的带“ * ”的提问;(6)带“ ** ”的提问:在潜力分析(P1)范围内至少要提问
  • MKT中兴优招提问.docx

    2020-07-23 15:27:32
    2020年6月,MKT-技术产品岗位提前批,专业面和综合面,面试问题整理合集。适用于西安的产品岗位,可以用来参考
  • 之前参加过几次会议,也有观众现场提问,问到关于产品经理的一些问题,相对大家比较关注的是“产品经理的职责范围是什么?”,“如果没有技术背景,能不能做产品经理?”,“AI产品经理是不是一定需要有丰富的AI知识...
  • 前段时间在知乎和微博提问产品的商业化一定要破坏用户体验吗?有什么平衡的方法?”。可是得到的讨论和回答比较少,所以今天想总结一下自己的思考。因为我是做工具软件的,不像直接做电商或者门户的,针对产品直接...
  • PAGE / NUMPAGES 百度知道问题提问篇之技巧一 二 一直对于百度的产品情有独钟一来是因为百度的性格如此二来百度的外链的确非常不错尤其是百度知道很多时候一个百度知道链接一天能够给我们10个IP甚至更多的访问量而且...
  • 在知乎和微博提问产品的商业化一定要破坏用户体验吗?有什么平衡的方法?”。可是得到的讨论和回答比较少,所以今天想总结一下自己的思考。因为我是做工具软件的,不像直接做电商或者门户的,针对产品直接的商业化没...
  • Quoradar在quora搜索中, 显示提问的关注人数和浏览量, 帮助在quora上做营销的人能更容易找到有价值的问题.Quoradar允许您在quora搜索页面中查看关注者计数和查看计数,帮助quora营销人员轻松找到有价值的问题。...
  • 产品经理的私房菜 - 腾讯产品模型 - 沟通能力篇

    万次阅读 多人点赞 2021-09-30 17:45:13
    产品经理的私房菜 - 腾讯产品模型 - 沟通能力篇 编辑导语:第三章是关于“沟通能力”的分享。本系列就围绕”腾讯产品的能力模型“,一起从头梳理,每一个能力项的提升思路。希望大家从梳理过程中,找到提升的方向...

    产品经理的私房菜 - 腾讯产品模型 - 沟通能力篇

    编辑导语:第三章是关于“沟通能力”的分享。本系列就围绕”腾讯产品的能力模型“,一起从头梳理,每一个能力项的提升思路。希望大家从梳理过程中,找到提升的方向!(欢迎两位新同学加入~)

    初稿|木深、木小深、小桃桃

    编辑|牟深、丸子同学、Sam、Ella

    一、开场白

    今天想聊的话题是如何提高沟通能力,它本身是一个很宽泛宏大的命题。所以,从小伙伴们的私信里,挑选了3个高频场景:

    1. 求职面试场景 - 有人答不好面试题,还有人终面后被莫名其妙pass(u_u)…
    2. 工作协调场景 - 总是项目延期,被质疑能力不够(-_-)zz
    3. 向上汇报场景 - 明明很累,但是不被主管理解,还没有年终奖(T_T)/~~

    所以基于这3个高频场景,我们结合腾讯产品经理能力模型,针对性地给到了部分实例(目前可以公开的):

    1. 面试场景 - 腾讯云面试实例
    2. 协调场景 - 腾讯产品项目的流程
    3. 汇报场景 - Google产品经理实例

    好啦,开场白就到这里了,接下来是腾讯模型能力的拆解环节。

    二、执行能力的4档标准

    基于腾讯产品经理能力模型,本系列第三章沟通能力篇,重点分享“沟通能力”相关内容。

    2.1 初级

    考察要素:

    • 良好的主动沟通意识,能够准确理解和被理解。
    • 具有良好的沟通意愿,多数情况下都能够有效倾听和理解对方。
    • 能准确无误、简练的表达自己的观点,能够进行简单的协调。
    • 能够主动跟产品团队内成员进行有效沟通,确保产品目标的顺利达成

    行为标准:

    • 提交过往一年中组织的跨部门沟通协调会议纪要及后期的目标达成情况报告

    2.2 中级

    考察要素:

    • 主动沟通协调,有效开展工作。
    • 总能准确无误、逻辑清晰、简练的表达自己的观点,准确的领悟对方观点,并能引导对方沿着自己的思路展开交流,挖掘客户的显性和隐性需求;
      当工作出现问题,总能积极的想方设法去寻求帮助,协调工作群体中的其他成员共同解决问题,使工作正常进行。

    行为标准:

    • 提交过往1年中组织的跨BU沟通协调的会议纪要,解决的主要矛盾
    • 总结并提交在组织跨BU合作过程中使用的方法技巧及取得的效果等

    2.3 高级

    考察要素:

    • 良好的沟通协调技巧,讲求方式方法。
    • 掌握并运用有效沟通的基本原则和技巧,如事前知会事中沟通、协调,事后汇报,使得工作在团队或跨团队中协调进行,达成共同目标。
    • 能够善于因人而异,采取针对性沟通方式方法。经常能够通过有效沟通和协调解决别人感到难以解决的问题,沟通能力受到周围同事普遍认可。

    行为标准:

    • 提交过往1年中主导的复杂项目任务,并举证其中采取的沟通策略执行方法及有效解决的主要矛盾和问题、对目标达成的影响和贡献
    • 提交相关业务部门负责人的评价

    2.4 专家

    考察要素:

    • 惠己及人,重大事件和问题有效沟通和协调。
    • 与团队分享有效沟通和协调的经验和方法,带动团队沟通协调能力提升。
    • 能够跟上级及投资人进行有效沟通,通过有效的客户价值来传达产品的理念,协调各方资源,从而确保产品Ideal的实现
    • 对于突发或复杂问题,能够协调公司的稀缺资源,促成有力的解决方案。

    行为标准:

    • 举证过往沟通协调公司中的事件的总结报告
    • 举证过往在帮助团队提升沟通能力方面所开展的主要活动及取得的成果

    三、实际案例

    3.1 面试场景 - 腾讯云面试实例

    分享下19年腾讯产培生的经验,当时在39F,负责人叫“马哥”,他是特好看的一小哥哥,经常给我们带披萨和橙汁。跟着他少走了不少弯路,到这会都特别感谢他~

    说下还记得的案例嗷:

    王xx同学 腾讯云产品岗 - 终面环节

    • 问题:咱俩模拟一个销售场景。你作为腾讯云的产品经理,需要向我销售腾讯云的产品,劝我把在IDC的代码迁移上腾讯云,你会怎么说?

    • 回答:特紧张的模样。先是寒暄客户,然后尬推腾讯云。面试官问到产品特色时,只说了“监控”和“性能”优势,基本是挂了。(这种场景题,最恐怖了。完全不晓得公司产品优势基本就挂了)

    • 经验:面试应注重交流,而非答题这类模拟场景题,不是拍电影,需要你马上开始。我们可以适当的给自己争取些时间,1~3分钟都是会被允许的。缓冲的时间内,可以向面试官“复述题干”来旁敲侧击考点,也可以自己回想腾讯云产品在销售侧的真实情况。(面试前,至少弄明白产品的主打功能和目前优势,没渠道的同学得自己想办法,不然别人有你没有,就被卷了呀)

    孙xx同学 腾讯云产品岗 - 终面环节

    • 问题:假如你是腾讯云的产品经理,需要规划促销活动。已知我们的某款机型,卖A价格时,每月有X用户购买,希望每月有10X用户购买(10倍增长),那么你认为价格应该定为多少?

    • 回答:孙同学贼牛,不愧是心理学博士。面试官给完问题,人直接就卖萌→_→说:“哎呀,你这个问题很难呀。”然后面试官就慌了,就引导她,放轻松没标答,你当这是数学题,综轴是用户,那么价格曲线肯定在第一象限,你认为这个曲线会是什么样子…后面就听不懂了,她很实际的给到了方案,是很成功的一次面试。

    • 经验:通过拆解和分析面试官的问题,了解其问题目标时刻记得谦卑,总有大家不会的领域,大大方方的考虑对方感受,给上自己的专业方案就是很奈斯的表现!值得一提的是,面对提问我们要做到不畏难不瞎扯。不会你就寻求指引,再结合指引,突出自身与之契合的经验。

    陈xx同学 QQ产品岗 - 终面环节

    • 问题1:遇到紧急任务,怎么让同事加班?

    • 回答1:因为我平时人缘好,所以这事会直接说。对方有时间,就可以给他做,并且陪着他完成,体现自己也很重视。

    • 经验1:这题不是问你!它既考察你对公司加班文化的了解程度,又反映了你上家公司的加班文化。这里暂不公开分享,请提前了解意向企业的文化。

    • 问题2:介绍一个你最喜欢的独立APP。

    • 回答2:因为垃圾分类是热点,所以分享一款垃圾分类APP。他有两个特色,一是语音分类,二是类别卡片。巴拉巴拉~

    • 经验2:不要给面试官挖坑!尽量围绕岗位、业务相关领域的APP作答。一个愿意为面试花心思的候选人,可塑性会更强啦。

    3.2 协调场景 - 腾讯产品项目的流程

    这是去年五月份写的文章了,详情见:浅析-腾讯产品项目的流程。简单说腾讯产品项目的主体流程划分成了七个阶段,“概念阶段(CONCEPT)”、“提案阶段(PROPOSAL)”、“原型开发阶段(PROTOTYPE)”、“产品开发阶段(ALPHA)”、“内测阶段(CLOSE BETA)”、“正式运营阶段(OPERATION)”和“结项(CLOSE)”。所以,协调这件事可以按这几个维度进一步细分,我们挑重点的说。

    原型开发阶段(PROTOTYPE)

    • 需求的澄清和设计
    • 需求评审大会。评审不是第一步,是最后一步开会前,我们应该和各负责人达成共识,高效通过会议。比如,对接研发组“落实业务逻辑和研发逻辑的一致性”,对接设计组“确定交互思路和视觉主题”。

    产品开发阶段(ALPHA)

    • 成立项目组、PRE-ALPHA版本制作、自测、PRE-ALPHA专家评审、PRE-ALPHA决策评审
    • 正式研发、内测规划及准备、内测上线评审、总体运营规划

    当项目团队人数众多时,产品经理不可能和每个小伙伴都做深入交流。所以需要关联人以及利益对关联人划分优先级,并做好沟通策略。可以通过四维度象限法来做划分,按照关联人在项目中的权利和利益进行分析,然后制定有效的沟通计划,再根据沟通节奏做好项目管理。

    最好能做到每天都有沟通反馈!反馈做得好,可以有效体现你的价值,方便同时了解你的工作进展,开展后续工作。

    项目的协调管理方面,John老师有更详细的分享:和腾讯大佬聊下产品经理如何做好跨部门项目沟通?(图片就是John老师自己画的,是很用心做分享的老师

    以前腾讯移动互联网事业群(MIG)内部常说的,“产品经理是火车头”,这个话其实见仁见智。我理解的PM,类似麦肯锡公司的咨询顾问角色,是做服务的。同理2013年那会,微软先提出的产品经理岗(内部PM岗)。分为两个方向,其中一个偏项目管理职能(Project Manager),是我比较认可的一种。因为本身我们没有大的决策权利,所以在项目组的目标导向下,你愿意主动承担责任,协调各个成员高效的push,自然地大家会信任你,当你是主心骨。而不是,因为你是PM所以大家得听你的,要搞清楚这个理。

    3.3 汇报场景 - Google产品经理实例

    在跨部门沟通或向上管理时,遇到的最大困难的实际案例与如何解决?

    • Google Android 无障碍功能产品经理 Sharlene Yuan:跟不同部门的沟通要用对方的语言去沟通,以同理的角度,对其温情喊话。而对于向上沟通,大家都在同一艘船上,与其说向上管理,不如换位思考老板的需要与担心,使用对方的语言沟通,让老板帮助你一起将产品做到最好。
    • Google Pixel 相机产品经理 Kevin Fu:做沟通时有两个准则,第一个我永远是先问自己为什么,例如为什么沟通上有问题。第二是坦率地沟通,把问题坦率地讲出来。此外,沟通时你要先帮对方回答:为什么你要做的项目很重要?凭什么他要花时间在你身上帮你?最后但同样重要的是,工作上对你批评最凶的人,通常是最在意你、最在意产品的人,因此更要理解他们的想法,这是跨部门的沟通重要之处。

    对于情绪化的同事或上司,要如何应对?

    • Google Android 无障碍功能产品经理 Sharlene Yuan:避免在情绪高涨的尖顶上做任何的沟通。在情绪化的当下很容易会与对方起争执,而那不是一个解决问题的好方法,因此建议等冷静之后再回来沟通。
    • Google Pixel 相机产品经理 Kevin Fu:为什么对方情绪化?背后是什么原因?面对越情绪化的对象,你就要越稳定,并以倾听者的角色,理性地帮他分析。为什么他会有这样的感觉?我可以做什么去解决他的问题?(看得出来,Kevin 再度演绎了「产品经理」角色的能力应用)

    另外,涵小仙女也专门整理过向上管理的内容:如何看待职场中的「向上管理」?(超厉害的作者,是生活、职业双丰收的偶像人儿)

    以上就是今天的分享啦希望大家能够在评论区分享些你们求职、协调、汇报中的沟通小技巧。让我们一起互相种草๑乛◡乛๑

    四、结束语

    《产品经理的私房菜 - 腾讯产品模型 - 沟通能力篇》就到这里啦,希望本系列,可以帮助大家找到方向,积跬步以致千里。加油鸭,下期更精彩,期待你的加入~

    本系列交流群,近期会面向读者开放一阵子,特此感谢勤劳的小助手Ella❤️。记得备注 “进群”。

    如果你有任何问题,请在留言区告诉我们。也请记得订阅公众号木小深和我们的专栏,欢迎分享给其它有需要的人。我们这期分享就到这里了,再见❤️。

    展开全文
  • 匿名报告工具“ ART” ... 另一方面,对于那些遇到诸如以下问题的人们,尽可能多的匿名性可以使该应用程序更安全,更安全。 种族歧视,歧视,骚扰/偏见或工作场所中的虐待。 作为一名贡献者,这个工具是
  • “为什么LabVIEW优于C语言?” 作为LabVIEW产品经理,我被很多次问到这个问题。
  • 只有当组织创建了比较好的体系、流程等,具备有核心竞争力并不断更新持续改进的产品,而不是依靠个人英雄的时候,这个组织才能延续不断的发展,如toastmaster,如EF. 2、团队建设是非常重要的,leader是需要培养的。...

    1、在盈利性组织,管理都是为商业目标服务的,一定要时刻记得,管理的目的就是为了多生产粮食。

    2、团队的目标是什么?你的计划是什么?

    3、团队的top问题有哪些?列时间轴

    你准备在什么时间点,做哪些事情?可衡量的结果是什么?跟踪人是谁?

    4、支撑目标的组织架构是什么?有多少层级的leader,每一层的leader的目标是什么?要培养他们到什么程度?怎么去培养?

    5、团队的例行汇报机制、例行提交机制及集体决策。

    例行汇报机制:谁在什么时间点做什么汇报,向谁汇报?

    例行提交机制:谁在什么时间点提交什么,提交给谁?

    集体决策:双周会的决策结果,向上反馈。

    6、你接手一个团队之后,建立了哪些体系、机制、方法论?

    假设你明天要离职,你怎么交接?

    7、客户团队/项目的判断,哪里是我们的机会?

    客户关系,准备从哪里突破?

    8、争取资源。列出目标、计划、问题点、时间点、跟踪人后,你要向组织争取哪些资源?

    7.15 与老薛沟通DX人员离职问题:

    DX团队近期离职了十几个人,其中有部分是骨干人员。老薛很焦虑,他觉得他不了解员工的需求,于是请人力资源部出一稿员工满意度调查问卷。

    与老薛进行沟通之后,发现了2个问题:

    1、DQ团队并没有体系、流程,之前的交付经理和老客户经理离职之后,团队处于混乱状态。

    与TX团队的有序相比,这个团队显然还是处于急需建设的状态。

    对我的启示是,一个团队只有建立了良好的体系、流程、机制,才能避免对个人的依赖。就像上次在创业者俱乐部,一个做英语培训的创业者,说师资是最重要的。当时有个观众就说,师资是重要的没错,但是一旦某个人的力量强大了,脱离组织的时候,这个损失是组织无法衡量的。只有当组织创建了比较好的体系、流程等,具备有核心竞争力并不断更新持续改进的产品,而不是依靠个人英雄的时候,这个组织才能延续不断的发展,如toastmaster,如EF.

    2、团队建设是非常重要的,leader是需要培养的。

    在与老薛的沟通中,也发现,QX的小组长的职责是35%是在团队稳定与团队沟通上,而DX小组长们反馈的日报80%都是在沟通考勤问题。也就是说,小组长们用在团队管理方面时间和精力都在与员工沟通考勤上,而真正的团队沟通与稳定的的工作,几乎都是没有涉及的。小组长们没有识别到,或者即使识别到,也没有精力和时间去做真正重要的工作。

    小组长们是否明确自己的职责?AM是否对其进行培养与辅导?沟通流程与渠道是否通畅?

    展开全文
  • 提问的智慧/ 如何优雅的提问

    千次阅读 2020-07-30 18:07:31
    提问在学习中占据着重要的位置,很多人对知识好奇,却收效甚少,原因他们是尚未掌握正确提问的方法,因此,我尝试修改《提问的智慧》,发布出来。原作者是Eric S. Raymond,这篇文章在黑客界拥有很高的地位,指引...

      原文How To Ask Questions the Smart Way

      王刚 <yafrank at 126 dot com > 版本《提问的智慧》 

    摘要

    提问在学习中占据着重要的位置,很多人对知识好奇,却收效甚少,原因他们是尚未掌握正确提问的方法,因此,我尝试修改《提问的智慧》,发布出来。原作者是Eric S. Raymond,这篇文章在黑客界拥有很高的地位,指引无数黑客前进,希望对你有用。

    为何要做一个修改注释版?

    试图做出一个容易阅读,方便理解,与时俱进,可以执行的提问执行方案。

      1. 原翻译为2010年,新版2013年,时隔2年有余,原作有变;
      1. 尊重原作的复制及引用协议[1];
      1. 原翻译很好,检查中发现有些语句不顺,语意不准,或者已不符合现在语言规范,参照王刚老师的版本进行修改;
      1. 附上自己的看法和注解,更加适合现在阅读使用。
      1. 每当有人来向我提问,我可以将他指引到这篇文章,可以减少很多的不必要的麻烦。

    【本章注释】

    [1]复制协议中注明了应用该文时不可复制部分或者部分引用,只能全文转载。

    You may not make or redistribute static copies (whether print or online) without my express permission.

    However, I don't like having old, stale versions of my content floating around on other peoples' sites. These rules are mainly designed to try to ensure that when some third party sees my name on a document, the content reflects all my updates to it.

    译文

    译文: 印尼语、 巴西葡萄牙语、 汉语、 捷克语、 丹麦语、 荷兰语、 爱沙尼亚语、 芬兰语、 法语、 乔治亚语、 德语、 希腊语、 希伯来语、 匈牙利语、 意大利语、 日语、 蒙古语、 波兰语、 葡萄牙语、 罗马尼亚语、 俄语、 塞尔维亚语、 西班牙语、 瑞典语、 泰语、 土耳其语。 如果你想复制、镜像、翻译或引用本文,请参阅我的 复制协议[2]。

    【本章注释】

    [2]这份复制协议类似于版权声明,这份声明主要说明了以下四点:(1)你们可以复制此文,可以添加本站链接;(2)但是转载需注明出处,原版本经常更新(已更新11次),转载版本不会更新;(3)不可以部分引用,或拼接此文;(4)翻译要注明出处,并且注明翻译时间和翻译版本。

    免责声明

    许多的项目单位都在在他们的网站附加了帮助的链接,这正是我们想要的。但按照现实情况,如果你是该网站项目负责人,请在链接附近显著位置注明:我们不提供该项目的服务支持!

    我们已经领教了没有此说明带来的痛苦,我们将不停地被一些白痴们纠缠,他们认为既然我们发布了帮助链接,那么我们就有责任解决世上所有的技术问题。

    如果你是因为需要帮助正在阅读本文,还想着直接从作者那取得帮助(答案),然后挥一挥衣袖转身离开,那么你就不幸成了我们所说的白痴之一。别向我们提问,我们不会理你的。我们只是在这教你「如何从那些真正懂得问题答案的人那里取得帮助」的方法。不过,在99.9%的时间里我们不会是那些百事通。除非你非常地确定本文的作者是你的问题专家,否则请不要打扰,这样大家都更开心一点。

    引言

    在黑客[3]的世界里,你所提技术问题的解答很大程度上取决于你提问的方式与此问题的难度,本文将教你如何提问才更有可能得到满意的答复。

    开源程序的应用已经很广,你通常可以从其他更有经验的用户而不是黑客那里得到解答。这是好事,因为他们更能够容忍一般的新手错误。但我们还建议你使用我们推荐的方法,像对待黑客那样对待这些有经验的用户,这样,你能最有效地得到问题的回答。

    第一件需要明白的事:黑客喜欢艰巨的任务和激发思考的好问题。否则,我们也不会写这篇文章了。如果你有值得我们反复咀嚼玩味的好问题,我们自会对你感激不尽。好问题是激励和馈赠,帮助我们发展认知,揭示没有注意的问题。对于黑客,提供「好问题」就是热情而真诚的赞扬。

    虽然如此,黑客在外却有坏名声:遇到简单问题就表现出鄙视或傲慢的姿态。有时,我们看起来还会对新手和愚蠢的人有条件反射般的无礼,但事实并不如此。

    我们只是毫无歉意地鄙视那些提问前不愿思考、不做功课的人。这种人就象时间黑洞一样,只知道索取,不愿意付出,他们在浪费我们时间,而这些时间我们本可用于其它更有趣的问题或更值得回答的人身上。我们将这种人叫做 「loser」[4] (由于历史原因,我们有时将「loser」拼写为「lusers」[5])。

    我们注意到很多人只是想使用我们写的软件,对学习技术细节没有任何兴趣。对他们而言,计算机只是种工具,是种达到目的的手段而已。他们有自己的生活,有更重要的事要做,我们承认这一点,也从不指望每个人都能对这些让我们着迷的技术问题感兴趣。所以,我们回答问题也有自己的选择,仅仅回应那些真正对问题有兴趣并愿意主动参与解决问题的人,这一点现在不变,以后不会变,也不该变,否则,我们就无法做好那些该做好的事情了。

    我们(大多数)是自愿者,从自己繁忙的生活中抽时间来回答问题,有时也会力不从心。因此,(请原谅)我们会毫不留情地过滤问题,特别是那些像是losers提的问题,这样,我们就有更多的时间和精力去回答那些winner[6]的问题

    如果你认为这种态度令人反感、以施惠者自居或傲慢自大,烦请检查你的假设,我们并未要求你崇拜我们,事实上,假如你做了力所能及的努力,我们大多将非常乐意平等地与你交流,并欢迎你接纳我们的文化。我们认为试图去帮助那些不愿自助的人是一件没有效率和效果的事情。所以,我们宁愿被称作傲慢,也不去做愚蠢的事[7]。

    所以,你无须拥有很高超技术也可以吸引我们的注意,前提是你必须表现出解决此问题的积极态度:热切关注、深入分析、试图努力查找过解决此问题的方法,并且乐意主动参与到解决问题的组织,分享你的想法。如果你做不到使你与众不同,我们建议你付费寻求他人帮助,而不是要求黑客提供无偿的帮助。

    如果你决定向我们求助,不想成为一名loser,或者不想被看成一个lose,我们有一个立竿见影的方法:(1)有技术含量地提问,(2)像是一个有智慧有自信和会思考的人那样去提问,(3)暗示这个提问只是碰巧在特别情况出现的。

    (欢迎你对本文进行指正,可以将建议发至esr@thyrsus.comrespond-auto@linuxmafia.com。请注意,本文不想成为一般的网络礼仪指南,同时,我也会拒绝回应引自论坛并与此文不相关的建议。)

    【本章注释】

    [3]本文不仅仅适用于黑客,而且适用于普通人。黑客的态度:解决问题,建设事物,崇尚自由和无私的双向帮助。出自Eric S. Raymond的另一篇著名文章《How To Become A Hacker》

    [4]在此,用直接「loser」更加合适,语意浅点译做「失败者」,语意深点译做「废柴」、「贱人」和「窝囊废」。

    [5]wikipedia的解释:「lusers」为「loser」和「user」的混合词,有贬义,指使人厌烦的,愚蠢的计算机操作员。

    [6]指乐于分享,懂得专研和回报的人。

    [7]人必自助而后人助之,而后天助之。出自《周易·系辞上》

    提问前需要做的事情

    在通过邮件、讨论组、论坛或社区提问之前,请先尝试做以下事情寻找答案:

      1. 使用论坛、知乎、百度知道、Quaro的搜索功能;
      1. 善用google、百度或其他搜索引擎在网络搜寻;
      1. 阅读说明书或者使用手册;
      1. 阅读网站上「常见问题解答」(FAQ);
      1. 自己检查或做试验;
      1. 请教熟悉此问题的朋友;
      1. 如果你是程序员,尝试阅读源代码。

    提问时,请先表明你已做了上述事情,这将有助于改变你是懒又肥的寄生虫形象,同时给别人一种你不会浪费别人时间的印象。提问时最好再总结一下你从中学到的东西 ,我们喜欢那些善于学习总结的人,也喜欢回答他们提出的问题。

    运用搜索策略,比如利用Google搜索时你遇到的各种提示(记得也搜索一下Google groups),这样很可能直接就找到了解决问题的文档或讨论组的相关线索。即使没有结果,在论坛或讨论小组寻求帮助时提一句「我在Google中搜过下列句子,但没有找到什么有用的东西」也是件好事,至少它表明了搜索引擎暂时还不能提供哪些帮助。另外,将搜索关键词与你的问题及可能的解决方案联系起来,还有助于引导其他有类似问题的人。

    耐心一点,不要指望Google搜索几秒钟就能解决一个复杂的问题。读一下与产品或项目相关的常见问题解答。在向专家提问之前,先稍微放松一下,再深入地思考一下问题。相信我们,他们能从你的提问之中看得出你做了多少阅读与思考的准备功课,如果你是有备而来,专家们很有可能会为你解答。如果你第一次搜索没有结果(或者结果太多),也不要抛出一堆问题,专家们更喜欢有针对性的提问。

    认真地思考,准备好你的问题。草率的提问只能得到草率的回答,甚至得不到回答。在提问时,你越是表现出在此前做过思考与努力去解决自己的问题,你越有可能得到真正的帮助。

    注意别提问错误的问题。如果提问基于错误的假设,某黑客多半会一边想「这真是一个愚蠢的问题」,一边按将错就错地敷衍你,并且希望这个结果能够给你一个教训:如果提问的方式不对,你就得不到正确的答案。

    永远不要假设你有资格得到解答。你没有这种资格,毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题,你将通过自己的努力「挣到」答案,因为这种提问能够向社区贡献经验,而不仅仅是消极无止境地索取。

    另一方面,展现你的能力,并且表明你乐意参与解决问题,这是个很好的开始。「有没有人能指个方向?」,「我这还差点什么?」,「我应该查哪个网站?」,通常要比「请给出我可以用的解决方案」更容易得到回复,因为你的行为表明一种积极的态度:只要有人能为我指明方向,我就会很乐意自己走完剩下的路。

    提问时

    认真选择论坛

    谨慎地要选择提问的地方,如果你做了下述事情,多半会被忽视或被看成loser:

      1. 张贴与论坛主题无关的问题;
      1. 在面向高级技术问题的论坛上张贴初级的问题,反之亦然;
      1. 在不同的论坛或讨论小组同时张贴同一个问题;
      1. 向非熟人或没有义务解决你问题的人发送私人问题邮件。

    为防止论坛被灌水,黑客们(论坛管理员)会删掉那些与论坛及主题无关的问题,你不想自己的问题被删掉吧。

    因此,第一步是找到正确的提问论坛。谷歌和其它搜索引擎是你好帮手,当你遇到问题时,它们可以帮你搜索到与问题最相关的网站或者论坛。那里通常都会有「常见问题解答」(FAQ)、讨论组及文档的链接。如果你的努力(包括阅读 FAQ)都没有结果,这些讨论组就是你最后能取得帮助的地方。这些网站通常会有报告bug(错误)的地方或链接,你可以尝试通过这个方式按照指示反馈信息。

    冒昧地向陌生人发送邮件或在不熟悉的论坛发表主题是一件比较「冒险」的事情。你不要天真地以为一个经验丰富的网站架构师会给你提供免费解答,也不要以为你的问题会在论坛中引起巨大反响,除非你很确定这一点,否则还是发送去其他地方去吧,或者最好就别发了。

    在选择论坛和讨论组时,不要被他们的名字迷惑了,先看看FAQ或者版规以明确你的问题是否切合这个论坛的风格。发帖之前先翻翻已有的帖子,感受一下论坛的讨论氛围。事实上,善用论坛的搜索功能将会给带来极大的便利,或者这样你就更容易找到答案,即使没有,这也可以让你更好地表述出你的问题。

    不要像机关枪似的一次性「扫射」所有的帮助通道,这样的行为像泼妇骂街一样令人抓狂,要有重点地一步一步来。

    要搞清楚你提问的主题是什么!最典型的错误就是跑去苹果的论坛问关于Unix或Windows的问题,如果你不明白,最好在搞清楚概念,否则什么也别问。

    一般来说,在公共论坛中提问比在封闭论坛中提问更容易得到有用的回答。选择依据:一是评估潜在的回复数较多,二是估算论坛的活跃度较高,相比之下,黑客更喜欢回答那些能启发多数人的问题。

    同时,你可以理解,一些经验丰富的黑客和流行软件的作者正在承受过多的非议,因为涌入其私人邮箱的垃圾邮件变得越来越多,他们实在无法忍受,同时,你的加入有可能使情况更加恶劣,就像那根最后压垮骆驼背的稻草一样,所以,一些流行软件的作者正陆续停止对软件的更新和支持。

    通过新手论坛和在线客服可获得最快的回复

    本地发行商会为宣传新产品会专门为新手设置论坛或在线客服(IRC)[8],这些地方是提问的好地方,特别是当你觉得遇到的是很普通的问题时。通过专门的在线客服或者公开新手提问专区,一般可以得到实时的回复。

    事实上,如果出问题的程序来自某发行版(这很常见),最好先去该发行版的论坛中提问,再到程序本身的项目论坛中提问,否则该项目的黑客可能仅仅回复「尝试用我们的代码」来搪塞你。

    在任何论坛发帖之前,先看看有没有搜索功能。如果有,就试着用问题的几个关键词搜索一下,这会给你带来帮助。如果在此之前你已做过全面的网页搜索(你应该这样去做),还是应该再搜索一下论坛,搜索引擎有可能还没建立此论坛的内容索引[9]。

    目前,通过论坛或在线客服为用户提供帮助已经成为一种趋势,电子邮件交流方式则更多地为项目开发者保留。所以,新手一般建议在通过论坛或在线客服寻求与该项目相关的帮助。

    【本章注释】

    [8]「IRC」全程为Internet Relay Chat,即时聊天工具,在国内常见的是挂在网页内的QQ客服。

    [9]也有部分论坛会屏蔽来自搜索引擎的爬虫,所以有时候还得在论坛中搜索。

    使用项目组的论坛

    当某个项目组设立有开发者论坛[10]时,要向论坛而不是其中的个人成员提问,即使你确信他能为你提供最好的回答。查看一下项目的说明文件和主页,找到论坛地址并注册使用。采用这种办法有几个很好的理由:

      1. 如果向个人开发者提的问题足够好,他的回答也将对整个项目组有益。相反,如果你认为自己的问题对整个项目组来说太白痴,这也不能成为骚扰个人开发者的理由。
      1. 向论坛提问可以分散开发者们的负担,个人开发者(尤其是项目领导)也可能太忙,以至于没法回答你的问题。
      1. 大多数论坛记录都会存档,那些存档将会被搜索引擎索引,如果你向论坛递交的提问得到解答,将来其他人可以通过网页搜索找到你的问题和答案,那么他们就不用再次提问了。
      1. 如果某些问题经常被问到,开发者可以利用此信息改进说明文件或软件本身,以使其更清晰明白。如果只是私下提问,就没有人能知道最常见问题是什么,也无法建立一个常见问题解答手册。

    如果一个项目论坛中既有「用户」 也有「开发者」(或 「黑客」,而你又不钻研那些高深代码,那就向「用户」组论坛提问。不要以为自己会在「开发者」论坛中会受到欢迎,那些人只会认为你是一个在装逼的傻逼。

    然而,如果你确信你的问题十分特殊,在「用户」组论坛中提问了好几天都没有回复,可以尝试在「开发者」论坛提问。建议你在发帖前最好先潜水一阵以了解那的行事风格(事实上这是参与任何私有或半私有论坛的好主意)。

    如果你找不到一个项目组的论坛,只能查到项目维护者的邮箱地址,可以向其发送邮件。但即便在这种情况下,也不要以为这个论坛是不存在的。在电子邮件中你可以陈述你试图寻找这个论坛的事实,告诉维护者也可以转发该邮件到相关的人员手中(许多人认为,即使没什么秘密,私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人,你给了相应人员处置你邮件的选择)。

    【本章注释】

    [10]原文为邮件列表,邮件列表是论坛的初始形态,以前的论坛是以邮件名称作为联系ID交流,所以,在此篇文章中,邮件列表可视作论坛。

    使用含义丰富,描述准确的标题

    请在论坛中用五十个或更少的字来描述你的主题,这是你吸引专家专家注意力的黄金法则,

    精练的标题是你吸引专家注意的黄金机会,别喋喋不休地用诸如「帮帮我」的标题,这种主题只会被条件反射式地删掉,浪费掉一次提问的机会。不要试图用你深深的痛苦来打动我们,相反,要在讨论空间中使用简明扼要语句来描述问题。

    撰写主题的规则是「对象──偏差」式的描述,许多技术支持组织就是这样做的。「对象」部分需要指明是哪一个或哪一组项目有问题,「偏差」部分则描述与期望的行为不一致的地方。

    愚蠢的问题描述:救命啊!我的笔记本播放不了视频!

    明智的问题描述:X.org 6.8.1 鼠标光标出现偏差,MV1005型号的某显卡芯片组

    更明智的问题描述:使用 MV1005 型号的某显卡芯片组在 X.org 6.8.1 的鼠标光标出现偏差

    撰写「对象──偏差」式的主题描述有助于引发你对问题的细致思考:是什么导致了这个问题?仅仅是鼠标光标出问题或者还有其它原因?只在X.org中出现抑或是在6.8.1的版本中?是针对某显卡芯片组还是或者只是其中的 MV1005 型号?一个黑客只需瞄一眼就能够立即知道你遇到的什么问题和解决方案。

    为了方便索引查找,你需要正确地用标题来描述你的问题,以便下一个搜索类似主题的人能够迅速定位到你的答案中来,无须再发帖提问。

    如果你想在回复中提问,请修改主题名称,以注明你是在问一个问题,例如「Re: 测试」或者「Re: 新bug反馈」这样的信息就不能引起足够的注意,同时,请注意删除与新主题无关的引用内容。

    对于论坛消息,请不要直接点击回复(按钮)来开始一个全新的主题索引,这将限制主题的参与者。例如有些论坛允许隐藏消息,如果你这样做的话,别人就永远看不到你发的消息了。

    有时候,仅仅改变标题还不够。其他的一些论坛还会检查你论坛主题的其他信息,以便为其提供索引,所以这时候宁可重新发一新帖。

    成熟的论坛有一套完善的讨论规则,参与者发送的信息与特定的主题紧密结合,所以通过回复来提问也未尝不可。但并不是所有论坛都允许在回复中出现分支的主题,这样做的结果就是基本上没有人会去看[11],而且通过回复来继续提问是一种成效较低的做法,因为它们只会被正在查看该主题的人看到。所以,除非你只想向当前活跃的人群中提问,否则还是另发新帖比较好。

    【本章注释】

    [10]论坛中经常会出现灌水或者是版聊的情况,一大群人一个主题下你谈你的我谈我的,原主题容易就会被冲散。

    让回答来得更简便一点

    用「请将回答发送到……」这样的方式来提问会使你的问题得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都嫌麻烦,我们也懒得花几秒钟去考虑你的问题。如果你的邮件客户端程序不支持设置,请换一个;如果你的操作系统不支持这种邮件客户端程序,也请换一个。

    实际上,在论坛中,要求回答者通过电子邮件回复你的提问是粗暴无礼的,除非你确定他回复的比较敏感或涉及隐私的(现在的论坛也可以设置「私人可见」的回复)。如果你只是想在有人回复主题时得到电子邮件提醒,可以要求论坛发送。几乎所有论坛都支持诸如「留意本主题」、「有回复发送邮件」等功能[12]。

    【本章注释】

    [12]实际上,目前中国的论坛已很少使用邮件通知回复,只有少数索取资料的主题要求留些邮箱发送而已,大部分的论坛已采用消息提醒的方式来显示回复。

    用字义清晰、语法标准、拼写正确的语句撰写问题

    经验告诉我们,粗心草率的人通常也会粗心草率地思考与编程。回答这些粗心草率者的提问没有什么好处,我们宁可将时间花在其他地方。

    清楚、正确地表达你的问题非常重要。如果你嫌斟字酌句麻烦,那我们也懒得回复。所以,请稍微花一点点时间组织语言,也用不着太正式和死板──事实上,黑客文化提倡使用非正式词句、网络语言和幽默的语句,同时注意在遣词造句的过程中体现文字的准确性和你思考问题的积极性。

    正确地拼写、使用标点和大小写,不要将「its」混淆为「it's」,「loose」搞成「lose」或者将「discrete」弄成 「discreet」。不要全部用大写,这会被视为粗鲁无礼的大声嚷嚷 (全部小写也好不到哪去,因为不易阅读。Alan Cox[13]也许可以这样做,但你不行。)

    一般来说,如果你像个半文盲般来提问,你多半会被无视。也不要使用短信中的简写,如将「you」简化为「u」,这会让你看起来像偷懒的傻逼。更有甚者像个小孩似地用火星文来提问,那就绝对是在找死,真的是喊破喉咙也没有人来理你(或者会有人在围观,并给你一大堆指责与挖苦)。

    如果你在非母语(中文)的论坛提问,你可以犯点拼写和语法上的小错,但决不能在思考上懒惰(没错,我们能看得出其中的差别)。同时,除非你知道回复者们使用的语言,否则请使用英语书写。如果你用黑客看不懂的语言发送提问,繁忙的黑客一般会直接无视并立即除。英语是互联网上的通用语言,用英语书写可以避免你的问题被直接无视。

    如果你要用英文作为第二语言来提问,你可以使用以下的语句来进行说明,降低回答者对你语言使用的不适感:

      1. English is not my native language; please excuse typing errors.
      1. If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.
      1. I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.
      1. I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.

    【本章注释】

    [13]Alan Cox:著名黑客,Linux 内核的重要参与者

    使用易于读取且标准的文件格式发送问题

    本章阅读提示[14]。

    如果你将问题搞得复制难以阅读,它多半会被忽略,人们更愿读易懂的问题,所以:

      1. 使用纯文本而不是HTML格式;
      1. 发送邮件时如有附件,记得添加附件,同时记得检查附件内容是否能正常打开;
      1. 不要发送整段的文字,尝试将文字按主题分段;
      1. 发送数据时应该发送原始数据,让回复者看到的东西与你看到的一样;
      1. 很多邮件程序并不支持「Quoted-Printable」MIME编码,所以谨慎使用;
      1. 不要指望黑客们阅读封闭格式的文档,诸如微软公司的Word或Excel文件等。大多数黑客讨厌这种文件格式。即使他们能够处理,也很厌恶这么做;
      1. 如果你用Windows操作系统发送电子邮件,关闭微软的「引用」功能,以免在你的邮件中出现乱码;
      1. 切勿在在论坛勿滥用「表情符号」和「HTML」功能。使用一两个表情符号还可以,但使用过多的花哨彩色文本会使人认为你无法表达出你的意思。过滥地使用表情符号、色彩和字体会让看起来更傻逼;

    如果你是使用图形界面的邮件客户端程序(如腾讯的Foxmail、微软公司的Outlook),注意它们的默认配置不一定满足以上的这些要求。不过大多数这类程序有「查看源码」的命令,可以用它来检查发件箱的消息,确保发送的是没有乱码的纯文本文件。

    【本章注释】

    [14]在本章中作者使用大量的计算机术语,我已尽量简化处理,同时,我认为以上的方法并不适合大多数的提问者,所以我在此总结一下适合普通用户的文件格式:

      1. Txt:直接粘贴,方便阅读;
      1. Pdf:文件规范,推荐使用;
      1. Doc:使用广泛,打开方便;
      1. Md:Markdown文本,未来趋势。

    邮件送发建议使用网页端,邮件客户端推荐使用Outlook2013或Foxmail 7。

    准确简练地描述问题

    问题的描述应该包含以下内容:

      1. 清晰的细节;
      1. 问题发生的环境(主机品牌、操作系统、应用程序,任何相关的),提供销售商的发行版和版本号(如:「Fedora Core 7」、「Slackware 9.1」等);
      1. 提问前做过的调查研究及对其的理解;
      1. 提问前为确定问题而采取的诊断步骤;
      1. 最近对计算机或软件配置的任何相关改变;
      1. 如果可能,提供在可控环境下重现问题的方法;

    做大的努力预测黑客会提到的问题,并提前备好答案。

    如果你认为是代码有问题,在可控环境下重现问题,并向黑客提供报告,这个的方法尤其重要。当你这么做时,你大有可能获得及时而有效的回复。

    西蒙.泰瑟姆(Simon Tatham)曾写过一篇《如何有效报告bug》的文章,我强烈推荐各位阅读。

    话不在多,精炼最好

    你应该精炼且简要地描述问题,简单地将堆砌代码或罗列数据是没有用的。如果你有一个体积庞大且复杂的测试样本,尝试将其裁剪,越小越好。

    至少有三个理由支持以上这点。第一,让别人看到你在努力简化问题的过程,这会使你更有可能得到回复。第二,简化的问题更容易得到回复。第三,在简化的过程中,你有可能自己就找到了解决办法。

    别急于宣称找到bug

    当你在一个软件中遇到问题时,除非你非常、非常的有根据,否则不要动辄声称找到了bug。提示:除非你能提供解决问题的源代码补丁,或者在前一版本的回归测试收集了足够的证据,否则你都不能够完全确信。对于网页和文档也如此,如果你声称发现了文档的「bug」,你应该提供可以替代的解决方案。

    记住,还有许多用户并未经历你遇到的问题,否则你在阅读文档或搜索网页时早应该发现了(疑问:你在报怨前已经搜索过了,是吧?)。这也意味着很有可能是你弄错了,而不是软件本身有问题。

    编写软件的人总会非常努力地优化修正这个软件。所以,如果你声称找到了bug,这是对他们能力的质疑,即使你是对的,也有可能会使某些人人感到不爽。此外,在标题中寻找「bug」也是相当不厚道的行为。

    即使你私下已经非常确信发现一个真正的bug,你在提交问题时最好也写得像是你做错了什么。这样,如果是真有bug,你会在回复中获知,同时,维护者会向你道歉,这总比你无心破坏而欠下一个道歉要好。

    跪求也不能解决问题

    有些人明白不应该采用粗鲁或傲慢的方式提问并要求得到答复,所以他们走了另一个极端,转而低声下气地哀求:「我知道我只是个可怜的菜鸟,一个loser,但……」。这种对实际问题含糊的描述特别令人反感,不但困扰,也没有用。

    别用低级灵长类动物的老办法浪费时间,相反,尽可能清楚地描述背景情况和你的问题,这比摆出卑贱态度更有用,同时这也是对自己的重新定位。

    有的论坛专门设置了新手提问区,如果你真的认为遇到了新手该遇到的问题,直接到那去提问就好,别再跪求了。

    描述症状,不做猜测

    向黑客陈述你的猜测是没有用的(如果你的诊断理论真的那么有用,你还会向别人求助吗?)。所以,你只需要告诉他们问题的原始状态,而不是你的解释和理论,让他们来解释和诊断。如果你真的认为自己的猜测很重要,那么你就应该清楚地说明这只是你的猜测,并解释为什么不起作用。

    愚蠢的提问:我在编译内核时接连遇到SIG11错误,怀疑主板上的某根电路丝断了,找到它们的最好办法是什么?

    明智的提问:我组装的电脑(K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯片组]、Corsair PC133 SDRAM 256Mb 内存)最近在开机20分钟左右、做内核编译时频繁地报错,提示SIG11 ,但在头20分钟内从不出问题。重启动不会复位时钟,但会整夜关机。更换所有内存未解决问题,相关的典型编译会话日志附后。

    鉴于不是每个人都不能做到明智的提问,所以这里有一句话可以给到你启示:「所有的诊断专家都来自密苏里州」。美国国务院的官方座右铭则是「让我看看」(Show me)[15],对回复者而言,这并不是质疑,而只是一种真实而有用的需求,以便让他们看到与你看到一样的原始证据,目睹尽可能一致的东西,而不是你的片面的猜测与总结。(所以)让我们看看(Show me)。

    【本章注释】

    [15]「让我看看」出自国会议员威勒德.D.范迪弗[Willard D. Vandiver]在1899年时的讲话:「我来自一个出产玉米、棉花、牛蒡和民主党人的国家,滔滔雄辩既不能说服我,也不会让我满意。我来自密苏里州,你必须让我看看。」大意是我不相信别人的描述,我只相信我眼前的事实。

    按时间顺序描述问题症状

    解决问题最有效的线索就是问题之前发生的情况。所以,在问题描述汇中应准确地记录你、电脑和软件在崩溃前的情况。在命令行处理的情况下,对话日志(如运行脚本工具生成的)的记录会非常有帮助。

    如果崩溃的程序有诊断选项,试着选择能在能生成排错日志的选项。记住,「多」不等于「好」。试着选取适当的排错级别,以便提供有用的信息。

    如果你的问题记录很长(如超过四段),在开头简述问题,随后按时间先后描述详细过程也许更有用。这样黑客在阅读你的记录时就知道该注意哪些内容了。

    描述目标而不是过程

    如果你想知道如何做某事(而不是报告一个bug),你需要在开头就表明你的目标,然后再陈述你遇到问题。

    经常出现这种一种情况:寻求技术帮助的人在脑中里有个更高层次的目标,他们自以为按自己的路走能达成目的,但在中途却被卡住了,又跑来问该怎么走,他们从来没有意识到这条路本身有问题,所以他们往往更折腾才能达成目的

    愚蠢的提问:我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值?

    明智的提问:我正试着用自己选定数值的颜色替换一幅图片的色表,我现在知道的唯一方法是编辑每个表槽,但却无法让某图形程序的颜色拾取器取得十六进制的RGB值。

    第二种提法是明智的,它会获得更合适的回答:建议采用更合适的工具来完成任务。

    不要请求私下回复

    黑客们认为问题的解决过程应该公开、透明,这样就会有更多的人参与到此问题的解决,如果有知识渊博,经验更丰富的人发现了这个问题,他们就会留意到回答中不完整或不准确的地方,那么原来的回答就会被纠正修复。同时,这些人的能力和学识也会被其他同行看到而得到赏识。

    而当你要求私下回复时,以上的纠正过程就会被中止,所以,不要请求私下回复,要让回复者来决定是否私下回复。实际上,如果他真的私下回复你了,通常是因为他认为问题太差或者太肤浅,自己给出的答案对其它人也毫无意义,那就发给你吧。

    这条规则也有一个例外,如果你确定该提问可能会带来大量雷同的回复时,那么你可以主动表示:「请向我发电子邮件,我将为论坛统一归纳这些回复」。你这个举动是非常值得赞扬的,因为你将论坛从洪水般雷同的回复中解救出来。最后,最重要的一点,你必须言出必行。

    精准地提问

    漫无边际的问题通常被视为时间黑洞,回答这些问题需要付出更多的时间和精力,只有最忙的人才会给你最有用答案,但这些人对于时间黑洞极其敏感,所以他们比较讨厌那些漫无边际的问题。

    如果你明确指认了让回复者做的事(如指点方向、发送代码、检查补丁或其它),你更有可能得到有用的回复。(因为)这样可以让他们集中精力去解决问题,并间接地设定了他们为帮助你需要花费的时间和精力上限,这是很好的做法。

    如果你想要向专家提问,你可以这样设想:你去到一个金库,可是你只有一点点的时间。专家就像金库,如果你想在尽可能短的时间来换取更多的价值,你就要向他们提出一个精准的问题。

    所以,为了让专家能够用尽量少的时间来回答你的问题,你最好限定问题的范围。限定问题范围与简化问题是不一样的。举个例,「请问可否指点一下哪有好一点关于X的解释?」通常就要比「请解释一下X」来得明智。再譬如,如果你的代码运行不了,「请别人看看哪有问题」就比「叫他们帮你改正」更加明智。

    如何提问关于代码的问题

    不要直接要求别人给你修正代码,而应该提问如何入手解决这个问题,如果你一上来就一段几百行的代码,说你这里有bug提示出错,你能帮我找出来吗?这样的请求只会被直接无视,而如果你精简代码,明确地描述问题:在第七行以后,本应该显示<x>,但实际出现的是<y>,如何处理?这样就大大提高问题被回答的几率。

    最精确描述代码问题的方法是提供一个能展现问题的最小测试样本。什么是最小测试样本?它是可以集中展现问题,只需要能够刚好重现问题的代码即可。如何生成一个最小测试样本?如果你知道哪一行或哪一段代码会产生问题,将其复制并提供刚好够用的外围支撑代码以构成一个完整的样本(够用是指源码刚好能被编译器、解释器或任何处理它的程序所接受)。如果你不能将问题缩小到特定的段落,复制源代码并去除那些与问题无关的代码段。你能提供的最小测试样例本越小越好(参见《浓缩精华》这一章节 )。

    用最小测试样本去测试bug也并不是万能的,但这毕竟是一个很好的尝试,这有助于帮助你独立去解决问题,即使你找不到,黑客们也喜欢看到曾经你努力过,这将使他们跟你合作去解决这个问题。

    如果你只是想让别人帮忙审核一下代码,在最开头就要说出来,并且一定要提到你认为哪一部分特别需要关注以及为什么。

    不要提问「家庭作业式」的问题

    黑客们擅长发现「家庭作业式」[16]的问题。家庭作业要求独立完成,因为这是你该做的,这样你才能从中学到东西,遇到困惑的时候可以要去给一点提示,但是千万不要要求给出完整的答案。

    如果你怀疑自己碰到了一个「家庭作业式」的问题,自己尝试过但仍然无法解决,可以试试在用户组、论坛或(作为最后一招)中提问。在那里,黑客们会留意到你的问题,一些老用户也许会给你提示。

    【本章注释】

    [16]「家庭作业式」的问题:在学习者眼中的复杂问题,在专家眼中的简单问题,基础式问题。

    删除无意义的疑问

    有的人喜欢在求助信息的末尾加上「有人能帮我吗?」或者「有没有答案?」这一类无意义的提问,应该在提问中尽量删除这些废话,理由如下:第一,如果问题本身描述的不完整,这些附加的东西就是废话。第二,因为它们提问的方式不对,黑客们会认为这些东西很烦,很有可能就会用逻辑上无误回复来敷衍你,诸如「是的,你可以得到帮助」和「不好意思,没有人能帮你」。

    一般来说,避免提「是或非」问题,除非你想得到「是或非」回答。

    不要把问题标记为「紧急」,即使你真的很紧急

    「紧急」只是你的「紧急」,跟我们无关。同时,这些动辄「紧急」的提问往往欲速而不达,而且多数会被黑客们删掉,因为他们认为这是一种自私与鲁莽的提问方式:企图通过文字的简单修饰来引起别人注意而获得特殊的关照。

    当然也有例外,如果你在知名度很高使用某些程序出现问题,你的提问很有可能让黑客们兴奋,在这种情况下,如果你有时间压力,并且很有礼貌地提出请求,黑客们会有兴趣尽快地回复你。

    不过需要注意的一点是:这样提问是非常冒险的,因为黑客兴奋的标准和你的不同。譬如发个主题关于「国际空间站」帖子就可以得到关注,但是如果转发关于慈善或政治的帖子就几乎没人理你。再如「紧急:帮我救救这个毛绒绒的小海豹!」这样帖子在专业技术论坛让黑客看到了肯定会相当抓狂,即使他们认为拯救毛绒绒的小海豹很重要。

    如果你觉得以上的解释难以理解,把剩下的内容多读几遍,直到弄懂了再发帖也不迟。

    谦逊没害,而且有益

    礼貌一点,使用「请」和「谢谢你的关注」或者「谢谢你的帮助」,让别人明白你的真诚,让他们觉得这样无偿的帮助你是值得的。

    坦白讲,对黑客而言,在提问中使用正确的语法、清晰的文字、准确的内容,标准的格式远比使用礼节重要。黑客们一般宁可看文字锋利直白但技术鲜明的bug报告,也不要看那种彬彬有礼有礼但内容空洞含糊其辞的报告。(如果你不明黑客们为什么喜欢这样,那么你就要明白:黑客评价一个提问价值的标准在于这个问题能给他带来什么样的成长。)

    然而,如果你已经清楚地描述了一个问题,客气礼貌一点肯定会增加你得到回复的机会。

    (本文曾受到一些老黑客的指责,这也是本文的唯一受指责的地方,所以我们必须指出,我们曾经推荐使用「提前谢了」的感谢方式,这种感谢方式在一些黑客看来有一种事后不用再感谢任何人暗示和过河拆桥的味道,所以,我们现在的建议是:一、先说「提前谢了」,事后再表示对回复者的感谢;二、换一种表达方式,譬如用「谢谢你的关注」或「谢谢你的帮助」等。)

    问题解决后,追加简短说明

    在问题解决后向所有帮助过的人回复一条信息,让他们知道问题是如何解决的并再次感谢。如果问题在论坛中受到广泛关注,在那里追加此信息比较恰当。

    最理想的方式是向最初提问的主题中回复此消息,并在主题中注明「已解决」、「已搞定」或其它同等含义的字样[17]。这样,在信息快速流动的论坛中,一个注明「已解决」或「已搞定」的主题就会让别人节省很多时间,回复者不用再点进去重复回复(除非他觉得这个问题值得再商榷),因此他就可以用这些时间去解决其他问题。

    追加的信息无须太冗厂繁复,一句简单的「你好,问题已解决,是网线坏了!谢谢大家──比尔」就比什么都没有要好。事实上,除非解决问题的过程很复杂,需要用得很高深的技术,否则就用一条简短亲切的总结来回复就好了,总结中说明用了什么方法,解决了什么问题,无需将整个解决问题的过程给写下来。

    对于有深度的问题,建议给出一份完整解决该问题的方案,方案包括:问题的最终状态、用了什么方法、列出具体的步骤和和易出错的地方,这样才可以给到后来者一个完整的指引,注意不要将此方案搞成什么侦探推理小说。最后列出那些帮助过你的人的名字,那样你有可能会交到朋友。

    这种后续的跟进信息不仅是礼貌的回复,而且是内容的分享,因为这些后续的解决方案会帮助其他有同样问题的人,他们会在论坛中找到你的解决方案,并因此受益。

    最后,此类后续的信息跟进还让每位参与协助的人因问题的解决而产生一种满足感。如果你自己不是技术专家或黑客,相信我们,这种感觉对于你寻求帮助的老手和专家是非常重要的。问题的不了了之总会令人沮丧,但黑客们有强迫症,总渴望它们被解决,你的后续跟进就像是为他们消灭了一个眼中钉,并因此获得了一定的信誉的威望,这对你的下次提问非常有帮助。

    考虑到将来也会有人面临类似的问题,如何避免重蹈覆辙呢?你可以自己写一篇文章或者对FAQ进行补充,然后发给项目的维护者。

    在黑客交流的过程中,这种良好的后续跟踪行为比传统的礼貌更重要,这也是你善待他人赢得声誉的方式,这是非常有价值的经验和财富。

    【本章注释】

    [17]在国内论坛,问题解决之后,可以主动修改论坛主题,添加上「已解决」字样,然后通知版主做出处理。

    如何解读回答

    RTFM[18]和STFW[19]:你为什么不去试一试?

    有一个古老而神圣的惯例:如果你收到RTFM的回复,你就应该去「Read The Fucking Manual」,他说得对,去读一下吧。

    「Read The Fucking Manual」(RTFM)有个年轻点的亲戚,如果你收到「Search The Fucking Web」(STFW)的回复,你也应该去「Search The Fucking Web」,他说得也对,去搜一下吧。(更温和一点的说法是「善用Google」)

    在论坛,你也可能被要求去搜索论坛的存档记录。事实上,有人甚至可能热心到为你提供以前解决此问题的线索。但千万不要依赖这种帮助,你应该在提问前搜索一下存档。

    通常的情况是,要求你主动去搜索的人已经打开了能解决你问题的手册或网页,他那时可能是一边在看屏幕一边敲着键盘回复「RTFM」或「STFW」,这些回复意味着:第一,你要的信息很容易找到。第二,自己动手,丰衣足食。

    这不是一种是鄙视,按黑客的标准,回复者没有不理你,反而在耐心地回复你,这是对你提问的尊敬,你应该感谢他还像一个老奶奶一样唠唠叨叨地回复你。

    【本章注释】

    [18]RTFM,是一个英文缩写,意思是:「去读那些他妈的手册」(Read The Fucking Manual),这句话通常用在回复那些只要查阅文件就可以解决,拿出来提问只是浪费别人时间的问题.

    [19]STFW:Search The Fucking Web,去搜那些他妈的网站,语意同RTFM。

    如果还不明白……

    如果你看不懂回答,不要马上发帖要求别人进行解释说明,你应该回过头去看看你提问时候试用过的工具(如手册、FAQ、网页、行业内朋友等),如果检查过后,你发现还是需要解释说明,你就要将已学的东西展现出来。

    譬如,我告诉你:「看起来像是输入项有问题,你需要清除它」,接着是个不好的回帖示范:「什么是输入项?」(因为你没有主动在搜索引擎中搜查什么是输入项)。而以下就是一个很好的跟帖:「是的,我读了手册,某某输入项只在 -z 和 -p 开关中被提到,但都没有涉及到如何清除它们,你指的是哪一个还是我弄错了什么?」

    对待无礼

    很多黑客圈子中看似无礼的行为并不是存心冒犯。相反,它是直接了当、一针见血式的交流风格,这种风格对于更关注解决问题而不是使别人感觉舒服。

    如果你觉得被冒犯了,试着平静地对待。如果有人真的做了过分的事,论坛中的老前辈会教训他。如果这些没有发生而你却恼火了,那么这些致使你恼火的言语可能在黑客社区中看来是正常的,而你将被视为有错的一方,这会让你丧失进一步获得信息或帮助的机会。

    另一方面,如果你真的偶然地遇到了无礼和无聊的冲撞,你就要对真正的冒犯者予以狠狠的反击了,用犀利的语言将其驳得体无完肤都是可以接受的,然而,在行事之前一定要有非常肯定的证据。因为纠正无礼的言论与一场毫无意义的口水战仅一线之隔,黑客们自己莽撞地越线的情况也屡见不鲜。新手可能难免中枪。但如果你想得到的是信息和帮助,就不要浪费时间参与到口水战之中。

    (有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症[20],缺少用于润滑人类社会「正常」社交所需的人脑回路。这既可能是真也可能是假。如果你不是黑客,也许你会认为我们脑袋有问题,以为还能帮助我们纠正那些古怪行为。如果你真的以为这么做会有效,你就只管这么做好了,我们不在乎。我们就喜欢现在这个样子,因我们会对那些所谓的「诊断」拥有正常的科学的健康的怀疑精神。

    在下一节,我们会谈到另一个主题,当你犯错遭受到的指责该怎么办。

    【本章注释】

    20、阿斯伯格综合症,是一种泛自闭症障碍,其重要特征是社交困难,伴随着兴趣狭隘及重复特定行为,但相较于其他泛自闭症障碍,仍相对保有语言及认知发展。

    不要像loser那样去行事

    常在河边走,哪有不湿鞋。在黑客论坛混,总有有犯错的时候,你的错误会被别人长篇大论的公开地揭露,或许在言语之中还会透露着鄙视和得意。

    事后你能做的最坏的事莫过于哀怨你的遭遇、四处哭喊着被人诽谤、要求道歉、竭斯底里的呼喊、忍隐不做声、威胁诉诸法律、向他公司投诉、忘了关马桶盖等等,但实际上,以下的的几件事才是你应该去做的:

    就让它这样过去,这是一件很正常的事情。事实上,这样的被人指出错误也没什么大不了,对自己反而是好事。

    论坛社区的规则不会自行运转,它们是只能通过参与者通过积极公开的方式来执行维持。不要哭诉着要求将所有的批评和指责通过私下的邮件传达,这不是行之有效的运作方式,当有人在评论你的一个说法有误或者提出不同看法时,你坚持声称受到人身攻击,这也是没用的,这也是loser对待事情的态度。

    也有一些黑客论坛愚蠢地执行过「高礼节要求」的规则,禁止参与者公开发表任何对别人观点挑错的文章,并发出「如果你不想帮助用户就闭嘴」的言论,结果造成大批有思想的参与者逃离此论坛,这个论坛就变成了一个毫无意义,絮絮叨叨,没有价值的技术论坛。

    是要夸张的不切实际的「友好」还是坦诚直白的「实用」?你自己挑一个吧。

    记着:当黑客说你犯错了,并且(无论说得多么尖锐地)告诉你别再这样做时,这表明他在为关心你和这个社区。对他而言,无视并拉黑要容易得多,如果你无法做到感谢,至少要有点自尊,别大声哀怨,别以一个敏感而莽撞的新手自居,更别指望别人能像对待一个波大无脑的女人一样去抚慰你。

    有时候,即使你没有犯错(或者只是别人的臆想),有些人也会以莫须有的名义来指责你。在这种情况下,你的报怨倒是真的会把事情弄得更糟。

    这些无事生非的人其实也没有多大的能耐,不是在吹牛逼的专家,就是一天到晚在唱反调的心理预测专家。总有读者有能力分辨,并想办法去对付他们,这些人在玩火自焚,你就不用操心了。

    如果你在网络上不得不要面对一场争论,你得首先去确认一下自己是否犯错,如果你没有犯错,那么你就可以断定这是一场无聊的口水战,不要将自己卷入口水战之中,也最好不要理睬其他与你无关的口水战,因为这样争论不会有一个明确的结果。

    三思而后问

    下面是些典型的愚蠢问题和黑客不回答它们的原因和想法。

    • 问:1、我到哪可以找到某程序或X资源?
    • 问:2、我怎样用X做Y?
    • 问:3、如何配置我的shell提示?
    • 问:4、我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式吗?
    • 问:5、我的{程序、配置、SQL 语句}不运行了。
    • 问:6、我的Windows系统出问题了,你能帮个忙吗?
    • 问:7、我的程序运行不了,我认为是系统工具X有问题。
    • 问:8、我在安装Linux或X是遇到困难,你能帮个忙吗?
    • 问:9、我如何才能破解超级用户口令/盗取操作员的特权/查看某人的电子邮件?

    问:1、我到哪可以找到某程序或X资源?

    答: 在我找到的地方啊,笨蛋!──你就不会在网页找么,真抓狂,难道还有人不知道如何使用Google吗?

    问:2、我怎样用X做Y?

    答:如果你想得出Y的结果,那么请不要在想得出Y的结果前提供X的方法,这样的问题表明提问者不但对X完全无知,也对Y了解不深,这个问题还表明提问者已经被某种思维定势禁锢住了,最好让他们将问题整理好再来提问。

    问:3、如何配置我的shell提示?

    答:如果你有足够的智慧提这个问题,你也该有足够的智慧去「Read The Fucking Manual」(RTFM),然后自己去找出来。

    问:4、我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式吗?

    答: 试试就知道了。如果你试过,你既知道答案,又不用浪费我的时间。

    问:5、我的{程序、配置、SQL 语句}不运行了。

    答: 这不是一个问题,我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西,我的反应一般如下:

    • 你还有什么补充吗?
    • oh,太可惜了,希望你能搞定。
    • 这跟我有什么关系?

    问:6、我的Window系统出问题了,你能帮个忙吗?

    答:可以,将Windows系统给卸了,装个开源操作系统,例如Linux或BSD[21]。

    注意:你可以问与Windows系统相关的问题,前提是这个程序有Windows的官方版,不是我对Windows系统有偏见,而是Windows系统与大部分的软件存在兼容问题,而实际上Windows系统实在很差。

    问:7、我的程序运行不了,我认为是系统工具X有问题。

    答:这个程序被成千上万用户反复使用,你有可能是第一个提出这个程序有缺陷的人,不过你得要拿出具体的证明,最后有一份详细清晰的缺陷说明。

    问:8、我在安装Linux或X是遇到困难,你能帮个忙吗?

    答:不好意思,我帮不了你,我需要亲手操作你的电脑才能帮你排错,去向当地的Linux论坛寻求帮助吧。

    注意:如果安装问题与某Linux发行版有关,请首先在论坛中提问。同时,应准确描述问题的细节。在此之前,先用 「linux」和所有被怀疑出问题的硬件 [作关键词] 仔细搜索。

    问:9、我如何才能破解超级用户口令/盗取操作员的特权/查看某人的电子邮件?

    答:想做这种事情说明你是个人品恶劣的家伙,想让黑客教你做这种事情说明你是个傻逼。

    【本章注释】

    21、这个回答可以视为一句吐槽,也可以视为一个建议,毕竟大多数黑客都是使用开源系统的。

    好问题与坏问题

    最后,我将通过举例来演示提问的智慧。同样的问题两种提法,一种愚蠢,另一种明智。

    愚蠢:我在哪能找到关于Foonly Flurbamatic设备的东西?

    这个问题在请求一个「Search The Fucking Web」(STFW) 式的回复。

    明智:我用谷歌搜索过「Foonly Flurbamatic 2600」,但没有找到什么有用的信息,有谁知道在哪能找到这种设备的编程信息吗?

    这个人已经搜索过网络了,而且听起来他可能真的遇到了问题。

    愚蠢:我不能编译某项目的源代码,它为什么这么烂?

    提问者预提了一个假设:是别人搞砸了,太狂妄自大了。

    明智:某项目的源代码不能在某Linux 6.2版下编译。我读了常见问题文档,但其中没有与某Linux相关的内容。这是编译时的记录,我做错了什么吗?

    提问者已经指明了运行环境,读了常见问题文档(FAQ),列出了错误,也没有假设问题是别人的过错,值得留意一下。

    愚蠢:我的主板有问题,谁能帮我?

    某黑客管理员对此的反应可能是:「是的,还需要帮你拍背和换尿布吗?」,然后是敲下删除键。

    明智:我在S2464主板上试过X、Y和Z方法,当它们都失败后,又试了A、B和C方法。注意我试C时的奇怪症状,显然某某东西正在做某某事情,这并不是正常的现象。通常在Athlon MP主板上导致某某事情的原因是什么?有谁知道我还能再尝试什么方法以确定问题?

    相反地,这个人的问题看来值得回答。他或她展现了解决问题的能力而不是坐等天上掉馅饼。

    在最后那个问题中,注意「给我一个答案」与「请帮我看看我还能再做点什么测试以得到启发」之间细微但重要的差别。

    事实上,最后那个问题基本上源于2001年8月Linux内核邮件列表(lkml)上的真实事件,是我(Eric)当时提了那个问题,我发现Tyan S2462主板有神秘的死机现象,邮件列表成员给我提供了解决此问题的关键信息。

    通过这种提问方式,我给了别人可以深思玩味的东西。我设法使之对参与者既轻松又有吸引力,也表明了对同行能力的尊敬并邀请他们与我一起协商。通过告诉他们我已经走过的弯路,我还表明了对他们宝贵时间的尊重。

    事后,当我感谢大家并评论这次良好的经历时,一个Linux内核邮件列表的成员谈到,他认为我得到答案并不是因为我的名字挂在列表上,而只是因为我正确的提问方式。

    黑客们在某种层面上貌似是非常冷漠无情的精英分子。我想在这事上他是对的,如果我表现得像个不劳而获的寄生虫,不管我是谁都会被忽略或斥责。他建议将整个事件作为对其它人提问的指导,这直接导致了本文的编写。

    如果得不到回答

    如果得不到回答,请不要认为我们不想帮你,有时的确是因为被问到的小组成员不知道答案。没有回复不等于不被无视,当然,必须承认从外部很难看出两者的差别。

    一般而言,不要在再重复发表这个问题,这会被视为毫无意义的骚扰。耐心一点,知道你问题答案的人可能生活在不同的时区,有可能正在睡觉,也有可能你的问题一开始就没有组织好。

    还有其它信息源可以寻求帮助,例如一些面向新手的资源区。

    有许多在线与本地的用户组织,虽然他们自己不编写任何软件,但是他们对软件很忠诚热心。这些用户组通常因互助和帮助新手而形成。

    还有众多大小商业公司提供签约支持服务(红帽与SpikeSource是两家最出名的,还有许多其它的)。别因为要付点钱才有支持就感到沮丧!毕竟,如果你车子的汽缸垫烧坏了,你还是得花钱找个修理店把它弄好。同理,即使软件没花你一分钱,你总不能指望他的服务支持都是免费的。

    象Linux这样流行的软件,每个开发版至少有一万个以上的用户,一个人不可能应付这么多用户的服务要求。即使你必须付费才能得到支持,也比你还得额外花钱买软件要少得多(封闭源代码软件的服务支持与开源软件相比通常还要贵一点,也要差一点)。

    如何更好地回答

    态度和善一点。问题带来的压力常使人显得无礼或愚蠢,即使你平时不是这样的。

    对初犯错者私下回复。对那些无心犯错之人也没有必要当众羞辱,一个真正的新手也许连怎么搜索或者连FAQ在哪都不知道。

    如果你对某样事物不确定,一定要说出来! 一个听起来权威的错误回复比没有还要糟,别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。

    如果你帮不了忙,也不要帮倒忙。不要在具体步骤上开玩笑,有些可怜的新手会把它当成真的指令,那样也许会毁了用户的安装进程。

    探索性的疑问可以引出更多的细节。如果你问题问得好,你也可以学到点东西。试试将很差的问题转变成好问题,别忘了我们曾经都是新手。

    尽管对那些懒人敷衍一句「Read The Fucking Manual」(RTFM)是正当的,但是指出文档的位置(或者给出一个搜索关键词)会更好

    如果你决定回答一个问题,请尽可能详尽地提供一个好答案。当别人正在用错误的工具或方法时,别给出一个权宜之计,应推荐一个更好的工具,重新组织这个问题。

    提供一个可操作的回答建议!如果回答者已经详细地研究过问题,并且已经测试过X、 Y, Z, A、B、和C方法,均没有得出一个满意的结果,这表明简单地回复「请尝试X或者Y方法」或提供一个链接是没有用的,你要给出一个可操作的详细的操作步骤。

    让你所在的社区或论坛也从学习中获益。当回复一个好问题时,问问自己「如何修改相关文件或FAQ文档以免再次解答同样的问题?」,接着再向社区或论坛维护者发一份补充说明。

    如果你的答案是在研究一番后得出的,请展现你的解题技巧而不是直接端出结果,毕竟「授人以鱼,不如授人以渔」。

    相关资源

    如果需要个人电脑、Unix和互联网如何工作的基础知识,参阅Unix和互联网工作的基本原理。

    当你发布软件或补丁,试着按软件发布实践手册操作。

    鸣谢

    Evelyn Mitchell贡献了一些愚蠢问题例子并启发了我编写「如何更好地回答问题」这一章节
    Mikhail Ramendik贡献了一些特别有价值的建议和改进意见。

    附:知乎对「如何提问题?」的答案总结

      1. 认真:认真对待你的提问,就像你希望别人认真回答你的问题一样。
      1. 先搜索:确保你提了一个新问题,而不是别人问过的重复问题(解决办法:提问之前先搜索)。
      1. 具体:让你的问题处于具体的环境中,避免大而空洞、需要具体情况来分析、或别人难以读懂的问题。
      1. 解决办法:将问题阐述清楚,尽可能将问题的「补充说明」写清楚。
      1. 书写:正确地使用标点符号和英文大小写,没有错别字。
      1. 添加话题:给问题添加合适的相关话题。
      1. 邀请回答:使用右侧的「站内邀请」,邀请专业的人来回答。
      1. 在问题中避免出现绝对性词汇。很多问题你认为是这样但事实并不如此。eg. 为什么画的画画得再像也一眼能看出来不是照的相?
      1. 避免在问题中加上自己对答案非专业或非正确的猜想。

    我们若能更妥善地搜寻资料,实在已经改变世界。

    展开全文
  • 产品经理面试必问5大问题 (六)

    千次阅读 2020-02-21 19:01:11
    在五年的时间内,你的...第二年,时间花在产品推广上,花在技术细节上,花在产品测试上,花在协调各方面资源上面认为产品经理一定要全面; 第三到五年,工作的各方面都相对比较得心应手了,产品业务逻辑、交互流...
  • 产品经理的私房菜 - 腾讯产品模型 - 学习能力篇

    万次阅读 多人点赞 2021-05-23 23:35:39
    产品经理的私房菜 - 腾讯产品模型 - 学习能力篇 ...“这份简历,对于我们来说,没有什么优势” “我见过太多,自以为,有一个内推机会,就一定能进的人” 看到这个回复,心里蛮难受的。 以前就和鹅厂
  • hr面试十大经典提问

    千次阅读 2020-09-17 15:39:06
    下面是学习啦小编给大家整理的hr面试十大经典提问,供大家参阅! hr面试十大经典提问 1、HR:你希望通过这份工作获得什么? 1)、自杀式回答:我希望自己为之工作的企业能够重视质量,而且会给做得好的员工予以奖励。我...
  • 根据最近换工作的经历,笔者以个人经验总结整理出了“产品经理入职四部曲”,帮助小伙伴们在入职新公司工作岗位时,明确个人试用期的工作安排,快速适应新公司的工作环境,顺利度过试用考核期。
  • 编者荐语: 推荐“阿镜老师”的面经分享,万字长文,建议收藏...阿境从个人方面、公司方面、项目方面、产品基础知识方面、人事问题方面、提前准备方面、开放性问题方面等七个方面来介绍下产品经理在面试中能够遇到...
  • 刚刚学习期货量化分析,不知道如何获得历史数据,请大神帮帮忙!
  • 作者:Zevol全文共 2716 字,阅读需要 7 分钟———— / BEGIN / ————相比把用户成长体系玩得贼的C端产品,B端产品在用户成长体系上却一片空白。今天我们一起聊一聊:在B端产品中,应不应该建立用户成长体系,...
  • 技巧]销售人员该怎么向客户提问 要成为一名优秀的业务员必须要具备一定的专业知识,一定的演讲口才能力,敏锐的洞察力和积极进取的态度。然而同时也要把握一些实用的沟通技巧。 向顾客提问是一个很有技巧性的问题,...
  • 上面说的这三个步骤方法,比较偏向于做后台业务功能的流程梳理和调研,其实对于to c 类的产品来说,方法都是通用的,只不过调研业务部门换成了调研用户,只有更了解用户的操作行为、习惯、心理预期才能做出更好的...
  • 我为大家整理了一份应该算是史上最全的产品经理面试的问题及答案大全了吧! 希望各位朋友能够“融会贯通,好好吸收”,错误的方法则是“死记硬背”。 怎么自我介绍? 【参考答案】 您好,我叫XXX,今年XXX,毕业于XX...
  • (从以下问题选择2个提问即可) (1)部门和具体业务? 这个问题必问,如果面试官已经介绍过了,那就说想详细地了解一下我们这个岗位负责的业务或者具体职责,充分地了解能让你为下一轮的面试做好充足的准备。 (2)...
  • 测试需要理解的产品设计原则

    千次阅读 2021-12-11 15:14:30
    测试的角度,理解产品设计原则,便于测试用例的设计,以及提出设计不合理质疑的原则
  • 智慧的提问(不做慵懒的寄生虫)

    千次阅读 2017-01-02 09:35:18
    提问的智慧 作者:Eric Steven Raymond:《How To Ask Questions The Smart Way》 版本:3.9 修改时间:2013年4月13日 翻译:王刚(yafrank at 126 dot com) 翻译时间:2010年9月28日 王刚翻译...
  • 产品经理面试题目转载

    千次阅读 2021-07-15 10:24:04
    来源:知乎 题: 1. toC产品经理如何深入理解整个业务? 1) 问用户 ...2. 产品文档 ...一般来说全新的产品、未来发展有潜力的产品提供BRD! 2) MRD文档(市场需求文档)。包含产品版本。主要是描述什么样的.

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 46,987
精华内容 18,794
热门标签
关键字:

对于产品的提问