/conseil/ - 相談

怎麼處理要先看你想跟那樣的主管構成什麼樣的公事關係
看是想把對方視為職場上與自己長期明爭暗鬥的勁敵
還是想跟對有更友善互動的夥伴情誼
又或是其他

確立這點後再選擇處理的方法會紮實些
補充說下這裡說的紮實是指實行自己決定的處理方法時能無怨無悔有覺悟
因為職場上跟人相處很難有個既有益於己又能避免樹敵的通用正確標準
很多時候只能靠自己在裡面接收的訊息跟自己的感受去選擇自己想作的反應

我以前年輕工作時遇過一個常處處針對我的主管
因為那時比較血氣方剛不慣於圓滑處事
所以幾次下來就直接把對方當成了要來砸破我工作飯碗的敵人
大致上是邊忍耐邊在工作上挖洞給他跳
從準備到實行共花約半年時間
事成後他以扛重責為由向老闆自行請辭

這只是我工作生涯中的例子之一
之後換工作遇到類似的情況時我也不是通通都這樣做
也有先摸清主管牌氣後投其所好而關係變好
也有藉由探問跟主管關係不錯的熟人去推敲出自己遭主管針對的原因然後去改善
也有因意識到對方不值得深化關係而刻意和對方討厭的同仁加深同夥情誼使之孤立
這真的沒標準答案只有共同點都是確保自己的飯碗安穩

你的目的就是想確保你在你上班的地方的飯碗安穩
而你的那位主管對待你的方式令你有感自己飯碗不穩甚至可能會破
面對這樣的他你想與之往什麼樣的關係發展
是視為必須排除的敵人?還是視為可改善問題增進關係的朋友?
怎麼選都取決於你對他了解
選了之後才可在處理問題之道找出對自己較有利的方法

>>31278
感謝您的回覆
說實話我在職場上願意多一個朋友少一個敵人
但是如果對方懷有惡意刻意針對我,我也不想忍氣吞聲。現在我根本不明白他針對我的理由,覺得莫名其妙

小弟做了幾年程式,大部分同事軟體工程師都是比較實在的人.會在格式和命名上糾纏的工程師我真的是第一次見到。而且之前他好像也沒有對其他人那麽嚴格，所以只可能是對我有意見

找主管關係不錯的熟人去推敲出自己遭主管針對的原因這個方法不錯，我會考慮嘗試。
還有我想請問如果私下單獨找他問出原因這種處理方法合適嗎?我感覺這樣做情商很低所以沒有這樣做但真的很在意他針對我的原因

>>31279
>還有我想請問如果私下單獨找他問出原因這種處理方法合適嗎?
這個前提是你對於想處理的對象在個性和觀念了解上都已有一定程度的自信
然後自己對話術運用和情商能力也有把握時再用會較合適性
如果沒交涉或溝通的信心
或是對方的個性和觀念都是自己所不擅長應付的
就不建議選這步

畢竟要面對的是一個原本在公事關係上有芥蒂的對象
自己若想改朝關係改善的方向去處理就得避免讓對方掌握到自己明白了問題中的哪些相關情報

因此你若覺得自己情商不高但又不欲以敵視對方的方式來處理問題
那私下單獨問原因這一點是較不推薦

我是習慣採取爭論或以牙還牙的方式來處理類似的問題，畢竟工作上我秉持人不犯我我不犯人的觀念，如果要我和一個會藉挑剔工作為由處處找我麻煩的人共事，那對方也要做好被我反抗的覺悟。
只要是正常人都不會想在工作中增加敵人，但如果對方刻意找麻煩時都不介意這點了，我覺得自己採取反抗也不必替對方想太多，在抗爭告一段落前不用想著要和對方改善關係啥的。
我們不是完人也不是神，不可能面面俱到，即使自己能自律不主動樹敵，人一生裡仍總不免會碰到幾次無論如何都難以和對方好好相處的人，如果每次遇到這種的都要由自身的善意作為處理的出發點，那人生反而難過。既然現代人要包容不同聲音尊重不同觀念作為基本文明，那麼遇到主動處處藉工作來給自己找麻煩的人理應先檢討改善自己，而不是受害的自己要主動以善意和容忍去改善關係。

>>31278
雖然有點離題對不起po主 但想詳細一下挖坑過程
有點小好奇wwwww

>>31277
建議先觀察一下
第一個可能就是主管是精障 那你只能硬著頭皮對付了 或是找到機會烙跑
第二個可能就是主管只是程式社群常出現的那種火藥桶憤青 那你跟他聊過幾句打好關係後可能就沒那麼差

第一個基本上是無解 你只能銃回去或是轉職調部門 人生就是 就算你不犯人最後別人一定有機會犯你 跟你結仇不結仇沒關係 你也只能鞏固好自己的圈子做好份內事過好自己日子而已

當然第三種是做不好學問的廢柴沒事找事做 故意找東西罵才踩人讓自己看起來沒那麼廢 這種比較罕見 我只在小學和大學時各見過一個
不過通常這種因為太吵了 吵到大家都聽得到 最後都被看破手腳被鄙視
我之前系上就一個 最後因為種種複雜原因沒人跟他做實驗自己滾出去了還記我們仇 希望他轉的新系那邊的人平安 真的很吵

>>31277
個人在過去的公司同樣跟這種等級的垃O主管交手好幾次
給你點意見參考

>>比如程式上的變量大小寫命名不合公司規範，程式的轉行不夠整齊之類
>>如果是程式有BUG或者功能上的問題那確實沒啥好説，小弟從業7年多還沒見過特意在格式上卡人的。
先說了這個不是刁
你那邊應該是小公司或是小單位，而你的主管八成是從外頭大公司挖過來
這個叫做Coding Style,要求大家用同樣命名邏輯來為函式,變數,結構,封裝等各種物件命名
這樣負責整合的人可以更一目了然這個物件的來源與用途
假設有個函式叫做SendStr() ←從哪裡來的，這個要給誰用，類似這樣的情境
大公司可能隨隨便便就是跨部門專案，或是要維護已經使用了近十年的程式碼，當事人都不可考了
所以會需要透過這種方式在程式碼建構的當下就給予有意義的相關名稱，而非使用註解的方式

而這類Coding Style偏偏又不只有一種。
我運氣很差，在前公司每個軟體主管都得偏好都不同，我已經歷過
◎美國微軟風格
◎美國Google風格
◎美國亞馬遜風格
◎台積電風格
◎台灣豬屎屋通用風格

>>只能理解為他對我不爽所以刻意針對我
Coding Style的用意本來是好的，有問題的通常是使用的人
先跟你打個預防針，會吵這種的主管大概有80%是精障
把寫程式當成是畢生崇高使命的那種精障
如果是技術經理這種比較高級的工程師倒還無彷，如果是要帶人管進度的部門主管會很慘

這東西如果你的部門原來沒有，那本來就是要依循漸進慢慢導入的
畢竟你的單位再過去也已經累積了不少東西甚至都還在線上，沒辦法馬上修改
但這些沒管理能力的精障通常就會要求大家一次到位「因為這樣他才比較好管理大家的Code」
沒錯，他們通常也身兼"程式碼保母"的工作，要求大家上傳到Git前要先給他看過，確認你的程式碼符合它的要求

你們的專案會有一半以上的時間浪費在合code改格式跟主管幫大家上課講Coding Style上
看你們底下組員的配合度而定，如果大家配合度差的話就...

還是要再提一次Coding Style是無辜的
有問題的是那些不懂得帶人，只會用權勢強迫大家只能配合你的那種糟糕主管

再來就是講講如何交手的部分

>>不知道哪裏觸到他雷點。
如果你的主管是前面提到的那80%一輩子的人生榮耀就叫做寫程式的那種精障
那你用這一點挑戰它就是最大的引爆點了
>>小弟從業7年多還沒見過特意在格式上卡人的。

他們要的不是對與錯，是服從
你可以把它想像成那種(在寫程式這件事情上)控制慾超強的偏執狂
我就是王我就是King你們都不能動我的程式碼因為你沒有我畢生研究來得厲害
所以它們的心胸通常比屁眼還小
如果你的專業能力能夠比他強而讓他信服的話，它會變成你職場的好靠山，你會是他的陣前最強愛將
如果沒有把握的話，你要嘛就是當順民
不然就會被視為頑固份子，然後在大主管面前直接捅你刀(by個人經驗
「那個xxx配合度很差，叫他做什麼事情都有意見」
請自我保重

不過這種主管通常放著不管很容易就會自爆，至少我前公司那幾位就是這麼死的
要求程式碼寫得好看漂亮帥氣>>>>>>>>>>>>其他，所以跟他的案子要小心進度落溝
如果你們做的是純軟那倒還無所謂，如果是做系統整合的就小心後面的實機驗證時間都被吃掉了

剩下那20%就是厲害到可以不鳥你們這些跟不上的傢伙，自己一個人單幹把整個案子做完


>>不想因爲這點不爽影響到我的事業
如果你那邊是使用VisualStudio開發的話，VS本身可以建立所謂的規則檔
用內建的自動修改功能直接幫你處理程式的空行縮排大小寫等問題，請多加利用
當然變數函式命名規則那些只能自己勤抄筆記多留一些了

你可以使用這點用比較軟的方式跟你主管要求，請他提供or協助一份規則檔
讓大家以後可以直接沿用，省去相關改code的時間
那種愛表現的主管們通常也是會願意幫助的

>>31331
錯誤更正
>>假設有個函式叫做SendStr() ←從哪裡來的，這個要給誰用，類似這樣的情境

假設有個函式叫做SendStr() ←這東西從哪裡來的，要給誰用，都沒有人能夠知道
類似這樣的情境