หน้าที่ของ Scrum Master คือทำอย่างไรก็ได้ให้ทีมทำงานได้อย่างราบรื่น

เคยได้ยินคำว่า Scrum Master ไหมครับ หลายคนอาจจะเคยแต่ก็ยังไม่ค่อยเข้าใจ ผมจะมาเล่าเรื่องราวของผมในฐานะ Scrum Master ให้อ่านกัน แล้วคุณจะเข้าใจตำแหน่งงานนี้มากขึ้น

ผมเคยทำงานที่ Morphosis มา 2 ปีครึ่ง และย้ายมาที่บริษัทแม่อย่าง Seven Peaks ได้ 1 ปีเศษๆ

ก่อนหน้านั้น ผมเริ่มจากการทำงานเป็น PM หรือ Project Manager ก่อน ทำอยู่ประมาณ 3 ปี โดยปกติแล้วงาน PM มันจะมีอยู่สองสายคือสายพัฒนาซอฟต์แวร์ กับสายงานทั่วไป ซึ่งผมมาจากสายทั่วไปก่อน เป็นบริษัทที่ทำเกี่ยวกับสิ่งพิมพ์ ตอนนั้นเขามีโปรเจกต์ออกโปรดักต์ใหม่ ผมก็จะไปดูเรื่องการปฏิบัติงาน การบริหารจัดการ งบประมาณ แล้วก็ทรัพยากรที่มี ตามหลัก PM

ทีนี้ Benjamin เขาก็ชวนผมไปทำงานที่ Morphosis แต่เป็นการทำงานแบบ PM ที่ใช้กระบวนการทำงานแบบ Scrum คือเหมือนเป็น PM ผสม Scrum Master ในคนเดียวกัน เท่ากับว่ามันจะมีการดูแลเรื่องทีมงานและรับ requirement ต่างๆ จากลูกค้าด้วย และนั่นก็เป็นจุดเปลี่ยนในเส้นทางอาชีพของผม

พอย้ายมาที่ Seven Peaks ตำแหน่งงานก็มีการแยกเป็น Scrum Master ออกมาชัดเจนมากขึ้น เพราะเขาจะมี PM และ PO (project owner) แยกต่างหาก ทุกวันนี้ก็เลยทำ Scrum Master ประมาณ 70% อีก 30% เป็น PM ครับ

จุดเริ่มต้นในการทำงานสาย PM/Scrum Master

จริงๆ แล้วผมก็เรียนจบสายไอทีนี่แหละครับ แต่ไม่ค่อยถนัดเขียนโค้ดสักเท่าไร เพราะรู้สึกว่าตัวเองมีสมาธิค่อนข้างสั้น เลยคิดว่าไม่น่าจะไปรอดในสายงานนี้ ตอนที่ทำโปรเจกต์จบมันก็จะมี open house เพื่อแนะนำ career path ให้เรา เขาก็จะบอกว่าเรียนจบไปทำงานอะไรได้บ้าง หนึ่งในนั้นก็คือ PM ส่วน Scrum Master แต่ในยุคนั้นยังไม่ค่อยเป็นที่รู้จักในประเทศไทย

ผมก็เริ่มจากการทำงานเป็น project coordinator ซึ่งตอนนั้นผมก็ยังไม่รู้ว่า PM คืออะไร ทำงานแบบไหน ประสานงานกับ developer อย่างไร ในช่วงนั้นก็ไปเข้าพวก Networking Event ต่างๆ ไม่ก็งาน Event ที่จะมี Projects มา Pitch Investors แล้วก็เลยได้มีโอกาสพบเจอคนในสายนี้มากขึ้น ก็คอยแอบถามเรื่องการทำงาน และสุดท้ายก็ได้ทำงาน PM ผมก็รู้สึกชอบนะ เพราะถึงผมจะไม่ได้ทำงานเป็นโปรแกรมเมอร์โดยตรงแต่อย่างน้อยก็ยังได้อยู่ในสายงาน development อยู่ ยังคุยกับเพื่อนๆ รู้เรื่อง แล้วพอได้ยินชื่อ Scrum Master ก็เลยสนใจและไปศึกษาหาความรู้ดูด้วยตนเองว่ามันเป็นอย่างไร ใช้กระบวนการทำงานแบบไหน

ทีนี้ พอผมได้เรียนเกี่ยวกับ Scrum Master ในคอร์สออนไลน์ที่หนึ่งเพื่อเอาใบรับรอง ซึ่งทำให้ผมได้ความรู้ที่ช่วยให้ทีมสามารถทำงานตามหลักการ Scrum ได้ พอเอาหลักการเหล่านี้มาใช้แล้วช่วยให้งานไหลลื่นขึ้น อาจจะเป็นเพราะว่า developer บางคนอาจจะคุ้นเคยกับหลักการ Scrum มาบ้างแล้ว ก็เลยทำงานง่ายขึ้น แต่ Scrum มันมีรายละเอียดลึกมาก มีการจัดการสำหรับบริหารจัดการทีมเล็กหรือสำหรับทีมใหญ่ มันไม่ได้จบแค่ตรงนี้ สามารถนำไปปรับใช้ได้หลากหลาย

ความสนุกของการเป็น Scrum Master คือการเรียนรู้อยู่ตลอดเวลา ได้ช่วยให้ทีมผ่านพ้นอุปสรรคต่างๆ หรืออำนวยความสะดวกให้พวกเขาทำงานได้ง่ายขึ้น และโปรเจกต์สามารถเดินหน้าต่อไปได้ อาจจะเครียดบ้าง และมีกิจวัตรที่ต้องทำบางอย่าง แต่ไม่ใช่งานที่จำเจหรือน่าเบื่อเลย เพราะแต่สัปดาห์มี Challengeใหม่ๆ เข้ามาตลอด ไม่ว่าจะเรื่องคน เรื่องทีม บรรยากาศในทีม ทักษะของคนในทีม สิ่งเหล่านี้คือโจทย์ที่ต้องเจอ

ยกตัวอย่างเช่น ถ้ามีคนในทีมสองคนที่ไม่ถูกกัน ผมก็ต้องทำอย่างไรก็ได้ให้สองคนนี้ในทีมเดียวกันได้ ทำงานร่วมกันได้ แล้วเรื่องส่วนตัวที่มีปัญหากันก็ไปเคลียร์กันข้างนอก หรือถ้าใครติดปัญหา ทำอะไรสักอย่างไม่เป็น ถ้าผมสามารถแนะนำเขาได้ก็จะบอกเขา หรือต่อให้ไม่รู้ก็ต้องพยายามทุกวิถีทางที่จะช่วยสนับสนุนเขาจนกว่าเขาจะทำได้

ความแตกต่างของ PM กับ Scrum Master 

หลายๆ คนมักจะสับสนว่า PM กับ Scrum Master แตกต่างกันอย่างไร ผมขออธิบายว่า PM เนี่ย ด้วยความที่เป็น Management (ตามชื่อ) หลักๆ แล้วเขาก็จะดูเรื่องของ scope งาน, ไทม์ไลน์, ต้นทุน, คุณภาพ, ทรัพยากร, ผู้มีส่วนได้ส่วนเสีย, และการสื่อสารภายในทีม เป็นต้น 

แต่บริษัทส่วนมากจะเอา PM กับ Scrum Master มารวมเป็นคนเดียวกัน แม้ว่าจริงๆ แล้ว Scrum Master จะไม่ใช่คนที่ต้องมาทำเรื่องพวกนี้เลย ไม่ได้มีหน้าติดตามงานหรือบริหารจัดการทีม อยากให้มองว่า Scrum Master เป็นเหมือนโค้ชคนหนึ่งที่คอยให้คำแนะนำคนในทีม ทำอย่างไรก็ได้ให้คนในทีมทำงานด้วยกันได้ อย่างราบรื่นและมีประสิทธิภาพ

ทีมพัฒนาซอฟต์แวร์มักจะทำงานเป็น sprint ในแต่ละ sprint ก็จะมีเป้าหมายอยู่ว่าต้องการอะไร คุณค่าทางธุรกิจที่ลูกค้าคาดหวังคืออะไร หน้าที่ของ Scrum Master ก็คือ ต้องทำให้ทีมสามารถทำตามเป้าหมายเหล่านี้ที่วางไว้ได้ 

แต่พอดีว่าที่ผมทำมันจะไม่ใช่ Scrum Master แค่อย่างเดียว มันยังมีบางส่วนของ PM อยู่นิดหน่อย อย่างเช่น เมื่อได้รับ scope งานมาจาก PO ก่อนที่ผมจะเอาไปแยกย่อยเป็นสิ่งที่ต้องทำกับทีม ก็อาจจะต้องดูว่า scope ที่ได้รับมานั้นสมเหตุสมผลหรือไม่ ถ้าไม่ เช่น ไทม์ไลน์อาจจะไม่พอ ก็ต้องมีการโต้แย้งกลับไป หรือเรื่องของทรัพยากร ถ้าทีมมีปัญหาเรื่องขาดแคลนทรัพยากรบางอย่าง หรือขาดทักษะบางอย่าง ผมก็ต้องทำอะไรสักอย่างเพื่อแก้ปัญหานี้ด้วย เป็นต้น 

หวังว่าบริษัทในไทยจะมีการแยกหน้าที่ของ PM กับ Scrum Master ชัดเจนมากขึ้นนะครับ ที่จริงผมก็เข้าใจแหละว่าทำไมถึงรวมกัน เพราะว่าคนส่วนใหญ่โดยเฉพาะลูกค้ายังไม่เข้าใจว่า fixed product กับ agile product คืออะไร ต่างกันอย่างไร 

ในความเป็นจริงแล้ว บริษัทไอทีใหญ่ๆ มักจะมีการแยกหน้าที่ออกไปเลย เป็น PO กับ PM ในระดับผู้บริหาร แล้วก็ Scrum Master ในระดับทีมปฏิบัติงาน ซึ่งผมยังไม่เคยทำแค่ Scrum Master อย่างเดียวเพียวๆ มาก่อน ก็เลยบอกไม่ได้เหมือนกันว่าจริงๆ แล้วถ้าทำแค่นั้นจะสนุกเท่าตอนนี้หรือเปล่า

หลักการ Scrum ที่นำมาใช้กับตัวเอง

สิ่งแรกที่ผมนำมาปรับใช้กับตัวเองก็คือการเป็นแบบอย่างที่ดี คือผมต้องบริหารจัดการตัวเองได้ดีพอ ก่อนที่จะไปบริหารจัดการคนอื่น ต้องทำงานข้ามฟังก์ชันได้ โฟกัสกับสิ่งสำคัญที่ต้องทำตอนนี้ก่อน เข้าใจว่าสิ่งที่กำลังทำอยู่จะก่อให้เกิดผลลัพธ์อะไร เมื่อทำสิ่งเหล่านี้ได้ดีแล้วจึงสามารถไปถ่ายทอดให้คนอื่นๆ ในทีมได้

ด้วยความที่ Scrum มันเป็นเฟรมเวิร์กหนึ่งของ Agile มันจึงทำให้ผมเรียนรู้ที่จะปรับตัวให้เข้ากับความเปลี่ยนแปลงของทีมหรือสถานการณ์ต่างๆ ได้

อุปสรรคสำคัญที่เจอ

เหตุการณ์ที่ผมมักจะเจอคือ ผมรับ requirement มาจาก PO เสร็จแล้วจากนั้นก็ไปตกลงว่าจะทำงานอย่างไร สมมติว่าใช้เวลาทำงานหนึ่งเดือน ระหว่างทางตอนที่ทำ PoC (Proof of Concept) หรือทำ project research ก็รู้สึกว่าบางอย่างมันไม่สมเหตุสมผล ไม่น่าจะทำได้ตาม requirement ที่ให้มา ผมเลยต้องกลับไปหา PO เผื่อว่าต้องเปลี่ยนแปลง requirement บางอย่าง ถ้าจะให้เสร็จภายในเวลาที่กำหนด อาจจะต้องตัดฟีเจอร์บางอย่างออกไป

บางครั้งเป็นเรื่องของงาน ad-hoc เข้ามาแทรกระหว่างที่ทำ sprint นั้นๆ อยู่ ซึ่งจริงๆ ตามหลักแล้วเราต้องปฏิเสธ หรือไม่ก็เอาไว้ทำทีหลังตอนที่ sprint เสร็จแล้ว แต่นั่นมันคือทฤษฎี ในทางปฏิบัติมันทำไม่ได้ เพราะ ad-hoc ก็คือ ad-hoc จริงไหมครับ มันคือเรื่องด่วนที่หลีกเลี่ยงไม่ได้ ผมก็ต้องไปคุยกับทีม ซึ่ง developer แต่ละคนก็ต้องมีวิธีการเข้าหาที่แตกต่างกัน บางคนก็สามารถที่จะพูดกับเขาตรงๆ ได้ แต่บางคนก็ต้องใช้วิธีอื่น จากนั้นก็ค่อยไปคุยกับ PO ว่าทีมเราทำได้เท่านี้

นอกจากนั้นก็เป็นเรื่องการวางทีม ซึ่งที่ผมเจอมาคือ จะมีบางคนในทีมที่ดีมากๆ ไปเลย ระดับเทพ บางคนก็ระดับกลางๆ บางคนก็ไม่ถนัดเรื่องนั้นๆ ผมก็ต้องทำอย่างไรก็ได้ให้พวกเขาทำงานด้วยกันได้ เช่น อาจจะจับคนที่เป็น junior ไปประกบกับคนที่เป็น senior เป็นต้น ขึ้นอยู่กับ requirement ที่ได้รับ scope ของงาน หรือเวลาที่มีด้วย

แต่ถ้าให้เทียบกัน เรื่องที่ยากที่สุดก็คือเรื่องคนนี่แหละครับ เพราะยิ่งคนในทีมมาจากหลากหลายเชื้อชาติและวัฒนธรรม เขาก็จะมี mindset ที่แตกต่างกัน วิธีการเข้าหาก็ต้องแตกต่างกัน เช่น คนไทย บางทีมีฟีดแบ็กอะไรก็พูดตรงๆไม่ได้ เดี๋ยวจะงอน แต่ถ้าเป็นฝรั่ง ก็จะพูดด้วยตรงๆ ได้เลย เป็นต้น

วิธีแก้ปัญหาเรื่องคน

หลักๆ แล้ว เวลาคนมีปัญหากันผมจะเรียกเข้ามาคุย เพื่อคุยแบบเปิดอก บางคนอาจจะคุยในที่เปิดเผยไม่ได้ ก็อาจจะเข้ามาคุยกันส่วนตัว แต่ไม่ว่าอย่างไรก็ต้องแก้ปัญหาจากการสื่อสารกันให้มากขึ้น ถ้าการสื่อสารภายในทีมไม่ดี มันก็จะพังไปหมดเลย และถ้าผมไม่ได้เริ่มเป็นแบบอย่างที่ดีให้พวกเขา ไม่ว่าจะเป็นเรื่องการสื่อสาร คนในทีมก็จะไม่สื่อสารกัน พอไม่สื่อสารกัน ก็จะเกิดปัญหา frontend ทำงานออกมาแบบหนึ่ง backend ทำอีกแบบหนึ่ง DevOps ทำไปอีกแบบหนึ่ง

ถ้าผมอยากให้ทีมคุยกันแบบเปิดเผยได้ ผมก็ต้องแสดงให้พวกเขาเห็นว่าผมเปิดเผยและรับฟังความคิดเห็น ถ้าทีมมีฟีดแบ็กอะไรก็ยินดีฟัง แต่ถ้าผม skip meeting บ่อยๆ หรือผัดวันประกันพรุ่ง ทีมก็จะติดนิสัย “ไว้ก่อน” เหมือนกัน พูดง่ายๆ ก็คือ เราดูแลทีมอย่างไร เราเป็นตัวอย่างให้เขาได้ดีแค่ไหน เราก็จะได้ทีมอย่างนั้น คล้ายๆ เลี้ยงลูก

แนวทางการศึกษาเพื่อทำความเข้าใจคน

เดี๋ยวนี้มีหนังสือแนวจิตวิทยามากมาย หรือไปเข้าร่วมคอร์สออนไลน์ที่เขาสอนเกี่ยวกับการโค้ชคน เขาจะแนะนำว่าเราควรจะเขาหาคนแต่ละอย่างไร สิ่งเหล่านี้จะช่วยได้มาก 

โลกมันเปลี่ยนไปตลอดเวลา กระบวนการทำงานบางอย่างก็เปลี่ยนไป อย่างเช่น เมื่อก่อนเราทำงานกันที่ออฟฟิศ แต่สมัยนี้มีความเป็นไฮบริดมากขึ้น เหมือนอย่างที่ Seven Peaks เป็น มันก็จะมีหลักการบางอย่างที่พิสูจน์แล้วว่า การทำแบบไหนที่จะส่งผลดีต่อองค์กรที่เป็นไฮบริด Scrum Master ควรจะอัปเดตความรู้อยู่ตลอดเวลา

นอกจากนั้นก็ควรไปปรึกษาพวก senior หรือผู้บริการดูว่าพวกเขามีมุมมองอย่างไรต่อปัญหาต่างๆ คุณอาจจะคิดไม่ถึงว่า สิ่งที่ทำลงไปอาจจะส่งผลได้อีกแบบ เช่น เมื่อก่อนผมมักจะคุยกับ Benjamin บ่อย เขาก็จะมีเคล็ดลับมาแนะนำมากมาย 

ย้อนกลับไปเมื่อช่วงแรกที่เริ่มทำงาน Scrum Master โดยปกติแล้วเวลาทีมมีปัญหาหรือติดขัดด้านไหน ก็จะมีแจ้งปัญหา หรือปรึกษา Scrum Master ก่อน ซึ่งตอนนั้นเราก็พยายามหาโซลูชันเพื่อที่จะช่วย และในใจก็คิดว่า developer ก็จะได้โฟกัสในสิ่งที่ตัวเองทำอยู่ แต่การทำแบบนี้มันเป็นการเหมือน babysitting developer 

โดยทุกครั้งที่มีปัญหา ก็จะตรงมาถึงเราเลย บางทีมี community support อยู่มากมาย แต่เราก็ยังพยายามช่วยหาโซลูชันต่อไป จนมาถึงจุดที่เราไม่สามารถช่วยเขาได้ และมันค่อนข้างจะ critical โดยเราก็ได้ปรึกษาทาง management และได้รับคำแนะนำว่าถ้าเราป้อนอาหารตลอดเวลา แล้ววันนึงที่เราไม่สามารถที่จะป้อนได้แล้ว พวกเขาจะหาของกินเองได้ไหม เรามี specialist ในแต่ละสาย แต่ละคน เราควรใช้ความสามารถของพวกเขาได้เต็มที่ ผมก็เลยไปหา best practice ในเรื่องพวกนี้ และเป็นคำแนะนำที่เหมือนกัน ถ้าต้องการให้ทีมพัฒนา ในบางทีเราก็ต้องปล่อยให้เขาหาอาหารด้วยตัวเอง โดยเรามีหน้าที่คอยควบคุมอยู่ห่างๆ

คำแนะนำสำหรับคนที่อยากเป็น Scrum Master

จริงๆ แล้วถ้าคุณอยากเป็น Scrum Master เหมือนผมก็ไม่ต้องเตรียมตัวอะไรมากมายเลย เพราะคุณไม่จำเป็นต้องมีทักษะอะไรเป็นพิเศษ Scrum มันเป็นเฟรมเวิร์กหนึ่ง หมายความว่าใครก็ตามสามารถทำตามกระบวนการในเฟรมเวิร์กนี้ได้เลย แต่ประเด็นคือ คุณจะนำเฟรมเวิร์กนี้ไปใช้กับทีมอย่างไรมากกว่า ซึ่งมันต้องใช้ทักษะส่วนตัว

ทักษะอย่างแรกก็คือเรื่องของ soft skill ที่สำคัญมากในการทำงานร่วมกับคนอื่น เพราะต้องมีวิธีในการเข้าหาคนที่แตกต่างกัน

อีกเรื่องหนึ่งแม้ว่าจะไม่ได้จำเป็นมาก แต่ถ้ามีสักหน่อยก็ดี คือเรื่องประสบการณ์ในการทำงานพัฒนาซอฟต์แวร์ เพราะว่าเวลาที่ต้องประชุมทีมก็จะสามารถอธิบาย ticket ให้กับ developer ได้ บางทีก็ต้องเข้าใจว่าเขาคุยเรื่องอะไรกัน แม้ว่าจริงๆ แล้ว Scrum Master ที่ไม่รู้เรื่องพวกนี้มาก่อนจะทำงานได้โดยไม่ต้องมีพื้นฐานความรู้เรื่องเหล่านี้ก็ตาม เพราะหลักๆ แล้วสิ่งที่เขาต้องเข้าใจมากที่สุดก็คือ คน 

คุณแค่ต้องพยายามหมั่นหาความรู้ อัปเดตตัวเองอยู่ตลอดเวลา แต่ถ้าไม่รู้เรื่องอะไร ก็ไม่ยากครับ ถาม ChatGPT เอาก็ได้ ดังนั้น ถ้าคุณอยากลองก็เข้ามาทำงานนี้ได้เลย เพราะคุณจะได้พัฒนาตัวเองในหลายๆ เรื่อง

ประสบการณ์ทำงานกับทั้ง Morphosis และ Seven Peaks

ด้วยความที่ผมได้มีประสบการณ์ทำงานให้กับทั้งสองบริษัท สิ่งที่ผมมองว่ามีความเหมือนกันและชอบมากๆ คือ บริษัทมีความหลากหลายทางวัฒนธรรมสูง เจอคนจากแทบทุกประเทศ 

สำหรับ Seven Peaks ผมรู้สึกว่าทีม HR พยายามอย่างยิ่งที่จะปลูกฝังให้ทุกคนมีวัฒนธรรมในแบบของ  Seven Peaks ในที่นี้ก็คือ เราเป็นครอบครัวเดียวกัน ทุกเรื่องสามารถที่จะคุยกันได้ อย่างเช่น ทุกวันศุกร์จะมี Friday Bar มีการไปทำกิจกรรม CSR นอกสถานที่ด้วยกัน เช่น เก็บขยะ 

แล้วก็องค์กรของเราไม่มีแผนภูมิลำดับชั้นขององค์กร เมื่อเรามีปัญหาอะไร ผมก็สามารถเดินไปคุยกับ HR หรือผู้บริหาร เพื่อให้เขาช่วยแก้ปัญหาได้ ตอนประชุมรวมใน Townhall ก็จะมี Q & A ที่เราสามารถถามคำถามที่ปกติแล้วไม่กล้าถามให้ผู้บริหารตอบแบบสดๆ ได้ สิ่งเหล่านี้เป็นเรื่องที่ดีมาก

นอกจากนี้ เรายังมี bi-weekly meeting คือ 1 on 1 ที่จะได้มีเวลาคุยกับหัวหน้า ซึ่งดีตรงที่เราไม่จำเป็นต้องคุยแต่เรื่องงาน สามารถคุยเรื่องอื่นได้ มีปัญหาอะไรก็สามารถปรึกษากันได้

มีสิ่งหนึ่งที่ผมเห็น และไม่เห็นในองค์กรอื่นที่เคยทำมาก็คือ senior ทุกคน ถ้าหากมีเวลา พวกเขาจะพยายามช่วย น้องๆ junior หรือ mid-level ที่เข้ามาทำงานในทีมเสมอ ไม่ว่าจะเป็นให้คำปรึกษา หรือคอยตรวจงานให้

ความรู้สึกเมื่อมองกลับไปตอนที่ยังเรียนเขียนโปรแกรม

ผมคิดว่าทุกอย่างที่เกิดขึ้นในชีวิตมันขึ้นอยู่กับการตัดสินใจนะ การตัดสินใจบางอย่างไม่ว่าจะช้าหรือเร็วก็อาจจะไม่ได้แปลว่าถูกเสมอไป แต่คิดว่าตัดสินใจถูกที่เลือกมาทางนี้ เพราะผมรู้ตัวเองมาตั้งแต่ตอนเรียนจบแล้วว่าไม่เหมาะกับการทำงานเป็นโปรแกรมเมอร์ 

ซึ่งตอนนั้นก็มีเวลาสำรวจตัวเอง ผมจึงต้องตัดสินใจไปก่อนแล้วเชื่อว่าสิ่งที่ทำลงไปมันถูก แล้วถ้ามันออกมาไม่ดีจริงๆ ค่อยกลับมาดูว่าสาเหตุเพราะอะไร สมมติว่าเพราะผมไม่ถนัด ก็อาจจะหาความรู้บางอย่างมาเสริม สุดท้ายแล้วถ้าไม่ได้จริงๆ ก็คงต้องยอมรับแล้วก็เริ่มต้นใหม่ แต่อย่างน้อยก็ได้พิสูจน์แล้วว่าหนทางหนึ่งที่ผมต้องการทำมันไม่เวิร์ก 

แต่เวลาย่อมไม่คอยใคร ยิ่งใช้เวลามากขึ้น ถ้าผมทนรอต่อไป ตัวเลือกก็จะยิ่งมีน้อยลงผมอาจต้องมานั่งเสียใจทีหลังว่าทำไมตอนนั้นไม่เลือกหนทางนี้ สุดท้ายแล้วก็ไม่มีใครรู้ว่าสิ่งที่เราเลือกมันจะถูกหรือผิด อย่างไรก็ตาม ผมก็ดีใจที่ตัวเองกล้าตัดสินใจ กล้าออกจาก comfort zone ของตัวเองและเลือกเส้นทางที่แตกต่างจากสิ่งที่เรียนมา

แผนในอนาคต

หลังจากทำงาน Scrum Master มานาน ผมก็พอจะรู้แล้วว่าทีมงานที่ต้องดูแลจะเป็นประมาณนี้ ในอนาคตผมอยากลองทำงานสาย PO ดูบ้าง เพื่อที่จะได้รู้ว่าเวลาที่ต้องคุยกับลูกค้า ผมจะสามารถนำ pain point ของทีมมาช่วยสนับสนุนการทำงานของทีมได้อย่างไรบ้าง สามารถรับ requirement จากลูกค้าได้เยอะแค่ไหน รวมไปถึงการวางแผนงานต่างๆ ซึ่งสุดท้ายแล้วก็ทำไปเพื่อต้องการปกป้องทีม โปรดักต์ และองค์กรของเรา ซึ่งก็คือ Seven Peaks นั่นเอง

เพราะเป้าหมายสูงสุดของผมก็คือการมอบสิ่งที่ดีที่สุดให้กับทุกๆ ฝ่าย

เบญจพล หมอยา (เบ็น) Scrum Master ที่ Seven Peaks คุณเบญจพล เป็น Scrum Master/PM ที่คอยช่วย support Product Owner และทีม เพื่องานที่ราบรื่น และสามารถตอบโจทย์ความท้าทายของลูกค้าได้