#2022ProudMoment
3 posts
Avatar of 林鼎淵.
Tech Lead
4 months

#2022ProudMoment

我覺得願意直視問題,把問題攤在陽光下,應該是我最大的成長。

「我們學了很多方法,但在實務上卻各種出包。」我想這應該是很多開發團隊的心裡話,儘管大家都能看見問題,也嘗試導入各種方法試圖解決;但很多時候別說進步,有時甚至還會走回頭路,這邊就來分享這段時間以來,團隊面臨的問題,以及初步的解決方案。

不過解決方案是否有效、會不會衍生新的問題,就看之後的連載了😅

▋客戶、專案經理、開發人員,3 者沒有共同語言

為了讓每個角色各司其職,在溝通需求時,都是由專案經理跟客戶溝通,得到結論後再跟開發人員說明。

儘管看起來很合理,但在實務上容易遇到以下問題:

1. 名詞定義:同一個名詞,大家的定義都不一樣;這導致 3 者在溝通上雞同鴨講,彼此以為對方懂了,但根本在說不一樣的東西。

2. 專案經理與開發人員都不具備專案的背景知識:如果碰上大型專案,在開發團隊沒有相關背景知識的狀態下,光是架構的設計就很容易出問題;又因為沒有相關背景,所以根本沒有共同語言。

3. 規格書不明確:開發人員按照規格書來開發,但如果規格書很模糊,工程師在開發時會浪費很多時間在額外的溝通。(最悲慘的狀況是工程師放棄溝通,選擇按造直覺來開發)

上面的問題,想嘗試透過以下方法解決:

1. 專案經理與開發人員以「英文」來溝通欄位:資料庫都是英文欄位,如果規格書上的欄位都以中文表達,就不能怪工程師在開發上直接選擇「感覺」意思最接近的欄位。

2. 由專案經理建立一套「中英文名詞定義對照表」:內部可以用英文律定欄位,但跟客戶溝通時,大多情況還是使用中文;所以需要建立一份對照表,避免彼此的誤解。

3. 需求規格參數明確:對客戶來說好像差不多,但對工程師來說,差一個欄位就好似差了一個宇宙。

▋Scrum 淪為形式

我們期待導入「Agile(敏捷)」開發後,可以提升團隊的生產力、向心力,但實際上會遇到以下問題:

1. 只在意自己要講什麼:跑 Scrum 的原意是希望大家瞭解彼此工作的進度,透過資訊透明讓專案更加順利;但很多時候我們只在意自己今天要講什麼,這種狀況在 Scrum Master 為固定人選時更為明顯。

2. 規格不明確導致需求時常變更:在 Sprint Plan 時,我們會先估點來計算每個人工作需要的時間;但在開發階段若發現規格有問題,專案經理就要再跟客戶溝通,這一來一往與程式調整的時間,將會完全破壞這個 Sprint 預計要完成的項目。

3. 安排額外的任務:如果臨時安排不在這個 Sprint 的任務給工程師,又沒有明確告知任務優先度,當這種狀況頻繁發生時,Scrum 就變成單純的個人報告,工作內容逐漸與 Sprint Plan 脫鉤。

上面的問題,想嘗試透過以下方法解決:

1. 讓每個人輪流當 Scrum Master:在這個位置上,就算不願意,你還是得知道每個人的進度、卡住的問題、要做的事。

2. 指派任務前,充分確認客戶需求:如果在商談時就定下明確的需求規格,那工程師就有開發的依據,發現邏輯問題時也能第一時間提出,不至於自由發揮到一半才發現問題。

3. 盡量不要讓突發狀況影響現在的 Sprint Plan:工程師也是人,臨時安排的工作勢必會影響到現在的專案,如果可以,突發的狀況盡量安排到下個 Sprint。

▋專案到最後時刻才發現一堆 Bug

我們花 20% 的時間完成 80% 的功能,卻在最後 20% 的功能上花了 80% 的時間。

如果問題發生不只一次,那肯定要想辦法解決;通常會有這樣的狀況是因為:

1. 架構規劃不良:專案啟動後,一開始大家都是摸著石頭過河,無法確定自己現在的方向是否正確;往往到後期,才發現當初的規劃有某些後遺症。

2. 前期進度按照時程走很安心:因為前期每個 Check point 都很準時,所以產生接下來也會繼續準時的心理預期。

3. 想要一次交卷:有時我們會想等作品完成到某個程度後再給客戶看,但…有時客戶看過後會發現許多與他們理念不合的設計。

4. 新舊系統功能不吻合:就算功能都是 Copy&Paste,但程式底層的運作邏輯往往不同,部分欄位可能也存在誤會;你以為執行得很順利,殊不知早已偏離方向。

上面的問題,想嘗試透過以下方法解決:

1. 別管架構,先交出 MVP:我們規劃了太多功能,卻沒有一個 MVP,在一切都不明朗的狀態下,能規劃出好架構根本是靠運氣;與其在前期完成那麼多功能,還不如先交一個勉強能動的 MVP,以此向客戶確認是否符合需求。

2. 在一開始規劃時,就把容錯時程拉長:過往的經驗告訴我,意外通常在最後一刻才發生;因為在後期,我們才有辦法用整體的思維去看專案。(如果團隊有經驗非常豐富的架構師,那有機會規避這些問題,筆者目前還不具備這個實力)

3. 開發階段頻繁更新系統:讓客戶隨時體驗最新的功能,如果與預想不合也可以盡快作出調整;避免工程師要砍一堆程式,做無意義的重工。

4. 如果要改寫舊系統,就需要對方提供可以驗證的資訊:通常舊系統程式的參考價值不高,我們只能從操作流程來推估資料間的關聯性,但這些「都是靠想像」的,如果客戶沒有提供足夠的舊系統操作案例給工程師來驗證,就很可能開發出無法與舊系統銜接的系統。

▋Tech Lead 沒辦法發揮應有的作用

我們期待 Tech Lead 可以照顧到整個團隊的技術,但如果開發時程太趕,在 Tech Lead 也投入大量時間在開發時,會衍生以下問題:

1. Code Review 淪為形式:連自己的任務都快做不完了,Code Review 時頂多看一下 Coding Style,沒辦法從整體的架構去判斷他的演算法、邏輯是否合適。

2. 專案程式碼品質下降:因為 Code Review 不確實,很多功能只是為了解決當下的問題,這種時候很容易創造出一堆耦合性高的程式。

3. 沒辦法顧及所有人的進度:如果專案經理與 Tech Lead 配合不夠默契,那很容易發生 Tech Lead 埋頭開發,沒有從整體的視角來看專案的進度。

上面的問題,想嘗試透過以下方法解決:

1. 分配給 Tech Lead 的開發任務,不要超過他 60% 的工作時間:如果把 Tech Lead 當單純的 Developer 來使用,那團隊程式碼的品質就無法保證;為了避免日後要花更多的時間解決後遺症,建議多給 Tech Lead 一些靈活運用的時間。

2. 專案經理與 Tech Lead 訊息流暢:就算有專案管理系統輔助,但每個任務進度的細節、時程還是專案經理最清楚;如果能在發現進度 Delay 前期就做適當的調整與釐清,也許不會走到時程緊繃這一步。

3. 律定專案管理系統操作方式:開發人員 Commit 的內容也需要附註在 Ticket 上面(盡量白話),這樣更方便專案經理掌握實際進度;若該 Ticket 有相依性(後端完成後交付給前端),那開發人員也要將相關的 API doc 附在上面。

▋團隊失去成長動能

我們期待團隊裡的每個人都能夠隨著專案持續成長,但在管理出現問題時,團隊會慢慢轉變為 80/20 法則的模式,也就是 20% 的人完成了 80% 的任務,下面是筆者個人推估的原因:

1. 到 Deadline 時,總有人能幫忙解決問題:如果團隊成員發現沒做完的東西,在接近 Deadline 時就會有其他人來拯救,那很可能就會養成依賴性,喪失自己解決問題的能力。

2. 獎懲機制不夠透明:如果大家發現拼死拼活的結果跟躺平耍廢一樣,那我們為什麼不躺平?

3. 連坐制度:Deadline 就壓在那裡,你幫了,他無法成長;你不幫,專案就爆掉,自己也跟著倒霉,這種狀況到底要幫還是不幫?

上面的問題,想嘗試透過以下方法解決:

1. 幫忙時只給方向:可以提供一些關鍵字、網頁、參考資料、過去的程式碼,但不要直接解決問題。

2. 如果必須親自解決問題,先確認對方已經發揮所有潛能:儘管我們都希望給方向就能解決問題,但每個人的背景知識不同,如果給方向還是無法解決;在親自解決問題前,要先請對方說出自己過去所做出的研究,確保他已經盡力,任務難度真的超過了他的能力範圍。

3. 不影響健康的壓力:有壓力才會成長,如果發現能力需要提升,那有必要提醒對方,在下班、放假後的鑽研是必須的。

4. 律定獎懲機制:我們希望每個人都有想成長的自覺,但如果有必要,賞罰機制還是要存在的。

▋不是每個成員都按造流程走

我們秉持互信的原則來合作,就算有些人沒按造流程走,只要不出包,也可以睜一隻眼閉一隻眼;但如果這些行為產出的結果不符預期,甚至導致團隊損失,那勢必要做出改善。

這邊就以程式碼 Commit&Push 舉例,原則上我們期待每位開發人員一天至少 Push 一版程式,且裡面 Commit 都有詳細紀錄更動的部分。

會有這個要求是因為專案是「協作」的,如果有人憋了一個禮拜才 Push 一大包,會衍生以下問題:

1. Tech Lead 很難 Code Review:因為內容太多、太雜,釐清功能所需的時間反而更多。

2. 如果架構有問題,改善成本太高:如果在 Code Review 時才發現程式的結構問題,那又需要浪費很多時間改寫。

3. 如果把所有更新的內容塞到一個 Commit 裡面,很難對應功能與程式:因為程式往往散落在多個檔案,如果 Commit 內容太多,就很難知道彼此的對應關係。

4. 萬一發生狀況,接手的人會崩潰:如果做完的功能沒有 Push 上去,接手的人等於要重寫。

上面的問題,想嘗試透過以下方法解決:

1. 向開發人員說明定時 Commit&Push 的重要性:開發人員可能不知道自己這麼做會影響到其他人,需要講清楚問題嚴重性。

2. 如果任務太複雜,盡量做功能上的切分:有時被分配到的任務涉及面太廣,導致遲遲不敢 Push 上去;面對這種情況,可以依據開發的進度來 Commit&Push,反正有 Git 這種程式碼版控系統,不會影響到主分支。

▋血淚小結

1. 問題是長期沒改善積累而成的,想解決肯定會遇到不少阻力。

2. 只有被攤在陽光下的問題,才有機會被解決。

3. 許多問題互為因果,如果不解決,問題會向病毒般不斷變種。

4. 每個人都在適應自己的角色,專案經理不知道需求規格怎麼寫才能讓開發人員理解,開發人員不清楚遇到問題時要如何解決,Tech Lead 不確定怎麼帶人才是最合適的。

5. 規則律定出來就要執行,如果沒有執行;那其他乖乖遵守規則的人,也遲早會學壞。

#Scrum #Agile #Communicate #Deadline #Rule #Teamwork

一不小心打太多,如果覺得閱讀起來有點吃力,可以看我的部落格喔~

546 Views
Avatar of Sindy Chen.
Associate Marketing Manager
4 months

和大家分享你的 #2022ProudMoment

恭喜 Ries Enya Yurike 成功戰勝難搞的眼線,也恭喜我自己在 2022 年上半被升職為 Associate Marketing Manager!

Avatar of Ries Enya Yurike.
SaaS Support Specialist Intern at CakeResume
4 months

2022 年已經過了一半,有沒有什麼事情 (不論大小) 令你感到自豪呢?與我分享你的 #2022ProudMoment

我認為小成就不應該被忽視。每個人應該為自己在生活中所有實現的目標,無論大小,感到驕傲。每一個小小的里程碑都造就了今天的你,引領你到達現在的高度。

對我來說,我在 2022 年讓自己引以為傲的一件小事就是學會如何更流暢地畫好眼妝,特別是眼線的部分 👁️💅

身邊圍繞著很多化妝很厲害的朋友們,讓我從 14 歲開始就一直想學化妝。但是苦於沒有機會嘗試,因為我媽媽總是在所有活動中搶著扮演化妝師的角色。

直到我一個人搬到台灣讀大學,事情有了轉機。

起初,我還是忍受頂著一張素顏和朋友出遊、聚餐。直到大四,我開始在 YouTube 上探索講解不同化妝技巧的影片,包含如何畫出完美的眼線,這也讓我重新燃起對化妝的熱情,並從去年底開始在和朋友外出時嘗試化妝。

然而,任何事情都是 "practice makes perfect" (熟能生巧) 的,所以最初幾次的嘗試並不如我想像中的容易,成果也和理想中的相差甚遠,這些挫折讓我幾次想要放棄。

因此在 2022 年初,我向自己承諾我會更頻繁地 “practice”。

現在,踏入 2022 年的下半,老實說,沒有什麼能夠比 "practice makes perfect" 更適合形容我的情況。我堅持不間斷地練習讓我現在可以在 5 分鐘內畫出精緻又滿意的眼線 #bigflex

這是到目前為止,我在 2022 年對自己引以為傲的一件小事,你的呢?

1145 Views
Avatar of Ries Enya Yurike.
SaaS Support Specialist Intern at CakeResume
4 months

2022 年已經過了一半,有沒有什麼事情 (不論大小) 令你感到自豪呢?與我分享你的 #2022ProudMoment

我認為小成就不應該被忽視。每個人應該為自己在生活中所有實現的目標,無論大小,感到驕傲。每一個小小的里程碑都造就了今天的你,引領你到達現在的高度。

對我來說,我在 2022 年讓自己引以為傲的一件小事就是學會如何更流暢地畫好眼妝,特別是眼線的部分 👁️💅

身邊圍繞著很多化妝很厲害的朋友們,讓我從 14 歲開始就一直想學化妝。但是苦於沒有機會嘗試,因為我媽媽總是在所有活動中搶著扮演化妝師的角色。

直到我一個人搬到台灣讀大學,事情有了轉機。

起初,我還是忍受頂著一張素顏和朋友出遊、聚餐。直到大四,我開始在 YouTube 上探索講解不同化妝技巧的影片,包含如何畫出完美的眼線,這也讓我重新燃起對化妝的熱情,並從去年底開始在和朋友外出時嘗試化妝。

然而,任何事情都是 "practice makes perfect" (熟能生巧) 的,所以最初幾次的嘗試並不如我想像中的容易,成果也和理想中的相差甚遠,這些挫折讓我幾次想要放棄。

因此在 2022 年初,我向自己承諾我會更頻繁地 “practice”。

現在,踏入 2022 年的下半,老實說,沒有什麼能夠比 "practice makes perfect" 更適合形容我的情況。我堅持不間斷地練習讓我現在可以在 5 分鐘內畫出精緻又滿意的眼線 #bigflex

這是到目前為止,我在 2022 年對自己引以為傲的一件小事,你的呢?

484 Views

Explore hashtags

#naovethoga

49 posts

#ruthamcau

49 posts

#xulymuihoi

49 posts

#huthamcau

49 posts

#Farry文章

45 posts

#kotlin

41 posts

#leetcode

38 posts

See more posts about #2022ProudMoment.