เจ้าของเสียงที่คุ้นเคยนั้น ทำให้ Maxine ต้องประหลาดใจ เพราะเขาคือบาร์เทนเดอร์ที่เธอเจอครั้งล่าสุดที่ Dockside
เขาวางถาดเครื่องดื่มลงข้างๆ Maxine และตบหลัง Kurt อย่างเป็นกันเอง จากนั้นเขาก็หันไปหา Kirsten แล้วพูดว่า “โอ้โฮ—นี่ไม่ใช่คุณ Fingle หรอกเหรอ! ไม่ได้เจอกันนานเลยนะ! ยินดีต้อนรับสู่ Dockside กองบัญชาการของกลุ่มกบฏที่กำลังผลิบานครับ”
“พระเจ้าช่วย” Kirsten อุทานพลางจ้องมองเขา
“เอิ่ม... พวกคุณรู้จักกันด้วยเหรอครับ?” Kurt ถามด้วยน้ำเสียงที่ขาดความมั่นใจตามปกติของเขา
Kirsten หัวเราะ “นี่คือ ดร. Erik Reid ค่ะ คุณอาจจะไม่รู้ แต่ Steve และ Dick พยายามจ้างเขามาเป็นกรรมการบริษัท Parts Unlimited มาหลายเดือนแล้ว เขาทำงานกับบริษัทมาหลายทศวรรษ อันที่จริง Erik เป็นส่วนหนึ่งของการเริ่มใช้งานระบบ MRP ในยุค 80 และจากนั้นเขาก็ช่วยให้โรงงานผลิตนำหลักการและแนวทางปฏิบัติแบบ Lean มาใช้ เขาเป็นฮีโร่ตัวจริงในหมู่พนักงานโรงงานเลยล่ะค่ะ”
“เขาเนี่ยนะ?” Kurt พูดด้วยความไม่อยากจะเชื่อ พลางบุ้ยปากไปทางบาร์เทนเดอร์
Maxine ก็ประหลาดใจเช่นกัน เพราะเธอเป็นคนรับช่วงต่อในการพัฒนาและดูแลระบบ MRP ที่บริษัทสร้างขึ้นเองมาหลายปีแล้ว เธอประทับใจเสมอว่ามันไม่ได้แค่กำหนดวิธีการทำงานที่ยอดเยี่ยมซึ่งนำไปสู่สภาวะไหลลื่น (flow) ที่น่าทึ่งเท่านั้น แต่ยังช่วยให้เกิดการเรียนรู้อย่างต่อเนื่อง ทั้งสำหรับพนักงานหน้างานและผู้จัดการโรงงาน
“อย่าไปเชื่อทุกอย่างที่คุณได้ยินเลยครับ” Erik กล่าวพลางพ่นลมหายใจ
Maxine รีบประเมินเขาอย่างรวดเร็ว ดูเหมือนเขาจะอยู่ในวัยห้าสิบกลางๆ ถึงปลายๆ ซึ่งเป็นวัยที่เหมาะสมที่จะเป็นผู้ให้กำเนิดระบบ MRP เขามีรูปร่างใหญ่โตเหมือนคนที่เคยฟิตมาก่อน มีผมสีดอกเลายาวประบ่า ทำให้เธอนึกถึงตัวละคร The Dude จากเรื่อง The Big Lebowski แต่แทนที่จะดูเรื่อยเปื่อย Erik กลับดูเฉียบแหลมและช่างสังเกตอย่างเห็นได้ชัด
เขาหันมาหา Maxine พร้อมรอยยิ้มเจ้าเล่ห์ “ในนามของทุกคนในฝ่ายปฏิบัติการโรงงาน ขอบคุณที่ดูแลระบบ MRP เป็นอย่างดีนะครับ คุณช่วยสร้างและรักษาซอฟต์แวร์ที่เป็นผลงานชิ้นเอกของความเรียบง่าย (simplicity) และการรวมกลุ่มของหน้าที่ (locality) คุณไม่เพียงแต่บรรลุวัตถุประสงค์ทางธุรกิจได้อย่างยอดเยี่ยม แต่คุณยังสร้างระบบที่วิศวกรทีมเล็กๆ สามารถทำงานได้อย่างมีประสิทธิภาพและเป็นอิสระต่อกัน โดยมีส่วนประกอบที่ถูกแยกออกจากกันอย่างประณีตและสวยงาม แทนที่จะพันกันยุ่งเหยิง (complected) จนกลายเป็นความโกลาหลที่น่าเกลียด”
“นี่คือผลงานทางวิศวกรรมและสถาปัตยกรรมที่ยอดเยี่ยมจริงๆ!” เขากล่าวด้วยใบหน้ายิ้มแย้ม “ประสิทธิภาพของนักพัฒนาที่คุณสร้างขึ้นเป็นข้อพิสูจน์ที่สวยงามถึงความเรียบง่ายที่สง่างาม และสิ่งที่น่าประทับใจยิ่งกว่าคือการที่คุณกำจัดหนี้ทางเทคนิค (technical debt) อย่างไม่ลดละโดยถือเป็นส่วนหนึ่งของงานประจำวัน ผมดีใจที่ได้พบคุณเสียที!”
Maxine จ้องมอง Erik เธอคิดว่ามันไม่ใช่เรื่องปกติที่บาร์เทนเดอร์จะมาชมเชยเรื่องโค้ดที่คุณตั้งใจเขียนและดูแลมาหลายปีแบบนี้
“ขอบคุณค่ะ—ฉันจะนำไปบอกทีมงานให้ทราบนะคะ” เธอตอบด้วยความงุนงง แต่ก็ซ่อนความภูมิใจไว้ไม่มิด
“เอิ่ม คำว่า ‘complected’ แปลว่าอะไรเหรอครับ?” Kurt ถามขึ้น
Erik ตอบว่า “มันเป็นคำโบราณที่ Sensei Rich Hickey นำกลับมาใช้ใหม่ครับ ‘Complect’ หมายถึงการทำให้สิ่งที่เรียบง่ายกลายเป็นสิ่งที่ซับซ้อน”
“ในระบบที่มีการผูกมัดกันอย่างแน่นหนา (tightly coupled) และซับซ้อนยุ่งเหยิง (complected) มันแทบจะเป็นไปไม่ได้เลยที่จะเปลี่ยนแปลงอะไร เพราะคุณไม่สามารถเปลี่ยนโค้ดแค่จุดเดียวได้ คุณต้องเปลี่ยนโค้ดเป็นร้อยหรือเป็นพันจุด และแม้แต่การเปลี่ยนแปลงที่เล็กที่สุดก็สามารถส่งผลที่คาดเดาไม่ได้อย่างรุนแรงในส่วนที่ห่างไกลของระบบ ซึ่งบางครั้งคุณอาจจะไม่เคยได้ยินชื่อส่วนนั้นเลยด้วยซ้ำ”
“Sensei Hickey มักจะพูดว่า ‘ลองนึกถึงเส้นไหมพรมสี่เส้นที่แขวนอยู่อย่างอิสระ—นั่นคือระบบที่เรียบง่าย คราวนี้ลองเอาไหมพรมสี่เส้นเดิมมาถักเปียรวมกันดู ตอนนี้คุณได้ complected พวกมันเข้าด้วยกันแล้ว’ การจัดเรียงไหมพรมทั้งสองแบบสามารถบรรลุเป้าหมายทางวิศวกรรมเดียวกันได้ แต่อันหนึ่งจะเปลี่ยนได้ง่ายกว่าอีกอันอย่างมหาศาล ในระบบที่เรียบง่าย คุณสามารถเปลี่ยนไหมพรมเส้นหนึ่งได้อย่างอิสระโดยไม่ต้องไปยุ่งกับเส้นอื่น ซึ่งนั่นเป็นเรื่องดีมากครับ”
Erik หัวเราะ “อย่างไรก็ตาม ในระบบที่ complected เมื่อคุณต้องการเปลี่ยนแปลงไหมพรมเพียงเส้นเดียว คุณจะถูกบีบให้ต้องเปลี่ยนไหมพรมอีกสามเส้นที่เหลือด้วย ในความเป็นจริง สำหรับหลายๆ สิ่งที่คุณอยากจะทำ คุณกลับทำไม่ได้เลย เพราะทุกอย่างมันพันกันเป็นปมไปหมดแล้ว”
“และเมื่อเรื่องนั้นเกิดขึ้น”เขากล่าวต่อ “คุณได้ขังตัวเองไว้ในระบบการทำงานที่คุณไม่สามารถแก้ปัญหาทางธุรกิจจริงๆ ได้ง่ายๆ อีกต่อไป—แต่คุณกลับถูกบีบให้ต้องมานั่งแก้ปริศนาทั้งวัน พยายามหาทางว่าจะทำการเปลี่ยนแปลงเล็กๆ ของคุณได้อย่างไร โดยมีระบบที่ complected คอยขัดขวางคุณอยู่ทุกย่างก้าว คุณต้องนัดประชุมกับทีมอื่น พยายามหว่านล้อมให้เขาเปลี่ยนบางอย่างให้คุณ ต้องแจ้งเรื่องไปที่ผู้จัดการของพวกเขา หรืออาจจะยาวไปจนถึงระดับบนสุดขององค์กร”
“ทุกอย่างที่คุณทำจะยิ่งออกห่างจากปัญหาทางธุรกิจจริงๆ ที่คุณกำลังพยายามแก้ไขมากขึ้นเรื่อยๆ” เขากล่าว “และนั่นแหละครับ Dwayne คือสิ่งที่ทุกคนได้ค้นพบเมื่อพวกเขาเปลี่ยนเร้าเตอร์ (routers) ในโรงงานผลิตเหล่านั้น เมื่อก่อนคุณมีไหมพรมสามเส้นที่เป็นอิสระต่อกัน ทีมงานสามารถทำงานแยกกันได้ แต่ต้องแลกมาด้วยการดูแลรักษาสวิตช์เน็ตเวิร์กสามตัว”
“เมื่อคุณเอาพวกเขาทั้งหมดไปไว้บนสวิตช์ตัวเดียว คุณได้ทำให้สายธารแห่งคุณค่า (value streams) ของพวกเขา complected กัน ตอนนี้พวกเขาทั้งหมดมีสิ่งที่ต้องพึ่งพากันและกันซึ่งไม่เคยมีมาก่อน พวกเขาต้องสื่อสาร ประสานงาน วางแผน จัดการ ลำดับขั้นตอน และขจัดความขัดแย้งของงานอยู่ตลอดเวลา ตอนนี้พวกเขามีต้นทุนในการประสานงาน (cost of coordination) ที่สูงมาก ซึ่งส่งผลให้ระยะเวลานำ (lead times) ยาวนานขึ้น คุณภาพลดลง และในเรื่องเล่าของคุณ ก็นำไปสู่หายนะที่กินเวลานานเป็นสัปดาห์ซึ่งส่งผลเสียอย่างรุนแรงต่อธุรกิจ และเรื่องก็บานปลายไปถึง Steve” Erik กล่าวด้วยความสะใจ
“ความสำคัญของระยะเวลานำ (lead times) ในการส่งมอบซอฟต์แวร์นั้นเป็นสิ่งที่สำคัญที่สุด ดังที่ Dr. Nicole Forsgren และ Jez Humble ได้ค้นพบในงานวิจัยของพวกเขา” Erik กล่าว “ระยะเวลานำในการ deploy โค้ด, ความถี่ในการ deploy และเวลาที่ใช้ในการแก้ปัญหา ทั้งหมดนี้เป็นตัวบ่งบอกถึงประสิทธิภาพในการส่งมอบซอฟต์แวร์ ประสิทธิภาพในการดำเนินงาน และประสิทธิภาพขององค์กร และพวกมันยังสัมพันธ์กับอาการหมดไฟ (burnout) ความผูกพันของพนักงาน และสิ่งอื่นๆ อีกมากมาย”
“ความเรียบง่าย (Simplicity) นั้นสำคัญเพราะมันช่วยให้เกิดการรวมกลุ่มของหน้าที่ (locality) Locality ในโค้ดคือสิ่งที่ช่วยให้ระบบมีการผูกมัดกันอย่างหลวมๆ (loosely coupled) ทำให้เราส่งมอบฟีเจอร์ได้เร็วขึ้น ทีมงานสามารถพัฒนา ทดสอบ และส่งมอบคุณค่าให้กับลูกค้าได้อย่างรวดเร็วและเป็นอิสระ ส่วน locality ในองค์กรช่วยให้ทีมสามารถตัดสินใจได้เองโดยไม่ต้องสื่อสารและประสานงานกับคนนอกทีม ซึ่งอาจต้องรอการอนุมัติจากผู้มีอำนาจที่อยู่ห่างไกลหรือคณะกรรมการที่แยกขาดจากหน้างานจริงจนไม่มีข้อมูลเพียงพอที่จะตัดสินใจได้ดี” เขากล่าวพร้อมกับทำสีหน้าขยะแขยง
“คุณควรจะสร้างคุณค่าได้โดยการเปลี่ยนไฟล์เพียงไฟล์เดียว, โมดูลเดียว, บริการเดียว, ส่วนประกอบเดียว, การเรียกใช้ API ครั้งเดียว, คอนเทนเนอร์เดียว, แอปเดียว หรืออะไรก็ตาม! นั่นคือเหตุผลว่าทำไมการเอาเรื่องที่เกี่ยวข้องกับหลายส่วน (cross-cutting concerns) มาไว้ในที่เดียวถึงยอดเยี่ยมมาก เช่น ระบบล็อก (logging), ความปลอดภัย หรือนโยบายการลองใหม่ (retry policies) คุณเปลี่ยนมันที่นั่น แล้วมันก็เปลี่ยนให้ทุกที่เลย” เขากล่าว “มันไม่ไร้สาระไปหน่อยเหรอที่เวลาจะสร้างฟีเจอร์หนึ่งอย่าง บางครั้งทีม UI, ทีม front-end, ทีม back-end และทีม database ต้องเข้ามาแก้ไขกันหมด?”
“น่าสนใจค่ะ” Maxine กล่าว “Locality ในโค้ดและในองค์กรของเราคือสิ่งที่เป็นที่ปรารถนาอย่างมาก เมื่อเทียบกับสิ่งที่เรามีอยู่ตอนนี้ ซึ่งก็คือโค้ดที่กระจัดกระจายอยู่ทุกที่!”
“ใช่ ถูกต้องเลย กระจัดกระจาย!” Erik กล่าว “และการจะบรรลุความยิ่งใหญ่นี้ไม่ได้มาฟรีๆ มันต้องอาศัยการจดจ่อและการยกย่องการปรับปรุงงานประจำวัน ให้สำคัญยิ่งกว่าตัวงานประจำวันเองเสียอีก หากปราศจากการจดจ่ออย่างไม่ลดละนี้ ทุกระบบที่เรียบง่ายจะเสื่อมถอยลงตามกาลเวลา และถูกฝังกลบอยู่ใต้หนี้ทางเทคนิค (technical debt) ที่ทับถมกันหนาเตอะ ลองดูหายนะของระบบ build ของ Phoenix เป็นตัวอย่างสิครับ”
Maxine ขมวดคิ้ว “คุณกำลังจะบอกว่า Phoenix เคยเรียบง่าย แต่ตอนนี้มันกลับ complected จนจำไม่ได้แล้ว คุณกำลังบอกว่า Phoenix เคยมีกระบวนการ build ที่ยอดเยี่ยม แต่ตลอดหลายปีที่ผ่านมามันกลับถูกละเลย ถูกลดความสำคัญลงไปอยู่เบาะหลัง และในที่สุดก็ถูกถีบตกจากรถไปเลยงั้นเหรอคะ”
“เป๊ะเลยครับ” Erik กล่าว “ความรับผิดชอบเรื่อง build ย้ายจากทีม Dev ไปทีม QA แล้วก็ไปสู่เด็กฝึกงาน ยักษ์ใหญ่ด้านเทคโนโลยีอย่าง Facebook, Amazon, Netflix, Google และ Microsoft มอบหน้าที่รับผิดชอบด้านประสิทธิภาพของนักพัฒนา (Dev productivity) ให้กับวิศวกรที่อาวุโสและมีประสบการณ์สูงสุดเท่านั้น แต่ที่ Parts Unlimited แห่งนี้ กลับทำตรงกันข้ามโดยสิ้นเชิง”
Dwayne หัวเราะ “อย่างน้อยตอนนี้งาน build ของเราก็ไม่ได้เอาท์ซอร์สแล้วนะ เมื่อไม่นานมานี้ การรัน build แต่ละครั้งต้องเสียเงินตั้ง 85 ดอลลาร์แน่ะ” ทุกคนรวมถึง Maxine ต่างพากันหัวเราะออกมาอย่างไม่อยากจะเชื่อ
Kirsten พูดขึ้นว่า “ฉันได้ยินวิศวกรบ่นเรื่องหนี้ทางเทคนิค (technical debt) อยู่ตลอดเวลา แต่มันคืออะไรกันแน่คะ นอกจากจะเป็นสิ่งที่ไม่ดี?”
Erik หัวเราะ “มีนิยามอยู่มากมายครับ แต่นิยามที่ผมชอบที่สุดคือสิ่งที่ Ward Cunningham กำหนดไว้ในปี 2003 เขาบอกว่า ‘หนี้ทางเทคนิคคือสิ่งที่คุณรู้สึกในครั้งถัดไปที่คุณต้องการทำการเปลี่ยนแปลง’ มีหลายสิ่งที่ผู้คนเรียกว่าหนี้ทางเทคนิค แต่มันมักจะหมายถึงสิ่งที่เราต้องปัดกวาดเช็ดถู หรือจุดที่เราต้องสร้างหรือกู้คืนความเรียบง่ายกลับมา เพื่อให้เราสามารถทำการเปลี่ยนแปลงระบบได้อย่างรวดเร็ว มั่นใจ และปลอดภัย”
“บางครั้งมันคือระบบ build และระบบทดสอบที่ไม่ให้ผลตอบรับที่รวดเร็วแก่นักพัฒนา หรือตอนที่มันหยุดทำงานไปเลย” เขากล่าวต่อ “บางครั้งมันคือตอนที่ส่วนประกอบที่เรียบง่ายกลายเป็นสิ่งที่ complected และคุณไม่สามารถใช้เหตุผลกับมันหรือเปลี่ยนแปลงมันได้อีกต่อไปโดยไม่ใช้ความพยายามมหาศาลหรือเสี่ยงต่อความหายนะ บางครั้งมันคือตอนที่กระบวนการตัดสินใจหรือโครงสร้างองค์กรสูญเสีย locality ไป บีบให้แม้แต่การตัดสินใจเล็กๆ ต้องถูกส่งขึ้นไปตามลำดับชั้น—เจ้า ‘สี่เหลี่ยมมรณะ’ (the Square) ที่น่าอับอายของคุณนั่นแหละ”
“ผมเริ่มเรียกสิ่งเหล่านี้ว่า ‘หนี้ความซับซ้อน’ (complexity debt) เพราะมันไม่ใช่แค่ปัญหาทางเทคนิค—มันคือปัญหาทางธุรกิจ และมันคือทางเลือกเสมอครับ” เขากล่าว “คุณสามารถเลือกที่จะสร้างฟีเจอร์ใหม่ หรือคุณจะเลือกจ่ายคืนหนี้ความซับซ้อนก็ได้ เมื่อคนโง่ใช้เวลาทั้งหมดไปกับฟีเจอร์ ผลลัพธ์ที่หลีกเลี่ยงไม่ได้คือแม้แต่งานง่ายๆ ก็จะกลายเป็นเรื่องยากและใช้เวลาดำเนินการนานขึ้น และไม่ว่าคุณจะพยายามแค่ไหนหรือมีคนมากเท่าไหร่ ในที่สุดมันก็จะพังครืนลงมาเพราะน้ำหนักของมันเอง บีบให้คุณต้องเริ่มต้นใหม่ทั้งหมดตั้งแต่ศูนย์”
เขามองไปที่ Maxine แล้วกล่าวว่า “นั่นคือเหตุผลที่สิ่งที่คุณทำกับระบบ MRP นั้นยอดเยี่ยมมาก ทีมของคุณสามารถเพิ่มฟีเจอร์ได้ในอัตราที่ทีม Phoenix ทั้งหมดควรจะอิจฉา และนั่นเป็นไปได้เพียงเพราะคุณจ่ายคืนหนี้ทางเทคนิคโดยถือเป็นส่วนหนึ่งของงานประจำวัน มันเป็นตัวอย่างที่งดงามของอุดมคติข้อแรก (the First Ideal) เรื่อง Locality และ Simplicity ในโค้ดและองค์กรของเรา ทำได้ดีมากครับ Maxine”
Erik ลุกขึ้นยืน “คืนนี้ผมมีพนักงานไม่พอเท่าไหร่ เดี๋ยวเราค่อยคุยกันใหม่นะครับ และยินดีที่ได้พบคุณนะ Kirsten!”
“โอ้ อีกเรื่องหนึ่งครับ” เขาพูดพลางหันกลับมา “ลองคิดถึงคะแนนความผูกพัน (engagement scores) ของพนักงานไอทีเทียบกับส่วนอื่นๆ ของธุรกิจดูนะครับ แล้วลองพิจารณาความแตกต่างดู โดยเฉพาะในโปรเจกต์ Phoenix”
ขณะที่ Maxine เฝ้าดู Erik เดินกลับไปที่บาร์ เธอได้ยินทุกคนเริ่มระเบิดวงสนทนากันอย่างเมามัน
Maxine พูดว่า “ฉันไม่รู้เลยว่าเมื่อกี้เกิดอะไรขึ้น” เธอมองไปที่ Kirsten และ Kurt แล้วถามว่า “เรื่องทั้งหมดนี้คืออะไรคะ? แล้วเขาหมายความว่ายังไงเรื่องอุดมคติข้อแรก?”
“ผมก็ไม่รู้เหมือนกันครับ” Kurt พูดพลางส่ายหัว “ผมรู้จัก Erik มาปีกว่า ไม่รู้เลยสักนิดว่าเขามีความเกี่ยวข้องอะไรกับบริษัท...”
Dwayne พูดกับ Kurt “ฉันไม่เคยบอกนายเพราะมันดูเหมือนไม่สำคัญเท่าไหร่ แต่เย็นวันหนึ่งเขาเคยถามฉันว่ารู้อะไรเกี่ยวกับการตั้งค่า Kubernetes clusters บ้างไหม ซึ่งตอนนั้นฉันว่ามันแปลกๆ ดี”
“แปลกจริง” Shannon กล่าว “พอมานึกดูแล้ว ครั้งหนึ่งฉันเคยถกเถียงกับเขาเรื่องที่ว่าควรจะแยกสภาพแวดล้อมข้อมูลผู้ถือบัตร (cardholder data environment) ออกไปให้ขาดแค่ไหนเพื่อให้เป็นไปตามมาตรฐานความปลอดภัยข้อมูล PCI เขาถึงขั้นส่งลิงก์หัวข้อย่อยเฉพาะในมาตรฐานนั้นมาให้ฉันเลยนะ เขาดูมีความรู้มาก เหมือนเป็นผู้เชี่ยวชาญเลยล่ะ ตอนนั้นฉันนึกว่าแค่เพราะบาร์นี้รับชำระผ่านบัตรเครดิตเฉยๆ...”
“ฉันได้ยินมาว่าเขาคุยกับ Bill Palmer รองประธานฝ่าย IT Operations คนใหม่บ่อยมากค่ะ” Kirsten เสริม “Bill เล่าให้ฉันฟังว่า Erik กำลังสอนเขาเรื่องอะไรบางอย่างที่เรียกว่า ‘The Three Ways’ (แนวทางทั้งสาม) และ ‘The Four Types of Work’ (งานสี่ประเภท)”
“ฉันไม่เคยได้ยินชื่อพวกนั้นเลยค่ะ” Maxine กล่าว “เขาพูดถึงแค่ ‘อุดมคติข้อแรก’ (the First Ideal)... ฉันสงสัยจังว่าจะมีอุดมคติอีกกี่ข้อกันนะ?”
“แล้วเขาหมายความว่ายังไงเรื่องคะแนนความผูกพันครับ?” Kurt ถาม
“ฉันไม่แน่ใจค่ะ” Kirsten ตอบ “แต่ฉันรู้ว่าบริษัทเรามีคะแนนความพึงพอใจของพนักงานสูงเป็นอันดับต้นๆ ในอุตสาหกรรม... ยกเว้นแผนกไอที... ซึ่งฉันจำได้ว่าคะแนนคือติดลบยี่สิบเจ็ด”
“มันแย่มากไหมครับ?” Dwayne ถาม
Kirsten มีสีหน้าอับอาย “แย่มากค่ะ”
Maxine ไม่แปลกใจเลย แต่ถึงอย่างนั้น มีบางอย่างกวนใจเธอ ในงาน Town Hall Steve พูดถึงความห่วงใยในความผูกพันของพนักงานมากแค่ไหน เขาจะคิดอย่างไรเมื่อเห็นว่าแผนกที่รับผิดชอบโครงการเชิงกลยุทธ์ที่สุดในบริษัทกลับเต็มไปด้วยความทุกข์ระทม? เรื่องนี้ไม่ทำให้เขากังวลบ้างเหรอ?
เมื่อ Erik เดินผ่านมาพร้อมกับแก้วเบียร์เต็มแก้ว Maxine ก็ลุกขึ้นและรีบตามเขาไป “ขอบคุณอีกครั้งสำหรับคำชมนะคะ Erik คุณพูดถึงอุดมคติข้อแรก—มันมีทั้งหมดกี่ข้อ แล้วมีอะไรบ้างคะ?”
“ฮ่า! มันไม่ได้ทำงานแบบนั้นครับ” Erik กล่าวพลางหัวเราะ “ความจริงคือ ผมกำลังให้ Bill Palmer วิ่งวุ่นไปทั่วเพื่อตามหางานทั้งสี่ประเภท (the Four Types of Work) อยู่ คอยดูสิ แต่... บางทีผมอาจจะให้พวกคุณเริ่มก่อนนิดหน่อยก็ได้”
Erik และ Maxine เดินกลับไปที่โต๊ะ “อุดมคติมีอยู่ห้าข้อครับ (Five Ideals)” Erik เริ่มต้น คนทั้งโต๊ะหันมาสนใจเขา “ผมบอกคุณไปแล้วเรื่องอุดมคติข้อแรก: Locality และ Simplicity เราต้องออกแบบสิ่งต่างๆ เพื่อให้เรามี locality ในระบบและในองค์กรที่สร้างมันขึ้นมา และเราต้องการความเรียบง่าย (simplicity) ในทุกสิ่งที่เราทำ ที่สุดท้ายที่เราต้องการความซับซ้อนคือภายใน ไม่ว่าจะเป็นในโค้ด ในองค์กร หรือในกระบวนการของเรา โลกภายนอกมันซับซ้อนพออยู่แล้ว ดังนั้นมันจะเป็นเรื่องที่ยอมรับไม่ได้เลยถ้าเราอนุญาตให้มันเกิดขึ้นในสิ่งที่เราควบคุมได้! เราต้องทำให้งานของเราทำได้ง่ายครับ”
Maxine นั่งลง เปิดแล็ปท็อป (ดีใจที่คราวนี้เธอจำได้) และเริ่มจดบันทึก
“อุดมคติข้อที่สองคือ Focus, Flow, and Joy (การจดจ่อ สภาวะลื่นไหล และความสุข) มันเป็นเรื่องของความรู้สึกในงานประจำวันของเรา งานของเราเต็มไปด้วยความน่าเบื่อและการรอคอยให้คนอื่นทำงานแทนเราหรือเปล่า? เราก้มหน้าก้มตาทำงานชิ้นเล็กๆ ของเราไปโดยไม่รู้เรื่องราวภาพรวม แล้วเพิ่งจะมาเห็นผลลัพธ์ของงานตอน deployment เมื่อทุกอย่างระเบิดเป็นจลจล จนนำไปสู่การตามแก้ปัญหา (firefighting) การลงโทษ และการหมดไฟ (burnout) หรือเปล่า? หรือว่าเราทำงานในชุดเล็กๆ (small batches) ตามอุดมคติคือการไหลของงานทีละชิ้น (single-piece flow) เพื่อให้ได้รับผลตอบรับที่รวดเร็วและต่อเนื่องจากงานของเรา? นี่คือเงื่อนไขที่ช่วยให้เกิดการจดจ่อและสภาวะลื่นไหล ความท้าทาย การเรียนรู้ การค้นพบ การเป็นผู้เชี่ยวชาญในโดเมนของเรา และแม้กระทั่งความสุขครับ”
เขามองไปรอบโต๊ะด้วยสีหน้าภาคภูมิใจ “และนั่นคือทั้งหมดที่คุณจะได้รู้ในตอนนี้ ผมจะแบ่งปันอุดมคติอีกสามข้อที่เหลือเมื่อพวกคุณพร้อมครับ”
“คุณล้อเล่นหรือเปล่าคะ” Maxine กล่าว “คุณกำลังเล่นบท Yoda หรือคุณมิยากิ (จากเรื่อง Karate Kid) กับพวกเราเหรอคะ? เอาน่า อย่างน้อยบอกชื่ออุดมคติข้อที่เหลือหน่อยเถอะค่ะ!”
“โชคดีนะเจ้าตั๊กแตนน้อย ผมไม่มีเวลามาเถียงด้วยแล้วล่ะ เพราะมีคนต่อแถวรอที่บาร์ยาวเหยียดที่ผมต้องไปจัดการแล้ว” เขากล่าว “สรุปสั้นๆ นะครับ: อุดมคติข้อที่สามคือ Improvement of Daily Work (การปรับปรุงงานประจำวัน) ลองสะท้อนถึงสิ่งที่สายดึงหยุดเครื่องจักร (Andon cord) ของโตโยต้าสอนเราว่า เราต้องให้ความสำคัญกับการปรับปรุงงานประจำวันให้เหนือกว่าตัวงานประจำวันเอง อุดมคติข้อที่สี่คือ Psychological Safety (ความปลอดภัยทางจิตวิทยา) ที่ที่เราทำให้การพูดถึงปัญหากลายเป็นเรื่องที่ปลอดภัย เพราะการแก้ปัญหาต้องการการป้องกัน ซึ่งต้องอาศัยความซื่อสัตย์ และความซื่อสัตย์จะเกิดขึ้นได้เมื่อไม่มีความกลัว ในโรงงานผลิต ความปลอดภัยทางจิตวิทยาสำคัญพอๆ กับความปลอดภัยทางกายภาพครับ และสุดท้าย อุดมคติข้อที่ห้าคือ Customer Focus (การจดจ่อที่ลูกค้า) ที่เราต้องตั้งคำถามอย่างไม่ลดละว่าบางอย่างมันสำคัญกับลูกค้าของเราจริงๆ หรือเปล่า เช่น พวกเขาเต็มใจจะจ่ายเงินเพื่อสิ่งนั้นไหม หรือมันมีค่าแค่สำหรับแผนกของเราเท่านั้น?”
Erik ดื่มเบียร์จนหมดแก้วแล้วกล่าวพร้อมรอยยิ้ม “โชคดีนะทุกคน เจอกันสัปดาห์หน้าครับ”
“เดี๋ยวๆ แค่นี้เองเหรอคะ?” Maxine ถาม แต่ Erik เดินจากไปแล้ว Maxine ก้มลงมองโน้ตที่เธอรีบพิมพ์ไว้:
อุดมคติข้อแรก—Locality and Simplicity อุดมคติข้อที่สอง—Focus, Flow, and Joy อุดมคติข้อที่สาม—Improvement of Daily Work อุดมคติข้อที่สี่—Psychological Safety อุดมคติข้อที่ห้า—Customer Focus
Maxine จ้องมองที่รายการนั้น—อุดมคติทั้งหมดฟังดูดีนะ แต่พวกเขาจะนำพวกมันไปใช้เปลี่ยนทิศทางของโปรเจกต์ Phoenix ได้อย่างไรกันล่ะ? “มันแปลกมากเลยนะ” Kurt พูดขึ้นในสิ่งที่ทุกคนกำลังคิดอยู่
Dave ขี้บ่นเสริมว่า “เรื่องอุดมคติข้อที่สี่นี่มันโดนใจจริงๆ วัฒนธรรมแห่งความกลัวที่ทุกคนไม่กล้าแม้แต่จะบอกข่าวร้าย? นั่นแหละคือพวกเราเลย”
“Erik พูดถูกครับ” Adam กล่าว “ไม่มีใครพูดถึงปัญหาจริงๆ เลย คนส่วนใหญ่ไม่กล้าพอที่จะพูดในสิ่งที่คิดหรือทำในสิ่งที่ถูกต้อง พวกเขาแค่ตอบ ‘ตกลง’ ไม่ว่าจะเห็นด้วยหรือไม่ก็ตาม แต่บางทีเรื่องนี้อาจสร้างโอกาสขึ้นมาก็ได้นะ ตอนนี้ผังองค์กรมีช่องว่างใหญ่เบ้อเร่อเลย” เขาบอกกับ Kurt “คุณควรลองเสนอชื่อตัวเองเพื่อรับตำแหน่งเหล่านั้นนะ บางทีอาจจะเป็นตำแหน่งของ William เลยก็ได้?”
ความเงียบเข้าปกคลุมโต๊ะอาหารขณะที่ทุกคนหันไปมอง Adam และ Kurt
“นั่นเป็นไอเดียที่เข้าท่ามากเลยนะ Kurt คุณน่าจะสร้างความเปลี่ยนแปลงครั้งใหญ่ได้ในองค์กร QA ฉันว่าพวกเราทุกคนคงจะแฮปปี้มากถ้ามันเป็นแบบนั้น” Shannon กล่าว โดยมีเสียงพึมพำเห็นพ้องจากคนรอบโต๊ะ
“ก็อาจจะนะครับ” Kurt พยักหน้าช้าๆ “แต่รู้ไหม ถ้าเราอยากสร้างความเปลี่ยนแปลงจริงๆ มันมีการเคลื่อนไเหวอีกแบบหนึ่ง ผมกำลังคิดว่าจะไปบอก Chris ว่าผมต้องการตำแหน่งของ Peter”
Maxine ได้ยินเสียงสูดหายใจด้วยความตกใจจากคนรอบโต๊ะ ตามมาด้วยเสียงหัวเราะดังลั่นจาก Dave ขี้บ่น “คุณพูดถูก Kurt คุณจะสร้างผลกระทบได้มากกว่าเยอะถ้าได้คุมทีม Dev เราทุกคนรู้ว่าเราต้องเปลี่ยนวิธีที่ QA ทำการทดสอบ แต่จุดเริ่มต้นที่ดีที่สุดคือการเปลี่ยนวิธีที่ Dev ทำการทดสอบ และนั่นต้องอาศัยการเป็นผู้จัดการฝ่ายพัฒนา... แต่มันก็มีปัญหาเล็กๆ จิ๋วๆ อย่างหนึ่งนะ... พวกเขาไม่มีวันให้ตำแหน่งนั้นกับคุณหรอก Kurt” เขากล่าว “ก็คุณรู้ใช่ไหม เพราะคุณมันก็แค่ ‘ผู้จัดการฝ่าย QA’ ไง”
Maxine ถึงกับสะดุ้ง Dave ขี้บ่นกำลังพูดถึงอคติที่ฝังรากลึกที่นักพัฒนาส่วนใหญ่มักจะมีต่อคนฝ่าย QA ซึ่งมันทำให้เธอรู้สึกอึดอัด ฝ่าย QA มักถูกมองว่าเป็นพลเมืองชั้นสอง แต่อย่างน้อยก็ยังอยู่เหนือกว่าฝ่าย Ops ซึ่ง Maxine คิดว่ามันเป็นเรื่องไร้สาระสิ้นดี เพราะเธอเองก็เริ่มอาชีพด้าน Ops ตั้งแต่สมัยมัธยมปลายด้วยการคอยเปลี่ยนตลับเทปสำรองข้อมูล และต่อมาก็ทำงาน QA ก่อนจะเข้าเรียนปริญญาโท—ถ้าไม่มีประสบการณ์เหล่านั้น เธอคงไม่มีวันเป็นเธออย่างทุกวันนี้ เทคโนโลยีในปัจจุบันยังคงมีระบบชนชั้นสูงเกินไปจริงๆ
Adam บอกกับ Kurt “คุณรู้ว่าผมเป็นแฟนตัวยงของคุณและรักการทำงานร่วมกับคุณ—คุณคือผู้นำที่วิเศษมาก—แต่ผมเห็นด้วยกับ Dave นะ ไม่มีทางที่บรรดาผู้จัดการฝ่ายพัฒนาจะยอมให้ผู้จัดการ QA เข้าไปเสียบแทนที่ตรงนั้นหรอก บางทีคุณอาจจะยอมรับแค่ตำแหน่งเดิมของ William ก็พอ อย่างน้อยก็ต้องมีใครสักคนพาฝ่าย QA ออกจากยุคหินและนำระบบทดสอบอัตโนมัติมาใช้กับส่วนที่เหลือของโปรเจกต์ Phoenix”
“ฉันต้องเห็นด้วยกับเพื่อนๆ ของคุณนะ Kurt” Kirsten กล่าว “ทั้งคุณและฉันต่างก็รู้ดีว่า William ไม่เคยชอบคุณเลย เขาไม่เคยพูดถึงคุณในแง่ดีในการประชุมเลย พวกเขาคงจะไปจ้างคนนอกเข้ามามากกว่า”
Kurt ยิ้มกว้าง ดูเหมือนจะไม่สะทกสะท้านกับข้อสังเกตของ Kirsten เขาเลียนเสียง William อีกครั้งว่า “‘ใช่แล้ว Kirsten คุณพูดถูก แม้ว่า Kurt จะแสดงให้เห็นถึงศักยภาพบ้าง แต่เห็นได้ชัดสำหรับผมว่าเขาไม่เข้าใจเกมของการทดสอบ บางทีในอีกสองสามปีเขาอาจจะมีวุฒิภาวะพอที่จะรันองค์กร QA ได้’”
ทุกคนหัวเราะ Kurt กลับมาพูดด้วยน้ำเสียงปกติ “ทุกคนครับ นี่คือโอกาสที่เราจะสร้างความเปลี่ยนแปลง แต่ผมไม่คิดว่าเราจะทำมันได้จากที่ไหนก็ตามในองค์กร QA—QA อย่างที่เรารู้จักมันกำลังจะเปลี่ยนไป เราจะเป็นคนที่รอทดสอบหลังจากที่ทุกอย่างเสร็จแล้วไม่ได้อีกต่อไป เราต้องเข้าไปอยู่ในเกม และนั่นหมายถึงการหาทางเข้าไปอยู่ในทีมพัฒนาที่ต้องรับผิดชอบในการส่งมอบฟีเจอร์และคุณภาพของผลลัพธ์จริงๆ อย่างอื่นถือเป็นการเสียเวลาเปล่าครับ”
เขากล่าวต่อ “ความจริงแล้ว ถ้าเราสามารถยึดทีมของ Peter ได้ เป้าหมายของผมคือการแสดงให้เห็นว่าเราสามารถทำผลงานได้เหนือกว่าทุกทีมในโปรเจกต์ Phoenix คนที่นั่งอยู่รอบโต๊ะนี้คือกลุ่มหัวกะทิทางเทคนิคของบริษัท และเราได้สร้างโครงสร้างพื้นฐานที่สามารถนำแนวทางปฏิบัติทางเทคนิคที่ยอดเยี่ยมมาใช้ในเกมนี้ได้แล้ว”
Kurt โน้มตัวมาข้างหน้า “ถ้าผมสามารถทำให้ Chris ให้โอกาสผมได้ พวกคุณทุกคนจะเต็มใจเข้าร่วมทีมและแสดงให้เห็นว่าเราสามารถเปลี่ยนทิศทางของโปรเจกต์ Phoenix ได้ไหมครับ?”
“เอาสิ Kurt นับผมเข้าทีมด้วยคน!” Dave ขี้บ่นกล่าว Maxine ประหลาดใจที่เขาเป็นคนแรกที่อาสาสมัคร
Maxine พูดตาม “ฉันด้วยค่ะ นี่แหละคือสิ่งที่ฉันอยากทำ และฉันรู้ว่าเราจะทำงานได้ทิ้งห่างทีมอื่นๆ จนไม่เห็นฝุ่นเลย ฉันเห็นคู่แข่งมากับตาแล้วค่ะ” เธอกล่าวพร้อมรอยยิ้ม
ทุกคนรอบโต๊ะส่งเสียงสนับสนุนด้วยความตื่นเต้นกับโอกาสที่อาจจะเกิดขึ้น Dave ขี้บ่นพูดว่า “โอ้ โอเค พวกเราเอาด้วย Kurt แต่บอกตรงๆ นะ ผมไม่ค่อยอยากจะหวังสูงเท่าไหร่ Adam พูดถูก—การที่คุณจะได้คุมทีม Dev มันเป็นเรื่องที่ริบหรี่มาก”
Kirsten กล่าวว่า “Kurt ฉันเห็นด้วยกับสัญชาตญาณของคุณนะ ถ้าคุณต้องการ ฉันจะเขียนจดหมายรับรองส่งไปให้ Chris เอง”
“นั่นคงจะวิเศษมากเลยครับ Kirsten” Kurt กล่าวด้วยใบหน้ายิ้มแย้ม เห็นได้ชัดว่าเขาประหลาดใจและซาบซึ้งจริงๆ กับข้อเสนอของ Kirsten ในนาทีนั้นเอง Maxine ตระหนักได้ว่า Kurt ทำงานทั้งหมดนี้มาโดยตลอดโดยไม่มี "เกราะคุ้มกัน" (air cover) จากผู้ใหญ่เลย เขาอาจถูกไล่ออกได้ง่ายๆ จากการทำตัวนอกคอกแบบนี้
“ยินดีช่วยค่ะ” Kirsten กล่าว “แต่ขอให้ชัดเจนนะคะ ฉันยินดีจะเขียนจดหมายเพื่อสนับสนุนไอเดียของ Kurt แต่ฉันคงจะไม่สามารถไปปรากฏตัวต่อหน้าสาธารณะกับพวกคุณทุกคนได้ อย่างน้อยก็ในตอนนี้ คนอื่นๆ ยังต้องมองว่าฉันเป็นกลางอยู่ค่ะ”
“โอ้ คุณเต็มใจให้โอกาสพวกเรายอมเสี่ยงตายและถูกไล่ออก แต่คุณจะขอนั่งดูอยู่วงนอกอย่างปลอดภัยงั้นเหรอครับ?” Dave ขี้บ่นพูดทีเล่นทีจริง Kirsten เพียงแค่ยกแก้วให้ Dave แทนคำตอบ