- ทีมวิศวกรรมมักถูกกดดันให้ต้อง "ปล่อยฟีเจอร์ให้มากขึ้นและเร็วขึ้น"
- แต่ถ้าทำหลายงานพร้อมกันมากเกินไป กลับทำให้ประสิทธิภาพลดลง
- "เคล็ดลับของการปล่อยงานให้ได้มากขึ้น แท้จริงแล้วคือการทำน้อยลง" -
Less is More
หลักการสำคัญ
- ทำให้ทุกงาน มองเห็นได้ชัดเจน
- นิยามงานให้เป็นหน่วยเล็ก
- จำกัดงานที่ กำลังดำเนินอยู่
- จัดสรรทรัพยากรให้สอดคล้องกับขีดความสามารถ
- โบนัส: กันพื้นที่เผื่อไว้สำหรับเรื่องที่อาจเกิดขึ้น
# ทำให้ทุกงานมองเห็นได้ชัดเจน
- เมื่อทำให้งานมองเห็นได้ชัดเจน จะทำให้มองเห็นความเป็นจริงตรงหน้า
- เมื่อเห็นงานทั้งหมดได้ในภาพเดียว จะมีข้อดีดังนี้
- กำหนดลำดับความสำคัญได้ชัดเจน
- หยุดหรือละงานที่ไม่จำเป็นได้
- ทำให้ทีมโฟกัสกับการทำงานที่เริ่มไปแล้วให้เสร็จ
- เป้าหมายไม่ใช่การติดตามทุกงานไปตลอดกาล → แต่เพื่อ เข้าใจสถานการณ์จริงอย่างชัดเจนและตัดสินใจได้ดีขึ้น
# นิยามงานให้เป็นหน่วยเล็ก
- ถ้างานใหญ่เกินไป จะทำให้พลังงานของทีมหมดลงและมองไม่เห็นความคืบหน้าอย่างชัดเจน
- จำกัดขนาดของงานให้อยู่ราว 1~2 สัปดาห์
- นักพัฒนาจะรักษาแรงจูงใจได้จากผลลัพธ์ระยะสั้น
- รับ feedback ได้เร็วและปรับแก้ได้ทัน
- ข้อดีของงานหน่วยเล็ก
- code review ทำได้ง่ายขึ้น
- เกิดการแชร์ความรู้ได้อย่างเป็นธรรมชาติ
- ความร่วมมือระหว่างสมาชิกทีมดีขึ้น
- ลดความเสี่ยงในการ deploy
- ยิ่งลดขนาดของงาน ความเร็วก็ยิ่งเพิ่มขึ้น → ไม่ถูกฟีเจอร์ที่ซับซ้อนกลบจนเสีย momentum
# จำกัดงานที่กำลังดำเนินอยู่
- การจัดการหลายฟีเจอร์พร้อมกันกลับทำให้ประสิทธิภาพลดลง
- เกิด ต้นทุนจากการสลับบริบท → อาจใช้เวลาสูงสุด 23 นาทีในการปรับตัวเข้ากับงานใหม่
- ยิ่งมีงานระหว่างทำมากเท่าไร ก็ยิ่งเกิดปัญหาต่อไปนี้
- คุณภาพลดลง
- บั๊กเพิ่มขึ้น
- ขวัญกำลังใจของทีมลดลง
- สัญญาณของภาระงานเกินในระดับทีม
- นักพัฒนาแต่ละคนทำงานมากกว่า 4 ชิ้น
- ใช้เวลาทำเสร็จนานกว่าที่คาด
- ฟีเจอร์ที่กำลังทำมีมากกว่าฟีเจอร์ที่เสร็จแล้ว
- สัญญาณของภาระงานเกินในระดับบุคคล
- สมาธิลดลง
- เวลาในการตอบกลับ code review เพิ่มขึ้น
- อธิบายลำดับความสำคัญได้ยากในการประชุมอัปเดตสถานะ
# จัดสรรทรัพยากรให้สอดคล้องกับขีดความสามารถ
- แนวทางแบบ "นักพัฒนาหนึ่งคนรับผิดชอบหนึ่งฟีเจอร์" ไม่มีประสิทธิภาพ
- รวมทรัพยากรของทีมไปที่งานที่สำคัญที่สุด
- เพิ่มความร่วมมือ → แก้ปัญหาได้เร็วขึ้น
- คุณภาพโค้ดดีขึ้น → เอื้อต่อ peer review แบบเรียลไทม์
- ความเร็วในการทำงานให้เสร็จเพิ่มขึ้น
- นักพัฒนาสามารถเข้าใจงานได้ลึกขึ้นผ่านการทำงานร่วมกัน
- ควรส่งเสริมผลลัพธ์ระดับทีม → เน้นผลงานของทีมมากกว่าผลงานรายบุคคล
# กันพื้นที่เผื่อไว้
- การทำงานที่ความจุ 100% กลับทำให้ผลลัพธ์แย่ลง
- งานที่ไม่คาดคิดเป็นสิ่งหลีกเลี่ยงไม่ได้ → แค่ไม่รู้ว่าจะเกิดขึ้นเมื่อไร
- ปัญหาที่เกิดขึ้นเมื่อไม่มีพื้นที่เผื่อ
- ทีมจะทำงานแบบตั้งรับ
- คุณภาพลดลง
- นวัตกรรมลดลง
- หนี้เทคนิคเพิ่มขึ้น
- เมื่อมีพื้นที่เผื่อ จะมีข้อดีดังนี้
- รับมือกับปัญหาที่ไม่คาดคิดได้อย่างยืดหยุ่น
- แก้ปัญหาอย่างสร้างสรรค์ได้
- รักษาคุณภาพให้อยู่ในระดับสูงได้
- รักษาความเร็วในการทำงานอย่างยั่งยืนได้
- พื้นที่เผื่อที่เหมาะสมอยู่ที่ประมาณ 20% → ปรับได้ตามลักษณะของทีม
สรุปกลยุทธ์หลัก
- ทำให้งานมองเห็นได้ชัดเจน → เพื่อมองเห็นความเป็นจริงอย่างตรงไปตรงมา
- นิยามงานให้เป็นหน่วยเล็ก → เพื่อรักษา momentum
- จำกัดงานที่กำลังดำเนินอยู่ → เพื่อเพิ่มสมาธิ
- จัดสรรทรัพยากรให้สอดคล้องกับขีดความสามารถ → เพื่อโฟกัสตามลำดับความสำคัญ
- กันพื้นที่เผื่อไว้ → เพื่อรักษาความยืดหยุ่น
บทสรุป
- หากต้องการทำงานให้ได้มากขึ้น จำเป็นต้องใช้ กลยุทธ์แบบทำน้อยลง
- ผลลัพธ์ของทีมไม่ได้วัดจากจำนวนฟีเจอร์ที่จัดการพร้อมกันได้มากแค่ไหน แต่ วัดจาก การส่งมอบคุณค่าให้ลูกค้าได้อย่างมีประสิทธิภาพเพียงใด
- บทบาทของผู้นำไม่ใช่การเพิ่มงานให้ทีม แต่คือ การช่วยเอางานที่ไม่จำเป็นออกไป
12 ความคิดเห็น
ใน GeekNews ก็เคยมีการกล่าวถึงหลายครั้งเช่นกันว่า ในหนังสือ <The Phoenix Project> ก็พูดถึงเรื่องคล้ายกัน ยิ่งเข้าใกล้ความจุ 100% มากเท่าไร เวลาตอบสนองก็จะยิ่งยาวขึ้นแบบทวีคูณ
โอ้ เรื่องนั้นก็มีพูดถึงในหนังสือชื่อ Goal เหมือนกัน!
เพราะว่า The Phoenix Project เองก็เป็นหนังสือที่เขียนขึ้นให้เป็นเวอร์ชัน IT ของ The Goal นั่นเอง
โห........ ขอบคุณครับ!!
พยายามจะรักษาสัดส่วนงานไว้ที่ 80% และเผื่อพื้นที่ว่างไว้อีก 20% แต่ก็ยังคิดหนักทุกครั้งว่าจะใช้เกณฑ์อะไรดี.. บางทีก็รู้สึกว่าควรคิดเป็นเวลาแบบตรงๆ ไหม
ผมเลยกันเวลาบ่ายวันศุกร์ไว้เป็นเวลาพัฒนาส่วนตัวไปเลยครับ!
เมื่อแบ่งงานออกเป็นทาสก์เล็ก ๆ แบบนี้ ผู้นำที่มองเห็นภาพใหญ่จะมีอำนาจมากขึ้น วิศวกรที่ทำงานร่วมกันกลับยิ่งหมดแรงจูงใจและเริ่มรู้สึกว่า “แล้วพวกเรากำลังมุ่งหน้าไปทางไหนกันแน่” นี่คือข้อเสียที่เป็นตัวแทนชัดเจนของ agile แบบอิงสปรินต์
ดูเหมือนว่าบทความนี้จะเขียนจากมุมมองของผู้นำมากเกินไปจริง ๆ ตามชื่อเรื่องเลย
โมเมนตัมของวิศวกรได้รับอิทธิพลอย่างมากจากการที่ผู้นำกำลังชูธงไปในทิศทางไหนเช่นกัน ยังดูเหมือนว่าควรคิดให้มากขึ้นอีกหน่อยถึงวิธีสื่อสารว่าอยากส่งมอบคุณค่าอะไรให้ลูกค้า และ output กับ delivery outcome ของแต่ละสปรินต์คืออะไร แน่นอนว่านี่เป็น soft skill ที่ยาก จึงหาได้ยากทั้งผู้นำที่ทำได้ดีจริง ๆ และบทความที่เขียนเรื่องนี้ดี ๆ เช่นกัน
เห็นด้วยกับคอมเมนต์นี้อย่างแรงเลย มีความเสี่ยงที่จะเกิดการไมโครเมเนจในส่วนที่เป็นเทคนิคได้ (หรือเคยเกิดขึ้นแล้ว) ไม่ง่ายเลยจริงๆ
ไม่ใช่ว่าควรแชร์ภาพรวมใหญ่ ให้ทุกคนเข้าใจตรงกัน แล้วค่อยแบ่งงานออกเป็นทาสก์เล็ก ๆ เหรอครับ??
ถ้าแบ่งเป็นช่วงละ 1-2 สัปดาห์ ดูเหมือนว่าโดยธรรมชาติแล้วจะมีเพียงคนจำนวนจำกัดเท่านั้นที่เข้าใจภาพของฟีเจอร์หนึ่ง ๆ ได้ อย่างความแตกต่างระหว่าง process กับ thread นั่นแหละครับ เพราะเป็นการจำกัดขอบเขตความสนใจเพื่อเพิ่มผลิตภาพ
แม้จะแชร์ภาพนั้นร่วมกัน ก็ยังตั้งอยู่บนสมมติฐานว่าคนจะตั้งคำถามกับภาพนั้น แต่ดูเหมือนว่าผมเองก็เผลอตั้งสมมติฐานไปตามธรรมชาติด้วยว่า ถ้าทิศทางเปลี่ยนไปทีละนิดในทุกครั้งของการวางแผนสปรินต์ ก็จะไม่สามารถตามให้ทันได้ว่ากำลังติดตามภาพใหญ่อย่างไรอยู่
ผมเห็นด้วยอย่างยิ่งกับสิ่งที่บทความนี้นำเสนอ และก็เห็นด้วยกับปัญหาที่คุณกล่าวมาด้วย
จริง ๆ แล้วนี่ก็เป็นประเด็นที่ผมกำลังครุ่นคิดอยู่เช่นกัน
แม้จะแตกต่างกันไปในแต่ละสควอด แต่ถ้าให้สมาชิกทีมมีส่วนร่วมอย่างแข็งขันในการวางแผนสปรินต์ ปัญหาที่คุณพูดถึงก็ไม่ได้เกิดขึ้นจริง ๆ ครับ ขณะเดียวกันก็พยายามให้ทุกคนรับรู้ถึงงานที่เปลี่ยนไปได้อย่างเพียงพอ โดยแชร์บริบทของโปรเจกต์และสถานการณ์ที่เปลี่ยนไปในแต่ละสปรินต์ พร้อมกับขอให้ลองแบ่งงานออกเป็นส่วนย่อยให้ละเอียดมาก ๆ
อย่างที่คุณบอก ในแง่ของการบริหารจัดการ ไม่ว่าจะเป็นการติดตามความคืบหน้า การวัดความเร็วในการทำงาน การรับมือกับสถานการณ์ที่ไม่คาดคิด และต้นทุนค่าเสียโอกาสเมื่อผลงานออกมาไม่เป็นไปตามเจตนา พอมาคิดดูแล้ว การแบ่งงานให้เล็กลงก็มักทำให้งานเดินหน้าได้ดีในที่สุดครับ
มีบทความลักษณะคล้ายกันถูกพูดซ้ำอยู่เรื่อย ๆ แต่ความโลภของมนุษย์นั้นไม่มีที่สิ้นสุด และเราก็ทำพลาดแบบเดิมซ้ำ ๆ
การที่ CPU ของคอมพิวเตอร์มีโหลด 100% ไม่ใช่เรื่องปกติ แต่พอเป็นโหลดงานของมนุษย์ 100% กลับสรุปกันว่า...ต้องขยันให้มากขึ้น