iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 29
2
Agile

30天利用教練式引導建立指導新人的SOP系列 第 29

教練式引導新人SOP總整理(一) – 學習是一種持續改善的過程

持續改善」(Kaizen)的方法,最初是由日本持續改進之父豐田汽車公司會長-今井正明,所提出的管理概念,是指逐漸、連續地增加改善。


後來這個方法,引入戴明PDCA的概念,並追求質量第一為優先。敏捷崛起後,利用sprint疊代、review加上retro的方式,達到持續改善的效果。

即使在任何階段,都有可以再改善的項目與方法。

就像現在的團隊有點像「學習型組織」了? 但學習本身並沒有停止,學習是無止盡的,引導新人也是。你永遠都對於Team Member有所期待,你永遠都在引領著他們。

「一旦走入『持續改善』的這條路,是回不了頭的。」這是一張永遠沒有停靠站的單程車票。

也就是說,「選擇,比努力更重要。」

https://ithelp.ithome.com.tw/upload/images/20181029/200057227Be48oY0Ll.png

「時間向前走,沒有盡頭,只有路口。」

是你自己選擇了「學習」、「持續改善」這條路,剩下的就只是時間與勇往直前罷了。

https://ithelp.ithome.com.tw/upload/images/20181029/20005722wAKYH8M0M1.png

我選擇留下,團隊成員也是。React讀書會願意留下來的人也一樣,他們已經為自己邁出了另一大步。

我們的團隊: https://goo.gl/pkaWXf


沒有機會讓大家仔細了解我們團隊是怎麼運作的。但我想在前一篇U型修練的三個階段,我們團隊正處於逐漸前往第二階段,自然流現的狀態。譬如:

「這個設計不符合原先平台的基本樣式設計,是否可詢問A Team確認是否這樣設計有特別的意思,或者改回就用原本預設的樣式?」

「我詢問B Team他們是否可配合commit的時候做CI,順便幫前端webpack做自動bundle build files & commit? 但還考慮到pre-prod 和 production的狀況。目前無法突破。」

「或許只在上測試區的時候做bundle build files & commit。在pre-prod 和 production直接拉code放上去就好。」

「我跟PO提出應該把這一區塊改成跟APP一樣左右滑動的時候,ICON會跟著有反饋的震動效果。」

「desktop版本的menu tree我想重構。」

「mobile的filter我想一次全部換掉。」

「跟A team什麼時候真正在同一個git上開發...。」

很多這樣的問題,以及解決方法不斷地在團隊中流竄著,並逐一被解決。

這是我所觀察,不一定正確,但至少有開始了。

每一天的站會,每一週的例會,每一次的1 on 1 coach,都是重要的,要不斷地重複重要且相同的觀念,不斷地與團隊成員對焦「願景」,達成共識。

相信最近大家都很有感覺,在列車行駛的過程中,火車頭的帶領是很重要的。不斷的修正列車行駛的路線,符合正軌,與達成這台列車所有乘客共同的目標與願景,也就是平安到達目的地。

團隊的領導也是。

很多剛認識我的人,會跟我說,你看起來就是一個脾氣很好的人,你要怎麼管這些人?

再問問自己,我是好主管嗎? 我到底是「好主管」還是「好人」? (from 游舒帆gipi)

最近朋友A的公司也面臨這樣的問題,人們所認為的好人卻不是個好主管,甚至對於整個組織的發展是有害的。

所以朋友A想聯合其他同事,找更上上層的主管,一同想辦法拔掉這位好人主管。此為「下剋上」的情節。雖然不成功便成仁很危險,但想必這樣的狀況積怨已久,而不得不這麼做了。我朋友A認為,

「主管他並沒有扮演好一個主管應該扮演的角色,他沒有帶領團隊成員成長,也沒有帶領部門成功,在他底下只是過的安逸,但沒有成長,部門的績效也不好,這樣在公司也不會有什麼樣的未來。而這些,都是這位主管所間接造成的。」

又回到第一篇我說的,那種相安無事的好。

或許有人會覺得朋友A好好待著,不惹事又可以爽爽過,不好嗎?

第一年你覺得不錯,再過兩年、三年,甚至十年,你可能已經麻痺了。

激勵領導大師Simon Sinek在演講中指出,好的leader,是當團隊遇到危難之急時,sacrifice自己,總是eat last;但除此之外,我認為能帶領團隊走出新的方向,並且讓每個人在團隊中,都能夠有展現自己價值的機會,那才是真正的leader。

這都是為了體現五項修練的系統性思考,最終成為持續改善的「學習型組織」。

工具以及方法都可以再找,但心態與思維難以改變。

如同我團隊投影片中所說,敏捷發展到後來,從疊代變成持續整合,並逐漸改善,成為Dev(開發)與Ops(維運)之間的合作文化,這就是DevOps,所以說DevOps是一種思維,一種團隊與團隊之間自發性的改變。

這樣各項的改變正持續發生在我們的團隊與週遭...

① 減少組織之間的穀倉效應(Silo Effect)

  1. 與ops leader密切配合,並在做任何前端上線前,與ops leader討論並主動召開會議,討論上線後的做法;另外在上線維運期間的問題,也配合協助並指導其提出解決的solution。
  2. 與QE Team在開發前就先對焦測試案例(test cases),確認彼此對需求的認知是一致的,若有任何疑問,找PO一起討論。並在上測試環境之前,RD自動or手動自己跑過一次acceptance criteria,確保交付給QE的Quality。到上了pre-production和production,RD一樣主動協助確認一次自己做的需求是否都OK。

② 接受失敗,視其為開發週期中的一個元素 (就是團隊feel safe to take risk)
團隊成員在完成需求上線後,發生問題,協助其找出問題的核心;並鼓勵團隊成員重構程式碼,勇於面對重構後會有的side effect風險,只要做好足夠的防護措施,上線後的問題就是面對並解決它,不責備。

③ 逐漸改善
在專案很趕的狀況下,使用了暫時的症狀解。要求團隊成員要在下一次提出根本解,並且寫下plan逐一改善。

④ 善用工具和自動化
能自動化的東西,就該自動化。比如程式碼風格統一就使用ESlint & Prettier;與Art team之間的溝通就build up style guide;與後端的API串接,在還沒有資料時,就架設mock server做測試。

⑤ 任何事都是可以被量測的
我們每一季前都會和團隊成員,訂定季目標,確認本季的考核方式,會用數據化可測量的實際數字來做評核。

今天下午去參加facebook id8台灣VR/AR開發者大會,本以為會有很多宅宅工程師,後來發現是與FB合作的各家廠商間的打廣告競賽,一位曾經是developer的創業者這麼說:「台灣有很多優秀的工程師很可惜,應該多走出去,open mind一點,多思考這市場、老闆在想什麼,讓台灣走出去。其實台灣在軟體業會很有競爭力的。」

這是思維的改變。想想看,我們自己追求的到底是什麼? 不斷地問自己,跟自己過不去,因為你自己的路只有你自己去走才知道。需要我們走出去,去看待這個世界。


上一篇
學習五項修練: U型修練
下一篇
教練式引導新人SOP總整理(二) – 教練,我想寫程式
系列文
30天利用教練式引導建立指導新人的SOP30

尚未有邦友留言

立即登入留言