更新於 2024/07/08閱讀時間約 5 分鐘

【🔒 江湖一點訣】不要讓軟體開發引發 🥊 超派鐵拳 的對立內耗

近期新聞炒的沸沸洋洋的Toyz超派事件, 相信大家已經都耳熟能詳了吧! 一個是美食公道伯, 專門評論美食, 另外一個則是餐廳的經營者, 兩者因為立場不同難免衝突, 若我們以第三方的角度來看這件事情, Toyz身為美食公道伯就像是QA一樣, 在替客戶們把關品質, 而餐廳經營者就像是產品研發的角色, 背後付出了大量的金錢與心力, 產品就像新生兒誕生一般, 對於產品研發者來說非常重視每一分回饋, 那兩者間所關注的點就產生了認知上的差異了, 就像底下這張圖, 兩個人站的地方不同所看到的結果也有所不同, 自然就容易引發意見不合及爭端。

raw-image



關於超派事件在這邊我們就不多贅述了, 我們僅針對事情的角度對應到軟體開發, 如果想要了解詳細過程請至: Toyz超派又槓上!超派鐵拳、始末一次看


另外!另外! 溝通的藝術也歡迎參考以下篇章, 讓我們不只是程序猿,更是創造價值的創作者。


超派事件跟軟體有什麼關聯呢?

我們乍看之下只是一個新聞事件, 哪能聯想到軟體研發啊! 但其實道理相通, 我們研發的產品第一線就是面對廣大的客戶們, 當然過程中少不了嚴格的檢視, 而檢視的過程中也難免被批評的體無完膚, 但事實上我們應該虛心的接收批評, 這樣有進步的空間。

從完整產品到開發流程及程式碼都可能是被審核的重點, 而身為開發者的我們很容易陷入一個迷思, 那就是「我開發的程式碼怎麼可能有錯!!!! 一定是你們雞蛋裡挑骨頭吧!」, 而檢核產品的第一線內部角色就是「QA」, 對於QA來說主要的任務就是確保產品的品質, 心裡會想說:「為什麼產品一直有BUG!!! 難道就不能好好的開發嗎!!!」。

兩者的立場不同、認知不同, 自然就會有意見上的不同而有所衝突, 加上公司的績效制度, 這種內部的衝突自然就成為公司的內耗問題, 相信是大家都不樂見的狀況吧! 而且QA與開發只是公司的一小環節, 那麼如果我們細想到更多的角色呢? 這一點一點的問題只要引爆, 對於大家來說都是沒有好處的傷害。

身為開發者應該如何減少被批評呢?

我們應該都不想因為「程式碼像大便💩」、「一堆BUG🐞爛死人」…等理由, 被其他人尖酸刻薄的指出錯誤, 而引發鐵拳攻擊吧!

大家在同一個地方工作賺錢都非常辛苦且不容易, 我們應該相互體諒跟包容, 也做好自己應該值守的品質把關, 相信身為頂尖開發者的我們都希望自己的成果被肯定與讚賞吧! 當然複雜的程式碼絕非我們自己能夠看的全面的, 也需要搭配一些協作審核、自動化檢核機制來輔助我們。

這邊我們就非常推薦大家關於幾個良好的寫作習慣的主題:

MR機制創造共同學習與審核的日常作業

MR全名就是所謂的Merge Request, 也就是合併請求, 這套流程機制除了讓我們開發者自行檢視彼此的程式碼之外, 也能夠結合自動化, 如此一來就算公司沒有QA角色也能夠讓產品具有一定的基礎品質, 至少交付給客戶的時候不會因為一些缺陷導致客戶的抱怨與爆氣, 這部份我們之後會在「」進行更詳細的說明與分享, 歡迎加入共學。

那在這邊也提供您一個蠻值得閱讀的資源:

你發的是Merge Request還是Monster Request?

適當的讓機器當QA

機器不像我們人類很容易有情緒上的波動, 它們可以根據我們給予的指令執行動作, 而我們可以設定好一些檢核的規則給他們定期幫我們擔任第一線的把關者,如此一來當產品出廠前會有任勞任怨的自動化QA幫我們檢查, 我們也不會因為「人」的情緒波動引發衝突及困擾, 這部份我們也非常推薦您閱讀「【🔒 Python 先修班】🧐 請加入自動化QA(pre-commit)來幫我們檢核程式碼」 裡面不僅包含實作, 也分享了一些概念脈絡, 而我們也希望您能夠從中得到一些啟發。

結語

好了, 今天的主題有點扯遠了, 我們回到超派鐵拳事件, 我們雖然會因為立場及認知不同而引發衝突, 但只要我們在衝突前能夠多站在對方的立場著想, 找出共同交集的部份, 相信就能夠減少許多紛爭, 最後推導出利他也利己的作法。

軟體的開發也不只有技術的鑽研, 更多的是人與人之間的溝通與討論, 因此我們在開發的過程中會需要注意到幾個重要的原則, 那就是先把自身做好, 透過AI協助我們排除掉繁瑣日常事務, 將重點著重於與「人」的高品質互動, 減少分歧與紛爭。

那軟體的部份我們也會希望做好自身的品質, 讓我們的產品倍受考驗時能夠減少批評, 得到更多的正面回饋與鼓勵, 最後也非常歡迎您來到「🔒 阿Han的軟體心法實戰營」共同學習軟體相關的心法與知識。

分享至
成為作者繼續創作的動力吧!
© 2024 vocus All rights reserved.