每个人都有自己的人生经验，本篇文章是从笔者的角度出发，希望可以给读者带来不同的视角与观点。

从第二份工作开始，几乎每场面试你都会被问到：「过去在公司或是专案上扮演过什麽角色？遇到过什麽样的困难、如何解决？」

只要出现在你履历上的工作经验都可能会被询问，所以请务必准备。

大纲

1. 在工作中有遇过哪些挫折、冲突，以及的解决方式

   • 1.1 同事刻意挑选你无法处理问题的时间捅你一刀
   • 1.2 常常快到下班时间临时开会
   • 1.3 跨部门沟通时遇到合作意愿低又甩锅的同事
   • 1.4 跨部门开会时遇到用阶级压人的长官
   • 1.5 开会冗长且不断偏离主题

2. 描述一下你在这份工作中担任的角色、负责的任务

   • 2.1 叙述本职工作
   • 2.2 与产品经理沟通
   • 2.3 处理主管交代的事情
   • 2.4 分配任务给组员
   • 2.5 分享印象最深刻的专案

3. 常见问题

   • 3.1 如果把事情搞砸了，你会怎麽办？
   • 3.2 如果跟主管意见冲突如何处置
   • 3.3 如果担任专案经理，你会如何与多个部门沟通，制定共同遵守的流程
   • 3.4 公司有跑 Scrum 吗？你们是如何运作的？
   • 3.5 [状况题]公司高层突然在周五下班前要求提前部署，你会如何应对？

1. 在工作中有遇过哪些挫折、冲突，以及的处理方式

下面的内容可能由求职者主动说出来，或是被面试官问到，无论如何谨记一个原则：「要说出你是如何面对、处理这些事情，千万不要沦为单纯的抱怨！」

大家为人处世的方法不同，笔者的做法仅供参考；主要是为了让读者在遇到问题前，可以先思考自己的处理方式，不至於手忙脚乱。

1.1 同事刻意挑选你无法处理问题的时间捅你一刀

• 事件描述
  过去上班时有碰过同事，遇到问题不在上班时间询问，而是等你离开办公室後才在有总经理的群组 tag 你，说你的专案有 bug。
• 处理方式
  • 先作反思
    我会先回忆过去有什麽地方惹到他了，或是部门间是否有利益冲突；因为一个正常人没道理在对方无法处理问题的时候，故意在有高阶长官的群组 tag 他。
  • 尽快回覆
    尽管是在下班时段，但因为对方是在有高阶长官的群组发布讯息；所以我会尽快回覆，但不管对自己的程序多有自信，我都不会强调专案没 bug，因为你此时可能在吃饭、运动、逛街，根本无法确认这个问题是否存在；笔者的回覆范例：「专案每个版本在释出前有撰写完整的测试案例确保功能稳定性，且通过测试部门的严密测试，针对 XXX 所提出的问题，我会尽快确认，并於明早 10:00 做好汇整向大家报告。」这段回覆有几个重点：
    • 专案是经过测试，确认稳定後才释出的。
    • 你有即时看到这则讯息。
    • 给出明确的报告时间。

      这边举例的是不影响系统运行且无法确认是否为真的 bug，如果是系统当机这类重大问题，你还是得即时处理。

  • 汇整报告
    • 真的有 bug
      老实承认错误，并承诺bug 的修复时间。
    • 如果没 bug
      笔者报告完後，会用这段话做结尾：「感谢 XXX 在下班时间努力工作，可能是因为他太累了才会有这个错误回报；这部分我会再跟 XXX 沟通，希望他之後可以先跟负责的工程师厘清问题，避免类似的乌龙再次发生，抱歉让各位长官受惊了。」

      笔者不会趁这个机会打压对方，将对方的问题点出来、厘清责任归属就好；如果你没办法让对方离开公司，那请做人留一线。

1.2 常常快到下班时间临时开会

• 事件描述
  有些人一整天上班时间都不找你讨论，偏偏等到下班前 10 分钟才传讯息跟你说有问题需要讨论。
• 处理方式
  • 如果对方是故意的
    偶尔发生就算了，但如果对方是刻意如此，请明确地告知对方，你希望在上班时间讨论；笔者的讯息范例：「如果有问题请在下班前一小时找我讨论，这样不会耽误到彼此的下班时间，也有比较好的讨论品质。」
  • 如果劝告无效
    如果对方在你明确告知後依然故我，笔者建议直接请上级提醒对方；有些人加班不是因为工作做不完，只是想在长官面前刷存在感，自己想刷存在感没关系，但如果影响到其他同事就真的不好了。

    不是所有事情都一定要靠自己解决，适时的请上级支援也是有必要的。

1.3 跨部门沟通时遇到合作意愿低又甩锅的同事

职场奇葩多，遇到问题先甩锅。

• 事件描述
  有时专案需要多个部门一起合作才能完成，但有些部门成员就是努力地拖延进度；你可能已经在 2 个月前就把功能完成并交付到对方手上，可是对方拖到最近才开始实作，但当上级问他功能怎麽还没做完时，他会第一时间把责任丢到你身上，说是因为你功能不够完善导致他无法作业。
• 处理方式
  • 留存证据
    职场上难搞的人太多，明明是自己的问题，却把责任都推到对方身上；如果原本公司就有使用专案管理软件就是一个很好的证据；如果没有的话，建议要截图对话纪录并且每封 Email 都要把上级加入 Loop，以此保护自己。
  • 寻找关键人物
    如果你是专案负责人，但对方总是有各种理由拖延；到最後专案无法如期交付时，上级会找你麻烦，而不是找那个没做事情的人麻烦。
    如果对方是因为部门不同而不愿意配合，笔者建议你直接找对方上级沟通；但请在问题发生初期就去沟通，如果等到时程紧绷才去沟通就晚了，对方也会想办法推卸责任。

1.4 跨部门开会时遇到用阶级压人的长官

• 事件描述
  在组织结构庞大的公司，有时开会的结论不是看哪个部门的方案比较好；而是看出席会议的长官中，谁的阶级比较大。
• 处理方式
  • 先了解会议出席人员
    会有高阶长官出席的会议不可能没有会议通知；笔者会先向上级询问这些长官在开会时的习性，因为有些长官会用阶级来判断你是否有跟他说话的资格。
  • 获得相同话语权
    如果不幸遇到只看阶级说话的长官，我会请主管邀请能与之抗衡的长官在会议列席，这样在沟通上才有平等的话语权。

    直接请一个拥有相同话语权的人，会远比自己以下犯上好很多；这里是现实社会，不要以为自己是故事的主角。

1.5 开会冗长且不断偏离主题

• 事件描述
  相信大家都有这个经验，我们为了 A 的议题开会，但常常会开到一半就冒出 B、C、D 的延伸议题；不但造成会议时间大幅延长，有时甚至在会议结束後连 A 的议题都没有结论。
• 处理方式
  • 以会议大纲为讨论主轴
    很多会议只有主题没有大纲，这造成了很多参与人员根本没搞清楚开会目的，所以偏移主题实属正常。
    如果在会议前就有把大纲发给与会人员，并在会议开始时先说明要解决的议题；把情境限制住後，就能减少非常多的延伸议题。
  • 延伸议题在其他会议讨论
    开会过程中产生延伸议题实属正常，但不建议在同一场会议中讨论新的议题；除了会议容易失焦外，会议的时间延长也会使人无法集中精神。

2. 描述一下你在这份工作中担任的角色、负责的任务

这块原则上都是依照个人经历叙述，面试官会挑感兴趣的部分做深入询问；下面是笔者统整常见的问题以及个人的回答方式。

2.1 叙述本职工作

目前担任 Backend lead 并兼任专案经理。

• Backend lead
  对程序 Code Review、思考专案优化方向、负责新人的教育训练。
• 专案经理
  与产品经理沟通了解需求，规划专案时程、分配工作以及追踪进度。

对内，让团队工程师实力成长，提升部门价值；对外，让产品符合客户需求，提升公司价值。

备注：其实跟自我介绍很像，说出面试官可能会感兴趣的关键字。

2.2 与产品经理沟通

• 如果多项任务要完成
  我会先询问每项任务的 Priority、要完成的时间；并初估开发所需时间以及人力资源配置。
• 需要跨团队合作的任务
  我会建议产品经理找相关的 key man 一起讨论，避免双方的认知差异，导致最终结果不符预期。
• 遇到不熟悉的需求与技术
  如果碰上不熟悉的领域，我会先研究完这方面的资讯後，再跟产品经理说我预估的时程，而不会在一开始就直接承诺。

2.3 处理主管交代的事情

大部分的主管只会交代方向，比如：「帮忙规划下个阶段的企划书。」

如果在不了解方向、时程、人力的状态下直接开工，有大机率最後的成果与主管心中的答案不符，所以在收到任务时，我会先确认自己的思路是否与主管一致，举例来说：

• 方向
  之前跟产品经理开会时，他有提出几项客户期待优化的需求，您看是否以这个为改版的主轴；其次再规划新的功能。
• 时程
  我预计在周四早上将相关规划整理好交给您，请问这个时间点可以吗？

  记得尽量避免在周五以及平日下班前交企划，这个时间点交企划是希望主管加班吗？

• 人力
  这次规划的功能在人力资源上，除了团队内部成员外，还需要与 XXX 部门合作；我这边会先向他们的主管询问方便合作的 schedule。

有时主管在指派任务时也没有太多想法，所以要多做沟通厘清需求；如果时间允许，笔者会在初期提供几个方案让主管评估，否则加班加点到最後弄出来的产品不是公司需要的就真的悲剧了。

2.4 分配任务给组员

如果你担任专案经理，上面交代给你的任务可能很模糊，但你向下分配的时候可不能模糊。

千万不要把组员当成你心中的蛔虫，指派任务时都要有明确的需求规格，像是：

• 需求来源
• 需求描述
• 影响范围
• 验收标准
• 预估工作天数
• 负责组员

如果需求规格写的不够明确，除了组员会时常跑来问你问题外，还可能做出完全无法使用的成果；尽管这个阶段很费力气，但真的要写仔细，并且确认组员都明白自己要做的事。

每个工程师的工作效率相差很大，但在分配工作时还是要尽量做到平衡；不要让能者过劳的状况频繁发生。

2.5 分享印象最深刻的专案

在我入职 3 年後，很幸运担任一个千万级别专案的负责人；除了撰写程序外，需求访谈、时程规划、易用性测试、教育训练等工作都需要由我来做安排。

当时这个专案主要的使用者年龄落在 40~60 岁，我需要设计一个系统取代过去他们用纸本及 Excel 的作业流程；但是在沟通以及开发的过程是非常挫折的，因为网页系统对他们来说是一个很陌生的东西，他们并不清楚自己要的是什麽；而当时的我只有开发经验，对需求与规划一窍不通，因此处处碰壁；再向周围的前辈请教後才知道在前期可以先透过 Mind-Map 了解客户需求，并利用 Wireframe 向客户说明规划。

不过 Wireframe 跟真实系统毕竟还是两个概念，在系统进入第一次易用性测试後就是噩梦的开始；因为当时的流程规划是跟承办人还有一些长官讨论出来的，但他们并不是这个系统的主要使用人员；导致系统在易用性测试时发现并不符合真实使用者的需求。

因此在易用性测试後，专案需求大幅更动，但截止日期没有改变，且时程只剩下 1/3；我在这个时机点做了一个冒险的决定：「导入 Scrum 机制。」以此充分了解每个团队成员的进度、遇到的困难、需要什麽帮助。在完成每个 Sprint 後，会请客户试用确保符合需求，最後顺利在时程内完成系统验收。

一开始在承接这个案子的时候，我觉得他们有很多行为是无理取闹；但到後来我体悟到：「只有你真正在乎的工作才会去争辩，如果你不在乎大可让他随便。」所以我把自己的角色重新定位，带着更多的同理心，从对方的视角去看问题，最後讨论出来的答案往往是藉由工程师的专业以及他们的经验揉合出来的成果。

一开始承接这个案子的时候我整天被客户骂，但是在最後结案时，客户主动打电话到公司向老板称赞我：「做事认真负责、工作效率高、沟通技巧良好；多亏了他才做出我们想要的系统。」

从一开始的四处碰壁，到最後得到甲方的尊重与认同；我现在回想起这段经历，虽然苦涩但还是非常骄傲。

• 故事需要包含的元素
  笔者选择用说故事的方式来回答这个问题，这边整理故事中包含的元素。

  • 发生时间
  • 你担任的角色
  • 遇到了什麽困难
  • 解决困难的方式
  • 自己从这个专案中学到了什麽
  • 客户对你的回馈
  • 自己对这份专案的感悟

3. 常见问题

3.1 如果把事情搞砸了，你会怎麽办？

我会明确说明自己在什麽时间点能够解决，并尽力在预估的时间点前解决任务。

备注 1：第一时间千万不要找理由搪塞，这只会让主管更火；他此时关注的只有什麽时候可以解决问题。

备注 2：如果你真的是因为有其他的重要的事耽搁了，请把任务完成後再去跟主管解释，此时的主管才听得进去。

3.2 如果跟主管意见冲突如何处置

不同职位看事情的角度也会不一样，我会先做一个聆听者了解主管的想法，毕竟主管的经验通常比我丰富，他会选择这个做法可能是有一些我没有考虑到的问题。

在了解意见的全貌後，如果我认为自己的想法有更多好处，我会先用询问的方式，问看看主管有没有考虑到这一块，毕竟一个人能想到的内容是有极限的，透过一些思维的碰撞可以弥补彼此欠缺的地方，我相信有效的沟通是建立在双方愿意聆听彼此的想法上面。

3.3 如果担任专案经理，你会如何与多个部门沟通，制定共同遵守的流程

• STEP 1：我会先找合作部门的负责人协调，确认流程可行性与需要调整的地方。
• STEP 2：各部门负责人都认可流程後，我们会各自向部门成员再次确认是否有不周之处。
• STEP 3：各部门成员都接受後，我会开一个正式会议来公布，以取得「全员共识」。
• STEP 4：在会议後发布「正式流程」。

3.4 公司有跑 Scrum 吗？你们是如何运作的？

在我们公司每个人都需要当 Scrum Master；如果只专注在自己的任务上，有时会偏离专案的方向。

我认为这样跑 Scrum 的好处有：

• 培养从团队的角度来看专案
• 快速回顾每个人的工作
• 解决成员卡住的问题
• 在当下确认任务，并协商出一个完成时间
• 每个 Sprint 结束後去思考有什麽部分可以再改进

开 Scrum 时会要求每个人说明以下内容（尽量控制在 3 分钟内）：

• 昨天完成了哪些任务
• 有卡在哪些问题
• 今天要完成的事情
• 有需要哪些部门、同事的协作

3.5 [状况题]公司高层突然在周五下班前要求提前部署，你会如何应对？

并不是高层交代下来的事情都必须答应，如果情境特殊，应该要先思考几个问题：

• 这个任务是不是你一个人就能解决的？
• 如果搞砸了，会不会需要其他人的协助？会不会影响到公司？
• 这个任务一定要在这个时间点处理吗？有什麽特别的理由？
• 如果按造原定计画执行，会造成什麽损失？

笔者认为所有问题都是可以讨论的，不要一开始就给自己否定答案；像是这个状况题，如果真的发生意外，後果可能非常很严重，让我们看看不同选择带来的後续影响：

• 接受
  如果顺利部署那当然是皆大欢喜，但万一不顺利呢？
  • 注意力不集中
    今天是礼拜五而且快要下班了，你敢说自己还有 100% 的注意力在部署上？
    如果中间漏掉某个步骤、少了一个指令都可能导致部署失败。

    若没有 IaC（Infrastructure-as-code），在这个时间点部署根本是赌运气；就算有，笔者也不建议在这个时间点部署。

  • 影响到同事
    如果部署失败，问题你无法一个人解决，但已经到下班时间了；你可能晚上没事，但你的同事呢？他们会不会有约会？
    大家急迫想下班的心情，可能会使洞越补越大，最後甚至变成整个部门留下来加班。
  • 没有太多好处
    你部署成功，高层只会认为这是应该的，对整体职涯没有太大帮助。
    但万一出错，或是假日才察觉到错误，那这件事对你在这间公司的职涯可说是毁灭性打击。

    完全没必要承担高风险低报酬的任务。

• 拒绝
  当然不能用快要下班了这种理由拒绝，我们可以换个说法。
  • 询问提前部署原因
    是因为客户在假日有急迫的使用需求吗？如果在下周一早上部署会造成什麽损失吗？

    有时提前部署这件事，只是因为高层想要炫一波，并没有特别原因。

  • 说明按造原定计划的好处
    如果在周一部署有这些好处：「系统稳定性高、可有效追踪部署後的状况、如果发生意外可以尽快处理。」

本篇文章汇集了笔者与朋友在面试、工作上的应对进退，希望文章的内容对大家有帮助，也欢迎读者在留言区分享自己的经验。

感谢大家的阅读，如果喜欢我的文章可以订阅接收通知；如果有帮助到你，按Like可以让我更有写文的动力，我们明天见～

我在 Medium 平台 也分享了许多技术文章
❝ 主题涵盖「MIS & DEVOPS、资料库、前端、後端、MICROSFT 365、GOOGLE 云端应用、自我修炼」希望可以帮助遇到相同问题、想自我成长的人。❞