เลิกเซ็นอนุมัติจนเหนื่อยใจ: ถอดรหัส Agile Manifesto เป็นภาษาคนทำธุรกิจ ใน 4 ประโยค
แถลงการณ์อไจล์ (Agile Manifesto) ที่วิศวกรซอฟต์แวร์ 17 คนเขียนไว้ในปี 2001 จริงๆ แล้วไม่ได้พูดถึงการเขียนโปรแกรม แต่พูดถึง "ทำไมบริษัทที่ยึดแผนตายตัวถึงแพ้บริษัทที่พร้อมปรับเปลี่ยนได้ตลอดเวลา" บทเรียนนี้แปล 4 ประโยคของแถลงการณ์เป็นภาษาที่เจ้าของธุรกิจ SME เข้าใจง่าย พร้อมเคสจริงจากการปฏิรูปสู่อไจล์ของธนาคารไทย
คุณหลิน เจียหรง เจ้าของโรงงานขนาดเล็กในสมุทรปราการ ที่รับผลิตเครื่องแบบพนักงานสั่งตัดและงานปักโลโก้ให้โรงแรมและสายการบิน มีพนักงาน 26 คน เมื่อเดือนที่แล้ว เครือโรงแรมระดับห้าดาวรายหนึ่งเปลี่ยนสเปกผ้าเครื่องแบบประจำฤดูกาลทั้งหมดกะทันหัน สาเหตุเพียงเพราะเครือโรงแรมเปลี่ยนผู้อำนวยการฝ่ายจัดซื้อคนใหม่ที่มีซัพพลายเชนที่ชอบต่างออกไป ทีมของคุณหลินซึ่งทำตามสัญญาที่เซ็นไว้เมื่อสามเดือนก่อนไปแล้ว ทั้งตัดแบบ สั่งซื้อผ้า จัดคิวสายการผลิต ต้องเป็นโมฆะในชั่วข้ามคืน แค่ค่าเสียหายจากผ้าอย่างเดียวก็หลักแสนบาท
ที่ทำให้เธอเหนื่อยใจกว่านั้นคือปฏิกิริยาภายในทีมเอง ผู้จัดการฝ่ายผลิตกางแผนงานโครงการสิบสองหน้าที่แน่นขนัดออกมาแล้วบอกว่า "ลูกค้าผิดสัญญาก่อน ต้องว่ากันตามเงื่อนไขสัญญา" แต่ผู้จัดการฝ่ายขายเตือนเธอว่า เครือโรงแรมนี้คิดเป็นเกือบสามสิบเปอร์เซ็นต์ของรายได้ทั้งปี การหักหน้ากันไม่ใช่ทางเลือก คืนนั้นคุณหลินไถมือถือเจอบทความหนึ่งพูดถึง "Agile Manifesto" สี่ประโยค ประโยคแรกคือ "บุคคลและการปฏิสัมพันธ์ สำคัญกว่ากระบวนการและเครื่องมือ" เธอจ้องแผนงานสิบสองหน้าที่พิสูจน์แล้วว่าไร้ประโยชน์นั้น รู้สึกถึงความย้อนแย้งขึ้นมาทันที
ทำไม
เดือนกุมภาพันธ์ ปี 2001 ผู้เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ 17 คน รวมถึง Kent Beck, Martin Fowler, Jeff Sutherland และ Ward Cunningham รวมตัวกันที่รีสอร์ตสกี Snowbird รัฐยูทาห์ สหรัฐอเมริกา เป็นเวลาสามวัน และร่างสิ่งที่ต่อมาถูกเรียกว่า "Agile Manifesto" ปัญหาที่พวกเขาต้องการแก้ไข แท้จริงแล้วเป็นปัญหาแบบเดียวกับที่คุณหลินเจอ นั่นคือ ใช้เวลาหลายเดือนเขียนแผนงานที่ละเอียดยิบทุกจุด แต่พอถึงเวลาส่งมอบจริง ตลาดเปลี่ยนไปแล้ว แผนงานนั้นกลับกลายเป็นอุปสรรคแทนที่จะเป็นตัวช่วย สี่ประโยคของแถลงการณ์คือ บุคคลและการปฏิสัมพันธ์ สำคัญกว่ากระบวนการและเครื่องมือ ผลงานที่ใช้งานได้จริง สำคัญกว่าเอกสารที่ละเอียดครบถ้วน ความร่วมมือกับลูกค้า สำคัญกว่าการต่อรองตามสัญญา การตอบสนองต่อการเปลี่ยนแปลง สำคัญกว่าการยึดตามแผนที่วางไว้ สี่ประโยคนี้จงใจใช้คำว่า "สำคัญกว่า" ไม่ใช่ "แทนที่" หมายความว่าไม่ใช่ไม่ต้องมีกระบวนการ เอกสาร สัญญา หรือแผนงานเลย แต่เมื่อสองสิ่งนี้ขัดแย้งกัน ควรเลือกฝั่งไหนก่อน สำหรับเจ้าของธุรกิจ SME สี่ประโยคนี้จริงๆ แล้วกำลังตอบคำถามที่พื้นฐานกว่านั้นคือ ในเมื่อทรัพยากรบริษัทมีจำกัดขนาดนี้ ควรทุ่มแรงไปกับ "เขียนแผนให้สมบูรณ์แบบที่สุด" หรือ "ทำให้ทีมค้นพบว่าแผนผิดพลาดได้เร็วขึ้นแล้วปรับแก้" คำตอบของ Agile Manifesto ชัดเจนมาก คือแบบหลัง
ทำอย่างไร
บุคคลและการปฏิสัมพันธ์ สำคัญกว่ากระบวนการและเครื่องมือ
ไม่ได้หมายความว่าให้ทิ้งแบบฟอร์มทั้งหมด แต่เมื่อเจอเรื่องติดขัด ให้คนที่เกี่ยวข้องสองคนคุยกันห้านาที ดีกว่าส่งเอกสารอนุมัติไปมาสามวัน วิธีที่คุณหลินทำหลังจากนั้นคือ ให้ผู้จัดการฝ่ายผลิตกับผู้จัดการฝ่ายขายนัดคุยกันสิบห้านาทีทันทีในบ่ายวันที่โรงแรมเปลี่ยนสเปก เพื่อตัดสินใจแผนหยุดความเสียหายทันที แทนที่จะต่างคนต่างเขียนเอกสารเสนอขึ้นไปตามลำดับชั้น
ผลงานที่ใช้งานได้จริง สำคัญกว่าเอกสารที่ละเอียดครบถ้วน
แทนที่จะใช้เวลาสองสัปดาห์เขียนแผนงานที่สมบูรณ์แบบ ควรทำตัวอย่างชิ้นงานให้ลูกค้าดูภายในสามวัน KBTG บริษัทลูกด้านเทคโนโลยีของธนาคารกสิกรไทย เคยแชร่วิธีการต่อสาธารณะระหว่างการปฏิรูปสู่อไจล์ว่า ฟีเจอร์ใหม่ไม่ต้องรอให้ "เอกสารสเปกฉบับสมบูรณ์" เสร็จก่อนจึงเริ่มพัฒนา แต่จะส่งมอบต้นแบบที่ใช้งานได้จริงให้ผู้ใช้ภายในลองใช้ภายในสองสัปดาห์ อาศัยฟีดแบ็กจริงในการปรับทิศทาง ซึ่งเร็วกว่าการนั่งเดาในห้องประชุมมาก
ความร่วมมือกับลูกค้า สำคัญกว่าการต่อรองตามสัญญา
สัญญามีไว้ป้องกันเส้นแบ่งขั้นต่ำ ไม่ใช่ข้ออ้างในการหยุดสื่อสาร หลังจากนั้นคุณหลินตกลงกับเครือโรงแรมใหม่ว่า จะจัดประชุมยืนยันตัวอย่างผ้าล่วงหน้าแปดสัปดาห์ก่อนเปลี่ยนฤดูกาล ให้ฝ่ายจัดซื้อของลูกค้าเข้ามามีส่วนร่วมและแสดงจุดยืนล่วงหน้า แทนที่จะรอจนถึงวันหมดสัญญาแล้วค่อยมาพบว่าสเปกเปลี่ยนไปแล้ว
การตอบสนองต่อการเปลี่ยนแปลง สำคัญกว่าการยึดตามแผนที่วางไว้
ให้มอง "แผนงาน" เป็นแผนที่เส้นทางที่ปรับแก้ได้ตลอดเวลา ไม่ใช่คำสัญญาที่สลักไว้บนหิน ประเด็นนี้จะถูกขยายความในบทเรียนถัดไป "แบ่งหนึ่งปีเป็นยี่สิบหกรอบสองสัปดาห์" ว่าจะออกแบบรอบตรวจสอบอย่างไร ในบทนี้ขอปูฐานความคิดไว้ก่อนว่า แผนที่ถูกแก้ไขไม่ใช่ความล้มเหลว แผนที่ตายตัวแก้ไม่ได้ต่างหากคือความเสี่ยง
🔧 ลงมือทำกับ AI: เครื่องแปล Agile Manifesto
อธิบายกระบวนการหรือการประชุมที่ติดขัดอยู่ในบริษัทของคุณให้ AI ฟัง แล้วให้มันวินิจฉัยตามสี่ประโยคของ Agile Manifesto ว่าปัญหาอยู่ตรงไหน พร้อมให้วิธีแก้แบบที่เริ่มทำได้ภายในสัปดาห์นี้
คุณคือที่ปรึกษาการปฏิรูปสู่อไจล์ของฉัน นี่คือกระบวนการ การประชุม หรือเอกสารที่บริษัทของฉันติดขัดอยู่ตอนนี้: [อธิบายให้ชัดเจน เช่น ทุกครั้งที่ลูกค้าเปลี่ยนความต้องการกะทันหัน ต้องผ่านใบขออนุมัติเปลี่ยนแปลงที่ต้องเซ็นสามระดับผู้บริหาร ปกติใช้เวลาหนึ่งสัปดาห์กว่าจะเริ่มงานจริง] ช่วยฉัน: 1. เทียบกับคุณค่าหลักสี่ข้อของ Agile Manifesto (บุคคลและการปฏิสัมพันธ์ ผลงานที่ใช้งานได้จริง ความร่วมมือกับลูกค้า การตอบสนองต่อการเปลี่ยนแปลง) แล้วชี้ว่ากระบวนการนี้ตอนนี้เอนไปทางความคิดแบบเดิมข้อไหน 2. ให้วิธีแก้แบบ "อไจล์" ที่ทำได้จริง ละเอียดถึงระดับ "เริ่มลองได้สัปดาห์นี้" ไม่ใช่แค่ทิศทางกว้างๆ 3. เตือนความเสี่ยงที่อาจเจอจากการปรับแบบนี้ (เช่น ความรับผิดชอบที่คลุมเครือขึ้น) และวิธีลดความเสี่ยง ประเภทธุรกิจ: [กรอก เช่น รับผลิตเครื่องแบบสั่งตัด/ร้านอาหารเครือข่าย/โลจิสติกส์] จำนวนทีม: [กรอก]
สิ่งที่ทำได้สัปดาห์นี้: เลือกเรื่องที่กำลังรออนุมัติหรือรอสรุปแผนงานอยู่สักหนึ่งเรื่อง ลองใช้พรอมต์ข้างต้นดูสักครั้ง ดูว่าจะตัดเวลารอลงได้ครึ่งหนึ่งหรือไม่
📎 อ้างอิงทฤษฎี: Agile Manifesto ร่างขึ้นโดยผู้เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ 17 คน รวมถึง Kent Beck, Martin Fowler, Jeff Sutherland และ Ward Cunningham ที่ Snowbird รัฐยูทาห์ สหรัฐอเมริกา ในเดือนกุมภาพันธ์ ปี 2001 กรอบการทำงาน Scrum เสนอโดย Jeff Sutherland และ Ken Schwaber ร่วมกันในปี 1995 แนวทางการปฏิรูปสู่อไจล์ของ KBTG บริษัทลูกด้านเทคโนโลยีของธนาคารกสิกรไทย อ้างอิงจากบล็อกเทคนิคและการบรรยายสาธารณะของบริษัท
สมาชิกฟรีทำแบบทดสอบ คุยกับโค้ช AI ฟังบทความสะสมประวัติการเรียนรู้ สมัครรับ 100 พอยต์ทันที
สมัครฟรี