เพิ่มความเร็วของทีม ด้วยการช้าลง !!

คำพูดเกี่ยวกับทีมพัฒนาที่มักได้ยินจากฝ่าย Management, Team lead, Product Manager และ ... คือ ทีมพัฒนาทำงานช้า หรือ ทำงานยังไม่เร็วตามความต้องการ คำถามคือ ถ้าต้องการให้ทีมพัฒนาทำงานเร็วขึ้นต้องทำอย่างไร ? คำตอบที่มักจะได้รับคือ

• ตัดเรื่องคุณภาพออกไป หรือ ลดลง
• ทำ OT สิ
• ทำให้มันเร็วขึ้นสิ
• เพิ่มคนสิ

ผลที่ได้รับกลับมาเป็นอย่างไร ?

• คุณภาพของ feature และ ระบบมันต่ำลงเรื่อย ๆ
• จำนวนข้อผิดพลาดเยอะขึ้นเรื่อย ๆ
• จำนวน feature ที่ไม่ถูกทดสอบเยอะขึ้นเรื่อย ๆ
• การพัฒนาช้าลงอย่างต่อเนื่อง
• ปัญหาในเรื่องการ integrate ระบบต่าง ๆ เข้าด้วยกันเพิ่มขึ้นเรื่อย ๆ
• การ deploy ระบบใช้เวลานานขึ้นเรื่อย ๆ
• ผู้ใช้งาน และ ลูกค้า เริ่มไม่พอใจขึ้นเรื่อย ๆ
• ฝ่ายบริหารเริ่มไม่พอใจขึ้นเรื่อย ๆ
• ทีมเริ่มถูกกดดันอย่างมาก อาจจะทนอยู่หรืออยู่ทน

คำถามที่ต้องถามตัวเราเอง คือ แนวทางแบบนี้มันคือการเพิ่มความเร็วจริงหรือ ?

หรือว่า มันกลับทำให้เราช้าลงไปกว่าเดิม ? ทั้งในแง่คุณภาพของระบบ ทั้งในแง่คุณภาพของ code ทั้งในแง่การทำงานเป็นทีม ดังนั้น เรามาเรียนรู้จากความผิดพลาดเหล่านี้กัน เพื่อไม่ให้เราผิดซ้ำที่เดิมอีก ก่อนอื่นเราควรมาทำความรู้และเข้าใจกับคำว่า ความเร็ว (Speed) ทีมจะทำงานได้อย่างรวดเร็ว ก็ต่อเมื่อแต่ละคนในทีม

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

แต่ดูมันเยอะนะ ตอบได้เลยว่า ใช่

ดังนั้นก่อนที่จะทำให้เร็ว ลองหยุด หรือ ทำตัวให้ช้า เพื่อมาเรียนรู้กับที่มาของความเร็วกัน

เรื่องของความเร็ว (Speed) มันประกอบด้วยหลาย ๆ สิ่ง แต่มีส่วนประกอบหลัก 2 อย่างคือ

1. Throughput
2. Cycle time

ถ้าเป็นความเร็วของการพัฒนา Softwate สามารถอธิบายได้ว่า

1. Throughput คือ จำนวนงานที่พัฒนาเสร็จในช่วงเวลาหนึ่ง ๆ
2. 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 ก็น้อยลงนะ !!

แต่การจะทำสิ่งเหล่านี้ได้ ต้องสร้างสภาวะแวดล้อมที่เอื้อด้วย

ทั้งความเชื่อมั่นใจในทีม ทั้งทีมต้องทำให้เชื่อมั่น เมื่อต่างฝ่ายต่างเชื่อมั่นซึ่งกันและกัน เมื่อนั้นคุณจะเห็นความเร็วที่แท้จริง