คำพูดเกี่ยวกับทีมพัฒนาที่มักได้ยินจากฝ่าย Management, Team lead, Product Manager และ …
คือ ทีมพัฒนาทำงานช้า หรือ ทำงานยังไม่เร็วตามความต้องการ
คำถามคือ ถ้าต้องการให้ทีมพัฒนาทำงานเร็วขึ้นต้องทำอย่างไร ?
คำตอบที่มักจะได้รับคือ
- ตัดเรื่องคุณภาพออกไป หรือ ลดลง
- ทำ OT สิ
- ทำให้มันเร็วขึ้นสิ
- เพิ่มคนสิ
ผลที่ได้รับกลับมาเป็นอย่างไร ?
- คุณภาพของ feature และ ระบบมันต่ำลงเรื่อย ๆ
- จำนวนข้อผิดพลาดเยอะขึ้นเรื่อย ๆ
- จำนวน feature ที่ไม่ถูกทดสอบเยอะขึ้นเรื่อย ๆ
- การพัฒนาช้าลงอย่างต่อเนื่อง
- ปัญหาในเรื่องการ integrate ระบบต่าง ๆ เข้าด้วยกันเพิ่มขึ้นเรื่อย ๆ
- การ deploy ระบบใช้เวลานานขึ้นเรื่อย ๆ
- ผู้ใช้งาน และ ลูกค้า เริ่มไม่พอใจขึ้นเรื่อย ๆ
- ฝ่ายบริหารเริ่มไม่พอใจขึ้นเรื่อย ๆ
- ทีมเริ่มถูกกดดันอย่างมาก อาจจะทนอยู่หรืออยู่ทน
คำถามที่ต้องถามตัวเราเอง คือ แนวทางแบบนี้มันคือการเพิ่มความเร็วจริงหรือ ?
หรือว่า มันกลับทำให้เราช้าลงไปกว่าเดิม ?
ทั้งในแง่คุณภาพของระบบ
ทั้งในแง่คุณภาพของ code
ทั้งในแง่การทำงานเป็นทีม
ดังนั้น เรามาเรียนรู้จากความผิดพลาดเหล่านี้กัน
เพื่อไม่ให้เราผิดซ้ำที่เดิมอีก
ก่อนอื่นเราควรมาทำความรู้และเข้าใจกับคำว่า ความเร็ว (Speed)
ทีมจะทำงานได้อย่างรวดเร็ว ก็ต่อเมื่อแต่ละคนในทีม
- รู้ว่าตัวเองต้องทำอะไร เพื่อให้เป้าหมายของทีมสำเร็จ
- มีความรู้ความเข้าใจในสิ่งที่กำลังทำ
- ต้องมีความชำนาญในสิ่งที่รับผิดชอบ
- รักในสิ่งที่ทำ
- มีความภูมิใจในสิ่งที่ทำ
- ทำงานกันเป็นทีม
แต่ดูมันเยอะนะ
ตอบได้เลยว่า ใช่
ดังนั้นก่อนที่จะทำให้เร็ว ลองหยุด หรือ ทำตัวให้ช้า เพื่อมาเรียนรู้กับที่มาของความเร็วกัน
เรื่องของความเร็ว (Speed) มันประกอบด้วยหลาย ๆ สิ่ง
แต่มีส่วนประกอบหลัก 2 อย่างคือ
- Throughput
- Cycle time
ถ้าเป็นความเร็วของการพัฒนา Softwate
สามารถอธิบายได้ว่า
- Throughput คือ จำนวนงานที่พัฒนาเสร็จในช่วงเวลาหนึ่ง ๆ
- Cycle time คือ จำนวนเวลาของการพัฒนางานหนึ่ง ๆ ให้เสร็จ
คำเตือน !!
เราสามารถทำการเพิ่ม Throughput และลด Cycle time ได้ก็ต่อเมื่อ
เราเข้าใจมันดีพอแล้วเท่านั้น
มิเช่นนั้น แทนที่จะทำให้ดีขึ้น กลับเลวร้ายลงกว่าเดิม
หรือเกิดผลกระทบมากมายตามมา
Throughput
ส่วนใหญ่ชอบเทียบด้วยจำนวนรถยนต์ที่วิ่งบนถนน
ซึ่งวิ่งจากที่หนึ่งไปอีกที่หนึ่งในเวลาที่กำหนด
คำถามเราจะเพิ่มจำนวน Throughput ได้อย่างไร ?
เพิ่มจำนวนรถเข้าไปให้ได้มากที่สุด เท่าที่ถนนจะรองรับได้ไงล่ะ
ทำการวัดความเร็วจาก
จำนวนรถที่วิ่งถึงเป้าหมายในเวลาที่กำหนด
ดังนั้นรถทุกคันต้องวิ่งด้วยความเร็วที่สูงขึ้น
แต่ลองคิดดูสิว่า
รถก็เยอะ วิ่งก็เร็ว แล้วมันจะปลอดภัยหรือ ?
จะเกิดอุบัติเหตุบ่อยไหม ?
ถ้าเกิดอุบัติเหตุขึ้นมาสักจุดบนถนน
การจราจรจะติดขัดมากน้อยเท่าไร ?
ดังนั้น การเพิ่มความเร็วของรถ ไม่เพียงทำให้เรากลัวเท่านั้น
ยังอาจจะทำให้เกิดการบาดเจ็บ ล้มตาย
ยังอาจจะทำให้ระบบหยุดทำงานอีกด้วย
สุดท้ายดันไปทำให้ค่าของ Throughput ลดลงไปอีก !!
การพัฒนา Software ของทีมก็เช่นเดียวกัน
เราต้องการกระบวนการการทำงานที่ปลอดภัย
นั่นคือ ต้องมีคำว่าคุณภาพในระดับที่ยอมรับร่วมกันทุกฝ่าย
แต่ถ้าตัด หรือ ลด สิ่งเล็ก ๆ ที่เรียกว่า คุณภาพลงไป
คุณต้องพบเจอความน่าสะพรึงกลัวมากมายตามมา !!
แต่เรากลับพบว่า สิ่งเหล่านี้ มันคือ ความปกติที่เกิดขึ้นอยู่ในทุกทีม ทุกองค์กร !!
ดังนั้น เชื่อเถอะว่า
คุณไม่ได้เดินอย่างเดียวดาย (You will never walk alone)
กลับมาดูว่า สิ่งที่ทำให้เราช้ามีอะไรบ้าง ?
ช่วยกันแก้ไข
ช่วยกันปรับปรุง
ช่วยกันหา way of work ใหม่ ๆ กัน
บางคนถามว่า ถ้าเราหยุดเพื่อแก้ไข ปรับปรุง แล้ว มันจะไม่ช้าลงหรือไง ?
ตอบได้เลยว่าช้าลงอย่างแน่นอน
แต่เฉพาะในช่วงแรกเท่านั้น
ต่อจากนั้นคุณจะเร็วขึ้นอย่างต่อเนื่อง
Cycle time
เป็นค่าที่บอกว่า คุณมีความเร็วเท่าไรต่อการทำงานงานหนึ่ง ๆ ให้เสร็จสิ้น
หรือความเร็วของทีม ในการตอบสนองต่อสิ่งหนึ่ง ๆ เช่น bug !!
ตัวอย่างง่าย ๆ ของ Cycle time คือ
การเข้าคิวซื้อและรับของในร้านกาแฟ
คุณใช้เวลาเท่าไรในการเข้าคิวกว่าจะได้กาแฟตามที่ต้องการ
ถ้าใช้เวลาในการรอนาน ๆ นั่นหมายถึง คุณสร้างประสบการณ์ที่แย่ ๆ ให้กับลูกค้า
มันย่อมไม่ใช่สิ่งที่ดีนัก !!
ไม่ว่ากาแฟจะรสชาติดีเพียงใด
ไม่ว่าคนชงจะเก่งขนาดไหน
ซึ่งการปรับค่าของ Cycle time ให้ลดลงนั้น
ไม่สามารถทำได้ด้วยการเพิ่มคุณภาพ
ไม่สามารถทำได้ด้วยการเพิ่มจำนวน Throughputเพราะว่ายิ่งเพิ่มสิ่งต่าง ๆ เหล่านี้เข้าไป ยิ่งทำให้เวลารอนานขึ้นไปอีก
แล้วทำอย่างไรดีล่ะ ?
คุณน่าจะรู้และเข้าใจว่า
การเพิ่มจำนวน Throughput ไม่ได้ช่วยเพิ่มความเร็วเลย
ดังนั้น สิ่งที่ต้องทำคือ รู้ก่อนว่าตัวเองมีความสามารถเท่าไร ?
หรือจำนวนงานเท่าไร ที่สามารถทำให้เสร็จในช่วงเวลาหนึ่ง
นั่นคือจงหาค่า Limit Work In Progress (WIP) ซะ
คำถามคือใครจะบอกได้ล่ะ ?
ตอบง่าย ๆ ว่า ทีมที่ทำไงล่ะ
จงเรียนรู้ไปด้วยกัน
ส่วน Cycle time ที่ดี ก็คือ ต้องสั้นที่สุดเท่าที่จะทำได้
ถ้าต้องการให้ชงกาแฟเร็วขึ้น
วิธีการง่าย ๆ คือ ลดคุณภาพของการชง
ซึ่งมันไม่ดีอย่างแน่นอน ทั้งต่อร้าน และ ลูกค้า !!
ดังนั้นวิธีการที่เหมาะสมก็คือ
- เพิ่มจำนวนคนชงสิ
- แบ่งขั้นตอนการชงออกมาสิ
แต่สำหรับการพัฒนา Software แล้ว !!
การเพิ่มคนเข้าไปในระหว่างการพัฒนา มันกลับทำให้ยิ่งช้าลง
สิ้นเปลืองค่าใช้จ่าย
และเพิ่มความซับซ้อนให้กับทีมอีก
เพราะว่า คนเยอะขึ้นการพูดคุยก็เยอะขึ้นอีก !!
มันยากเนาะ การพัฒนา Software
ดังนั้นแทนที่จะทำการเพิ่มคนเข้ามา
ให้กลับไปดูงานที่อยู่ในการพัฒนาดีไหม
ว่ามันเยอะเพียงใด ?
ทำการจัดเรียงลำดับความสำคัญ
ทำการเลือกสิ่งที่สำคัญมาทำก่อน
นั่นคือ การลดจำนวนงานลงไป จากสายการผลิต ตาม Limit WIP ของทีม
จำนวนงานที่น้อยลงในแต่ละรอบการทำงาน
มันยิ่งทำให้เราเข้าใจรายละเอียดของสิ่งที่จะทำมากขึ้น
มันยิ่งทำให้เราพูดกันมากขึ้น
ทั้งสิ่งนั้นคืออะไร ?
ทั้งทำสิ่งนั้นไปทำไม ?
ทั้งทำสิ่งนั้นไปเพื่ออะไร ?
และที่สำคัญการรอของแต่ละ feature ก็น้อยลงนะ !!
แต่การจะทำสิ่งเหล่านี้ได้ ต้องสร้างสภาวะแวดล้อมที่เอื้อด้วย
ทั้งความเชื่อมั่นใจในทีม
ทั้งทีมต้องทำให้เชื่อมั่น
เมื่อต่างฝ่ายต่างเชื่อมั่นซึ่งกันและกัน
เมื่อนั้นคุณจะเห็นความเร็วที่แท้จริง
