Agile Methodology VS.โลกความเป็นจริง เป็นไปได้แค่ไหน?

Agile Methodology หลักการทำงานยอดนิยมของสาย Tech เป็นไปได้จริงแค่ไหน เมื่อต้องเจอกับโลกความเป็นจริง?

ที่ Muze Innovation เราเชื่อในการให้ความยืดหยุ่นเพื่อให้เกิดการทำงานที่มีประสิทธิภาพสูงขึ้น ซึ่งเป็นหัวใจสำคัญของ Agile Methodology ที่เราใช้กัน คุณเข็ม-พิชาน์ (Picha Mahakittikun) CTO แห่ง Muze Innovation เป็นอีกหนึ่งสายเทคที่สนใจกระบวนการคิดนี้ และเริ่มศึกษาด้วยตัวเองผ่านประสบการณ์การร่วมงานกับองค์กรมากมาย ไม่ว่าจะเป็นขนาดเล็ก กลาง ใหญ่ รวมถึงการได้เข้ามาบริหารทีม Developer ที่ Muze อีกด้วย วันนี้ Muze จึงชวนคุณเข็มมาพูดคุยเกี่ยวกับตัวกระบวนการนี้ ว่ามันเป็นไปได้จริงมากแค่ไหนเมื่อต้องเจอกับธรรมชาติขององค์กรรูปแบบต่าง ๆ

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

มาต่อกันหัวใจหลักของ Agile คือความยืดหยุ่น (Flexibility) ซึ่งมี Agile Manifesto เป็นข้อกำหนดว่าควรให้ความสำคัญกับอะไร 4 ข้อด้วยกัน แต่คุณเข็มก็ได้ดักไว้ก่อนเลยว่า การจะทำให้แต่ละข้อเกิดขึ้นได้และเวิร์กจริง ๆ นั้น ต้องอาศัยทีมที่ทำงานได้เข้าขากันมาก ๆ รวมถึงอีกหลาย ๆ ปัจจัยเลยทีเดียว คุณเข็มเลยจะมาเล่าให้ฟังว่า เมื่อแต่ละข้อเจอกับโลกความเป็นจริงที่ต้องผูกชะตาการทำงานกับลักษณะองค์กรของแต่ละที่แล้วนั้น Spectrum ความเป็น Agile จะถูกเลื่อนไปเลื่อนมาอย่างไรบ้าง มาดูกันเลย

(1) คนทำงานและปฏิสัมพันธ์ระหว่างกัน ควรมาก่อน ขั้นตอนและเครื่องมือ (Individuals and Interactions over Processes and Tools)

โลกในอุดมคติ: ทีมไม่มีกำหนด Ceremony หรือกรอบการทำงานอื่น ๆ ที่ตายตัวภายในทีม เน้นแค่ว่าเป็นกรอบใดก็ได้ตราบที่เป็นมติของทีม การเลือกขั้นตอนและเครื่องมือ (Tools) ที่ใช้ก็จะเน้นเป็น Guideline ที่ตกลงไว้หลวม ๆ ปรับได้ตามความเหมาะสม

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

แต่ในองค์กรขนาดกลางและใหญ่ ที่มีทีมหลากหลายและต้องบริหารงานในลักษณะภาพใหญ่มากขึ้น ก็อาจจะต้องลดระดับความยืดหยุ่นของ Agile นี้ลง และนำระบบขั้นตอนเข้ามาติดตามและรายงานผลได้ เช่น การทำ Burn Down Chart มาใช้เป็นหัวข้อหนึ่งในการวัดประสิทธิภาพ ซึ่งถือว่าคุมเข้มสำหรับ Dev ทีเดียวเมื่อเทียบกับสิ่งที่ Manifesto บอกเอาไว้

ส่วนที่ Muze เองที่เราเป็นองค์กรขนาดกลาง มี Squad 7 ทีม คุณเข็มก็เล่าว่า เรายังสามารถให้แต่ละทีมกำหนดรูปแบบการทำงานของตัวเองได้ โดยที่จะมี Dev Manager ของแต่ละทีมมาอัปเดตความคืบหน้าและแลกเปลี่ยนวิธีการแก้ปัญหาของแต่ละทีมระหว่างกัน

(2) Software ที่ใช้ได้จริง ควรมาก่อน เอกสารที่ครบถ้วน (Working Software over Comprehensive Documentation)

โลกในอุดมคติ: หลายคนอาจจะไม่เห็นด้วย ว่าการทำ Software Development จะเป็นไปได้อย่างไรที่จะไม่มีการทำเอกสาร? คุณเข็มมองว่าเป็นไปได้มาก ๆ สำหรับทีมขนาดเล็ก ที่คนในทีมมีความสามารถพอ ๆ กัน พร้อมแลกเปลี่ยนไอเดียกันเสมอ สามารถสลับสับเปลี่ยนงานกันได้ ก็ไม่ได้มีความจำเป็นต้องทำเอกสารอะไรมากมาย

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

(3) การทำงานร่วมกับลูกค้า ควรมาก่อน การร่างสัญญา (Customer Collaboration over Contract Negotiation)

โลกในอุดมคติ: ข้อนี้ตรงกับ Muze มากครับ เพราะแต่ก่อนเราก็ทำงานในลักษณะตามสั่ง ที่ดีลงานกับลูกค้ามา เซ็นสัญญา มี TOR (Terms of Reference) เขียน Requirement เน้นสเปกแบบละเอียดยิบ และกำหนด Timeline เป๊ะ แต่ปัจจุบันเราเลือกที่จะผันตัวมาเป็น Tech Partner เพราะต้องการดึงลูกค้ามาเป็นพาร์ตเนอร์ ที่สร้าง Requirement ไปร่วมกัน พาร์ตเนอร์กำหนดเป้าหมายมาให้ แล้วมาออกแบบรายละเอียดร่วมกัน ซึ่งก็ต้องอาศัยการสร้างความสัมพันธ์อันดีกับพาร์ทเนอร์ มากกว่าจะเป็นการทำตามในสัญญาแบบลูกค้าและลูกจ้างทั่วไป

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

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

(4) การตอบรับความเปลี่ยนแปลง ควรมาก่อน การทำตามแผนที่วางไว้ (Responding to Change over Following a Plan)

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

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

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

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