เวลา 12:13 น. ตอนที่ผมเดิน เข้าไปในห้องประชุม Kick-off ของทีม SWAT ผมของผมเปียกโชกและเสื้อเชิ้ตก็ชุ่มไปด้วยน้ำจากการนั่งรถเปิดประทุนของ Erik กลับมา Chris กำลังพูดอยู่ “—และ Steve ก็ได้อนุมัติให้ทีมเล็กๆ ทีมนี้รับผิดชอบในการส่งมอบฟีเจอร์โปรโมชัน และทำทุกวิถีทางเพื่อสร้างผลกระทบเชิงบวกให้กับช่วงเทศกาลช้อปปิ้งที่กำลังจะมาถึง”
Chris หันมาทางผมและชี้ไปที่หลังห้อง “ผมสั่งมื้อเที่ยงมาเผื่อทุกคนแล้วเพื่อเริ่มงานนี้ เชิญไปหยิบ—ว่าแต่เกิดอะไรขึ้นกับคุณน่ะ?”
ผมโบกมือปัดคำถามเขาไปพลางมองตามที่เขาชี้ ผมรู้สึกประหลาดใจปนยินดีที่เห็นกล่องแซนด์วิชไก่งวงยังเหลืออยู่ข้างหลัง ผมหยิบมันมาแล้วนั่งลง พยายามประเมินท่าทีของทุกคนในห้อง โดยเฉพาะ Brent
Brent ตอบกลับว่า “ช่วยอธิบายอีกทีสิว่าผมมาทำอะไรที่นี่?”
“นั่นคือสิ่งที่เรากำลังจะมาหาคำตอบกันนี่ไง” Wes พูดอย่างจริงจัง “นายรู้เท่าๆ กับที่พวกเรารู้นั่นแหละ หนึ่งในว่าที่บอร์ดบริหารยืนยันว่านายต้องเป็นส่วนหนึ่งของทีมนี้ ซึ่งเอาตรงๆ นะ เขาพูดถูกมาหลายครั้งจนฉันเชื่อใจเขาแล้วล่ะ ถึงแม้ฉันจะยังไม่รู้เหตุผลจริงๆ เลยก็ตามว่าทำไม”
Patty เสริมขึ้น “เขาให้คำใบ้เรามานิดหน่อยค่ะ เขาบอกว่าปัญหาที่เราต้องโฟกัสคือกระบวนการ Deployment และวิธีที่เราสร้าง Environment เขาดูเหมือนจะคิดว่าเราต้องทำอะไรผิดพลาดในระดับพื้นฐานแน่ๆ เพราะความวุ่นวายที่เกิดขึ้นทุกครั้งที่เราทำ Phoenix deployment”
ขณะที่ผมแกะห่อแซนด์วิช ผมก็พูดขึ้นว่า “ผมเพิ่งกลับมาจากคุยกับเขามาครับ เขาโชว์อะไรให้ผมดูหลายอย่าง และอธิบายวิธีที่ Toyota ทำ Single-Minute Exchange of Die เขาคิดว่าเราต้องสร้างความสามารถในการทำสิบ Deploy ต่อวันให้ได้ เขาไม่ได้แค่ยืนยันว่ามันเป็นไปได้นะ แต่เขายังบอกว่ามันจะช่วยสนับสนุนรอบการปล่อยฟีเจอร์ที่ธุรกิจต้องการ ไม่ใช่แค่เพื่อให้อยู่รอด แต่เพื่อที่จะชนะในตลาดด้วย”
น่าประหลาดใจที่ Chris เป็นคนที่ค้านรุนแรงที่สุด “อะไรนะ? ทำไมเราถึงต้องทำถึงสิบ Deploy ต่อวันล่ะ? รอบ Sprint ของเรายาวตั้งสามสัปดาห์ เราไม่มีอะไรให้ Deploy ตั้งสิบครั้งต่อวันหรอก!”
Patty ส่ายหัว “คุณแน่ใจเหรอคะ? แล้วพวก Bug fix ล่ะ? แล้วพวกการปรับปรุงประสิทธิภาพตอนที่เว็บไซต์เริ่มอืดเหมือนที่เกิดขึ้นในการเปิดตัวใหญ่สองครั้งล่าสุดล่ะ? คุณไม่อยากแก้ไขอะไรพวกนี้ใน Production ให้เป็นเรื่องปกติ โดยไม่ต้องแหกกฎทุกข้อเพื่อทำ Emergency change บ้างเหรอคะ?”
Chris นิ่งคิดครู่หนึ่งก่อนจะตอบ “น่าสนใจ ปกติผมจะเรียกการแก้ไขพวกนั้นว่า Patch หรือ Minor release แต่คุณพูดถูก—พวกนั้นมันก็คือการ Deployment เหมือนกัน มันคงจะดีถ้าเราปล่อยตัวแก้ไขได้เร็วขึ้น แต่โถ่... _สิบ Deploy ต่อวันเนี่ยนะ?_”
ผมนึกถึงสิ่งที่ Erik เคยบอก จึงเสริมขึ้น “แล้วถ้าทำให้ทีม Marketing สามารถเปลี่ยนเนื้อหาหรือเงื่อนไขทางธุรกิจได้ด้วยตัวเองล่ะครับ? หรือทำให้พวกเขาสามารถทำการทดลองหรือทำ A/B Split Testing ได้เร็วขึ้น เพื่อดูว่าข้อเสนอไหนได้ผลดีที่สุด?”
Wes วางมือทั้งสองข้างลงบนโต๊ะ “ฟังคำพูดฉันไว้นะทุกคน มันทำไม่ได้หรอก เรากำลังสู้กับกฎทางฟิสิกส์อยู่นะ ลืมไปได้เลยว่าตอนนี้ต้องเตรียมการกว่าหนึ่งสัปดาห์และใช้เวลาอีกแปดชั่วโมงในการ Deploy จริง! นายไม่สามารถเขียนข้อมูล (Bits) ลงแผ่นดิสก์ได้เร็วขนาดนั้นหรอก”
นั่นคือสิ่งที่ผมจะพูดเป๊ะๆ เลยก่อนที่จะได้ไปดูโรงงานกับ Erik ผมจึงพูดอย่างจริงจัง “เอาละ คุณอาจจะพูดถูกก็ได้ แต่ลองพิจารณาตามผมหน่อย: ขั้นตอนทั้งหมดในกระบวนการ Deployment ตั้งแต่ต้นจนจบจริงๆ มีกี่ขั้นตอนกันแน่? ยี่สิบ สองร้อย หรือสองพันขั้นตอน?”
Wes เกาหัวครู่หนึ่งก่อนจะพูด “นายว่าไง Brent? ฉันคิดว่าน่าจะประมาณร้อยขั้นตอน...”
“จริงเหรอครับ?” Brent ตอบ “ผมคิดว่าน่าจะแค่ยี่สิบขั้นตอนเองนะ”
William แทรกขึ้นมา “ผมไม่แน่ใจว่าพวกคุณเริ่มนับจากตรงไหนนะครับ แต่ถ้าเราเริ่มจากจุดที่ทีม Dev คอมมิตโค้ด (Commit code) และเราติดป้ายให้มันเป็น ‘Release Candidate’ ผมว่าผมลิสต์มาได้เป็นร้อยขั้นตอนแล้วล่ะครับ ตั้งแต่ก่อนจะส่งต่องานมาให้ทีม IT Operations ด้วยซ้ำ”
อ้าว งานเข้าแล้วไง
Wes ขัดจังหวะ “ไม่ๆๆ Bill บอกว่า ‘Deployment steps’ อย่าเพิ่งเปิดประเด็น—”
ขณะที่ Wes กำลังพูด ผมนึกถึงตอนที่ Erik ท้าทายให้ผมคิดแบบผู้จัดการโรงงานแทนที่จะเป็นหัวหน้าแผนก ผมเพิ่งตระหนักได้เดี๋ยวนี้เองว่าเขาคงหมายถึงการที่ผมต้องก้าวข้ามขอบเขตระหว่างแผนกของทีม Development และทีม IT Operations
“พวกคุณพูดถูกทั้งคู่แหละครับ” ผมพูดขัดจังหวะ Wes และ William “William คุณช่วยเขียนขั้นตอนทั้งหมดบนไวท์บอร์ดหน่อยได้ไหมครับ? ผมแนะนำให้เริ่มตั้งแต่ ‘Commit โค้ด’ ไปจนถึงตอนที่ส่งมอบงานมาให้กลุ่มของเรา”
เขาพยักหน้าและเดินไปที่ไวท์บอร์ด เริ่มวาดกล่องทีละใบพร้อมอธิบายขั้นตอนทีละขั้น ในช่วงสิบนาทีถัดมา เขาพิสูจน์ให้เห็นว่าน่าจะมีกว่าร้อยขั้นตอนจริงๆ รวมถึงการทำ Automated test ใน Dev environment การสร้าง QA environment ให้เหมือนกับ Dev การ Deploy โค้ดลงไป การรันเทสทั้งหมด การ Deploy และย้ายข้อมูล (Migrate) ไปยัง Staging environment ที่สดใหม่และตรงกับ QA การทำ Load testing และสุดท้ายคือการส่งไม้ต่อให้ทีม IT Operations
เมื่อ William เขียนเสร็จ มีกล่องทั้งหมดสามสิบใบอยู่บนกระดาน
ผมมองไปที่ Wes แทนที่จะเห็นท่าทางรำคาญ ผมกลับเห็นเขาดูตกอยู่ในภวังค์ กำลังถูคางพลางมองไปที่แผนภาพนั้น
ผมส่งสัญญาณบอกให้ Brent หรือ Wes คนใดคนหนึ่งเขียนต่อจากที่ William ทิ้งไว้
Brent ลุกขึ้นแล้วเริ่มวาดกล่องเพื่อระบุถึงการแพ็คโค้ด (Packaging) เพื่อเตรียม Deploy การเตรียม Server instance ใหม่ การโหลดและตั้งค่า OS, ฐานข้อมูล และแอปพลิเคชัน การตั้งค่าระบบเครือข่าย ไฟร์วอลล์ (Firewall) และโหลดบาลานเซอร์ (Load Balancer) และสุดท้ายคือการทดสอบเพื่อให้แน่ใจว่าการ Deployment เสร็จสมบูรณ์อย่างถูกต้อง
ผมพิจารณาแผนภาพทั้งหมดนี้ ซึ่งน่าแปลกใจที่มันทำให้ผมนึกถึงผังในโรงงาน แต่ละขั้นตอนเปรียบเสมือนศูนย์ปฏิบัติงาน ซึ่งมีทั้งเครื่องจักร คน วิธีการ และมาตรวัดที่แตกต่างกัน งานไอทีอาจจะ ซับซ้อนยิ่งกว่า งานผลิตเสียอีก งานเหล่านี้ไม่เพียงแต่จะมองไม่เห็นซึ่งทำให้ติดตามได้ยากกว่าเท่านั้น แต่มันยังมีสิ่งที่อาจผิดพลาดได้มากกว่าด้วย
การตั้งค่า (Configuration) นับไม่ถ้วนต้องทำให้ถูกต้อง ระบบต้องมีหน่วยความจำ (Memory) เพียงพอ ไฟล์ทั้งหมดต้องวางอยู่ในตำแหน่งที่ถูกต้อง และโค้ดทั้งหมดรวมถึงสภาพแวดล้อมทั้งระบบต้องทำงานได้ตามปกติ
แม้แต่ความผิดพลาดเล็กๆ น้อยๆ เพียงอย่างเดียวก็สามารถทำให้ระบบพังพินาศได้หมด นี่แสดงว่าเรายิ่งต้องมีความเข้มงวด มีวินัย และมีการวางแผนที่มากกว่างานผลิตเสียอีก
ผมแทบรอไม่ไหวที่จะบอกเรื่องนี้กับ Erik
ผมตระหนักถึงความสำคัญและความท้าทายอันยิ่งใหญ่ที่อยู่ตรงหน้า จึงเดินไปที่ไวท์บอร์ดแล้วหยิบปากกาสีแดงขึ้นมา “ผมจะเขียนดาวสีแดงดวงใหญ่ไว้ในแต่ละขั้นตอนที่เราเคยมีปัญหาในช่วงเปิดตัวครั้งที่ผ่านมาครับ”
ผมเริ่มเขียนเครื่องหมายบนไวท์บอร์ดพร้อมอธิบาย “เพราะ QA environment ที่ใหม่เอี่ยมยังไม่พร้อมใช้งาน เราจึงต้องใช้เวอร์ชันเก่าแทน และเพราะเทสไม่ผ่าน เราจึงต้องไปแก้โค้ดและสภาพแวดล้อมใน QA environment โดยตรง ซึ่งมันไม่เคยถูกย้อนกลับไปแก้ไขใน Dev หรือ Production environment เลย และเพราะเราไม่เคยทำให้ Environment ทั้งหมดทำงานสอดคล้องกัน (Synchronized) เราจึงเจอแต่ปัญหาเดิมๆ ซ้ำแล้วซ้ำเล่าครับ”
ผมทิ้งร่องรอยดาวสีแดงไว้บนกล่องของ Brent ต่อ “เพราะเราไม่มีขั้นตอนการ Deployment ที่ถูกต้อง เราจึงต้องลองผิดลองถูกถึงห้าครั้งกว่าจะทำ Packaging และเขียนสคริปต์ Deployment ได้ถูกต้อง ซึ่งมันระเบิดกลางคันตอนขึ้น Production เพราะ Environment ถูกสร้างมาอย่างผิดพลาดเหมือนที่ผมได้บอกไปแล้ว”
แม้ผมจะไม่ได้จงใจ แต่เมื่อเขียนเสร็จ กล่องของ William และ Brent เกือบทุกใบก็มีดาวสีแดงอยู่ข้างๆ
ผมหันหลังกลับไปและเห็นสีหน้าที่ดูหดหู่ของทุกคนเมื่อเห็นสิ่งที่ผมเพิ่งทำลงไป เมื่อรู้ตัวว่าอาจทำพลาดไป ผมจึงรีบเสริมว่า “ฟังนะครับ เป้าหมายของผมไม่ใช่การโทษใคร หรือบอกว่าพวกเราทำงานได้แย่ ผมแค่พยายามจะบันทึกลงกระดาษว่าจริงๆ แล้วเรากำลังทำอะไรกันอยู่ และพยายามวัดผลแต่ละขั้นตอนอย่างเป็นรูปธรรม ให้เรามาสู้กับปัญหาที่อยู่บนไวท์บอร์ดนี้ในฐานะทีมเดียวกัน โดยไม่โทษกันเอง โอเคไหมครับ?”
Patty พูดขึ้น “คุณรู้อะไรไหมคะ เรื่องนี้ทำให้ฉันนึกถึงอะไรบางอย่างที่เห็นพวกคนในโรงงานใช้กันเป็นประจำ ถ้าคนพวกนั้นเดินเข้ามา ฉันเดาว่าเขาคงคิดว่าเรากำลังทำ ‘Value Stream Map’ อยู่แน่ๆ คุณจะว่าอะไรไหมถ้าฉันขอเสริมอะไรบางอย่างลงไปสักหน่อย?”
ผมส่งปากกาเขียนไวท์บอร์ดให้เธอแล้วนั่งลง
สำหรับกล่องแต่ละใบ เธอถามว่าโดยปกติแล้วการทำงานเหล่านี้ใช้เวลานานแค่ไหน แล้วเขียนตัวเลขกำกับไว้บนยอดกล่อง จากนั้นเธอก็ถามว่าปกติแล้วขั้นตอนไหนที่งานต้องหยุดรอ แล้ววาดรูปสามเหลี่ยมไว้หน้ากล่องนั้น เพื่อระบุว่าเป็น Work in Process
เหลือเชื่อจริงๆ สำหรับ Patty ความคล้ายคลึงระหว่างการ Deployment ของพวกเรากับสายการผลิตในโรงงานไม่ใช่แค่คำถามเชิงทฤษฎี แต่เธอกำลังจัดการกับการ Deployment ของพวกเราราวกับว่ามันเป็นสายการผลิตจริงๆ!
เธอใช้เครื่องมือและเทคนิคของ Lean ที่คนในโรงงานใช้ในการบันทึกและปรับปรุงกระบวนการทำงาน
ทันใดนั้น ผมก็เข้าใจสิ่งที่ Erik หมายถึงตอนที่เขาพูดเรื่อง “Deployment pipeline” แม้ว่าเราจะมองไม่เห็นงานของเราเหมือนในโรงงาน แต่มันก็ยังคงเป็น Value Stream อยู่ดี
ผมแก้คำพูดตัวเองเสียใหม่ มันคือ Value Stream ของพวกเรา และผมมั่นใจว่าเรากำลังจะหาวิธีเพิ่ม Flow ของงานผ่านมันไปได้อย่างมหาศาล
หลังจากที่ Patty บันทึกระยะเวลาของขั้นตอนต่างๆ เสร็จแล้ว เธอก็วาดกล่องใหม่โดยใช้ชื่อสั้นๆ เพื่ออธิบายแต่ละขั้นตอน ในไวท์บอร์ดอีกแผ่นหนึ่ง เธอเขียนหัวข้อไว้สองจุดคือ “Environments” และ “Deployment”
เธอชี้ไปที่สิ่งที่เธอเพิ่งเขียนแล้วพูดว่า “จากกระบวนการปัจจุบัน เรามีสองปัญหาที่โผล่ขึ้นมาตลอดเวลาครับ อย่างแรกคือในทุกขั้นตอนของการ Deployment มักจะไม่ค่อยมี Environment พร้อมใช้งานเมื่อเราต้องการ และต่อให้มีแล้ว เราก็ยังต้องเสียเวลาทำงานซ้ำซ้อน (Rework) อีกมากเพื่อให้มันทำงานสอดคล้องกัน ใช่ไหมคะ?”
Wes พ่นลมหายใจออกมาแรงๆ “ไม่ได้มีรางวัลให้สำหรับการพูดเรื่องที่มัน ชัดเจน ขนาดนั้นหรอกนะ แต่คุณพูดถูก”
เธอพูดต่อ “ส่วนอีกปัญหาหนึ่งของการ Rework และเวลา Setup ที่ยาวนานคือกระบวนการทำ Code packaging ซึ่งฝ่าย IT Operations จะหยิบเอาสิ่งที่ทีม Dev เช็คอิน (Check-in) เข้ามาใน Version control แล้วสร้างเป็น Deployment package ขึ้นมา แม้ว่า Chris และทีมของเขาจะพยายามอย่างเต็มที่ในการบันทึกข้อมูลโค้ดและค่าคอนฟิกต่างๆ แต่ก็ยังคงมีบางอย่างเล็ดลอดหลุดรอดไปจนได้ ซึ่งเราจะมารู้ก็ต่อเมื่อโค้ดรันไม่ได้หลังจากการ Deployment เข้าไปใน Environment แล้ว ถูกไหมคะ?”
ครั้งนี้ Wes ไม่ได้ตอบโต้ทันที แต่ Brent แย่งพูดขึ้นมาก่อน “คุณพูดถูกเผงเลย William ก็น่าจะรู้อยู่แล้วว่าปัญหาคือขั้นตอนการ Release มักจะไม่ค่อยอัปเดต เราเลยต้องมาวิ่งวุ่นพยายามแก้ปัญหากันตลอด ต้องเขียน Installer script ใหม่และติดตั้งมันซ้ำแล้วซ้ำเล่า...”
“ใช่เลยครับ” William พยักหน้ายืนยันอย่างหนักแน่น
“ฉันขอแนะนำให้พวกเราโฟกัสสองเรื่องนี้ก่อนครับ” เธอพูดพร้อมกับมองไปที่กระดานแล้วกลับมานั่งที่เดิม “มีไอเดียอะไรบ้างไหมคะ?”
Brent บอก “บางทีผมกับ William อาจจะทำงานร่วมกันเพื่อทำ Deployment Run Book ขึ้นมา เพื่อบันทึกบทเรียนที่เราได้รับจากความผิดพลาดที่ผ่านมาดีไหมครับ?”
ผมพยักหน้าพลางฟังไอเดียของทุกคน แต่ดูเหมือนว่ามันยังไม่มีไอเดียไหนที่จะช่วยแก้ปัญหาได้อย่างเด็ดขาดตามที่เราต้องการ Erik เคยอธิบายถึงการลดเวลา Setup ในกระบวนการปั๊มประตูรถไว้ ดูเหมือนเขาจงใจบอกว่ามันสำคัญ แต่เพราะอะไรล่ะ?
“การที่แต่ละทีมต้องมานั่งสร้าง Environment เองมันไม่ได้ผลจริงๆ ครับ อะไรก็ตามที่เราทำมันต้องพาเราเข้าใกล้เป้าหมาย ‘สิบ Deploy ต่อวัน’ ได้ก้าวใหญ่ๆ” ผมพูด “ซึ่งมันหมายความว่าเราต้องการระบบอัตโนมัติ (Automation) อย่างมาก Brent ครับ จะต้องทำยังไงถึงจะสร้างกระบวนการสร้าง Environment ส่วนกลางขึ้นมาได้ เพื่อให้เราสามารถสร้าง Dev, QA และ Production environment พร้อมๆ กัน และรักษาความสอดคล้องกันไว้ได้ตลอดเวลา?”
“ไอเดียน่าสนใจครับ” Brent บอกพลางมองที่กระดาน เขาลุกขึ้นแล้ววาดกล่องสามใบชื่อ “Dev”, “QA” และ “Production” จากนั้นใต้กล่องพวกนั้นเขาก็วาดอีกใบชื่อ “Build Procedure” พร้อมลากลูกศรชี้ไปที่กล่องทั้งสามด้านบน
“จริงๆ แล้วมันยอดเยี่ยมมากเลยครับ Bill” เขาบอก “ถ้าเรามี Build procedure ส่วนกลาง และทุกคนใช้เครื่องมือพวกนี้ในการสร้าง Environment ฝั่ง Developer ก็จะได้เขียนโค้ดใน Environment ที่อย่างน้อยก็ใกล้เคียงกับ Production environment แค่นั้นอย่างเดียวมันก็เป็นการปรับปรุงที่ยิ่งใหญ่มากแล้วครับ”
เขาเอาฝาปากกาออกจากปาก “ในการสร้าง Phoenix environment เราใช้สคริปต์ที่เราเขียนไว้จำนวนมากครับ ถ้าทำคู่มือนิดหน่อยและเก็บกวาดให้เรียบร้อย ผมพนันได้เลยว่าภายในสองวันเราน่าจะทำอะไรที่มันใช้ได้ออกมาได้ครับ”
ผมหันไปทาง Chris แล้วพูดว่า “ดูท่าทางจะมีอนาคตนะครับ ถ้าเราสามารถทำให้ Environment เป็นมาตรฐานเดียวกัน และถูกใช้งานทุกวันโดยทีม Dev, QA และไอที เราก็จะสามารถกำจัดความแตกต่าง (Variance) ส่วนใหญ่ที่สร้างปัญหาให้กระบวนการ Deployment ได้ครับ”
Chris ดูตื่นเต้นมาก “Brent ครับ ถ้าคุณและคนอื่นๆ ไม่ขัดข้อง ผมขอเชิญคุณเข้าร่วมทีม Sprint ของพวกเรา เพื่อที่เราจะได้เริ่มนำการสร้าง Environment เข้ามาบูรณาการในกระบวนการพัฒนาโค้ดให้เร็วที่สุดครับ ตอนนี้พวกเราส่วนใหญ่เน้นไปที่การมีโค้ดที่พร้อมจะ Deploy ตอนจบโปรเจกต์ ผมขอเสนอให้เปลี่ยนความต้องการใหม่ครับ ในทุกรอบ Sprint สามสัปดาห์ เราต้องไม่เพียงแค่มีโค้ดที่พร้อม Deploy เท่านั้น แต่ต้องมี Environment ที่โค้ดนั้นจะ Deploy ลงไปที่ตรงกันเป๊ะ และต้องเช็คอินเข้า Version control ไว้ด้วยครับ”
Brent ยิ้มกว้างกับข้อเสนอนั้น ก่อนที่ Wes จะทันได้โต้ตอบ ผมก็พูดขึ้นก่อนว่า “ผมเห็นด้วยอย่างยิ่งครับ แต่ก่อนที่เราจะไปไกลกว่านี้ เรามาลองตรวจสอบอีกประเด็นที่ Patty ได้เน้นไว้ดีไหมครับ? แม้ว่าเราจะทำตามข้อเสนอของ Chris แล้ว แต่เรายังคงมีปัญหาเรื่องสคริปต์การ Deployment อยู่ ถ้าเรามีคทาวิเศษล่ะก็ เมื่อเราได้ QA environment ที่สร้างใหม่เสร็จแล้ว เราควรจะ Deploy โค้ดลงไปอย่างไรดีครับ? เพราะทุกครั้งที่เราทำ เราต้องคอยส่งต่อโค้ด สคริปต์ และอะไรต่อมิอะไรวุ่นวายกันไปหมดระหว่างทีมครับ”
Patty เสริมขึ้น “ในโรงงานนะคะ เมื่อไหร่ก็ตามที่เราเห็นงานต้องส่งย้อนกลับไปจุดเดิม นั่นคือการทำงานซ้ำซ้อน (Rework) และเมื่อเรื่องนั้นเกิดขึ้น พนันได้เลยว่าการทำคู่มือและ Flow ของข้อมูลกำลังแย่มากครับ ซึ่งหมายความว่ามันจะไม่สามารถทำซ้ำได้ และมันจะยิ่งแย่ลงไปอีกเมื่อเราพยายามเร่งความเร็วครับ ในโรงงานเขาเรียกสิ่งนี้ว่ากิจกรรม ‘Non-value-add’ หรือว่า ‘ของเสีย’ (Waste) ค่ะ”
เธอมองที่ไวท์บอร์ดแผ่นแรกที่เต็มไปด้วยกล่องแล้วพูดว่า “ถ้าเราจะออกแบบกระบวนการใหม่ เราต้องดึงเอาคนที่เกี่ยวข้องมาทำงานด้วยกันตั้งแต่ต้นครับ เหมือนกับการที่กลุ่มวิศวกรโรงงานต้องทำให้แน่ใจว่าชิ้นส่วนทั้งหมดได้รับการออกแบบมาเพื่อการผลิตที่เหมาะสมที่สุด และสายการผลิตก็ถูกออกแบบมาเพื่อชิ้นส่วนเหล่านั้นครับ ซึ่งถ้าทำได้แบบ Single-piece flow ก็จะดีที่สุดเลยค่ะ”
ผมพยักหน้าพลางยิ้มให้กับความคล้ายคลึงกันระหว่างสิ่งที่ Patty แนะนำกับสิ่งที่ Erik เพิ่งเสนอผมมาเมื่อตอนเช้านี้
ผมหันไปทาง William และ Brent แล้วพูดว่า “โอเคครับพวกคุณ ตอนนี้คุณมีคทาวิเศษแล้ว คุณอยู่หัวแถวของสายพานเลยนะ บอกผมหน่อยสิว่าคุณจะออกแบบสายการผลิตยังไงไม่ให้งานต้องส่งกลับหลังไปมา และทำให้ Flow มันเดินหน้าไปได้อย่างรวดเร็วและมีประสิทธิภาพที่สุดครับ?”
เมื่อทั้งคู่ทำหน้างง ผมเลยพูดต่ออย่างมีอารมณ์ขันเล็กน้อย “คุณมี คทาวิเศษ อยู่ในมือนะ ใช้มันสิ!”
“คทาวิเศษนี่มันทำอะไรได้แค่ไหนครับ?” William ถาม
ผมทวนคำพูดเดิมที่เคยบอก Maggie “มันเป็นคทาวิเศษที่ ทรงพลัง มาก มันทำได้ทุกอย่างเลยครับ”
William เดินไปที่ไวท์บอร์ดแล้วชี้ไปที่กล่องชื่อ “Code commit” “ถ้าผมเสกคทาวิเศษได้ ผมจะเปลี่ยนขั้นตอนนี้ครับ แทนที่จะรับ Source code หรือ Compiled code จากทีม Dev ผ่าน Source control ผมอยากได้ Packaged code ที่พร้อมจะ Deploy ได้ทันทีเลยครับ”
“แล้วรู้อะไรไหมครับ” เขาพูดต่อ “ผมอยากได้แบบนี้มากเสียจนผมยินดีที่จะอาสากลับไปเป็นคนรับผิดชอบเรื่องการสร้าง Package เองเลยครับ ผมรู้ด้วยว่าจะมอบหมายให้ใครทำดี เธอจะเป็นคนรับผิดชอบการรับมอบงานจากฝั่ง Dev โดยตรง เมื่อโค้ดถูกระบุว่า ‘พร้อมทดสอบ’ เราก็จะเริ่มสร้างและ Commit ตัว Packaged code นั้นทันที ซึ่งมันจะไปกระตุ้นให้เกิดการ Deployment แบบอัตโนมัติลงใน QA environment และในอนาคตอาจจะรวมถึง Production environment ด้วยครับ”
“ว้าว คุณจะทำแบบนั้นจริงๆ เหรอครับ?” Wes ถาม “มันคงจะดีมากๆ เลย งั้นเราเริ่มกันเถอะ ยกเว้นว่า Brent ยังอยากจะเป็นคนทำ Packaging เองอยู่นะครับ?”
“ล้อเล่นหรือเปล่าครับ?” Brent ถามพลางระเบิดหัวเราะออกมา “ผมจะเลี้ยงเครื่องดื่มคนนั้นทั้งปีเลยล่ะ! ผมชอบไอเดียนี้มาก และผมก็อยากช่วยสร้างเครื่องมือสำหรับ Deployment อันใหม่ด้วย เหมือนที่บอกไปครับ ผมมีเครื่องมือที่เคยเขียนเก็บไว้เพียบเลย ซึ่งเราสามารถนำมาใช้เป็นจุดเริ่มต้นได้ครับ”
ผมสัมผัสได้ถึงพลังและความตื่นเต้นที่อบอวลอยู่ในห้อง ผมรู้สึกทึ่งมากที่เราเปลี่ยนจากความคิดที่ว่าเป้าหมาย ‘สิบ Deploy ต่อวัน’ เป็นแค่เรื่องเพ้อฝัน มาสู่การพยายามทำให้ได้ใกล้เคียงที่สุดในเวลาอันรวดเร็ว
ทันใดนั้น Patty ก็เงยหน้าขึ้นและพูดว่า “เดี๋ยวนะคะ โมดูลทั้งหมดของ Phoenix นี่เกี่ยวข้องกับข้อมูลการซื้อขายของลูกค้า ซึ่งต้องได้รับการคุ้มครองอย่างดี เราควรจะดึงคนจากทีมของ John เข้ามาร่วมด้วยในโปรเจกต์นี้ไหมคะ?”
พวกเราทุกคนมองหน้ากัน ต่างเห็นพ้องกันว่าเขาควรจะเข้ามามีส่วนร่วม และอีกครั้งที่ผมรู้สึกมหัศจรรย์ใจที่องค์กรของเราเปลี่ยนแปลงไปได้ขนาดนี้