ทำไม Agile ไม่ใช่คำตอบ
เกือบ 20 ปีแล้ว ที่ Agile Manifesto for Software Development มีการประกาศออกมาอย่างเป็นทางการ ในปัจจุบัน Agile ได้พัฒนามาไกลจุดเริ่มต้นมาก โดยเริ่มจากส่วนงาน Development และขยายไปส่วนงานอื่นๆ ใน IT Value Stream ขององค์กร ไม่ว่าจะเป็น QA, IT Operation, Design & UX และข้ามฟากมายังฝั่งธุรกิจ ทั้งนี้ไม่ว่าจะเป็นการสลาย Silo แบบแท้หรือเทียมก็ตาม เราก็ได้เห็นการร่วมไม้ร่วมมือที่มีมากขึ้นระหว่างกัน ทั้งภายในส่วนงานเดียวกันหรือข้ามส่วน
ยิ่งไปกว่านั้น ตอนนี้ Agile ได้กระโดดออกมานอก IT Value Stream ไปยังสายธุรกิจเต็มตัว จะหันไปทางไหน ไม่ว่าองค์กรนั้นจะทำซอฟต์แวร์ ทำประกันหรือว่าขายปูนซีเมนต์ ใคร ๆ ก็พูดถึงเรื่อง Agile กันทั้งนั้น ในงาน Agile Thailand และ Agile Tour Bangkok ก็มีหัวข้อเกี่ยวกับ Business Agility โดดเด่นขึ้นมาก ลูกค้าของ Lean In เองก็เริ่มจะเป็นธุรกิจที่ไม่ได้มี IT เป็นหัวใจหลักเลยด้วยซ้ำ
แต่สิ่งหนึ่งซึ่งเราเริ่มจะสัมผัสได้จากกระแสนิยม Agile นี้คือ คนทำงานหลาย ๆ ที่มักจะมีความรู้สึกเนือง ๆ ว่า Agile ไม่น่าจะเวิร์ค ลองทำมาซักพักแล้วก็ยังไม่มีทีท่าว่าจะได้ผล แต่ก็ไม่กล้าขัดบัญชาหัวหน้า ที่อาจจะไปอ่าน HBR มา หรือเห็นองค์กรอื่นทำ หรือยานแม่จากประเทศที่พัฒนาแล้วสั่งมาให้ทำอีกที ทำไมถึงเป็นเช่นนั้น? ลองมาดูบทวิเคราะห์ฉบับ Lean In Way จากประสบการณ์ของพวกเรากัน
Business Agility Quadrants
ถ้าเรามองลักษณะของธุรกิจ ผ่านสองมุมมอง โดยมุมมองแรกในแกนนอนคือ ความไม่แน่นอนของตลาด(หรือของลูกค้า) ถ้าตลาดนิ่ง เรารู้แน่นอนว่าลูกค้าต้องการอะไรก็อยู่ทางซ้าย ถ้าตลาดผันผวน เราไม่รู้ชัดว่าลูกค้าเป็นใคร อยากได้อะไร เปลี่ยนความต้องการรายวันให้อยู่ทางขวา มุมมองที่สองในแกนตั้งคือความไม่แน่นอนของเทคโนโลยี ถ้าเทคโลยีไม่ค่อยเปลี่ยนใช้แบบไหนมาก็แบบนั้นไปอีกนานก็อยู่ด้านล่าง ถ้าเปลี่ยนรวดเร็วตามกันแทบไม่ทันก็อยู่ด้านบน เมื่อเอามาประกอบกันก็จะได้เป็น Business Agility Quadrants ดังภาพข้างล่างนี้ จริงๆก็ไม่ใช่ Quadrant แค่ 4 โซนซะเดียว เป็น spectrum ที่บอกถึงระดับของความไม่แน่นอนเสียมากกว่า
Innovation Quadrant
มาดู Quardrant แรกทางขวาบนกันก่อน เป็นส่วนที่เราไม่รู้ว่าลูกค้าต้องการอะไร แถมยังไม่แน่ใจว่าจะใช้เทคโนโลยีอะไรมาตอบโจทย์ด้วย ย้อนกลับไปนานหน่อย หลายร้อยปีก่อน ตอนนั้นมนุษย์มักจะเชื่อว่า ชีวิตเราถูกกำหนดไว้แล้วจากเบื้องบนที่มีอำนาจเหนือทุกสรรพสิ่ง อาจจะเป็นภูติผี อาจจะเป็นเทพเจ้า หรือ อาจจะเป็นพระเจ้า เราเชื่อแบบนั้นมาจนถึงยุค Scientific Revolution ที่มนุษย์เราเริ่มตื่นรู้ว่า ทุกอย่างไม่ได้เขียนไว้ในพระคัมภีร์ ยังมีอะไรอีกหลายอย่างในจักรวาลนี้ที่ “เราไม่รู้”
Francis Bacon บอกว่าถ้าไม่รู้ให้ ตั้งสมมุติฐาน ทดลอง สรุปผล และวนซ้ำ ที่เรารู้จักกันดีสมัยเรียนว่า Scientific Method หรือ กระบวนการทางวิทยาศาสตร์ ซึ่งนวัตกรรม(หรือ Innovation) ทั้งหลายในโลกไม่ว่าจะเป็นหลอดไฟหรือโพสต์อิตก็ค้นพบกันด้วยวิธีการแบบนี้
งานแบบนี้ในองค์กร มักจะเป็นงานฝ่าย Research & Development รวมไปถึงงาน Process Improvement ที่มีอยู่ทั่วไป ซึ่งมักจะมีแต่โจทย์กว้าง ๆ เช่นฝ่าย HR จะปรับกระบวนการสรรหาพนักงานใหม่ให้เร็วขึ้น หรือฝ่ายการตลาดและฝ่ายขายต้องคิดหาเทคนิคการขายที่เพิ่มยอดขายกว่าเดิม โจทย์แบบนี้ไม่ได้มีคำตอบชัดเจนที่จะมาแตก Product Backlog ได้ แค่จะเรียกว่า Product Backlog ก็ประหลาดแล้ว วิธีแก้โจทย์แบบนี้จึงมักจะอยู่ในรูปของการตั้งสมมุติฐานแล้วทดลองทำและปรับไปเรื่อยๆ แบบกระบวนการทางวิทยาศาสตร์ที่เราเรียนสมัยมัธยม ไม่น่าเชื่อว่ากระบวนการที่มีมากว่า 400 ปีนี้ ยังเป็นที่นิยมอยู่ในปัจจุบัน แต่เปลี่ยนชื่อใหม่เป็น Experiment บ้าง Design Thinking บ้าง หรือ Lean Startup บ้าง หัวใจของกระบวนการเหล่านี้คือ “การ ยอมรับว่าเราไม่รู้” เมื่อไม่รู้ก็ต้องไม่มโน แต่กล้าลองผิดลองถูกดู และปรับเปลี่ยนไปตามผลลัพธ์ที่ได้ นวัตกรรมจึงจะเกิดขึ้นได้
Mass Production Quadrant
Quadrant ที่มุมซ้ายล่าง ซึ่งอยู่ตรงข้ามกับ Innovation Quadrant เป็นส่วนที่มีความชัดเจนทั้งตลาดและเทคโนโลยี ตามปกติแล้วเมื่อเราได้นวัตกรรมอะไรบางอย่างที่ใช้ได้กับคนหมู่มาก นวัตกรรมนั้นก็มักนำมาผลิตเป็นสินค้าจำนวนมากเพื่อตอบสนองกับความต้องการ เรียกง่าย ๆ ว่าปั๊มออกมาจากโรงงาน ถ้าพูดถึงยุคแรก ๆ ที่มีการผลิตจำนวนมากแบบนี้ เราก็อาจจะนึกไปถึงเมื่อต้นศตวรรษที่แล้วสมัยที่ Henry Ford ผลิต Ford Model T ออกมาฮิตติดตลาด ผลิตรถสีดำแบบเหมือนๆกัน เป็นจำนวนมากในเวลาอันรวดเร็ว โดยปรับใช้แนวคิดของ Frederic Taylor ที่รู้จักกันในชื่อของ Scientific Management ที่มองว่า คนงานมีหน้าที่ใช้แรงทำ ไม่จำเป็นต้องใช้หัวคิด แต่ละส่วนมีหน้าที่เพียงแต่ทำตามกระบวนการที่มีคนคิดไว้ให้ ส่วนหน้าที่คิดเป็นหน้าที่ของผู้มีกึ๋น ที่มีอำนาจบังคับบัญชาจากเบื้องบน แนวคิดนี้มีส่วนช่วยทำให้ Ford ก้าวขึ้นมาเป็นผู้นำของการผลิตรถยนต์ในยุคนั้นอย่างหาใครเทียบไม่ได้
แนวคิดแบบปั๊มออกมาจากโรงงานแบบนี้ ถูกนำมาใช้อย่างแพร่หลายในหลายๆบริบท รวมไปถึงการพัฒนาซอฟต์แวร์ในยุคแรก ๆ ด้วย เราจึงได้มีการวางแผนให้แต่ละคนทำตามหน้าที่เป็นขั้นตอนที่เรารู้จักกันในชื่อว่า Waterfall มีการแตกแผนออกเป็นรายละเอียดชัดเจนแบบ Work Breakdown Structure หรือ WBS และการใช้ Man-Day เป็นหน่วยของการประเมินและติดตามความคืบหน้าของโครงการ ในปัจจุบันเราตื่นรู้กันแล้วว่า แนวคิดนี้ใช้กับโรงงานผลิตปลากระป๋องได้ดี แต่นำมาใช้กับการผลิตงาน Creative Work ไม่ได้
Lean Production Quadrant
ย้ายมาทางขวาอีกหน่อยที่มุมขวาล่าง เป็นมุมที่เทคโนโลยีค่อนข้างนิ่ง เรารู้ว่าเราจะทำอย่างไร แต่ตลาดมีความหลากหลายไม่แน่นอน จุดเริ่มของการทำงานในแบบ Quadrant นี้อยู่ในยุคที่ญี่ปุ่นมีบทบาทสูงในอุตสาหกรรมรถยนต์ในช่วงปี ค.ศ. 50 ซึ่งตลาดของญี่ปุ่นยุคนั้นมีความหลากหลาย จะผลิต Ford Model T สีดำเหมือนกันทุกคันแบบอเมริกาไม่ได้ ฝั่งญี่ปุ่นได้แรงบันดาลใจด้านการบริหารและควบคุมคุณภาพมาจาก Edwards Deming จนเป็นจุดกำเนิดของการผลิตแบบลีนหรือ Lean Production ที่ใช้แนวคิดแบบ Lean Thinking ที่ผลิตเฉพาะของที่จำเป็น ในเวลาที่จำเป็น เท่าที่จำเป็น เพื่อไม่ให้เกิดความสูญเปล่า และสามารถตอบความต้องการที่หลากหลายได้ จนในที่สุดบริษัทญี่ปุ่นสามารถเอาชนะยักษ์ใหญ่ทั้งสามแห่งเมืองดีทรอยต์ ขึ้นมาเป็นเจ้าตลาดรถยนต์โลกได้
ต้นตำหรับของแนวคิดนี้ก็คือ Toyota Production System (TPS) ของ Toyota ซึ่งเป็นแนวคิดพื้นฐานให้กับแนวคิดที่ได้รับความนิยมมากในเวลาต่อมาที่เรารู้จักกันดี เช่น Lean Six Sigma ที่ใช้กันมากในการปรับปรุงกระบวนการทำงาน และ Kanban ที่ใช้ในการพัฒนาซอฟต์แวร์และงาน creative work อื่นๆ ข้อดีอีกอย่างของ Lean Thinking คือนอกจากงานแบบ Lean Production แล้วแนวคิดนี้ยังสามารถนำมาใช้กับงานแบบ Mass Production ได้อีกด้วย
ทั้งนี้งาน Business Operation ส่วนใหญ่ในองค์กรธุรกิจ มักตกอยู่ในงานประเภท Mass Production นี้ เราจดจำวิธีการทำงานของเราได้ขึ้นใจ แบบที่เราเรียกว่าเป็น Business As Usual หรือ BAU เราทำตามวิธีการเดิม ๆ จนชินจนเรียกว่าเป็นงาน Routine เพียงแต่เรายังไม่รู้ว่าจะมีงานของลูกค้ารายไหน เข้ามาเท่าไหร่ จะให้เอางานมาแตก Sprint Backlog ก็ทำไม่ได้ สัปดาห์นี้ยังไม่รู้เลยว่าจะมีงานอะไรเข้ามาบ้าง
Software Quadrant
กระโดดมาที่มุมซ้ายบน เป็น Quadrant ที่เราพอจะรู้จักลูกค้าเราดี เราพอจะรู้ว่ามีความต้องการอะไร แต่ยังไม่แน่ใจว่าจะทำอย่างไรเพื่อตอบสนองความต้องการนั้น ตัวอย่างที่ชัดเจนมากคือการพัฒนาซอฟต์แวร์ ซึ่งเรามักจะมีลูกค้าหรือตัวแทนของลูกค้าที่บอกความต้องการได้ชัดเจนระดับหนึ่ง จนสามารถแตกออกมาเป็น Product Backlog ได้ แต่เทคโนโลยียุคนี้ไปเร็วมาก เมื่อก่อนต้องใช้ OOP เดี๋ยวนี้ต้องใช้ Functional Programming อีกทั้ง Framework มากมายก็ถาโถมเข้ามาให้เลือกใช้ ตั้งแต่ JavaScript หลายสิบ Framework ไปจนถึงแนวเลิกใช้ JavaScript กันเถอะเรา แน่นอนว่าวิธีการที่เหมาะที่สุดกับการทำงานแบบนี้ก็คือ Agile อันเป็นที่รัก ซึ่งถ้าพูดถึง Agile หลายๆคนก็มักจะนึกถึง Scrum หรือถ้าเป็นสาย Dev หน่อยก็จะนึกถึง XP หรือ TDD แม้แต่ Mass Production เช่นการทำ Project ก็นำเอาแนวคิด Agile ไปจัดการได้
จุดเด่นที่ทำให้ซอฟต์แวร์แตกต่างจากงานแบบอื่นๆคือมันสามารถเปลี่ยนแปลงได้ ปกติเวลาเราซื้อแอร์หรือเครื่องซักผ้า เราจะไม่ได้มีความคาดหวังว่าความสามารถของมันจะมีอะไรเปลี่ยนไปหลังจากซื้อมาแล้ว แต่ถ้าเราซื้อซอฟต์แวร์โดยเฉพาะในยุคนี้สมัยนี้ เป็นเรื่องปกติที่จะมี Update มาเรื่อยๆ ถ้าจะว่าไปแล้ว งาน Creative Work อื่นๆเช่น การทำหนัง ทำภาพยนต์ ก็มีธรรมชาติเรื่องความสามารถในการเปลี่ยนแปลงแบบนี้เหมือนกัน
Agile Transformation
ในปัจจุบันนี้เราจะเห็นซอฟต์แวร์เข้าไปมีบทบาทกับแทบจะทุกธุรกิจทุกผลิตภัณฑ์ ไม่มีธนาคารหรือบริษัทโทรคมนาคมที่ไหนไม่ใช้ซอฟต์แวร์ในการดำเนินการ สินค้าซึ่งเคยเป็นแต่ฮาร์ดแวร์ก็มักจะมีซอฟต์แวร์ผสมเข้าไปด้วยอย่างพวก IoT ทั้งหลาย แม้แต่เครื่องกรองอากาศหรือรถยนต์ ก็ยังมีการ Update ของซอฟต์แวร์ออกมาเรื่อยๆ จึงไม่แปลกที่เราจะได้ยินวลีที่มาจากบทความดังของ Marc Andreessen เรื่อง Why Software Is Eating The World จนมาช่วงหลังๆ Steve Denning ก็มาเขียนบทความออกมาล้อกันว่า Why Agile Is Eating The World แล้ว ด้วยความที่ปัจจุบัน Agile ดูเหมือนจะเอาไปทำได้เกือบทุกอย่าง หลาย ๆ องค์กรจึงตั้งเป้าที่จะทำ Agile Transformation
Lean In บอกลูกค้าอยู่เสมอว่าเราไม่ค่อยชอบคำว่า Agile Transformation สักเท่าไร เพราะคำนี้มักจะทำให้เกิดภาพว่าเราจะกลายร่างจากดักแด้น้อยที่น่าเกลียดไปเป็นผีเสื้อที่งดงามยิ่งใหญ่ เรามักจะชอบใช้คำว่า Agile Adoption เสียมากกว่า เพราะเราให้ความหมายในแง่ของการเพิ่มไม่ใช่การเปลี่ยน
ธรรมชาติธุรกิจขององค์กร ไม่ได้มีแต่ Mass Production หรือ Lean Production หรือ Innovation หรือ Software แต่เพียงอย่างเดียว แต่มักจะมีผสมปนเปกัน อาจเป็นไปได้ว่าจะเอียงไปทางใดมากกว่าทางหนึ่ง การที่พยายามยัด Agile เข้าไปทั้งดุ้นเพื่อแทนที่ของเดิมที่มีอยู่ในปัจจุบันที่อาจจะใช้ได้ดีอยู่แล้ว จึงไม่ใช่คำตอบ
จุดหมายขององค์กรจึงไม่ควรเป็นการทำ Agile Transformation แต่ยังควรเป็นเป้าหมายทางธุรกิจปกติขององค์กรและเพิ่มความสามารถในการปรับเปลี่ยนทางธุรกิจหรือ Business Agility ให้กับองค์กร โดยทำความเข้าใจว่า ธุรกิจหรืองานขององค์กรอยู่ใน Business Agility Quadrants ไหน จากนั้นจึงเลือกหยิบและปรับใช้วิธีการที่เหมาะสม เพื่อให้เกิดผลทางธุรกิจตามที่คาดหวัง ซึ่งแน่นอนว่าจะไม่ได้มีวิธีเดียว และไม่มีใครหน้าไหน แม้แต่ที่ปรึกษาราคาร้อยล้าน จะมารู้จักเราดีไปกว่าตัวเราเอง
ปัญหาของการทำ Agile Transformation รูปแบบหนึ่งที่พบเห็นได้บ่อยๆ โดยเฉพาะในบริษัทขนาดใหญ่ที่มีกำลังจ้างที่ปรึกษาราคาแพงก็คือ จะเริ่มต้นโดยการปรับโครงสร้างองค์กรจากเดิมที่ทำงานกันเป็นแผนก ให้ยุบทิ้งกลายมาเป็น Cross-Functional Team หรือที่เรียกติดปากกันว่า Squad ถ้าหนักๆหน่อยก็อาจจะมีเป้าของการลดค่าใช้ง่ายโดยการลดคนเข้าไปด้วย ไหนๆเขาก็บอกกันว่า Agile นี้ทำน้อยได้มากอยู่แล้ว ความสับสนจากการปรับเป็น Squad ยังไม่ทันจางหาย ความวุ่นวายจากการบังคับให้ทุกคนทำ Scrum ก็ติดตามมาทันที โดยเฉพาะอย่างยิ่งถ้าไม่ใช่ทีมไอทีแต่เป็นทีมอย่าง Business Operation นี่ก็ไปกันไม่ค่อยเป็นเลยทีเดียว จังหวะนี้จะหันไปหาที่ปรึกษาที่มาตั้งต้นไว้ให้ก็ไม่อยู่ให้ถามซะแล้ว
ถ้าไม่นับเรื่อง Psychological Safety ที่ถูกทำลายทิ้งไปตั้งแต่ตอนปรับโครงสร้าง แล้วมาวิเคราะห์ธุรกิจและการทำงานด้วยมุมของ Business Agility Quadrants ถ้าหากธุรกิจเราเป็น Digital เต็มตัวที่ขับเคลื่อนด้วย Software เป็นหลัก การใช้ Scrum ก็น่าจะช่วยได้ แต่เราต้องยอมรับด้วยว่าธุรกิจในประเทศไทยส่วนใหญ่ไม่ใช่อย่างนั้น แม้เราจะตื่นตัวเรื่อง Digital Transformation กันขนาดไหน ความเป็นจริงก็คือธุรกิจของเรามักจะเป็นผู้ใช้ซอฟต์แวร์ มากกว่าผู้ผลิตซอฟต์แวร์ การพยายามยัด Agile ซึ่งส่วนใหญ่ก็มักจะเป็น Scrum ตามตำราให้กับทั้งองค์กร จึงมักไม่ประสบความสำเร็จนัก
ในการเดินทางสาย Enterprise Agile Coaching กว่าสิบปีที่ผ่านมา Lean In ได้มีโอกาสนำวิชาต่าง ๆ จากหลายสำนัก ไม่ว่าจะเป็น XP, Scrum, Kanban, SAFe, LeSS และอีกหลากหลาย มาปรับใช้ในการช่วยเหลือลูกค้าของเรา จนเมื่อไม่นานนี้เราได้พบเจอกับศาสตร์ Flight Levels ซึ่งเราเชื่อว่าจะเป็นกุญแจสำคัญในการช่วยให้ลูกค้าสร้าง Business Agility ในองค์กรได้ด้วยตัวเอง ไม่ว่าธุรกิจขององค์กรจะอยู่ตรงใน Quadrant ไหนบ้างและไม่ว่าจะมี Agile ผสมกันอยู่กี่ค่ายในองค์กรก็ตาม
ด้วยเหตุนี้ เราจึงได้ร่วมกับสหาย Flight Levels Guide จำนวน 16 คนก่อตั้ง Flight Levels Academy เพื่อเผยแพร่ศาสตร์ Flight Levels ให้เป็นที่รู้จักในวงกว้าง ผู้คิดค้น Flight Levels คือ ดร. Klaus Leopold มักเปรียบ Flight Levels ว่าเป็นกาวที่ช่วยประสานให้องค์กรเชื่อมติดกันได้ ส่วนตัวผมเองมอง Flight Levels ว่าเป็น D.I.Y. Business Agility Framework แต่ถ้าจะให้อธิบายถึงรายละเอียด เกรงว่าจะทำให้บทความนี้ยาวเกินไป เอาไว้โอกาสหน้าจะมาเขียนให้อ่านกันเพิ่มนะครับ
ขอบคุณ คุณภรรยา อาจารย์ธีรมน วงศาโรจน์ ที่ช่วยเป็นบรรณาธิการส่วนตัว ให้กับบทความนี้ครับ ;-)
- 194
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2024 Blockdit
