Review การทำงานครบ 2 ปีที่ Muze Innovation
สวัสดีจ้า ห่างจากการเขียนไปนานมากกกกก ยังมีคนรออ่านอยู่ไหมนะ 🥺
จาก Developer หน้าโง่เมื่อหลายปีก่อนก็ได้เดินทางมาเติบโตมาอย่างดีบ้าง ไม่ดีบ้าง 55555 เอาน่าตามสภาพอ่ะเนาะ
และหลังจากการเปลี่ยนแปลงตัวเองครั้งใหญ่ ตอนนี้เน็ตได้เปลี่ยนตำแหน่งงานมาเป็น Product Owner เต็มตัวแล้วจ้าช่วยยินดีกับฉันโดยการปรบมือให้ซักสามทีด้วยนะคะ
เรามาเริ่มต้นด้วยประวัติปัจจุบันก่อนของเน็ตก่อนเลยแล้วกันน๊า ตอนนี้เน็ตก็ได้ทำงาน ที่ Muze Innovation ในตำแหน่ง Product Owner จ้าาา ตอนนี้ก็ทำงานมาได้สองปีนิดกับหน่วยวัน ก็ขอขอบคุณพี่ๆ ที่เอ็นดูแล้วใจเย็นทำงานกับเน็ตมาตลอด 2 ปีเต็มด้วยค่ะ 💖 จากนี้ไปก็เอ็นดูน้องคนนี้ต่อไปด้วยน๊า 🫣
คำเตือน บทความนี้เน็ตตี้ใช้คำทับศัพย์ค่อนข้างเยอะ หากมีคำไหนที่คนปกติใช้ภาษาไทยแล้เข้าใจง่าย ได้โปรดจดแจ้งฉันเลย
Product Owner ใน บ. Tech Partner เนี้ยะนะ?
หลายคนอ่านมาถึงตรงนี้ แล้วอาจจะรู้จัก Muze อยู่แล้วคงเกิดความสงสัยว่า เอ๊ะ! แก Muze เป็น Tech Partner แล้วทำไมถึงมีตำแหน่ง Product Owner (PO) อ่ะ ทำไมไม่เป็น Project Manager (PM) อ่ะ
ตอนนี้เน็ตสัมภาษณ์ก็สงสัยค่ะ แต่เดี๋ยวจะมาสรุปให้อ่านตามนี้จ๊ะ Muze เป็น บ. Tech Partner ก็จริงแต่ด้วยความที่เราเป็น Tech Partner เนี้ยแหละเลยมีความจำเปนต้องมีตำแหน่งนี้ เพราะเราจะช่วยคุณลูกค้า ตั้งแต่ร่วมออกแบบ วางแผน ลงมือ Develop และส่งงานให้ลูกค้าเลย โดยวิธีการทำงานของเราก็อิงการทำงานจาก SDLC ทั่วๆ ไป โดยแบ่งการทำงานออกเป็นแต่ละขั้นตอนตามข้างล่าง
Requirement Analysis : จะเป็นขั้นตอนที่เราไปเก็บ Requirement ของลูกค้าว่าอยากได้ Software ประมาณไหน มี ฟังก์ชั่นอะไรบ้าง ทีนี้ก็เป็นหน้าที่ของ PO และ SA ที่เข้าไปรับฟัง Requirement ที่ต้องเอามาประเมิน และออกแบบต่อ
System Design : หลังจากเราเข้าใจ Requirement ภาพรวมละ ทีนี้เราก็จะมา Design ว่าจะมีโครงสร้างภาพใหญ่แบบไหน ซึ่งตรงนี้เราก็มีส่วนร่วมกับ SA นะ แต่อาจจะไม่ได้ให้ความเห็นได้มากเท่าพี่ๆ ที่เป็น SA แต่เราต้องให้ข้อมูล Requirement ที่ถูกต้อง เพื่อให้การออกแบบครั้งนี้ ได้ของที่ตรงกับความต้องการของ User และสามารถเอาไปใช้งานได้จริง ซึ่งหลังจากที่ออกแบบ พวกโครงสร้างต่างๆ แล้ว เราจะเห็นงานใหญ่ๆ ที่ต้องทำละ เราจะเป็นหน้าที่หลักในการออกแบบว่าแต่ละ Sprint จะเอาอะไรเข้ามาทำ ทำการจัด Priority แต่เป็นแค่หน้าที่หลักเท่านั้น ซึ่งเราต้องการความเห็นและความรู้จาก Development Team ด้วย ในส่วนนี้จริงๆ ก็ช่วยกันทำประมาณนึง
Implementation : หลังจากที่เราได้รู้แล้วว่าแต่ละ Sprint เราต้องทำอะไรยังไงบ้าง เราก็จะลงมือทำงานในแต่ละ Sprint กัน ที่ Muze เราใช้ Scrum Framework เป็นหลัก เพราะงั้นเราก็จะทำงานกันเป็น Sprint ในแต่ละ Sprint ก็จะมี Ceremony ตามที่ทุกคนรู้กันเลย แต่ว่าในบางโปรเจค PO และ SA ก็จะมีมีทต้ิงที่มากกว่านั้น ส่วนใหญ่จะเป็นการสื่อสารกับทางลูกค้า ตัวอย่าง จะมีโปรเจคนึงที่เราจะมีมีทติ้ง
Gettering Requirement เพื่อเก็บรายละเอียดแต่ละ Function ได้ละเอียดและนำไปออกแบบ UI ต่อไป โดยในการคุย Requirement ครั้งแรก หรือหลายๆคนเรียกว่า Sprint 0 มันจะได้ของที่เป็นภาพใหญ่มากๆ แต่มันไม่ได้รายละเอียดปลีกย่อยว่าแต่ละ Function มันมีเงื่อนไขตรงนี้นะ ซึ่งเราจะใช้มีทติ้งนี้ในการทำสิ่งนั้นกันค่ะ
Design Sync up มีมีทติ้งนี้เพื่อเอาของที่เรา Design UI มาคอนเฟิร์มกับ User หรือลูกค้าที่ให้ Requirement กับเราว่าโอเคไหม ทีมทำงานมีประเด็นตรงไหนไหม เพราะถ้าอยากปรับในตอนนี้ก็ยังปรับได้ง่ายและใช้เวลาไม่นาน ถ้าหากหลุดจากตรงนี้ไปแล้ว การจะปรับแก้ไขอะไรมันจะเป็นปัญหาที่ระดับชาติประมาณนึง
Testing : ทีนี้หลังจากที่เราก็ทำงานวิ่งรอบแบบ Sprint เรียบร้อยแล้ว เราจะมีการทำ UAT เพื่อเตรียมส่งมอบงานให้ลูกค้า หลายคนอาจจะเอ๊ะ แล้วมีคำถาม ในเมื่อเราทำงานกันแบบ Scrum อยู่แล้วเรามีการทำการทดสอบในแต่ละ Sprint อยู่แล้ว ทำไมต้องมีการทดสอบอีกค่ะ จริงๆ เรามีการทดสอบในทุก Sprint จริงค่ะ แต่หลายๆ โปรเจคที่เน็ตเข้ามาจับ เราจะทำเป็นล็อตแล้วค่อย Release ไปทีเดียว ซึ่งการทดสอบในขั้นตอนสุดท้ายเพื่อความมั่นใจขั้นสุดว่า ของที่เราจะ Release ขึ้นไปจะไม่มีปัญหาอะไร และเป็นการ UAT เพื่อส่งมอบงานด้วยค่ะ
Deployment : หลังจากที่เราดำเนินการทุกอย่างมาเรียบร้อยแล้ว ก็ถึงการ Deployment เพื่อลงโปรแกรมใช้งานจริง ส่วนใหญ่โปรเจคที่เน็ตทำเราไม่ได้ช่วย Deploy ใน Production Environment แต่เราจะอยู่เป็นเพื่อกับคุณลูกค้าในวันที่ Deploy เผื่อมีติดอะไรจะได้ช่วยกันแก้ไขได้
ตอบคำถามว่าทำไม Muze ถึงต้องมี Product Owner ในเมื่อสิ่งที่เราต้องทำมันมีทั้งตั้งแต่การประเมิน Requirement การออกแบบโครงสร้าง, ออกแบบระบบ, ออกแบบ Sprint, จัด Priority ของงาน, ดูภาพรวมของ Timeline และ Product แล้ว ทำไมเราถึงจะเรียกตัวเองว่า Product Owner ไม่ได้ล่ะ 😎
แล้วฉันจะรอดมั้ย มีเรื่องที่ต้องเรียนรู้เต็มไปหมด
เอาจริงๆ คิดหนักมากหลังจากที่น้อง HR โทรมาบอกว่า ผ่านสัมภาษณ์เพราะว่านี่คิดว่าตัวเองยังไม่เก่งไม่พอที่จะอยู่ตำแหน่งนี้เลยง่ะ คิดว่าจะไหวหรอมีเรื่องต้องเรียนรู้เต็มไปหมด แต่ก็เพื่อนๆ รอบตัวก็ให้กำลังใจดีมากแล้วก็เดินหน้าเต็มกำลัง เริ่มงานที่นี่เลย พอมาทำงานจริงๆ โอ้วแม่เจ้าาาาา มีเรื่องให้ต้องเรียนรู้เยอะกว่าที่คิดไว้อีก 5555555555 อ้อแล้วการทำงานที่นี่เป็นแบบ Agile Adoption นะคะ อาจจะไม่ได้ถูกหลัก Agile จ๋า แต่เราพยายามปรับเปลี่ยนเพื่อให้ได้สมดุลย์ทั้งในฝั่ง Develop และ Business โดยมเป้าหมายเดียวกันคือการส่งมอบ Product ที่สามารถใช้งานได้จริงให้กับ User
อันนี้ก็เป็นเรื่องที่ใหม่สำหรับเน็ตมากอยู่เพราะแน่นอนพอเราเปลี่ยนที่ทำงานเรื่องกระบวนการทำงาน วิธีการทำงานต่างๆ มันก็ขึ้นอยูากับแต่ละองค์กร แต่ละทีมไรงี้อยู่แล้วชะมะ ก่อนเริ่มงานก็มีความกังวลเรื่องนี้อยู่ ว่าสิ่งที่เราเคยทำมามันอาจจะทำไม่ได้กับที่นี่ แต่ไม่ลองก็ไม่รู้ ฉันก็ลองผิดๆ ถูกๆ กันไป ตอนนี้ก็ยังทดลองทำบางสิ่งเพื่อแก้ปัญหาบางอย่างไปเรื่อยๆ ชีวิตคือการเรียนรู้อ่ะเนาะ ผิดถูกก็ทำไปจะได้รู้ผลลัพธ์ของวิธีแก้ปัญหานั้น
เรื่องที่ใหม่สำหรับเน็ตเรื่องถัดมาเป็นเรื่องงานเอกสาร เนื่องจากตอนเราเป็น Programmer เราไม่ได้ต้องทำเอกสารอะไรเป็นชิ้นเป็นอันอยู่แล้วพอมาอยู่ตำแหน่งนี้มีเอกสารที่ต้องทำเยอะมาก ซึ่งจากที่เคยทำที่เก่ามา เราก็ไม่เคยรู้จักสิ่งนี้มาก่อน เช่น Proposal Document, Delivery Document, Manual Document เอาจริงงานเอกสารมันก็แล้วแต่โปรเจคนะแกบางโปรเจคก็จะทำแค่นี้ บางโปรเจคคุณพี่เขาก็ต้องการเยอะกว่านี้ตามที่ตกลงกัน
เรื่องที่ใหม่อีกเรื่องคือเรื่องทีมค่ะด้วยความที่เราย้ายที่ทำงานแหละ เราก็เป็นกังวลความเข้ากันได้ของเรากับคนอื่นๆ ด้วยเราเป็นคนขี้อาย(?) ไม่กล้าทำความรู้จักใครกลัวว่าคนอื่นจะไม่อยากรู้จักเรา 555555 แล้วด้วยที่ Muze ยังมีให้ work from home ได้ สัตว์สังคมแบบฉันก็ค่อยข้างจะเฉา แต่เอาจริงๆทีมที่นี่ค่อนข้าง Friendly เลย แรกๆ ก็มีความเกร็งมาก แต่พอคุย 1 วันถ้วนฉันก็สนิทกับ PO ในทีมเดียวกันเรียบร้อย 5555555 ตอนนี้ทีม PO หมู่หมูป่าก็คุยแทบทุกเรื่อง ตั้งแต่เรื่องงานยังเรื่องเสริมความงาม ปัญหาสิว ผิวหมองคล้ำ คุยหมดไม่สนเรื่องอะไร อ้อแล้วก็ส่วนใหญ่พวกเราก็จะมีการนัดกันเข้าออฟฟิศทุกวันพฤหัสอยู่แล้ว นอกจากเวลากลางวันจะเม้ามอยทำงานคุยเรื่องงานแล้ว ตอนเย็นเราก็ไปสังสรรค์ กินหมาล่า พิซซ่า และเล่นบอร์ดเกมด้วยกันตลอด เลยทำให้สนิทไวกันขึ้นด้วยละมั้ง
พอมองย้อนกลับไป 2 ปี ก็รู้สึกว่าเอ่อเราก็รอดมาได้นะเพราะเรามีทีมที่ช่วยเรา
แรกๆ ช่วยกัน หลังๆ ช่วยด้วย
สุบสิบประสบการณ์จริงจากลูกค้าจริง!
แกข้างบนแค่น้ำจิ้มข้างล่างนี่ซิของจริง!
เน็ตทำงานมาสองปีมีประสบการณ์มา 3โปรเจคแล้ว ขอเล่าที่โปรเจคแรกแล้วกัน โดยโปรเจคนี้เป็นแอปสั่งอาหารเจ้าหนึ่ง ความพีคของโปจเจคนี้คือ ต้องการ Feature ที่เกี่ยวกับวิธีการชำระเงินแบบใหม่แบบสับ โดยต้องไปแตะกับของเดิมที่ใช้งานได้อยู่แล้วในปัจจุบัน ซึ่งมีเวลาให้ 2 เดือนนิดๆ แน่นอนค่ะเราทำได้ เน็ตจะมาเฉลยความลับนางฟ้าให้ค่ะ
ทีมทำงาน จำนวนทีมทำงานและคนที่ทำงาน เนื่องจากโปรเจคนี้ ต้องทำทั้งตัว Application ที่ต้องเขียนแยกกันทั้ง iOS และ Android และส่วนของ Logic ในเรื่องของบัญชี ซึ่งเราต้องใช้ทีมที่ชำนาญงานส่วนนี้ ถึงแม้ว่า Muze จะแบ่งทีมเป็นแบบ Full Stack แต่แน่นอนค่ะ แต่ละทีมก็มีความชำนาญที่ไม่เหมือนกันทั้งหมดทั้งภาษาที่ใช้เขียน และประสบการณ์โปรเจคที่แต่ละทีมเคยทำ และจากโจทย์ของลูกค้าเจ้านี้ เราต้องการคนที่พร้อมลงสนามกับ PO มือใหม่คนนี้ค่ะ! อ้อ ข้อสรุปของจำนวนคนที่เข้ามาทำโปรเจคนี้จะเป็น Dev 2 Squad Teams และ PO 2 คน
การแบ่งหน้าที่ จากที่บอกไปว่าโปรเจคนี้ค่อนข้างจะบีบบังคับด้วยระยะเวลาเพราะงั้นเราต้องใช้ทุกวินาทีให้มีค่า ในหัวข้อนี้เน็ตตี้จะขอเล่าในส่วนของ PO นะคะ (ถ้าใครอยากรู้ Inside ส่วนไหนอินบ็อกมาเม้ากันได้ทุกช่องทาง อิอิ) เน็ตได้รับหน้าที่ทำโปรเจคนี่กับพี่เนม Head Of Product Owner ที่ Muze หลังจากที่เราเคลียเรื่องทีม เอกสารก่อนเริ่มงานต่างๆ เราก็มาจัดการแบ่งหน้าที่กันเลย ว่าใครดูส่วนไหน โดยในโปรเจคนี้ก็จะแบ่งเป็นส่วนงานออกเป็น
Application จะดุแลงานที่อยู่ใน Application ทั้งหมดทั้งหน้าจอที่รองรับการใช้งาน Feature ใหม่นี้ และพวก API ที่เกี่ยวข้องว่าส่งข้อมูลมาครบถ้วนสมบูรณ์หรือไม่ เน็ตรับหน้าที่ในการดูแลงานส่วนนี้เพราะว่าเป็นงานที่เข้าใจง่ายกว่าอีกด้านสุดๆ 5555
GL File อย่างที่บอกว่า Feature ที่เราทำมันไปเกี่ยวกับวิธีการชำระเงินต่างๆ เพราะงั้นมันกระทบเรื่องของ GL File แน่ๆ (GL File คือไฟล์ที่บันทึกรายละเอียดของการเกิดธุรกรรมต่างๆ) แค่หัวข้อก็ขอลาก่อยละ 555555
ในการแบ่งหน้าที่เราไม่ได้ตัดกันขาดขนาดนั้นนะ แต่เป็นการแบ่งหัวข้อที่ต้องรับผิดชอบเป็นหลัก ซึ่งโดยรวมแล้ว ทั้ง 2 ส่วนงานนี้ก็ต้องเกี่ยวข้องกันอยู่ดี แล้วในแต่ละหน้าทมี่รับผิดชอบใครทำอะไรบ้างล่ะ ?
หน้าที่รับผิดชอบของ PO แต่ละคน เราจะโฟกัสกันคนละเรื่องในการประชุมแต่ละครั้ง ซึ่งสำหรับเน็ตมองว่าดีนะมันไม่ใช่ว่า ถ้ามีเรื่อง GL เน็ตจะไม่ฟังเลย ไม่ใช่ มันคือเน็ตฟังแต่ก็ซึมๆ เอา อาจจะมีคำถามบ้าง ต้องคิดภาพตามเพื่อแมพเข้ากับงานส่วนของเน็ต แต่ว่าเน็ตจะไม่ใช้ Efford ของเน็ตในการ Clarify ในทุกๆ เรื่องของหัวข้อ GL เฉยๆ เพราะว่าเราแบ่งหน้าที่กันแล้ว และหากว่ามีประชุมแยกที่เป็นเรื่อง GL อย่างเดียวถามว่าเน็ตเข้าด้วยไหม เน็ตเข้าด้วยค่ะ แต่ก็จะมีบ้างที่ เอ่อพี่เนมน้องขอไม่เข้านะ มีงานตรงนี้ต้องเคลียซึ่งก็ไม่ได้เป็นปัญหาอะไรเพราะว่าเราคุยกันแล้วว่าใครรับผิดชอบงานส่วนไหนเป็นหลัก และนอกจากงานประชุมเพื่อเก็บ Requirement แล้ว งานที่ PO ต้องทำอีกก็คือ การเขียนการ์ด User Story อันนี้ก็แบ่งกันชัดเจนว่าใครทำส่วนของตรงไหน ส่วนงานเอกสารที่เป็น Delivery Document อันนี้เราก็แยกค่ะ แค่ทำในไฟล์เดียวกัน ทำให้เป็น Pattern เดียวกัน (แต่ก็มีบ้างที่เน็ตทำงานส่วนนี้ในงานจอง GL เพราะว่าพี่เนมยุ่งมาก แต่แค่ Delivery Document ไม่เป็นปัญหาสำหรับเราอยู่แล้ว!)
การ Sync up จากที่เราทำการแบ่งหน้าที่ความรับผิดชอบไปแล้ว ส่วนต่อมาที่ขาดไม่ได้คือการ Sync up การทำงานร่วมกัน อย่างที่บอกว่าโปรเจคมันไม่ได้แยกออกจากกันเพราะงั้นมันมีส่วนที่แตะกันอยู่บ้าง เราจึงต้องมีการคุยกันในภาพรวมให้ไม่แตกต่างกัน (แต่ในรายละเอียดยิบย่อยอันนี้พี่เนมเขาอนุโลมให้เรา) โดยในการ Sync up มันก็จะเป็นการบอกว่า ตอนนี้เรากำลังทำอะไรอยู่ มีส่วนไหนที่เราวางแผนแล้วไม่ตรงตามแผนไหม มีของอะไรที่เราต้องช่วยตามกับทีม กับลูกค้า หรือมีอะไรที่กังวลว่ามันอาจทำให้งานไม่เสร็จตามแผนที่วางไว้ มีอะไรที่อยากให้พี่เนมหรือคนอื่นๆ ช่วยหรือไม่ เราจริงๆ นี่ว่ามันไม่ต่างกับกับ Daily Meeting หรอก แค่จะไม่ได้คุยในเชิง Implement Function แค่นั้นเอง ซึ่งแรกๆ เรา Sync up กับพี่เนมทุกวัน มีตารางว่าจะคุยกันทุกกี่โมง แต่พอหลังจากเริ่มทำงานไปซักระยะ ก็มาตกลงว่าหากมีอะไรต้องอัปเดท จะหาเวลามาคุยกัน โดยไม่ได้กำหนดเวลาที่ตายตัวแล้ว ก็มีบางวันที่ไม่มีอะไรน่าตื่นเต้นก็ไม่คุยอะไรกัน แต่ถ้าวันไหนมีเรื่องน่าตื่นเต้นอย่างมาก ก็คุยกัน 3 เวลาหลังอาหารก็มี
ถามว่าหมดความลับของนางฟ้าแล้วหรอ เราว่าการสื่อสาร นี่เป็นส่วนสำคัญของความลับที่ทำให้โปรเจคนี้มันสำเร็จได้ เพราะเราว่าถ้าทีมมีคนที่เก่ง แต่ไม่สื่อสารกัน มันก็เท่านั้น ใครติดอะไรถ้าไม่สื่อสารออกมาก็ต้องแก้ปัญหาด้วยตัวคนเดียว ซึ่งหลายทีมันอาจจะแก้ไม่ได้ด้วยตัวเองด้วยซ้ำ แต่ Develop ที่นี่ ติดปัญหาก็บอกออกมา รวมถึงเราที่เป็น PO ก็ต้องสื่อสารออกไป
อย่างที่ย้ำหลายทีว่าโปรเจคนี้มีเวลามาบังคับมากๆ เพราะงั้นเราต้องคุยภาพกว้างกับทีมบ่อยมาก กาง Timeline คุยกับทีม Re-Write Timeline Plan แทบจะทุกวัน คุยกับ Dev Manager ว่าวันนี้ติดอะไรทำให้งานไม่เป็นตามแผน อยากให้เราช่วยตรงไหนไหม เพื่อให้ทีมทำงานได้สะดวกขึ้น
ซึ่งเราก็ทำแบบนี้กับทุกโปรเจคที่ได้รับมอบหมาย มีคนเคยถามเราว่า เราเป็น PO ทำไมเราต้องทำอะไรที่ไม่เกี่ยวกับงานของ PO ด้วยล่ะ ทำไมไม่เอาเวลามาโฟกัสงานของ PO? เราก็มาคิดนะว่างานที่ PO ต้องทำเราทำไม่ได้ดีตรงไหนหรือเปล่า เราสามารถอธิบาย Requirement ให้ทีมเข้าใจตรงกันได้ สามารถตอบคำถามหรืออันไหนที่ต้องไปคอนเฟิร์ม หรือสรุปกับ User เราก็หาคำตอบหาข้อสรุปมาให้ทีม เราเรียงลำดับงานที่ต้องทำในแต่ละ Sprint รวมทำดูภาพรวม และทำให้ Product สามารถส่งมอบให้ User ใช้งานได้จริง เราว่านี้คือหน้าที่ของ PO มากกว่า
เรามองว่า PO เป็นหนึ่งในทีม Develop อะไรที่พอจะทำได้เราว่ามันคือหน้าที่ของคนในทีมที่ต้องทำอยู่แล้ว
จริงๆ ก็ไม่รู้ว่าจะเขียนอะไรเพิ่มเติมอีกดี ไว้คิดออกแล้วจะรีบเขียนมาให้ทุกคนได้อ่านกัน 💖 หรือถ้าใครมีเรื่องอะไรที่อยากรู้เพิ่มก็คอมเม้น หรือทักมาได้ทุกช่องทางได้เลยค้าบ หากมีเวลา และเป็นเรื่องที่เผยแพร่ได้จะเขียนมาให้ทุกคนได้อ่านกันจ้า 😚
สุดท้ายนี้กด Claps 👏🏻 แชร์ ♿︎ ให้เน็ตตี้ด้วยนะต๊ะ 💖
ชัลจาโยนะคะ ♡♡♡
