ขณะที่ผมขับรถไปทำงานในเช้าวันอังคารถัดมา, ผมได้รับโทรศัพท์ด่วนจาก Kirsten ดูเหมือนว่าตอนนี้ Brent จะส่งงาน Phoenix ล่าช้าไปเกือบสัปดาห์แล้ว—ทั้งที่ Brent เคยบอกว่างานนี้จะใช้เวลาเพียงแค่ชั่วโมงเดียวเท่านั้น และอีกครั้งที่ตารางการทดสอบ Phoenix ทั้งหมดกำลังตกอยู่ในอันตราย
นอกจากนั้น งานสำคัญอื่นๆ อีกหลายอย่างของกลุ่มผมก็ล่าช้าด้วย ซึ่งเป็นการเพิ่มแรงกดดันต่อเส้นตาย (deadline) มากขึ้นไปอีก มันน่าท้อใจจริงๆ ที่ได้ยินแบบนี้ ผมนึกว่าการค้นพบวิธีการใหม่ๆ ล่าสุดของเราจะช่วยแก้ปัญหาเรื่องประสิทธิภาพการทำงานให้ทันตามกำหนด (due-date performance) ได้เสียอีก
เราจะเลิกแช่แข็ง (unfreeze) งานเพิ่มได้อย่างไร ในเมื่อตอนนี้เรายังทำงานตามไม่ทันเลย?
ผมฝากข้อความเสียงถึง Patty และที่ผมประหลาดใจคือ เธอใช้เวลาถึงสามชั่วโมงกว่าจะโทรกลับหาผม เธอบอกผมว่ามีบางอย่างผิดปกติอย่างมากกับการประมาณการตารางเวลาของเรา และเราต้องมาประชุมกันทันที
และอีกครั้งที่ผมอยู่ในห้องประชุม โดยมี Patty อยู่หน้าไวท์บอร์ด และ Wes กำลังตรวจสอบแผ่นกระดาษที่เธอแปะเอาไว้ “นี่คือสิ่งที่ผมได้เรียนรู้มาครับ” Patty กล่าวพลางชี้ไปที่กระดาษแผ่นหนึ่ง “งานที่ Kirsten โทรมาตามคือการส่งมอบสภาพแวดล้อมสำหรับการทดสอบ (test environment) ให้กับ QA อย่างที่เธอบอก Brent ประมาณการไว้ว่ามันจะใช้เวลาแค่สี่สิบห้านาทีครับ”
“ก็ฟังดูสมเหตุสมผลนะ” Wes กล่าว “คุณก็แค่ต้องสร้าง virtualized server ตัวใหม่ ติดตั้ง OS และแพ็กเกจซอฟต์แวร์อีกสองสามอย่างลงไป เขาคงจะเผื่อเวลาไว้เป็นสองเท่าแล้วล่ะเพื่อความชัวร์”
“ผมก็คิดแบบนั้นเหมือนกันครับ” Patty พูดพลางส่ายหัว “ยกเว้นแต่มันไม่ใช่แค่ ‘งานเดียว’ สิ่งที่ Brent รับปากไว้จริงๆ แล้วมันเหมือนโปรเจกต์ย่อยๆ โปรเจกต์หนึ่งเลยล่ะครับ—มันมีขั้นตอนมากกว่ายี่สิบขั้นตอนที่ต้องใช้คนจากอย่างน้อยหกทีมที่แตกต่างกัน! คุณต้องการทั้ง OS และแพ็กเกจซอฟต์แวร์ทั้งหมด, license keys, IP address เฉพาะ, การตั้งค่าบัญชีผู้ใช้พิเศษ, การกำหนดจุดเชื่อมต่อ (mount points) และจากนั้นคุณก็ต้องการให้ IP address เหล่านั้นถูกเพิ่มเข้าไปในรายการ ACL บนไฟล์เซิร์ฟเวอร์บางตัว ในกรณีนี้ ข้อกำหนดระบุว่าเราต้องการ physical server ดังนั้นเราจึงต้องการพอร์ตบนเราเตอร์ (router port) การเดินสายเคเบิล และชั้นวางเซิร์ฟเวอร์ (server rack) ที่มีพื้นที่ว่างเพียงพอด้วยครับ”
“โอ้...” Wes อุทานด้วยน้ำเสียงหงุดหงิดขณะอ่านสิ่งที่ Patty กำลังชี้ให้ดู เขาพึมพำว่า “เซิร์ฟเวอร์ที่เป็นฮาร์ดแวร์จริง (physical servers) นี่มันน่ารำคาญชะมัด”
“คุณกำลังหลงประเด็นครับ เรื่องนี้มันก็จะยังเกิดขึ้นอยู่ดี ต่อให้มันเป็นระบบเสมือน (virtualized) ก็ตาม” Patty กล่าว “อย่างแรก ‘งาน’ ของ Brent กลายเป็นว่ามันมีอะไรมากกว่าคำว่างานเยอะมาก อย่างที่สอง เราพบว่ามันคืองานหลายอย่างที่กระจายไปยังคนหลายคน ซึ่งแต่ละคนก็มีงานด่วนของตัวเองที่ต้องทำอยู่แล้ว เราเสียเวลาไปเป็นวันๆ ในทุกขั้นตอนการส่งต่องาน (handoff) ในอัตราความเร็วเท่านี้ ถ้าไม่มีการเข้ามาแทรกแซงอย่างรุนแรง คงต้องใช้เวลาเป็นสัปดาห์กว่า QA จะได้สิ่งที่พวกเขาต้องการครับ”
“อย่างน้อยเราก็ไม่ต้องเปลี่ยนค่าไฟร์วอลล์ (firewall change) นะ” Wes พูดประชด “ครั้งล่าสุดที่เราต้องการเปลี่ยนไอ้พวกนั้น กลุ่มของจอห์นใช้เวลาเกือบเดือน สี่สัปดาห์สำหรับการแก้ไขที่ใช้เวลาแค่สามสิบวินาที!”
ผมพยักหน้า รู้ดีว่า Wes หมายถึงอะไร ระยะเวลานำ (lead time) สำหรับการเปลี่ยนแปลงไฟร์วอลล์ได้กลายเป็นตำนานไปแล้ว
เดี๋ยวนะ Erik เคยพูดอะไรทำนองนี้หรือเปล่า? สำหรับการเปลี่ยนค่าไฟร์วอลล์ ถึงแม้งานจริงๆ จะใช้เวลาลงมือทำ (touch time) เพียงแค่สามสิบวินาที แต่มันกลับกินเวลาตามเข็มนาฬิกา (clock time) ถึงสี่สัปดาห์
นั่นเป็นเพียงภาพจำลองย่อส่วนของสิ่งที่กำลังเกิดขึ้นกับ Brent แต่สิ่งที่กำลังเกิดขึ้นกับเราตอนนี้มันแย่กว่านั้นมาก เพราะมันมีการส่งต่องาน
“ในทางกลับกัน ถ้าทรัพยากรทำงานยุ่งอยู่เก้าสิบเปอร์เซ็นต์ เวลาในการรอคอยจะเป็น ‘เก้าสิบเปอร์เซ็นต์หารด้วยสิบเปอร์เซ็นต์’ หรือเท่ากับเก้าชั่วโมง พูดอีกอย่างก็คือ งานของเราจะต้องรออยู่ในคิวนานกว่าตอนที่ทรัพยากรว่างงานห้าสิบเปอร์เซ็นต์ถึงเก้าเท่าครับ”
ผมสรุปว่า “ดังนั้น สำหรับงาน Phoenix สมมติว่าเรามีการส่งต่องานเจ็ดครั้ง และทรัพยากรแต่ละคนยุ่งอยู่เก้าสิบเปอร์เซ็นต์ของเวลาทำงาน งานเหล่านั้นจะใช้เวลาอยู่ในคิวรวมทั้งหมดเก้าชั่วโมงคูณด้วยเจ็ดขั้นตอน...”
“อะไรนะ? หกสิบสามชั่วโมง แค่เวลารอคิวเนี่ยนะ?” Wes พูดอย่างไม่อยากจะเชื่อ “เป็นไปไม่ได้!”
Patty พูดพร้อมรอยยิ้มเยาะ “โอ้ แน่นอนสิคะ ก็มันใช้เวลาพิมพ์แค่สามสิบวินาทีเองไม่ใช่เหรอ?”
“โอ้ ชิบหายแล้ว” Wes สบถพลางจ้องมองไปที่กราฟ
ทันใดนั้น ผมก็นึกถึงบทสนทนาระหว่างผมกับ Wes ก่อนที่ Sarah และ Chris จะตัดสินใจ deploy Phoenix ในที่ประชุมของ Kirsten ตอนนั้น Wes บ่นเรื่อง Ticket ที่เกี่ยวข้องกับ Phoenix ที่ถูกโยนไปมาอยู่เป็นสัปดาห์ๆ ซึ่งทำให้การ deployment ล่าช้า
มันก็เกิดขึ้นตอนนั้นเหมือนกัน แต่นั่นไม่ใช่การส่งต่องานระหว่างพนักงาน IT Operations ด้วยกันเอง แต่มันคือการส่งต่องานระหว่างองค์กร Development และ IT Operations ซึ่งซับซ้อนกว่านั้นมาก
การสร้างและจัดลำดับความสำคัญของงานภายในแผนกเดียวก็ยากพอแล้ว แต่การจัดการงานระหว่างแผนกต้องยากกว่านั้นอย่างน้อยสิบเท่าแน่นอน
ในขณะที่เรากำลังทำความเข้าใจเรื่องนี้ Patty ก็พูดต่อ “กระดาษแต่ละแผ่นบนบอร์ดนี้ก็เหมือนกับ ‘งาน’ ของ Phoenix นี้แหละค่ะ” เธอพูดพลางทำมือเป็นเครื่องหมายคำพูดในอากาศ “มันดูเหมือนงานที่ทำโดยคนคนเดียว แต่มันไม่ใช่ค่ะ จริงๆ แล้วมันคือหลายขั้นตอนที่มีการส่งต่องานหลายครั้งระหว่างคนหลายคน มิน่าล่ะการประมาณการโปรเจกต์ของ Kirsten ถึงได้คลาดเคลื่อนไปหมด”
“เราต้องแก้ไขเรื่องนี้ในตารางเวลาของ Kirsten และโครงสร้างการย่อยงาน (work breakdown structure หรือ WBS) ของเธอด้วยค่ะ จากที่ฉันเห็น หนึ่งในสามของงานที่เราสัญญาไว้กับ Kirsten ตกอยู่ในหมวดหมู่นี้ทั้งหมดเลยค่ะ”
“เยี่ยมไปเลย” Wes กล่าว “มันเหมือนในหนังเรื่อง Gilligan’s Island เป๊ะเลย เราส่งคนออกไปทัวร์สามชั่วโมง แต่พอผ่านไปหลายเดือน เรากลับมาสงสัยว่าทำไมไม่มีใครกลับมาเลยสักคน”
Patty กล่าวว่า “ฉันสงสัยว่าเราจะสร้างเลนคัมบัง (kanban lane) สำหรับแต่ละ ‘งาน’ เหล่านี้ได้ไหมคะ?”
“ใช่ครับ นั่นแหละ!” ผมกล่าว “Erik พูดถูก คุณเพิ่งเจอกองงานที่เกิดขึ้นซ้ำๆ (recurring work) กองโตเข้าให้แล้ว! ถ้าเราสามารถจดบันทึกและสร้างมาตรฐานให้กับงานที่ทำซ้ำๆ เหล่านี้ และฝึกฝนจนชำนาญ เหมือนที่คุณทำกับเรื่องการเปลี่ยนแล็ปท็อป ผมมั่นใจว่าเราจะพัฒนาการไหลของงาน (flow) ได้แน่นอนครับ!”
ผมเสริมว่า “รู้ไหมครับ ถ้าเราสามารถสร้างมาตรฐานให้กับงานการ deployment ที่ทำซ้ำๆ ทั้งหมดของเราได้ ในที่สุดเราก็จะสามารถบังคับใช้ความสม่ำเสมอของการตั้งค่าในระบบ production (production configurations) ของเราได้เสียที นั่นจะช่วยแก้ปัญหา infrastructure แบบ ‘เกล็ดหิมะ’ (snowflake) ของเรา—คุณก็รู้ ที่ไม่มีอันไหนเหมือนกันเลยน่ะ การที่ Brent กลายเป็น Brent ได้อย่างทุกวันนี้ ก็เพราะเราปล่อยให้เขาสร้างโครงสร้างพื้นฐานที่มีแต่เขาคนเดียวที่เข้าใจ เราจะยอมให้เรื่องนั้นเกิดขึ้นอีกไม่ได้เด็ดขาดครับ”
“เป็นประเด็นที่ดีครับ” Wes พ่นเสียงตอบรับ “รู้ไหม มันแปลกนะ ปัญหามากมายที่เราเจออยู่นี้ล้วนเกิดจากการตัดสินใจของเราเองทั้งนั้น เราได้เผชิญหน้ากับศัตรูแล้ว และศัตรูคนนั้นก็คือพวกเราเองนี่แหละ”
Patty กล่าวว่า “รู้ไหมคะ การ deployment ก็เหมือนกับการประกอบชิ้นส่วนสุดท้ายในโรงงานผลิตเลยค่ะ ทุกการไหลของงานต้องผ่านขั้นตอนนี้ และคุณไม่สามารถส่งสินค้าออกไปได้ถ้าไม่มีมัน ทันใดนั้น ฉันก็รู้เลยว่าคัมบังควรจะมีหน้าตาเป็นยังไง”
ในช่วงสี่สิบห้านาทีถัดมา พวกเราก็ได้ร่วมกันสร้างแผนงาน Patty จะทำงานร่วมกับทีมของ Wes เพื่อรวบรวมงานที่เกิดขึ้นบ่อยที่สุด 20 อันดับแรก
เธอยังจะหาวิธีจัดการและควบคุมงานให้ดีขึ้นเมื่อมันต้องรออยู่ในคิว Patty เสนอบทบาทใหม่ ซึ่งเป็นการผสมผสานระหว่างผู้จัดการโครงการและผู้ประสานงานเร่งรัดงาน (expediter) แทนที่จะคอยดูแลเป็นรายวัน พวกเขาจะทำหน้าที่ควบคุมแบบนาทีต่อนาที เธอพูดว่า “เราต้องการการส่งต่องานที่เสร็จแล้วไปยังศูนย์งานถัดไปอย่างรวดเร็วและมีประสิทธิภาพ ถ้าจำเป็น คนคนนี้จะไปนั่งเฝ้าที่ศูนย์งานจนกว่างานจะเสร็จและหามันไปส่งที่ศูนย์งานถัดไปทันที เราจะไม่ยอมให้งานที่สำคัญหายไปในกอง Ticket อีกต่อไปแล้วค่ะ”
“อะไรนะ? จะให้ใครสักคนมาคอยหามงานส่งจากคนหนึ่งไปให้อีกคนหนึ่ง เหมือนเป็นบริกรอย่างนั้นเหรอ?” Wes ถามอย่างไม่อยากจะเชื่อ
“ที่โรงงาน MRP-8 เขามีบทบาทที่เรียกว่า ‘แมงมุมน้ำ’ (water spider) ที่ทำหน้าที่แบบนั้นเป๊ะเลยค่ะ” เธอโต้แย้ง “ความล่าช้าล่าสุดเกือบทั้งหมดของ Phoenix เกิดจากการที่งานต้องรออยู่ในคิวหรือการส่งต่องาน วิธีนี้จะช่วยให้มั่นใจว่ามันจะไม่เกิดขึ้นอีกค่ะ”
“ในที่สุด” เธอเสริม “ฉันอยากจะย้ายคัมบังทั้งหมดไปไว้บนระบบ เพื่อที่เราจะได้ไม่ต้องใช้คนมาเป็นกลไกส่งสัญญาณการส่งต่องานอีกต่อไป ไม่ต้องห่วงนะคะ เดี๋ยวฉันจะหาทางจัดการเรื่องนี้ให้เสร็จภายในวันสองวันค่ะ”
Wes และผมไม่กล้าสงสัยในตัวเธอเลยแม้แต่นิดเดียว