“7 พึงระวังกับเรื่องเอะอ่ะ! ก็ Agile ในองค์กรขนาดใหญ่" (หมายเหตุ : ขออภัยที่เขียนเกิน 8 บรรทัด)
จริงๆ เป็นต้นฉบับที่เขียนค้างไว้นานพอสมควรแล้ว ได้ฤกษ์เขียนต่อ จากประสบการณ์ที่ไม่มาก แต่ก็ไม่น้อยนัก…
หลายปีมาแล้วตั้งแต่ปี 2013 ถึงสัก 2020 ตอนที่ตัวเองยังอยู่ใน Front-field (หน้างานในตำแหน่งงาน Product Manager/Owner จริงๆ…พอได้ทำงานในองค์กรใหญ่หลายที่ และใกล้ชิดกับผู้นำ เราก็มีมุมมองที่เปลี่ยนไป
จาก “คนทำงาน” จนกลายเป็น “คนที่มองเห็นความเป็นไปของการเปลี่ยนแปลงหลายอย่างในองค์กร”
แต่วันนี้จะไม่มาเล่าเรื่องมุมสูงๆ แต่จะเล่าในมุมที่เป็นตัวของตัวเองตอนอยู่ Front-field ละกัน โดยข้อเขียนนี้ จะ
“As a Frontfield Player, so that… “หลับตาถอยหลังไปหลายปีก่อนสักประมาณช่วง 2013–2020 สมัยที่ตัวเอง “เป็นคนที่อยู่ในหน้างาน ระดับ Battle-field” ว่ามองเห็นอะไรบ้าง และอยากแบ่งไปดูนะครับ”
“สมัยผมต้องอยู่ใน loop หน้างานในฐานะ PO (ที่เคยบริหาร 3 squad พร้อมกันในเวลาเดียว) ผมมองเห็น 7 ประการที่เราควรเอ๊ะ!! ในการทำงานดังนี้
--------------------------------------------
ประการที่ 1 : คนรอบข้างมักมาบอกให้เริ่มด้วย “Tools นั่น-นี้-โน่นมากมาย”
แต่ไอ้เราก็จำได้นี่หว่าว่า Agile Manisfesto ข้อแรกมันก็กล่าวว่า “Individual interaction over process and tools” แต่แปลกมากสมัยอยู่ที่หน้างาน สิ่งแวดล้อมเวลาคิดอะไรไม่ออกจะเริ่มจากหา Tools ที่มันดูเจ๋งๆ ว้าวๆ ก่อน (สมัยนี้ไม่รู้เป็นไหมนะ??) และคงเคยได้ยินว่า
“ไม่มีการ์ดใน Jira ก็เอาเรื่องเข้า sprint ไม่ได้บ้างไหม?” ไอ้เราก็ถามทำไมวะ? ก็คุยกันก่อนสิ เดี๋ยวใส่ให้ …ปลายเสียงคนที่มีหน้าที่ก็กล่าวกับว่า “เพราะทีมผม/ชั้นต้อง track burndown นะ….ไม่ทำไม่ได้ !!@##$$”
บ้างก็บอกว่า “ทำไมไม่ใช้ tools A-B-C นี้สิในการทำงาน…ไม่งั้นเรา plan ให้ไม่ได้นะ….”
”Test case ไม่ submit เข้าระบบ XYZ ก่อนก็จะปิด dev ไม่ได้นะ…”
หรือ “Dev ก็จะพูดว่าต้องเสียเวลาใช้ Tools XYZ ในการเขียน!@@#$$%” เป็นต้น
มานั่งคิดดู เห้ย!! ทุกคนลืมไปว่าจริงๆ tools อำนวยความสะดวกในการทำงานให้เราก็จริง “แต่ tools ไม่ใช่สิ่งแก้ปัญหา แล้วทำไมเราเอาเวลาทีมส่วนใหญ่ใช้ไปกับ tools เหล่านี้มากกว่าจะทำความเข้าใจกับ Goals ของงานจริงๆ แล้วไปให้ถึง?”
ตอนนี้มานั่งคิดย้อน ก็ยังคงจะแนะนำว่ากลับไปที่ Basic concept ที่จะไปสู่เป้าหมาย จับกระดาษ/Post-its จับปากกา หรือ เขียนกระดาน อย่าเสียเวลากับ tools ที่เราไปซื้อมา หรือมีคนมาขายมากเกินไป (ไม่ได้แปลว่าไม่ดี แต่ใช้ให้พอเหมาะ และเหมาะสมกับทีมงาน หรือสภาพแวดล้อมของโปรเจคในขณะนั้นเถิด สาธุ)
--------------------------------------------
ประการที่ 2 : “ไม่เริ่มด้วย Tools แต่พี่ขอเริ่มด้วย Process อย่างแน่น…” (พรรณนา process ที่มีความเชื่อว่าจะสำเร็จให้กับองค์กร แล้วใส่ให้คน don’t know what they don’t know คล้อยตามไป)
จากประการที่ 1 ใช้เวลากับ tools ก็ว่าเยอะแล้ว บางทีมงานที่รัน Agile (จะ Scrum หรือวิธีการไหนก็แล้วแต่) กลับมักเริ่มด้วย process มากมาย หรือข้อกำหนดมากมาย
ซึ่งจริงอยู่ process ที่ดีต้องช่วยให้การทำ product หรือทำ project management รัดกุม ดังนั้นเราก็ไม่น่ากังวลอะไรมากไปหรือเปล่า??
เพราะผู้รู้หลายท่านก็บอกว่า
process มันก็ proove แล้ว ต้องทำตามนี้”
“บ้างก็ว่ามาจากบริษัทระดับโลกเชียวนะเขาก็ทำแบบนี้ๆๆ แล้วไม่ดียังไงเหรอ?”
แต่ผลส่วนใหญ่ที่มักเกิดคือ ทำๆ ไป แบบคนทำก็เริ่มไม่รู้ทำไปทำไม ทำเหมือนหุ่นยนต์ แม้ว่าเราก็ทำตาม process ที่เค้าเหล่านั้นบอกให้ทำทุกอย่างแล้วนี่หว่า? ไม่ว่าตัวอย่างที่ได้ยินในอดีต เช่น เขียน unit test 100%, grooming/planning/review/retro ก็ครบถ้วน ทำไม product หรือการทำงานก็ยัง “FAIL?”
หลายคนลืมไปว่า Process มันคือ mechanics เท่านั้น (อาจจะเกิดจากที่ทำงานของท่าน มีคนมาสอนบ้าง หรือมี KPI บังคับให้ทำโน่นนี่มากมาย) จนเราลืมไปว่าแก่นแท้ไม่ต้องอาจง อไจล์ไรหรอก คือ การทำงานให้สำเร็จอะ เราต้องรู้จัก Adopt ตัวเองตลอด
เวลาที่เราการ adopt มันรวมถึง “การสื่อสารระหว่างกันจะแนวดิ่ง (ผู้บริหาร-ทีมงาน-User) และแนวราบ (ทีมทำงานกันหรือผสานเก่าๆ เรียก Crossfuinctional ให้ร่วมมือกัน” การเปิดรับ Feedback แบบไม่หลอกตัวเอง แล้วเอาไปปรับปรุง รวมถึงการสร้าง ความเชื่อใจกันของทีมงานนั่นเอง
--------------------------------------------
ประการที่ 3 : “เอ๊ะก็ท่านๆ บอกว่า Development practice” ที่ดีก็น่าจะทำให้ product ของเราดีสิ ไม่ใช้เหรอ?
เคยได้ยินคำพูดประมาณนี้ไหมครับว่า
“Dev เราต้องคุณภาพ 100% ต้องทำ practice ที่เป็นมาตรฐานโลก เช่น TDD, continuous integration บ้าง, ต้อง Pair programming บ้าง, Test-First ได้ บลาๆ เป็นต้น”
แล้วหลายครั้งเราก็เสียเวลานั่งทำ practice เหล่านี้แบบเคร่งเครียดจนให้ความสนใจที่น้อยลงในเรื่องสำคัญจริงๆ เช่น การสื่อสาร หรือสนใจว่าลูกค้าอยากได้อะไร กลับน้อยมากๆ เมื่อเทียบกับความจริงจังในการทำ practice ที่ตนต้องทำหรือองค์กรบอกให้ทำ
ลืมแม้กระทั่งสิ่งที่ทำให้ทีมรู้ว่าต้องทำอะไรต่อไป แก้ไขอะไร หรือปรับปรุงอะไรอย่างไร?
เราต้องไม่ลืมว่าจะ Agile หรือไม่ Agile เรื่องของ “คน” และ “กระบวนการสื่อสาร” สำคัญไม่น้อยกว่าเรื่อง “เทคโนโลยี”
ให้สังเกตุว่า practice หลายอย่างให้ความสำคัญเรื่องระหว่างคนไม่ใช่ เทคโนโลยี เช่น Pair programming จริงๆ ก็ให้ความสำคัญเรื่องการสื่อสารระหว่าง developer มากกว่าการคาดว่าจะทำให้เขียนสุดยอดโปรแกรมอะไรขึ้นมา หรือการทำ retrosprective ก็เพื่อหวังเรื่องของการกระตุ้นให้ทีมเกิดการสื่อสารเช่นกัน
--------------------------------------------
ประการที่ 4 : “Agile Coach/Scrum master /Dev lead/PO/CoE…Whatever ที่ได้รับการแต่งตั้งหรืออุปโลกขึ้น ต้องรู้ทุกอย่างดิ ต้องตัดสินใจได้ดิ!!! เขามาหน้าที่รับผิดชอบนะ?”
เคยได้ยินไหมประโยคเด็ดๆ เช่น
“PO ต้องตัดสินใจได้ทุกเรื่องสิ เรื่องนี้บอกมาเลยต้องทำยังไง?…!@#$$%^^”
“โค้ชช่วยหน่อยความรู้เรื่องเฉพาะ XYZ นี้ทำยังไง…โค้ชต้องตอบได้สิ…”
“Dev lead ช่วยหน่อยจะแก้ bug หน่อยดิ…จะเขียน code ในโปรแกรมมิ่งเฉพาะ ABCD นี้ยังไงดี?”…
ซึ่งจริงๆ แล้วก็ถูกที่คนเหล่านี้น่าจะช่วยเหลือเราได้เวลาเกิดปัญหาแหละ แต่จริงๆ คนเหล่านี้อาจไม่ได้มีประสบการณ์เชิงลึกในเรื่องที่อยู่ตรงหน้าที่จะช่วย จัดการหรือตัดสินใจได้ทุกเรื่อง
ทีมต้องช่วยกัน reflect หรือกำหนดว่าจะทำอย่างไรที่จะแก้ไขปัญหาหรือทำอย่างไรที่แก้ blocker เหล่านี้ได้ร่วมกัน ไม่ใช่บอกเรื่องนี้คือหน้าที่ของใคร คนใดคนหนึ่ง หรือโยนกันเป็นลูกวอลเล่ย์??
--------------------------------------------
ประการที่ 5 : “ทีมของฉันก็ต้องรอดต้องมาก่อนดิ ใช้ Agile แล้วมี cross-functional ก็น่าจะช่วยได้ทุกอย่างแล้วนิ?” :
เคยคุ้นๆ ประโยคไรทำนองนี้ไหมครับ?
“เดี๋ยวทีม UX/UI จะส่งคนช่วยโปรเจคนี้ 1 คนนะ แต่ไม่ได้ allocate ให้เลยนะ…ดูคิวก่อนช่วงเวลานี้ใครว่างเพราะเขาทำหลายโปรเจค”
“QA Manager บอกว่าจะ delegate tester ให้ แต่ไม่ได้ให้เลยนะ ต้องหมุนไปทำ project xyz อื่นด้วย”
“เดี๋ยวโปรเจคนี้เราให้ Dev นั่งด้วยกันเป็นทีมเดียว กันแต่ฉันขอกั้นโซนทีมชั้นด้วยนะ เป็นทีม “ยอดมนุษย์ ABC” ด้วยกัน”
ในสถานกาณ์จำลองที่กล่าว หลายคนมักคิดว่า Agile คือยาวิเศษ จะช่วยให้เกิด cross-functional กันได้ดีแน่ๆ แต่โลกความจริง มักมีอะไรบางๆ กั้นไว้ไม่ให้เป็นเช่นนั้น
“ลองสลายใยบางๆ นี้ทิ้งครับ cross-functional จริงๆจะช่วยเรื่อง communication ให้ดีขึ้น ลดการแข่งขันกันเอง ทำให้เรื่องยากๆ หลายเรื่องเป็นเรื่องง่ายขึ้น รวมถึงสร้างเสริมความสร้างสรรค์ด้วย การเซททีมหรือหน่วยงานเดิม ที่ต้องการรักษาอำนาจ หรือ KPI อาจจะไม่ตอบโจทย์ของการบริหารทีมแบบใหม่ จริงๆ อาจจะต้องรื้อไปถึงโครงสร้างองค์กร และสายงานการประเมินผลกันเลยทีเดียวถ้าจะให้ลงลึกจริงๆ…”
--------------------------------------------
ประการที่ 6 : “ฉันตัดสินใจแบบนี้แหละ “ลูกค้าไม่รู้หรอกตัวเองต้องการอะไร?”
เป็นคำพูดแนวๆ เสมือนเราเป็น Steve Jobs กันทั้งหมด ในเวลาที่ต้องการเร่งทำงาน หรือ mindset ว่าตนเองคือคำตอบทุกอย่าง”
ซึ่งจริงๆ แล้วการสร้าง Product จะ Agile หรือวิธีการไหน ต้องมี Fast feedback ระหว่างกันในทีม หรือแม้กระทั่งจากลูกค้าทั้งภายในและนอก
และแน่นอน feedback ของลูกค้าคือสิ่งที่สำคัญที่สุด เหมือนกับถ้าลูกค้าต้องการส้ม แต่เราไปสร้าง Apple แน่นอนไม่มีวันที่จะตอบโจทย์ลูกค้าได้แน่ๆ และผลิตภัณฑ์นั้นก็ fail แล้วทำไมละเราต้องรอจนกว่ามันจะโตเป็น Apple ถ้ารู้ว่ามีรากงอกจากเมล็ดแล้วมันไม่ใช่ส้มก็รีบโค่นมันทิ้งดีกว่าไหม?
สิ่งสำคัญที่ทีมควรรู้ไว้ว่า “ทัศนคติที่ถูกต้อง” คือ “ลูกค้าถือเป็น team member ที่สำคัญและมีคุณค่ามากที่สุด” ถ้าเราไม่สามารถเอา feedback จากลูกค้าในเวลาที่เหมาะสมจะ Agile จะ Waterfall ยังไงมันก็ไม่ work หรอก
“สุดท้ายเราก็จะทำได้เพียงสร้าง product ที่สมบูรณ์แบบทางด้านเทคนิค หรือตามใจใคร…แต่ลูกค้าอาจจะไม่ชอบ product นี้สักนิด…”
--------------------------------------------
ประการที่ 7 : “การตั้งเป้าหมายที่ผิด (False Goals)”
หลายทีมงานทำ Agile ด้วยการเลียนแบบ practice ที่ได้รับการถ่ายทอดมา ปกติก็จะส่งคนไปเทรนจากโค้ชผู้เชี่ยวชาญในวงการ บ้างก็ซื้อคอร์สหรือซื้อ service จาก consult รวมถึงพวกเครื่องมือ Agile มาใช้ใน Agile practice ในบริษัท เป็นต้น
และสิ่งทำทั้งหมดหลายครั้ง เราทำเพื่อขอแค่ให้ทำยังไงให้องค์กรได้ชื่อว่าเป็น Agile เร็วที่สุดโดยที่เราไม่ได้คำนึงถึง Goal จริงๆ หรือเรื่องสำคัญที่สุดคือทำอย่างไรที่จะปรับเปลี่ยน culture ให้เหมาะสมกับองค์กรแบบ Agile
สุดท้ายก็จะทำแบบไม่รู้ มี process มากมาย บ้างก็เป็น practice ที่ออกแบบจากบริษัทที่ปรึกษาหรือเบื้องบนที่มีอำนาจ สุดท้ายคนทำงานก็ทำ Agile แบบที่ถูกออกแบบนั้น แบบที่ไม่ได้มี passion จริงๆ นำไปสู่เป้าหมายที่ผิด
ตัวอย่างอาการที่ฟ้องว่าเราน่าจะไปสู่เป้าหมายที่ผิด เช่น
“ทีมไม่มี commitment”
“Scrum Master or PM or Lead ต้องมานั่ง assign ทีมงานว่าใครต้องทำ user story ไหนตลอดโดยไม่มีคนอยากหยิบไปทำด้วยตัวเอง”
“ข้อแม้ทาง technical เยอะแยะมากมายเป็นกำแพงกั้นมากกว่าความต้องการลูกค้า”
“Business และฝ่ายที่สร้างผลิตภัณฑ์เริ่มไม่ฟังกัน เริ่มหาข้ออ้าง หรือข้อจำกัด หรือมุ่งแต่ชี้จุดอ่อนของแต่ละฝ่ายกันมากขึ้น เป็นต้น”
สุดท้ายเป้าหมายที่ผิดนำสู่ความล้มเหลวในระยะยาว และคนที่เจ็บและไม่ได้ประโยชน์สุดก็คือลูกค้า และองค์กร…
--------------------------------------------
และที่แย่กว่าคือ “เวลา” ของทุกคนที่เสียไป (และเวลาคือต้นทุนที่แพงที่สุดเสมอ)
หมายเหตุ : ข้อเขียนนี้เกิดจากการนอนฝัน ในวันวาน ไม่ได้มีความเกี่ยวข้องใดๆ กับงาน และตำแหน่งหน้าทีในปัจจุบัน…เพียงแค่อยากถ่ายทอดประสบการณ์ ในมุมมองสมัยเป็น Frontier เผื่อจะมีประโยชน์กับใคร
#และขออภัยที่เขียนเกิน8บรรทัด
#วันละเรื่องสองเรื่อง
- 1
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2024 Blockdit
