• 重庆各地各部门干部群众:切实把思想和行动统一到党的十九大精神上来 2019-04-11
  • “生态+康养” 冰雪康养小镇项目落户沽源 2019-04-04
  • 游江:游江闲画——猫的心事 2019-04-02
  • 推进“安康杯”竞赛广泛深入持久开展 汇聚职工群众参与安全生产的强大合力 2019-03-20
  • 国内 —频道 春城壹网 七彩云南 一网天下 2019-03-20
  • 【理上网来·辉煌十九大】许志勇:以金融改革助力乡村振兴 2019-02-26
  • 不懂技术,如何和工程师交流?

    非技术型产品经理福音来了,和程序员不再撕逼,10天在线学习,补齐产品经理必备技术知识。了解一下

    上次我们聊了聊,工程师如何转变成为一个优秀的管理者;这次我们聊聊不懂技术的管理者如何同工程师谈需求。

    管理者问我:“我不懂那些技术,每次跟工程师们交流时,都感觉他们会因为我不懂技术而暗自鄙视我,我应该怎么做?”

    如何活着向工程师谈需求?

    很多管理者,在和工程师谈需求时,都费尽唇舌的想要解释清楚自己的想法,却总是被工程师以“这个实现不了”为理由拒绝。如果再尝试沟通,一个“乱改需求”的帽子就扣到了头上。如果管理者再不依不饶的话,最后就变成真人PK了。

    如何活着向工程师谈需求?我们平时接触最多的工程师群体莫过于程序员了。

    你看见过的程序员往往是:

    • 聪明,知识面广。迷之自信,甚至自负。
    • 对于技术异常执着,难以沟通。
    • 沉浸在自己的小世界中。
    • (不会穿衣搭配)

    如何活着向工程师谈需求?

    现在,让我站在一个(曾经的)程序员的角度上,来谈一谈工程师的个人喜好:

    1. 热爱解决问题
    2. 强大的逻辑性
    3. 注重理论知识

    一、热爱解决问题

    工程师最开心的时候,莫过于解决了一个实际问题所带来的成就感。

    工程师希望能够从“看的见,摸得着”的事物中获得成就感,比如一台电机,一个软件,一组生产线。让工程师来“测试发电机运行是否良好”,他们肯定会很开心。而让工程师来“做空一个股票”,他们一定不乐意。

    为什么?

    因为“测试发电机运行是否良好”只需要严格遵照手册规则,一步一步做下去,就一定能测试成功。而“做空一个股票”,可以有很多种方式,同时还可能有很多突发事件。而这种不确定性,就是工程师最讨厌的部分。

    当然,常年累月的“解决问题”,也带给了工程师另外一个特点,强大的逻辑性。

    二、强大的逻辑性

    有个关于程序员的笑话:

    一天,妻子跟程序员丈夫说:“你去菜场买两斤苹果,如果你看见了烧饼,就买一个回来”。

    丈夫带着一个苹果回来了。

    工程师的逻辑性强,是大家的一个共识。这是很多工程师的优点,也是他们一个很大的阻碍。

    你如果和工程师辩论,他们的逻辑都自成一体?!澳阏飧鱿钅孔霾怀隼?,因为以下几个原因……”。里面混着数个专业术语,带着自信,不容你一丝反驳。

    工程师平时的工作,又强化了他们对于事物逻辑性的追求:我们很难想象,一个随机分布的程序,或者一个随意装配的机械,会如何的运作。而工程师为了保持这些事物的稳定,不得不学会按照机器的方式思考,也就是依靠逻辑来判断事物的正误。而逻辑性强的前提,就是需要有丰富的理论知识。

    三、注重理论知识

    一枚硬币抛了100次,都是正面,那么下一次是反面的几率有多大?

    如果是工程师,他会说:“50%,因为硬币的正反和之前的结果是互相独立的”。

    如果是个商人,他会说:“0%,因为100次正面,已经证明这个硬币被动过手脚了?!?/p>

    对于科学知识的信任,是所有工程师的共性。想要成为一个出色的工程师,就必须对技术和科学有着近乎狂热的信仰。

    工程师对技术的信仰,有时会成为偏执的原因。因为工程师的逻辑是依靠自身强大的理论知识所建立起来的。而这样也带来了社会心理学所说的“知识的诅咒”:专家以术语和他人交谈,失去了与非专业人士沟通的能力 。

    既然我们分析了工程师的特点,那么,如果我们想让工程师满足需求,我们该怎么做?

    • 给工程师发嗲,撒娇,卖萌?
    • 给他们买超好的电脑,配上超大的屏幕?
    • 做他们的出气筒,当受气包?

    当你只管理一两个工程师的时候,这样可能会有效,可能会留住那些优秀的工程师。但是,我们需要的是组建一个优秀的工程师团队,仅仅依靠人情,会浪费大部分精力在办公室社交上。

    那么,我们需要做到以下几点:

    1. 多听少说
    2. 提出问题
    3. 自我学习
    4. 证明自己
    5. 亲自交流

    1. 多听少说

    作为一个合格的管理者,我们需要做到和上级汇报,和客户解释,和供应商沟通……只有一个“能说会道”的管理者,才是一个优秀的管理者。

    这样也导致我们在跟工程师沟通时,总是在和工程师长篇大论,谈及各种设想,创意,需求。而工程师却不得不坐在那,耐着性子,听着对他们毫无意义的空话。

    我们知道工程师最喜欢的事情是:用尽可能简单的方式,去解决一个新奇的,有趣的,复杂的,实际的问题,并且因此而挣钱。而我们也知道,一个问题的长度,是远小于答案的长度的。

    所以,作为问题的提出者,我们需要更多的鼓励工程师占据谈话的主导权。他们作为天生的问题解决者,一定能提出更加精彩的点子。

    “没错呀,我们都是让工程师去解决一个实际问题啊,比如做个类似百度的搜索引擎。为什么他们一口回绝了呢?”

    这是由于我们创造了错误的问题,并且尝试让工程师去解决。这些错误的问题,站在我们的角度上,感觉并不是很难。而站在工程师角度上,这种问题是在故意刁难他们。

    那么,我们如何才能问出合适的问题呢?

    2. 提出问题

    很多管理者问的最多的问题是:“这个项目什么时候能做完?”

    试想一下,我们在看一个人弹钢琴。即使你不会弹钢琴,你也知道《小星星》比贝多芬的《命运》容易的多。这是因为我们在判断它的时候,我们依靠的是它的速度来进行判断的。而小《小星星》的速度比《命运》慢的多。

    作为不懂的钢琴技术我们,只能利用锚定效应来估计复杂度:为不熟悉的事物做估计时,我们会以熟悉的事物来作为“锚点”,而估计出来的结果和“锚点”往往相近。当然,这样的判断大多数情况是正确的。

    然而,你是不是经常听见工程师说:

    • 这个问题解决不了。
    • 这个需求没办法做。
    • 这个流程很复杂。

    你会想:“这有什么难的,不就是要你做个小程序来排个序/放大窗口/批量删除嘛”。

    我们提出的问题一般都是“难度低,重复性高”。这类问题大多数人都可以轻易解决,只是想利用机器减少人工的消耗。而我们的锚点就是“人可以轻易解决的问题”,自然而然的将问题看得很简单。

    所以,我们对于问题难度错误的估计,加上预算的紧逼,让工程师很难将注意力集中于提升产品质量上,反而去关心一些无关紧要的事情:

    • 如何让管理人员不再来烦我?
    • 如何向这些外行证明我才是对的?
    • 如何让别人来接手这个烂摊子?

    那么,我们如何避免被工程师认为是外行呢?

    我们需要自我提升。

    3. 自我学习

    我给大家讲个笑话:手持两把锟斤拷,口中疾呼烫烫烫。

    是不是完全无法理解这个笑话的笑点?

    正如这样,如果我们不深入理解需求中存在的技术问题,而让工程师头疼于那些非技术原因产生的问题,很容易让最终产品延期又低质。(至于那个笑话,是一个程序编译时常见的乱码错误)

    如何活着向工程师谈需求?

    因此,我们作为管理者,首先就需要将一些初级的,非技术的问题消灭掉,从而减少工程师的工作量。

    “如果我会的话,我自己做就好了,那就不需要请工程师了。问题是我学不会??!”

    我们不需要去懂得如何去实现,而是将基础原理适当的进行了解。至少做到能够理解工程师口中的专业词汇,就能大大减少我们交流沟通时的障碍。

    那么,如果我们真的完全搞不懂那些技术,我们该如何从其他方面下手呢?

    4. 证明自己

    不少工程师对于管理学的态度是:“这有什么难的?不就是做个PPT,写个报告,汇报一下就好了?”

    有些管理者则默认了这种想法的正确性,平时把自己的姿态放低,给工程师端茶送水,揉肩捶背。而有些管理者对这种想法嗤之以鼻,与工程师处于“道不同,不相为谋”的冷淡关系。

    没错,科学技术是第一生产力。而且,如果我们每个人都能良好的理解他人的想法,并且按照步骤按时完成,其实我们根本不需要任何管理者。然而,人与人思考模式有着巨大的鸿沟,管理者则是搭建这些桥梁的关键人物。

    明茨伯格的管理者角色理论中提出,管理者需要处理三个方面的问题:人际关系、信息传递、以及决策制定。由于人际关系依托于个人性格的展现,而决策制定很难直观的表述出来。那么,我们可以向工程师展现出自己的“信息传递”的能力。

    解决办法是:我们可以进行一下角色互换,让工程师来监督我们的PPT制作过程,报告的撰写流程等等。让工程师能够感受到管理者为项目所作出的努力,感受到管理者作为“沟通的桥梁”所展现出的技能与技术,增加工程师对于管理者的谅解。

    如果工程师觉得这是浪费时间,拒绝角色互换,怎么办?

    我们只能拿出杀手锏了:让工程师和客户交流。

    5. 亲自交流

    对于工程师来说,管理者是辅助他们与客户交流的桥梁。但如果工程师不听从管理者的建议,那么,让工程师直接去体验客户的需求,是解决需求纷争的最佳方案。

    我们有三种办法,让工程师直面用户的需求:

    (1)让工程师使用自己的产品

    这样的方式最为简便,但是也最不直观,因为工程师往往不是产品的主要受众。这样的方法可以让工程师很容易发现一些常见问题,但是很难去深入了解客户的特殊需求。

    例如:我们为烘培坊开发了一套自动化生产线,但是工程师自己很难依靠这个生产线分析出烘焙坊的真实需求。

    (2)让工程师接受用户反馈

    大多数用户反馈都是传递到了售后部门,然后由售后部门整理后集中发给技术部门。由于用户和售后部门对于技术的不了解,有些技术上的问题,可能因为被归类为非技术问题而忽略了。

    让工程师直面反馈,他们也能逐渐发现问题的规律,可以防止下一次开发犯同样的错误。然而,客户的反馈往往都是负面的,这样也容易造成工程师对于产品产生一定偏见。

    (3)让工程师观察用户如何使用

    这是最复杂的方法,但是也是最有效的方法。让工程师直接观察用户的使用方式与使用习惯。通过这种方法,工程师可以了解到,用户如何实际使用产品的,也能够为工程师改进产品提供更多的灵感。

    然而,这样的方式会占用大量的开发时间,而且大多数工程师,会对这个方式有如同本能般的抵触——因为这相当于让工程师自己承认,自己的产品有缺陷。

    作为杀手锏,这三个方式都可以酌情使用,然而会占用双方大量的时间和精力,造成项目的停工。相对于说服工程师,更难的可能是说服整个项目组花费时间来做这些“无用功”。

    最后,总结一下管理者和工程师沟通的五个要点:

    1. 让工程师成为解决问题的主导者
    2. 选择正确的方向进行沟通
    3. 提升管理者的专业知识
    4. 展现管理者的非专业技术
    5. 促进工程师和客户的直接交流

     

    本文由 @卤豆干 原创发布于人人都是产品经理,未经许可,禁止转载。

    题图来自Unsplash,基于CC0协议。

    给作者打赏,鼓励TA抓紧创作!
    5人打赏
    评论
    欢迎留言讨论~!
    1. 傲慢与偏见一书提到:人都会对事物产生偏见对比,这也是人之常情或者自私,但一个聪明人应该学会适当收敛,我会直接把甩锅的m开了,但问题是这是不是我的偏见没有收敛,我常常思考

      回复
      1. 摔锅的还骂不了,因为现在没法为未来下结论。常常的摔锅,就是对未来的质疑,站在不同假设条件下的质疑…

        回复
    2. 我司的有资历的程序猿们,只会强调谁谁谁背锅,很打击人工作的动力呢

      回复
      1. 我觉得那是他们开发的没有安全感,产品经理团队推卸责任的甩锅太多了,直接导致了这种情况。

        回复
      2. 都是自私的问题,都站在自己的角度想问题,又不想为所作所为负责。这个根本原因可能和民族特色有关,中国人自古都是贫民思想,每个人都期盼着强者来解决问题(比如各朝皇帝),每个贫民都不愿意出头,也不愿意担责;同时作为强者的自己,也不愿意承认是自己解决的问题,而是“天”解决的。所以就慢慢成就了不担责的民风,现在都无法改变…映射到职场,是一样样的。

        回复
      3. 个人认为,如果容易互相推卸责任,主要问题都是出在责任分配制度的不完善上。我之后会写一篇关于企业责任分配的必要性与方法的文章,欢迎您关注。

        回复
  • 重庆各地各部门干部群众:切实把思想和行动统一到党的十九大精神上来 2019-04-11
  • “生态+康养” 冰雪康养小镇项目落户沽源 2019-04-04
  • 游江:游江闲画——猫的心事 2019-04-02
  • 推进“安康杯”竞赛广泛深入持久开展 汇聚职工群众参与安全生产的强大合力 2019-03-20
  • 国内 —频道 春城壹网 七彩云南 一网天下 2019-03-20
  • 【理上网来·辉煌十九大】许志勇:以金融改革助力乡村振兴 2019-02-26