วันอังคารของสัปดาห์ถัดมา Maxine มาถึงที่ทำงานและเห็น Kurt กำลังยิ้มแก้มปริ “ผมได้งานแล้วครับ” เขาพูดออกมาด้วยความตื่นเต้นดีใจ
“จริงเหรอคะ? งานในทีม Dev เหรอ?” Maxine ถาม
“ใช่ครับ งานทีม Dev!” เขากล่าวราวกับว่าเขาเองก็ยังไม่อยากจะเชื่อ “มันคงเกิดขึ้นไม่ได้ถ้าไม่มีแรงสนับสนุนจาก Kirsten ผมกำลังจะไปร่วมทีม Data Hub และคุณก็ต้องไปกับผมด้วยครับ”
“ยอดเยี่ยมไปเลยค่ะ!” Maxine กล่าวอย่างปิติยินดี “คุณไปกล่อมให้ Randy ยอมอนุมัติการย้ายตัวฉันได้ยังไงคะ?”
“อืม เขาก็ไม่ค่อยแฮปปี้หรอกครับที่จะต้องเสียคุณไป เขาเอาแต่บ่นว่าคุณคือสิ่งที่ดีที่สุดที่เคยเกิดขึ้นกับที่นี่นับตั้งแต่มีการคิดค้นขนมปังแผ่นเลยล่ะ แต่... ก็นะ ผมมีวิธีของผมครับ” Kurt กล่าวพร้อมรอยยิ้มเจ้าเล่ห์
Maxine แตะมือไฮไฟว์กับเขา
เขามองไปรอบๆ แล้วกระซิบว่า “พวกผู้จัดการกำลังคุยกันเรื่องแปลกๆ ที่กำลังจะเกิดขึ้น ดูเหมือนว่าบรรดาผู้บริหารด้านเทคโนโลยีจะไปเข้าแคมป์ประชุมนอกสถานที่กับ Steve เมื่อต้นสัปดาห์นี้ และหนึ่งในสิ่งที่พวกเขาตกลงกันก็คือการแช่แข็งฟีเจอร์ (feature freeze) เป็นเวลาหนึ่งเดือน ดูเหมือนว่าพวกเขาจะเหยียบเบรกการส่งมอบฟีเจอร์เพื่อไปล้างหนี้ทางเทคนิค (technical debt) ทั้งหมดที่เราสะสมมาตลอดหลายปีครับ!”
“จริงเหรอคะ?!” Maxine รู้สึกตกใจ
“พวกเขาตระหนักแล้วว่าต้องแก้ไข ‘ขยะ’ ทั้งหมดที่ถูกสร้างขึ้นมา” เขากล่าว “ฝ่าย Ops กำลังหยุดงานทั้งหมดที่ไม่เกี่ยวข้องกับโปรเจกต์ Phoenix เพื่อที่พวกเขาจะได้ล้างหนี้ทางเทคนิคและทำระบบให้เป็นอัตโนมัติ และฝ่าย Dev กับ QA ก็จะหยุดงานด้านฟีเจอร์ทั้งหมดเพื่อล้างหนี้ทางเทคนิคของพวกเขาเหมือนกัน”
“นี่คือช่วงเวลาที่เราจะได้เฉิดฉายครับ นี่คือโอกาสที่เราจะแสดงให้ผู้คนเห็นว่าความยอดเยี่ยมทางวิศวกรรม (engineering greatness) เป็นอย่างไร” Kurt อุทาน
บ่ายวันนั้น มีอีเมลประกาศบทบาทใหม่ของ Kurt Maxine ไม่อยากทำให้ Kurt เสียความรู้สึก แต่เธอค่อนข้างแน่ใจว่าเหตุผลจริงๆ ที่เขาได้งานนี้ก็คือไม่มีใครในฝ่าย Development อยากรับงานนี้เลย Data Hub ถูกกล่าวขวัญกันอย่างกว้างขวางว่าเป็น “สาเหตุต้นตอ” (root cause) ของการแครชที่วินาศสันตะโรในช่วงการปล่อยตัว Phoenix แม้แต่ Chris ยังเคยระบุชื่อทีมนี้ออกมาตรงๆ ในระหว่างการประชุมที่ Maxine เข้าร่วม ซึ่งเธอคิดว่ามันไม่ยุติธรรมเลย
การโทษทีม Data Hub สำหรับความพินาศย่อยยับของการ deployment ของ Phoenix นั้น เหมือนกับการโทษว่าเครื่องบินตกเป็นเพราะผู้โดยสารที่นั่งแถวหลังสุดรัดเข็มขัดไม่แน่นพอ
เธอรู้ดีว่าทำไมการโทษ Data Hub ถึงทำได้ง่ายนัก เพราะมันเป็นส่วนงานเทคโนโลยีที่ดูไม่ค่อยน่าสนใจที่สุดแห่งหนึ่งในบริษัท Data Hub เป็นส่วนหนึ่งของระบบ message bus ขนาดใหญ่ที่น่าเบื่อ ซึ่งจริงๆ แล้ว Maxine กลับชอบมัน เพราะมันคือวิธีที่แแอปพลิเคชันหลักๆ และระบบจัดเก็บข้อมูล (systems of record) ใช้สื่อสารกัน ไม่ว่าจะเป็น ฐานข้อมูลสินค้า, ฐานข้อมูลราคา, ระบบจัดการคลังสินค้า, ระบบจัดการคำสั่งซื้อ, ระบบจ่ายค่าคอมมิชชันการขาย, ข้อมูลการเงินของบริษัท และระบบหลักอื่นๆ อีกเกือบร้อยระบบ ซึ่งหลายระบบมีอายุนับสิบปีแล้ว
Maxine ไม่เคยชอบเลยที่มีระบบจัดการคลังสินค้าถึงสามระบบ—สองระบบสำหรับร้านค้าจริง (ระบบหนึ่งได้มาจากการควบรวมกิจการและไม่เคยถูกปลดระวาง) และอีกระบบสำหรับช่องทางอีคอมเมิร์ซ และยังมีระบบป้อนคำสั่งซื้อ (order entry) อย่างน้อยหกระบบ—สามระบบรองรับร้านค้าจริง, หนึ่งระบบสำหรับอีคอมเมิร์ซ, อีกระบบสำหรับลูกค้า OEM และอีกระบบสำหรับการขายผ่านช่องทางสถานีบริการ
Maxine รักกระบวนการที่ซับซ้อนยุ่งเหยิงเหมือนกับที่กุมารแพทย์รักเด็กป่วย แต่แม้แต่เธอก็ยังต้องตกใจเมื่อเห็นว่า Data Hub ต้องเชื่อมต่อกับระบบจำนวนมหาศาลขนาดนี้
ยิ่ง Maxine ศึกษาว่า Data Hub ทำหน้าที่อะไร เธอก็ยิ่งงุนงงมากขึ้น Data Hub ดูเหมือนไม่ควรจะเป็นส่วนหนึ่งของ Phoenix เลยด้วยซ้ำ เพราะโค้ดส่วนใหญ่ของ Data Hub ถูกเขียนขึ้นเมื่อกว่ายี่สิบปีก่อน ซึ่งนานก่อนที่ Phoenix จะกลายเป็นโปรเจกต์เสียอีก
ดูเหมือนว่า Data Hub เคยเป็นกลุ่มของแอปพลิเคชันขนาดเล็กที่กระจัดกระจายอยู่ทั่วบริษัท บางส่วนอยู่ในฝ่ายการเงินพร้อมกับระบบ ERP, บางส่วนอยู่ในหน่วยธุรกิจการผลิต และส่วนอื่นๆ อยู่ในกลุ่ม Development ภายใต้การดูแลของ Chris
เมื่อโปรเจกต์ยักษ์ใหญ่อย่าง Phoenix เริ่มต้นขึ้น ความต้องการใหม่ๆ จำนวนมหาศาลก็ถูกโถมใส่ทีมเหล่านั้น และทีมเหล่านั้นก็ไม่ได้มีกำลังคนเพียงพอจะรับมือ ฟังก์ชันการทำงานใหม่ๆ ของ Phoenix จำนวนมากถูกบล็อก (blocked) เพราะ Data Hub มีลำดับความสำคัญทางธุรกิจอื่นที่ขัดแย้งกัน และในไม่ช้าฟีเจอร์ของ Phoenix ก็เริ่มล่าช้าออกไป เดือนแล้วเดือนเล่า
ในที่สุด ในการปรับโครงสร้างองค์กร ส่วนประกอบเหล่านั้นทั้งหมดจึงถูกยุบรวมเข้าเป็นกลุ่มใหม่ที่เรียกว่า Data Hub และถูกจัดให้อยู่ภายใต้โปรเจกต์ Phoenix เพื่อให้แน่ใจว่างานของ Phoenix จะได้รับความสำคัญเป็นอันดับแรกเสมอ และตอนนี้ทุกคนก็กำลังรุมโทษ Data Hub สำหรับสิ่งที่ผิดพลาดไป
เช้าวันพุธ Maxine และ Dave ขี้บ่น เข้าร่วมประชุมครั้งแรกกับเหล่าวิศวกรของ Data Hub พร้อมกับ Kurt Maxine ประหลาดใจที่เห็นว่า Dave ขี้บ่นสามารถย้ายมาอยู่ Data Hub ได้เร็วขนาดนี้ด้วย เธอถามเขาว่าเขาจัดการเรื่องนี้ได้อย่างไร
Dave ขี้บ่นเพียงแค่ยิ้มแล้วพูดว่า “เป็นหนึ่งในข้อดีมากมายของบุคลิกที่น่าหลงใหลของผมไง—ไม่มีผู้จัดการคนไหนยอมพลาดโอกาสที่จะส่งผมไปอยู่ทีมอื่นหรอกครับ มันช่วยให้ผมไปที่ไหนก็ได้ที่ผมต้องการ”
เธอยืนข้าง Dave ขี้บ่น ขณะที่วิศวกรของ Data Hub อีกห้าคนมารวมตัวกันที่พื้นที่ประชุมส่วนกลาง
พวกเขามีทั้งรุ่นราวคราวเดียวกับเธอ หรือไม่ก็เพิ่งจบใหม่จากมหาวิทยาลัย ไม่มีใครที่อยู่กึ่งกลางเลย เธอสงสัยว่าเหล่านักพัฒนาอาวุโสน่าจะอยู่กับทีมนี้มาตั้งแต่ต้น ส่วนวิศวกรรุ่นใหม่ๆ คงจะรีบย้ายออกไปหาความท้าทายอื่นที่น่าสนใจกว่าอย่างรวดเร็ว แล้วก็ถูกแทนที่ด้วยเด็กจบใหม่อีกกลุ่มหนึ่ง
Chris กระแอมและกล่าวเปิดการประชุม “สวัสดีตอนเช้าทุกคน ขอต้อนรับ Kurt Reznick ที่จะมารับช่วงต่อจาก Peter ครับ”
Kurt ดูจะประหลาดใจกับการแนะนำตัวสั้นๆ แต่ก็กล่าวอย่างร่าเริงว่า “สวัสดีครับทุกคน อย่างที่พวกคุณทราบ นี่คือทีม Dev ทีมแรกที่ผมได้บริหาร ผมเชื่อว่างานของผมนั้นง่ายมาก: ฟังพวกคุณ ทำทุกอย่างที่พวกคุณต้องการเพื่อให้พวกคุณประสบความสำเร็จ และขจัดอุปสรรคทุกอย่างที่ขวางทางพวกคุณครับ” เห็นได้ชัดจากสายตาที่ดูไม่ค่อยศรัทธาของทุกคนว่าพวกเขารู้ดีว่า Kurt ยังขาดประสบการณ์
Kurt กล่าวต่อ “ผมได้คุยกับลูกค้าภายใน (internal customers) มากมายของเรา และพวกเขาบอกผมว่า Data Hub สำคัญแค่ไหน แต่พวกเขาก็บอกด้วยว่าบ่อยครั้งเราเป็นคอขวด (bottleneck) สำหรับการเปลี่ยนแปลงที่จำเป็นทั่วทั้งองค์กร รวมถึงโปรเจกต์ Phoenix ด้วย และอย่างที่พวกเราทราบดี เมื่อบริการของเราล่ม Phoenix ก็ล่มตามไปด้วย ผมได้จัดตารางประชุมปลายสัปดาห์นี้เพื่อให้เรามาระดมสมองกันว่าจะทำให้บริการของเราเสถียรและทนทาน (resilient) มากขึ้นได้อย่างไร”
“การโทษว่า Data Hub และ Peter เป็นต้นเหตุให้ Phoenix ล่มนั้นมันไร้สาระสิ้นดีครับ” หนึ่งในนักพัฒนาอาวุโสกล่าว
“ผมเห็นด้วยกับคุณอย่างที่สุดครับ Tom” Kurt กล่าว “และขอให้มั่นใจได้เลยว่าผมจะพยายามแก้ไขความเข้าใจผิดนั้นเอง”
Kurt กล่าวต่อ “ผมรู้สึกขอบคุณมากที่ Peter ยอมพบกับผมก่อนที่ผมจะเริ่มงาน เขาบอกผมว่าเขาพยายามขอเพิ่มจำนวนพนักงาน (headcount) สำหรับนักพัฒนาอาวุโสมาเป็นปีแล้ว เพราะความต้องการทางธุรกิจเพิ่มขึ้นเรื่อยๆ โดยเฉพาะเรื่องการเชื่อมต่อ (integration) กับ Phoenix เขาแนะนำให้ผมพยายามต่อไป”
Kurt ผายมือไปทาง Chris “และผมสัญญาว่าผมจะยังคงผลักดัน Chris ต่อไปเพื่อขออัตรากำลังเพิ่มครับ”
“และผมก็จะยังคงผลักดัน Steve ต่อไปครับ” Chris ตอบกลับพร้อมรอยยิ้มที่ดูเคร่งขรึม Kurt หัวเราะ “ดังนั้น ในระหว่างนี้ ผมได้พาวิศวกรอาวุโสสองคนมาเข้าร่วมทีมด้วยครับ Maxine เป็นวิศวกรที่อาวุโสที่สุดจากทีม MRP และ Dave เป็นวิศวกรอาวุโสจากทีม Phoenix back-end server ทั้งคู่คือนักพัฒนาที่ผมไว้วางใจมากที่สุดครับ”
เหล่านักพัฒนาของ Data Hub มองมาที่พวกเขาด้วยความประหลาดใจ แต่ก็ดูดีใจจริงๆ ที่เธอและ Dave ขี้บ่นมาอยู่ที่นี่
“เร็วๆ นี้จะมีคำสั่งจาก Chris เกี่ยวกับการแช่แข็งฟีเจอร์ (feature freeze) เพื่อให้เราได้แก้ไขข้อบกพร่อง (defects) ที่ส่งผลกระทบต่อลูกค้า และแก้ไขส่วนที่มีปัญหาในโค้ดของเรา” Kurt กล่าว “แต่ไม่ต้องรอประกาศหรอกครับ สิ่งที่สำคัญที่สุดในตอนนี้คือการแก้ไขสิ่งที่คุณคิดว่าควรแก้ และอะไรก็ตามที่คุณคิดว่าจะช่วยให้คุณทำงานได้ดีขึ้น หรือทำให้ Data Hub เสถียรขึ้น ผมจะคอยรับมือกับคำบ่นต่างๆ ที่จะตามมาเอง”
Maxine ยิ้มเมื่อเห็นสีหน้าของการยอมรับกึ่งแบ่งรับแบ่งสู้จากเหล่าวิศวกรของ Data Hub
ในฐานะวิศวกรใหม่ Dave ขี้บ่นและ Maxine ได้เริ่มปรับตัวเข้ากับวิถีชีวิตประจำวันของทีม Data Hub พวกเขาเข้าร่วมการประชุมยืนคุย (stand-ups) และอาสาช่วยเหลือในเรื่องต่างๆ อย่างรวดเร็ว
Maxine จับคู่ทำงาน (pairing) กับ Tom นักพัฒนาอาวุโสที่เคยแสดงความเห็นเรื่องความไม่ยุติธรรมในการถูกเป็นแพะรับบาป Tom อายุสี่สิบปลายๆ ใส่แว่น กางเกงยีนส์ และเสื้อยืด เธอนั่งลงที่โต๊ะของเขาพร้อมเปิดแล็ปท็อป ขณะที่เขาอธิบายสิ่งที่เขากำลังทำอยู่
ขณะที่เขาพูด Maxine สังเกตเห็นว่า Data Hub เป็นการผสมผสานของเทคโนโลยีที่สั่งสมมานานหลายทศวรรษ รวมถึงส่วนใหญ่ที่รันบน Java servlets, สคริปต์ Python และบางอย่างที่เธอนึกว่าเป็น Delphi แถมยังมี PHP web server อีกด้วย
เธอไม่ได้ตัดสินหรือปฏิเสธเทคโนโลยีเหล่านั้น—ยังไงซะ มันก็รับใช้คนทั้งองค์กรมาได้อย่างประสบความสำเร็จเป็นเวลาหลายทศวรรษแล้ว มันอาจจะไม่ใช่ซอฟต์แวร์ที่สวยงามที่สุดที่เธอเคยเห็น แต่ซอฟต์แวร์ที่รันอยู่ใน production มายี่สิบปีแล้วมักจะไม่ค่อยสวยงามหรอก ซอฟต์แวร์ก็เหมือนเมืองที่ต้องมีการเปลี่ยนแปลง ปรับปรุง และซ่อมแซมอยู่ตลอดเวลา อย่างไรก็ตาม เธอต้องยอมรับว่า Data Hub ไม่ใช่ย่านที่ทันสมัยที่สุดแน่นอน มันคงยากที่จะดึงดูดนักศึกษาจบใหม่ที่อยากเรียนรู้และใช้ภาษาหรือเฟรมเวิร์ก (frameworks) ที่กำลังฮิตที่สุดในตลาด
แต่อย่างน้อย Data Hub ก็ยังอยู่ในสภาพที่ดีกว่าระบบ build ของ Phoenix เยอะ ซึ่งที่นั่นเหมือนกับเขตกักกันกัมมันตภาพรังสีที่อาศัยอยู่ไม่ได้ หรือไม่ก็เหมือนซากปรักหักพังหลังสงคราม
Maxine นั่งอยู่ที่โต๊ะของ Tom ขณะที่เขาอธิบายงานที่ทำอยู่ “ผมกำลังแก้ defect ด่วนตัวหนึ่งครับ Data Hub มักจะสร้างธุรกรรมข้อความ (message transactions) ที่ผิดพลาดเป็นบางครั้ง และแครช (crash) เมื่อเจอโหลดหนักๆ มันมักจะเกิดขึ้นเมื่อพนักงานในร้านทำเครื่องหมายว่างานซ่อมเสร็จสมบูรณ์ในแอปพลิเคชันสถานีบริการครับ” เขากล่าวพลางทำท่าเขินๆ แล้วพูดต่อ “ผมเสียเวลากับเรื่องนี้มาหลายวันแล้ว ในที่สุดผมก็สร้างเคสทดสอบ (test case) ที่พอจะจำลองปัญหาออกมาได้—มันเกิดขึ้นประมาณหนึ่งในสิบครั้ง ผมค่อนข้างมั่นใจว่ามันเกิดจากสภาวะการแย่งชิงทรัพยากร (race condition) ครับ”
“นี่มันงานยากตั้งแต่เริ่มเลยนะเนี่ย” Maxine คิดในใจ แต่เธอชอบความท้าทายนี้และมั่นใจว่าเมื่อพวกเขาแก้ปัญหานี้ได้ มันจะสร้างความประทับใจที่ดีให้กับทั้งทีมแน่นอน เพราะสภาวะการแย่งชิงทรัพยากร (race conditions) เป็นหนึ่งในปัญหาที่แก้ยากที่สุดในโลกของระบบกระจายตัว (distributed systems) และวิศวกรรมซอฟต์แวร์ ถ้าการทำงานกับเด็กมัธยมคือความท้าทายระดับสายเหลืองในคาราเต้ สิ่งที่ Tom กำลังบรรยายอยู่นี้ก็สามารถทำให้สายดำขั้นที่สิบผู้มีประสบการณ์สูงสุดตกอยู่ในความสิ้นหวังและเป็นบ้าได้เลย
Maxine ทึ่งที่ Tom สามารถจำลอง (reproduce) ปัญหานี้ออกมาได้ ใครบางคนเคยเรียกปัญหาพวกนี้ว่า “heisenbugs” ซึ่งอ้างอิงถึงปรากฏการณ์ทางควอนตัมฟิสิกส์ที่การเฝ้าสังเกตการณ์จะเปลี่ยนธรรมชาติของความจริงนั้นไปเอง
งานประเภทนี้แตกต่างอย่างมากจากภาพการเขียนโค้ดในภาพยนตร์: ที่มีโปรแกรมเมอร์หนุ่มใส่เสื้อฮู้ด พิมพ์งานอย่างบ้าคลั่ง และที่แปลกคือยังใส่แว่นกันแดดด้วย (ซึ่งเธอไม่เคยเห็นนักพัฒนาคนไหนทำจริงๆ ในชีวิตเลย) เขามีหน้าต่างเปิดอยู่มากมาย มีข้อความเลื่อนผ่านไปอย่างรวดเร็วในทุกหน้าต่าง ข้างหลังเขามีกลุ่มคนยืนมองข้ามไหล่ รอคอยอย่างใจจดใจจ่อ หลังจากผ่านไปไม่กี่วินาที คนเขียนโค้ดก็ตะโกนว่า “ได้แล้ว!” และทุกคนก็โห่ร้องแสดงความยินดี วิธีแก้ปัญหาถูกสร้างขึ้น ฟีเจอร์ถูกส่งมอบ หรือโลกถูกกู้ไว้ได้ และฉากนั้นก็จบลง
แต่ในความจริง เมื่อนักพัฒนาทำงาน พวกเขามักจะจ้องมองหน้าจอด้วยสมาธิที่แน่วแน่ พยายามทำความเข้าใจว่าโค้ดนั้นทำอะไร เพื่อที่พวกเขาจะได้แก้ไขมันได้อย่างปลอดภัยและแม่นยำ (surgically change) โดยไม่ไปทำลายส่วนอื่นจนเกิดผลกระทบที่ไม่ตั้งใจ (unintended side-effects) โดยเฉพาะอย่างยิ่งถ้าพวกเขากำลังทำงานกับระบบที่สำคัญระดับภารกิจ (mission-critical)
Tom พาเธอไล่ดูปัญหา “เมื่อมีธุรกรรมการซ่อมหลายรายการถูกประมวลผลพร้อมกัน บางครั้งหนึ่งในธุรกรรมนั้นจะได้รับรหัสลูกค้า (customer ID) ที่ผิดไป และบางครั้ง Data Hub ก็แครชไปเลยครับ” เขากล่าว “ผมลองใส่ lock ครอบออบเจ็กต์ลูกค้า (customer object) ไว้แล้ว แต่มันทำให้แอปพลิเคชันทั้งหมดช้าลงมากจนไม่ใช่ทางเลือกที่ใช้งานได้จริง ลำพังแค่ตอนนี้เราก็มีปัญหาประสิทธิภาพ (performance) มากพออยู่แล้วครับ”
Maxine พยักหน้า เพราะ Tom กำลังยืนยันความเชื่อที่เธอมีมานานว่า ความผิดพลาดจากการทำงานหลายเทรด (multi-threading errors) นั้นแทบจะเกินขีดจำกัดที่มนุษย์จะใช้เหตุผลขบคิดได้ โดยเฉพาะอย่างยิ่งเมื่อภาษาโปรแกรมกระแสหลักส่วนใหญ่อย่าง Java, C# และ JavaScript สนับสนุนการเปลี่ยนค่าสถานะที่ใช้ร่วมกัน (mutation of shared state)
มันแทบจะเป็นไปไม่ได้เลยที่จะคาดเดาว่าโปรแกรมจะทำงานอย่างไร หากส่วนอื่นของโปรแกรมสามารถเปลี่ยนข้อมูลที่คุณกำลังพึ่งพาอยู่ได้ตลอดเวลา Maxine คิดในใจ แต่เธอค่อนข้างมั่นใจว่ารู้วิธีแก้ปัญหานี้
“เราลองไล่ดูเส้นทางการทำงานของโค้ด (code path) กันอีกรอบได้ไหมคะ?” Maxine ถาม ขณะที่พวกเขาไล่ดูโค้ด Maxine ก็ทำรายการตรวจสอบในใจเพื่อยืนยันสมมติฐานของเธอ มี thread pool ที่จัดการข้อความที่เข้ามา เช็ก ระบบบันทึกการซ่อมสามารถถูกจัดการโดยหลายเทรดพร้อมกัน เช็ก เทรดเหล่านั้นส่งต่อออบเจ็กต์ไปมา และออบเจ็กต์ถูกเปลี่ยนค่า (mutated) เมื่อเมธอด (methods) ของมันถูกเรียกใช้งาน เช็ก
สมมติฐานได้รับการยืนยัน ปัญหานี้เกือบจะแน่นอนว่าเกิดจากการเปลี่ยนค่าสถานะ (state mutation) ที่ผิดพลาด เธอคิด เหมือนกับที่โรงเรียนมัธยมเป๊ะเลย
“คุณพูดถูกค่ะ มันคือ race condition แน่นอน” Maxine กล่าว “และฉันค่อนข้างมั่นใจว่าเราสามารถแก้ปัญหานี้ได้โดยไม่ต้องใส่ lock ครอบออบเจ็กต์ลูกค้าทั้งตัว ฉันขอโชว์สิ่งที่ฉันคิดหน่อยได้ไหมคะ?”
เมื่อเขาพยักหน้า Maxine ก็ทำแบบเดียวกับที่เธอทำกับเด็กมัธยม คือการเสนอให้เขียน code path นั้นใหม่โดยใช้หลักการของ functional programming เคสทดสอบของ Tom มีการใช้ mocks และ stubs มากมายเพื่อจำลองสภาพแวดล้อม production ทั้ง configuration server, ฐานข้อมูล, message bus, โรงงานผลิตออบเจ็กต์ลูกค้า (customer object factory) . . . .
เธอโยนสิ่งเหล่านั้นทิ้งไปทั้งหมด เพราะนั่นไม่ใช่ส่วนของระบบที่เธอต้องการจะทดสอบ แต่เธอเลือกที่จะผลักดันเรื่อง Input/Output และผลกระทบข้างเคียง (side-effects) ทั้งหมดออกไปไว้ที่ขอบนอกของระบบ (edges) และสร้างหน่วยทดสอบ (unit tests) รอบๆ วิธีการประมวลผลข้อความคำสั่งซ่อมที่เข้ามา ว่าข้อมูลลูกค้าถูกแปลง (transform) อย่างไร และมีข้อความอะไรถูกส่งออกไปบ้าง
เธอให้แต่ละเทรดสร้างสำเนา (copy) ของออบเจ็กต์ลูกค้าเป็นของตัวเอง พวกเขาเขียนเมธอดของออบเจ็กต์แต่ละอันใหม่ให้กลายเป็นชุดของ pure functions—ซึ่งเป็นฟังก์ชันที่ผลลัพธ์ขึ้นอยู่กับอินพุต (inputs) ของมันเท่านั้น โดยไม่มีผลกระทบข้างเคียง ไม่มีการเปลี่ยนค่าสถานะ หรือการเข้าถึงสถานะส่วนกลาง (global state)
เมื่อ Maxine แสดงหน่วยทดสอบ (unit test) ที่สามารถจำลองปัญหาออกมาได้แบบ 100% ให้ Tom ดู รวมถึงวิธีแก้ไขที่ปลอดภัยต่อการทำงานหลายเทรด (thread-safe) และทำงานได้ถูกต้อง 100% ตลอดเวลา Tom ได้แต่จ้องมองเธอด้วยดวงตาที่เบิกกว้างด้วยความทึ่ง “นั่นมัน... มัน... เหลือเชื่อมากครับ”
เธอรู้ดีว่าทำไมเขาถึงประทับใจ โค้ดของเธอนั้นเรียบง่ายมากจนเข้าใจและทดสอบความถูกต้องได้ง่าย ในที่สุด หลังจากที่ชื่นชมหน้าจออยู่พักใหญ่ เขาก็พูดว่า “ผมไม่อยากจะเชื่อเลยว่าคุณทำให้มันง่ายได้ขนาดนี้ มันจะทำงานได้เหมือนกับกองขยะที่ซับซ้อน (complex mess) ที่เราเคยมีได้ยังไงกันครับ?” ตลอดช่วงบ่ายที่เหลือ เขาถามคำถามมากมาย พยายามพิสูจน์กับตัวเองว่าเคสทดสอบของ Maxine ครอบคลุมปัญหาจริงๆ และโค้ดที่เขียนใหม่นั้นถูกต้อง ในที่สุดเขาก็พูดว่า “ผมไม่อยากจะเชื่อเลย แต่ผมว่าคุณพูดถูกครับ แบบนี้มันทำงานได้แน่นอน!”
Maxine ยิ้มกว้างกับปฏิกิริยาของ Tom นี่เป็นอีกหนึ่งข้อพิสูจน์ว่าหลักการ functional programming เป็นเครื่องมือที่ดีกว่าในการใช้ขบคิด และพวกเขาก็ทำให้โค้ดดีขึ้นกว่าตอนที่เจอมาก—มันปลอดภัยกว่า ทดสอบง่ายกว่า และเข้าใจง่ายกว่าเดิมเยอะ นี่มันสนุกจริงๆ เธอคิด และเป็นตัวอย่างที่ยอดเยี่ยมของอุดมคติข้อแรกเรื่อง Locality และ Simplicity
“โอเค มา merge วิธีแก้ปัญหานี้กันเถอะ!” เขากล่าวพลางเปิดหน้าต่างเทอร์มินัลและพิมพ์คำสั่งบางอย่างลงไป เขาหันมาหา Maxine “ยินดีด้วยครับ! คุณเพิ่งแก้ defect แรกสำเร็จและได้เช็กอิน (check in) การเปลี่ยนแปลงครั้งแรกของคุณแล้ว!”
Maxine แตะมือไฮไฟว์กับเขาอย่างแรง พร้อมรอยยิ้มกว้างบนใบหน้า การกำจัดข้อผิดพลาดแบบ race condition ได้ตั้งแต่วันแรกที่มาอยู่นี่มันโคตรเจ๋งเลย “เยี่ยมไปเลยค่ะ! งั้นเรามาทดสอบแล้ว push ขึ้น production กันเถอะ” Maxine ตื่นเต้นเมื่อนึกภาพผู้จัดการร้านที่กำลังขอบคุณพวกเขา
“เอิ่ม... อ่า...” Tom พูดหยุดไปครู่หนึ่ง “การทดสอบจะยังไม่เริ่มจนกว่าจะถึงวันจันทร์ครับ”
Maxine รู้สึกเหมือนหัวใจหล่นวูบ “พวกเราทดสอบเองไม่ได้เหรอคะ?”
“เราเคยทำได้ครับ ก่อนที่จะโดนปรับโครงสร้าง (re-org) เข้ามาอยู่ในโปรเจกต์ Phoenix” เขากล่าวอย่างอาลัยอาวรณ์ “กลุ่ม QA ยึดเรื่องการทดสอบไปทั้งหมด และเมื่อพวกเขามีปัญหาเรื่องทีมต่างๆ ใช้สภาพแวดล้อมการทดสอบ (test environment) พร้อมกัน เขาก็เลยตัดสิทธิ์การเข้าถึงของทุกคนทิ้ง ตอนนี้มีแค่พวกนั้นเท่านั้นที่ล็อกอินเข้าไปรันการทดสอบได้”
“เดี๋ยวนะคะ” เธอกล่าว “เราเป็นคนเขียนเทสแต่รันมันไม่ได้เนี่ยนะ?”
เขาหัวเราะ “เปล่าครับๆ พวกเขาเป็นคนเขียนเทสเองด้วยซ้ำ แถมยังไม่ยอมให้เราเห็นแผนการทดสอบ (test plans) อีกต่อไปแล้วครับ”
Maxine รู้สึกห่อเหี่ยวลงไปอีก เมื่อพอจะเดาออกว่าเรื่องจะจบลงอย่างไร “แล้วเราก็ push ขึ้น production เองไม่ได้ด้วยใช่ไหมคะ?”
Tom หัวเราะอีกครั้ง “ไม่ครับ ไม่ได้แล้วเหมือนกัน เมื่อก่อนเราเคยทำได้นะครับ แต่ตอนนี้คนอื่นเป็นคน deploy ให้เราแทน ‘อยู่แต่ในเลนของคุณก็พอ’ พวกเขาบอกมาแบบนั้นครับ” เขายักไหล่ Maxine ค่อนข้างมั่นใจว่าเธอรู้ว่าใครเป็นคนพูดประโยคนั้น—ก็น่าจะเป็น Chris นั่นแหละ
ความสุขที่ Maxine รู้สึกมาตลอดทั้งวันจากการแก้ปัญหาก็อันตรธานหายไป เพราะการแก้ไขโค้ดโดยเฉพาะสำหรับฟีเจอร์ต่างๆ นั้นเป็นเพียงส่วนเสี้ยวเดียวของงานทั้งหมด งานมันยังไม่จบจนกว่าลูกค้าจะได้ใช้งานสิ่งที่พวกเขาเขียนขึ้น และแม้แต่ตอนนั้น มันก็น่าจะยังเป็นงานที่ต้องทำต่อไปเรื่อยๆ เพราะเราสามารถเรียนรู้เพิ่มเติมได้เสมอว่าควรจะช่วยให้ลูกค้าบรรลุเป้าหมายได้อย่างไร
“ให้ตายเถอะ” เธอพึมพำ ฉันกลับมาอยู่ที่เดิมอีกแล้ว ห่างไกลจากอุดมคติข้อแรกเหลือเกิน ฉันยังทำอะไรเองไม่ได้เลยจริงๆ Maxine คิดในใจ อีกครั้งหนึ่งที่เธอต้องพึ่งพาคนอื่นเพื่อสร้างคุณค่าให้กับลูกค้า
Tom ผู้ไม่รับรู้ถึงความรู้สึกเธอหัวเราะและเปิดหน้าต่างใหม่ขึ้นมา “มันไม่แย่ขนาดนั้นหรอกครับ เราแค่ต้องเข้าไปในระบบจัดการ Ticket แล้วติ๊กสถานะปัญหานี้เป็น ‘done’ (เสร็จสิ้น) แค่นั้นเอง เพื่อให้ทีม QA รู้ว่าต้องทดสอบมัน เพื่อที่จะได้ส่งต่อ (promote) ขึ้น production ต่อไป”
Tom มองนาฬิกาแล้วหันกลับมาหาเธอ “วันนี้ยอดเยี่ยมมาก เราทำอะไรเสร็จไปตั้งเยอะ อยากเลือก defect อื่นมาทำต่อไหมครับ?” Maxine ฝืนยิ้มและพยักหน้า นี่มันห่วยแตกสิ้นดี Maxine คิดในใจ เธอชอบทำงานให้เสร็จจริงๆ ไม่ใช่แค่การเริ่มต้นทำไว้เฉยๆ
Maxine ทำงานกับ Tom ต่อไปตลอดทั้งวัน โดยเลือก defect ที่เร่งด่วนที่สุดลำดับถัดไปขึ้นมาแก้ไข Tom เอ่ยชม Maxine อีกครั้งเกี่ยวกับวิธีที่เธอใช้คิดเพื่อแก้ปัญหา เขาทึ่งวิธีที่เธอเขียนหน่วยทดสอบ (unit tests) ที่สามารถรันได้โดยไม่ต้องพึ่งพาสภาพแวดล้อมการทดสอบแบบรวม (integration test environment) ที่ซับซ้อน
แต่มันก็มีขีดจำกัด—งานของ Data Hub คือการเชื่อมต่อระบบต่างๆ เข้าด้วยกัน มันมีสิ่งที่คุณสามารถจำลอง (simulate) บนแล็ปท็อปเครื่องเดียวได้เพียงจำกัดเท่านั้น มันคงจะดีถ้าเราสามารถปรับสถาปัตยกรรม (rearchitect) ของ Data Hub ใหม่เพื่อให้ทำแบบนั้นได้ Maxine คิดอย่างมีความหวัง
แม้ว่าเธอจะสนุกกับการเรียนรู้เรื่อง Data Hub และส่วนต่างๆ ของธุรกิจที่มันเชื่อมต่ออยู่ แต่มีบางอย่างเกี่ยวกับงานนี้ที่ทำให้เธอรู้สึกไม่พึงพอใจอย่างลึกซึ้ง
เธอนึกถึงอุดมคติข้อที่สองของ Erik เรื่อง Focus, Flow, and Joy ความสุขทั้งหมดที่เธอรู้สึกระเหยกลายเป็นไอไปทันทีเมื่อ Tom บอกเธอว่าพวกเขาเพิ่งทำงานเสร็จไปเพียงเศษเสี้ยวเล็กๆ ของงานที่จำเป็นในการสร้างคุณค่าจริงๆ นั่นยังไม่ดีพอสำหรับเธอ ในทีม MRP ของเธอนั้น นักพัฒนาทุกคนสามารถทดสอบโค้ดของตัวเองและแม้แต่ push โค้ดขึ้น production ได้ด้วยตัวเอง พวกเขาไม่ต้องรอนานเป็นสัปดาห์เพื่อให้คนอื่นมาทำงานนั้นแทน การที่สามารถทดสอบและ push โค้ดขึ้น production ได้เองนั้นช่วยเพิ่มประสิทธิภาพการทำงาน ทำให้ลูกค้ามีความสุขมากขึ้น สร้างความรับผิดชอบต่อคุณภาพโค้ดให้กับคนที่เขียนมัน และยังทำให้งานมีความสุขและคุ้มค่ายิ่งขึ้น
Maxine เริ่มคิดหาวิธีนำเครื่องมือบางอย่างที่กลุ่ม Rebellion กำลังสร้างอยู่มาใช้ อย่างน้อยที่สุด เราต้องทำให้มีสภาพแวดล้อมการพัฒนา (Dev environments) ที่เป็นมาตรฐาน เพื่อให้ฉันสามารถรัน build บนแล็ปท็อปได้ เธอคิด มีเรื่องให้ต้องคุยกันอีกเยอะในการประชุมที่ Dockside ครั้งถัดไป
เธอทำงานหนักต่อไป ช่วย Tom ในงานที่เขาได้รับมอบหมาย พวกเขาร่วมกันแก้ไข defect ได้สองรายการ และจากนั้นก็เริ่มจัดการฟีเจอร์ระดับเร่งด่วนสูงสุด (crash-priority) คราวนี้เป็นการสร้างกฎเกณฑ์ทางธุรกิจเกี่ยวกับแผนขยายการรับประกัน (extended warranty plans) ซึ่งสำคัญพอที่จะได้รับการยกเว้นจากการแช่แข็งฟีเจอร์
“ทำไมเรื่องนี้ถึงมีความสำคัญสูงขนาดนั้นคะ?” Maxine ถาม Tom ขณะอ่าน Ticket
“มันสร้างรายได้มหาศาลเลยครับ” Tom อธิบาย “หนึ่งในผลิตภัณฑ์ที่มีกำไรสูงสุดคือแผนขยายการรับประกันใหม่พวกนี้แหละ ลูกค้าชอบโปรแกรมการรับประกันนำร่องมาก โดยเฉพาะเรื่องยางรถยนต์ ตอนนี้พนักงานในร้านต้องการวิธีดึงข้อมูลนี้ขึ้นมา เพื่อที่พวกเขาจะได้ซ่อมแซมและยื่นคำร้องเคลม (file the claim) กับบริษัทประกันภายนอกได้”
Tom กล่าวต่อ “มันดีสำหรับลูกค้า ดีสำหรับเรา และบริษัทประกันภายนอกก็เป็นคนแบกรับความเสี่ยงทางการเงินทั้งหมดครับ”
“เจ๋งค่ะ” Maxine กล่าวพลางรู้สึกกระตือรือร้นขึ้นมา ฟีเจอร์แบบนี้แหละที่สนับสนุนทุกสิ่งที่ Steve พูดในงาน Town Hall นานมากแล้วที่ Maxine ไม่ได้ทำงานในส่วนที่สร้างรายได้ให้กับธุรกิจแบบนี้
เธอกลับมาตั้งปณิธานกับตัวเองว่าจะต้องมองโลกในแง่ดีอย่างไม่ลดละ Maxine และ Tom เริ่มศึกษาฟีเจอร์นี้ พยายามหาว่าต้องทำอะไรบ้างเพื่อให้ความสามารถทางธุรกิจที่สำคัญนี้ใช้งานได้จริง เธอพยายามไม่คิดว่า ต่อให้พวกเขาทำเสร็จในวันนี้ มันก็จะไปนั่งแช่นิ่งๆ รอให้ทีม QA มาทดสอบอยู่ดี
เช้าวันรุ่งขึ้น Tom และ Maxine อยู่ที่หน้าไวท์บอร์ด กำลังไล่รายการระบบทั้งหมดที่พวกเขาต้องเข้าไปแก้ไขเพื่อให้ระบบขยายการรับประกันใช้งานได้ วิศวกรอีกสองคนเข้ามาร่วมด้วยเมื่อขอบเขตของงาน (scope) ขยายใหญ่ขึ้นเรื่อยๆ แล้วพวกเขาก็ตระหนักว่าต้องไปคุยกับวิศวกรจากทีมอื่นอีกสองทีมด้วย Maxine คาดเดาว่าพวกเขาอาจจะต้องดึงทีมอื่นเข้ามาเกี่ยวถึงหกทีม เพราะฟีเจอร์นี้ส่งผลกระทบต่อระบบธุรกิจหลายตัวมาก
Maxine รู้สึกท้อแท้เมื่อจำนวนทีมที่ต้องเข้ามาเกี่ยวข้องเพิ่มขึ้นเรื่อยๆ นี่เป็นสิ่งที่ตรงข้ามกับอุดมคติข้อแรกเรื่อง Locality และ Simplicity อีกครั้ง ในที่นี้ การเปลี่ยนแปลงที่ต้องทำไม่ได้ถูกจำกัดอยู่ในที่เดียว (localized) แต่กลับกระจัดกระจายไปทั่วหลายทีม นี่ไม่ใช่ไอเดียอันโด่งดังเรื่อง “ทีมขนาดสองถาดพิซซ่า” (two-pizza team) ของ Amazon ที่ฟีเจอร์สามารถสร้างขึ้นได้โดยทีมเดี่ยวๆ ที่เลี้ยงด้วยพิซซ่าแค่สองถาดก็อิ่ม
“เราคงต้องใช้พิซซ่าทั้งรถบรรทุกเลยล่ะกว่าจะส่งมอบฟีเจอร์นี้ได้” Maxine คิดในใจ ขณะเฝ้ามอง Tom วาดกล่องเพิ่มขึ้นเรื่อยๆ บนไวท์บอร์ด
Kurt โผล่หัวเข้ามาในห้องประชุม “เฮ้ ขอโทษที่ขัดจังหวะนะ มีคนจากฝ่าย Ops และผู้จัดการแอปจัดการการฝึกอบรมรออยู่ในสายประชุม (conference bridge) ตอนนี้ลูกค้าล็อกอินไม่ได้เลย พวกเขาบอกว่าตัวเชื่อมต่อ (connector) หยุดทำงานน่ะ”
“เอาอีกแล้วเหรอ” Tom กล่าว “ระบบยืนยันตัวตน (authentication) รวนมาตั้งแต่ตอน deploy Phoenix แล้ว พวกเราจะรีบจัดการให้ครับ...”
“รับทราบครับ” Kurt พูดพลางกดอะไรบางอย่างในโทรศัพท์ “ผมเพิ่งสร้างแชนเนลแชทสำหรับพวกเราทุกคนแล้วนะ โอเคไหม?”
Maxine ตาม Tom กลับไปที่โต๊ะทำงานของเขา ขณะที่ Tom เปิดหน้าต่างเบราว์เซอร์ใหม่และพิมพ์บางอย่างลงไป ข้อความแสดงข้อผิดพลาดในการล็อกอินก็ปรากฏขึ้นบนหน้าจอของเขา
“โอเค มีบางอย่างทำงานไม่ถูกต้องจริงๆ มาลองแยกแยะดูซิว่าเป็นเพราะอะไร...” Tom พึมพำ “ผมสงสัยว่ามันไม่ใช่ที่ Data Hub connector หรอก น่าจะเป็นที่บริการยืนยันตัวตนลูกค้าขององค์กร หรือไม่ก็ปัญหาที่เน็ตเวิร์กมากกว่า”
Maxine พยักหน้า จดบันทึกขณะที่จักรวาลของ Data Hub เริ่มปรากฏให้เห็นชัดเจนขึ้นเรื่อยๆ ด้วยความสงสัย เธอเสนอว่า “เราตัดเรื่องเน็ตเวิร์กกับ authentication ออกไปก่อนเลยได้ไหมคะ? ถ้าอันใดอันหนึ่งล่ม เราคงเข้าเว็บไซต์ไม่ได้เลย และถ้า authentication ล่ม ทุกบริการก็น่าจะเดี้ยงไปหมดแล้ว...”
“จริงด้วย...” Tom กล่าว “แต่ก็อาจจะเป็นเน็ตเวิร์กได้อยู่นะ... ช่วงนี้เราเจอปัญหาบ่อย สัปดาห์ก่อนพวกเน็ตเวิร์กเผลอไปบล็อก internal IP บางตัวจนทำให้เรามีปัญหา”
“เน็ตเวิร์ก มันมักจะเป็นพวกเน็ตเวิร์กเสมอเลยใช่ไหมคะ?” เธอพูดพลางยิ้ม “แต่ถ้ามันเป็นเพราะคนเน็ตเวิร์กตลอด แล้วทำไมเขาต้องโทรหาพวกเราด้วยล่ะคะ?” Maxine ถาม
เมื่อ Maxine เห็น Tom เปิดระบบจัดการ Ticket ของฝ่าย Ops และเริ่มสร้าง Ticket ใบใหม่ เธอจึงถามว่า “นั่นทำอะไรเหรอคะ?”
“เราต้องการดูไฟล์ล็อก (production logs) ของ Data Hub และตัวเชื่อมต่อต่างๆ เพื่อดูว่ามันยังจัดการทราฟฟิกอยู่หรือเปล่า หรือว่ามันแครชไปแล้ว” เขาตอบพลางกรอกข้อมูลในช่องต่างๆ มากมาย
“เราเข้าถึง production logs โดยตรงไม่ได้เหรอคะ?” Maxine ถามด้วยความเกรงกลัวในคำตอบ
“ไม่ได้ครับ พวก Ops ไม่ยอม” เขากล่าวพลางพิมพ์ลงในฟอร์ม
“งั้นก็ต้องมีใครสักคนมาตอบ Ticket แล้วก๊อปปี้ล็อกไฟล์จากเซิร์ฟเวอร์มาให้เราเนี่ยนะ?” เธอถามอย่างไม่อยากจะเชื่อ
“ใช่ครับ” เขากล่าวยังคงพิมพ์ต่อไป เห็นได้ชัดว่าเขาฝึกฝนการกรอกฟอร์มนี้มาอย่างดี เขาใช้ปุ่ม tab สลับไปตามช่องต่างๆ พิมพ์ข้อมูล ใช้เมาส์คลิกเลือกจาก drop-down box กดปุ่ม submit เพียงเพื่อจะพบว่ายังมีช่องที่จำเป็นต้องกรอกหลงเหลืออยู่อีกหนึ่งช่อง
Maxine ครางออกมา แอปพลิเคชัน Data Hub ที่พวกเขากำลังดูแลอยู่นี้ อาจจะเรียกได้ว่ามันรันอยู่ในอวกาศหรือที่ก้นบ่อน้ำลึกก็ได้ เพราะพวกเขาไม่สามารถเข้าถึงมันได้โดยตรง มองไม่เห็นว่ามันกำลังทำอะไรอยู่ และวิธีเดียวที่พวกเขาจะเข้าใจสิ่งที่เกิดขึ้นจริงๆ ได้คือการคุยกับใครบางคนในแผนก Operations ผ่านระบบ Ticket
เธอสงสัยว่า Ticket ใบนี้จะถูกส่งไปหา Derek เพื่อนของเธอที่แผนก Helpdesk หรือเปล่า
ในที่สุด Tom ก็ส่ง Ticket ได้สำเร็จ เขากล่าวอย่างพอใจว่า “คราวนี้เราก็แค่รอ”
“ปกติใช้เวลานานแค่ไหนคะ?” Maxine ถาม
“สำหรับเหตุการณ์ระดับ Sev 2 น่ะเหรอครับ? ไม่แย่เท่าไหร่ครับ—เราน่าจะได้รับไฟล์ภายในครึ่งชั่วโมง แต่ถ้าไม่ใช่เรื่องระบบล่ม (outage) อาจจะใช้เวลาเป็นวันๆ เลยล่ะ” Tom กล่าว เขามองนาฬิกา “เราควรทำอะไรดีระหว่างรอนี้?”
แม้แต่ในทีม Data Hub เธอก็ยังหนีไม่พ้น "สถานที่รอคอย" (Waiting Place)
สี่ชั่วโมงต่อมา หลังจากตรวจสอบไฟล์ล็อกแล้ว พวกเขาก็ยืนยันได้ว่าปัญหาไม่ได้อยู่ที่ Data Hub สองชั่วโมงหลังจากนั้น ในที่สุดทุกคนก็เห็นพ้องต้องกัน เป็นอย่างที่ Tom สงสัย มันคือการเปลี่ยนแปลงเน็ตเวิร์กภายในที่เป็นสาเหตุของปัญหา
เกิดการกล่าวโทษกันอย่างดุเดือดอีกรอบระหว่างฝ่ายปฏิบัติการธุรกิจ (Business Operations), ฝ่ายการตลาด และภายในองค์กรเทคโนโลยี ในที่สุด Sarah ก็เข้ามาแทรกแซงและยืนกรานว่าต้องมีบทลงโทษที่รุนแรง
“เอาแล้วไง” Tom กล่าว พลางเฝ้ามองพร้อมกับ Maxine จากอีกฟากหนึ่งของโต๊ะ “เรื่องนี้ไม่จบสวยแน่”
จาก: Wes Davis (ผู้อำนวยการฝ่าย Distributed Operations)
ถึง: พนักงานไอทีทุกคน
วันที่: 19:50 น., 25 กันยายน
เรื่อง: การเปลี่ยนแปลงบุคลากร
ให้มีผลทันที Chad Stone ในฝ่ายวิศวกรรมเครือข่าย พ้นจากสภาพพนักงาน โปรดส่งอีเมลทั้งหมดไปที่ผู้จัดการของเขา Irene Cooper หรือส่งมาที่ผม
เพื่อเห็นแก่สิ่งศักดิ์สิทธิ์ทั้งหลาย ได้โปรดหยุดทำผิดพลาดเสียที เพื่อที่ผมจะได้ไม่ต้องมานั่งเขียนอีเมลโง่ๆ พวกนี้อีก (และถ้าพวกเขาไล่ผมออก ก็ส่งอีเมลไปหา Bill Palmer รองประธานฝ่าย IT Operations แทนแล้วกันครับ)
ขอบคุณครับ, Wes
ในที่สุด วันนี้ก็จบลงเสียที ซึ่งนั่นหมายความว่าถึงเวลาประชุมที่ Dockside Bar อีกครั้ง คราวนี้พวกเขาเชิญทีม Data Hub ทั้งทีมมาร่วมด้วย Maxine เห็นด้วยกับการเปิดกว้างให้ทุกคนเข้าร่วม มากกว่าที่จะเผลอทิ้งใครที่คู่ควรไป Tom และวิศวกรอีกสามคนมาร่วมงานด้วย Maxine ดีใจที่พวกเขามา หลังจากช่วงสองสามวันที่ผ่านมา เธออยากจะระดมสมองหาวิธีปรับปรุงประสิทธิภาพของนักพัฒนาในทีม Data Hub ให้ดีขึ้นอย่างก้าวกระโดด
เมื่อเห็นทุกคนกำลังสนุกสนานกัน Maxine สังเกตว่านี่คือกลุ่มคนที่มีความสุขที่ได้แฮงเอาท์ร่วมกัน Kurt ลุกขึ้นยืนและกล่าวทักทายกลุ่ม
“สวัสดีเพื่อนร่วมทีม Rebellion ใหม่ทุกคน! ขอแนะนำให้รู้จักกันหน่อยนะครับ” Kurt กล่าว เขาแนะนำสมาชิก Rebellion ทุกคน เหมือนที่เคยทำกับ Maxine และ Kirsten “และถ้าพวกคุณไม่ว่าอะไร หลังจากที่ได้ฟังเรื่องราวแสบๆ (subversive things) ที่เรากำลังทำเพื่อนำความสุขกลับมาให้วิศวกรที่ Parts Unlimited แล้ว พวกคุณลองเล่าอะไรที่จะช่วยให้ชีวิตพวกคุณง่ายขึ้นหน่อยไหมครับ?”
เพื่อนร่วมงานสองคนของ Tom เริ่มก่อน โดยแนะนำตัวเองและเล่าภูมิหลังของพวกเขา คนหนึ่งอยู่ทีม Data Hub มาเกือบสิบปีเหมือน Tom แต่เขาไม่ได้มีอะไรจะบ่น โดยพูดแค่ว่า “ชีวิตก็โอเคครับ และขอบคุณสำหรับคำเชิญมาดื่มนะครับ”
เมื่อเห็นว่าเขาไม่มีอะไรจะพูดต่อแล้ว Tom จึงเริ่มบ้าง “เช่นเดียวกับเพื่อนร่วมงานของผม ผมอยู่ทีม Data Hub มานานมากแล้วครับ ตั้งแต่ตอนที่มันยังถูกเรียกว่า Octopus (ปลาหมึก) เราเรียกมันแบบนั้นเพราะวิธีที่มันเชื่อมต่อกับแอปพลิเคชันแปดตัว แต่ตอนนี้มันเชื่อมต่อกับแอปมากกว่าร้อยตัวแล้ว”
“ผมสนุกมากที่ได้ทำ pair-programming กับ Maxine และผมยังไม่อยากเชื่อเลยว่าเราแก้บั๊ก race condition ได้! ผมดีใจกับไอเดียของเธอเรื่องการทำ Data Hub Dev environments ให้พวกเราทุกคนได้ใช้” เขากล่าวต่อ “ผมไม่ได้ภูมิใจกับเรื่องนี้นะครับ แต่มีหลายครั้งที่เราจ้างนักพัฒนาใหม่เข้ามา แล้วผ่านไปหกเดือน พวกเขาก็ยังไม่สามารถรัน build ทั้งหมดบนเครื่องตัวเองได้” เขาส่ายหัว “มันไม่ได้เป็นแบบนี้มาตลอดหรอกครับ ตอนที่ผมเริ่มงานใหม่ๆ มันง่ายกว่านี้เยอะ แต่หลายปีที่ผ่านมา เราดันไปทำ hard-code ในสิ่งที่ไม่ควร อัปเดตตรงนั้นนิด ตรงนี้หน่อย โดยไม่เคยจดบันทึกมันไว้อย่างดี... และตอนนี้เหรอครับ? มันเละเทะไปหมดแล้ว”
เขาเงยหน้าขึ้นและยิ้มมุมปากให้เพื่อนร่วมทีมรอบโต๊ะ พลางพูดว่า “พวกคุณคงรู้จักมุกตลกของนักพัฒนาที่ว่า ‘มันรันได้บนเครื่องผมนะ’ (it worked on my laptop) ใช่ไหมครับ? แต่ใน Data Hub ของเราเนี่ย แม้แต่จะทำให้มันรันบนแล็ปท็อปของคนส่วนใหญ่ยังทำไม่ได้เลย”
ทุกคนหัวเราะ ไม่ว่าใครก็ตามที่เป็นนักพัฒนาต่างก็ต้องเคยเจอปัญหานี้มาแล้วทั้งนั้น และมันมักจะเกิดขึ้นในเวลาที่แย่ที่สุดเสมอ เช่น เมื่อมีบางอย่างแครชใน production แต่กลับรันได้อย่างสมบูรณ์แบบบนแล็ปท็อปของนักพัฒนา Maxine จำได้ว่านับครั้งไม่ถ้วนที่เธอต้องมานั่งวิเคราะห์อย่างละเอียดว่าแล็ปท็อปของนักพัฒนากับสภาพแวดล้อม production มันต่างกันตรงไหนกันแน่
“จุดที่ผมเจ็บปวดที่สุด (pain points) น่ะเหรอครับ?” Tom ครุ่นคิด “มันคือ environment ของพวกเราครับ เมื่อก่อนเราเคยจัดการเรื่องนี้ได้ดี แต่พอถูกย้ายเข้ามาในโปรเจกต์ Phoenix พวกเขาก็บังคับให้เราใช้ environment จากทีมจัดการ environment ส่วนกลางของพวกเขา”
“มันบ้ามากครับ พวกเราตัวเล็กจิ๋วเมื่อเทียบกับส่วนที่เหลือของ Phoenix แต่การจะรัน Data Hub ในตอนนี้ เราต้องติดตั้ง dependencies ที่ไม่เกี่ยวข้องเลยเป็นกิกะไบต์” เขากล่าวต่อ “มันใช้เวลานานมากในการหาทางทำให้ทุกอย่างรันได้ และมันง่ายมากที่จะเผลอทำบางอย่างพัง ไม่ได้พูดเล่นนะครับ ผมสำรองข้อมูล (back up) แล็ปท็อปทำงานของผมทุกวัน เพราะผมกลัวมากว่า build ของผมจะรันไม่ได้ขึ้นมา แล้วผมต้องเสียเวลาเป็นอาทิตย์เพื่อหาวิธีแก้มัน”
Tom หัวเราะ “สิบปีก่อน ผมทำไฟล์คอนฟิก emacs หายและหาไฟล์ที่เพิ่งสำรองไว้ไม่เจอ ผมไม่มีแรงใจพอจะสร้างมันขึ้นมาใหม่ สุดท้ายผมเลยยอมแพ้และเปลี่ยนไปใช้ editor ตัวอื่นแทน”
ทุกคนหัวเราะ พร้อมกับแชร์เรื่องราวความสูญเสีย ความเจ็บปวด และความเศร้าโศกจากการที่ต้องทิ้งเครื่องมือสุดรักสุดหวงของตัวเองไป
Tom หันมาหา Maxine “ผมอยากใช้เวลาสักสองสามวันศึกษาดูว่าเราจะสร้าง Dev environment ที่พวกเราทุกคนใช้ในงานประจำวันได้อย่างไร ถ้าเรามี virtual machine image หรือ Docker image สมาชิกใหม่ในทีมก็จะสามารถรัน build บนเครื่องไหนก็ได้ เมื่อไหร่ก็ได้ นั่นคงจะวิเศษมากครับ”
“เราสองคนต้องเข้ากันได้ดีแน่ๆ ค่ะ” Maxine พูดพลางยิ้ม “เราต้องการให้นักพัฒนาสามารถทุ่มเทพลังทั้งหมดไปกับการสร้างฟีเจอร์ ไม่ใช่ต้องมานั่งหาทางทำให้ build รันได้ ฉันเองก็มีแพสชันเรื่องนี้มากและยินดีที่จะให้คุณช่วยค่ะ”
“ยอดเยี่ยมมากครับ” Kurt กล่าว “พวกเราทุกคนรู้ว่า environment สำคัญแค่ไหน สำหรับตอนนี้ พวกคุณใช้เวลาครึ่งหนึ่งกับเรื่องนี้ได้เลยครับ เดี๋ยวผมจะหาทางซ่อนมันไว้ในระบบ timecard เอง”
ช่วงค่ำวันนั้น Kirsten มาถึงและรินเบียร์จากเหยือกบนโต๊ะให้ตัวเอง เธอถามพร้อมรอยยิ้มว่า “มีอะไรที่ฉันพลาดไปบ้างไหมคะ?”
“ก็แค่กำลังวางแผนโค่นล้มระเบียบอำนาจเดิมที่หลีกเลี่ยงไม่ได้น่ะครับ” Kurt กล่าว สมาชิกใหม่ของทีม Data Hub ต่างพากันจ้องมอง Kirsten ขณะที่เธอนั่งลง
Kurt ถามว่า “Kirsten ครับ โปรเจกต์ Inversion เป็นยังไงบ้าง? เรื่องแช่แข็งฟีเจอร์น่ะ ผมได้ยินว่า Bill Palmer กล่อม Steve ให้หยุดงานฟีเจอร์ทั้งหมดเพื่อให้ทุกคนได้ล้างหนี้ทางเทคนิคแล้ว”
“ยืนยันค่ะ” เธอกล่าว “Sarah Moulton กำลังสติแตก บ่นว่า ‘นักพัฒนาที่ว่างงานพวกนี้’ กำลังทำให้สัญญาที่บริษัทให้ไว้กับลูกค้าและ Wall Street ตกอยู่ในอันตราย ฉันยังไม่อยากเชื่อเลยว่าเธอไม่เข้าใจว่าเรื่องนี้จะช่วยเธอได้อย่างไร แต่โปรเจกต์ Inversion กำลังเกิดขึ้นแน่นอนค่ะ: เป็นเวลาสามสิบวันที่ฝ่าย Ops จะไม่ทำอะไรเลยนอกจากเรื่องที่จะช่วยสนับสนุน Phoenix”
“พวกนั้นไม่ได้ล้อเล่นนะครับ” Brent กล่าว “Bill สุดยอดมาก เขาบอกผมชัดเจนว่าให้ผมทำงานที่เกี่ยวกับ Phoenix เท่านั้น เขาเอาผมออกจากเวร pager สำหรับเกือบทุกอย่าง แถมยังเอาผมออกจาก mailing list ทุกอัน ให้ปิดการแจ้งเตือนจากห้องแชททุกห้อง และสั่งไม่ให้ผมรับสายโทรศัพท์จากใครทั้งนั้น และที่เด็ดที่สุดคือ เขาบอกว่าห้ามเสนอหน้าเข้าไปในสายแจ้งเหตุระบบขัดข้อง (outage calls) เด็ดขาด ถ้าผมทำ เขาจะไล่ผมออกครับ”
ได้ยินแบบนี้ Maxine ถึงกับช็อก Bill จะไล่ Brent ออกเนี่ยนะ? เมื่อนึกถึงทุกคนที่เพิ่งถูกไล่ออกไปช่วงนี้ Maxine ไม่เข้าใจเลยว่าทำไม Brent ถึงยังยิ้มได้
“มันวิเศษมากเลยครับ” Brent กล่าว แถมดูเหมือนเขาจะ... น้ำตาคลอ? “Bill บอกผมว่าเขาไล่ผู้บริหารหน่วยธุรกิจออกไม่ได้ หรือสั่งให้พวกเขาทำอะไรไม่ได้ สิ่งเดียวที่เขาทำได้คือทำให้แน่ใจว่าผมจะไม่เสียเวลากับเรื่องพวกนั้น เขาบอกให้ผมบอกใครก็ตามที่พยายามจะติดต่อผมว่า ผมจะถูกไล่ออกถ้าผมโทรกลับหาพวกเขา”
Brent หัวเราะ เห็นได้ชัดว่าเขากำลังมีความสุขสุดๆ เขาซดเบียร์จนหมดแก้วแล้วรินใหม่ “เขาให้ Wes คอยกรองอีเมลและสายโทรศัพท์ให้ผม และให้ Wes คอยตะเพิดใครก็ตามที่พยายามจะตามตัวผม ชีวิตตอนนี้มันยอดเยี่ยมมากครับ! จริงๆ นะ ไม่เคยดีกว่านี้มาก่อนเลย”
Maxine ยิ้ม เธอเคยเห็นมาหลายครั้งแล้วในอาชีพของเธอว่าวิศวกรสามารถกลายเป็นข้อจำกัด (constraint) ของระบบได้อย่างไร มันอาจจะดูสนุกที่ได้เป็นศูนย์กลางของทุกอย่าง แต่มันไม่ใช่สิ่งที่ยั่งยืนแน่นอน เส้นทางนั้นมีแต่การถูกปลุกกลางดึกเรื้อรัง ความเหนื่อยล้า การมองโลกในแง่ร้าย และการหมดไฟรออยู่
Kirsten ยิ้ม “มันได้ผลค่ะ ชื่อของ Brent ปรากฏอยู่ในรายการงานที่สำคัญ (critical action items) มากกว่าใครเพื่อน และ Bill ก็บอกกับทุกคนว่าเป้าหมายของพวกเขาคือต้องปกป้องเวลาของ Brent”
“ในฝั่ง Development Chris สัญญาว่าสำหรับทุกทีมที่ทำงานเกี่ยวกับโปรเจกต์ Phoenix จะไม่มีการทำฟีเจอร์ใหม่เป็นเวลาสามสิบวัน” Kirsten กล่าวพลางอ่านจากโทรศัพท์ “‘ทุกทีมต้องแก้ไข defect ที่มีความสำคัญสูง ทำให้ code base เสถียร และปรับปรุงสถาปัตยกรรม (rearchitecting) อะไรก็ตามที่จำเป็นเพื่อป้องกันไม่ให้เกิดหายนะในการปล่อยตัวครั้งหน้าอีก’”
Maxine ได้ยินเสียงพึมพำด้วยความตื่นเต้นจากรอบโต๊ะ Maxine รู้ว่าเรื่องแบบนี้แหละคือสิ่งที่จำเป็น—และนี่อาจเป็นโอกาสที่วิเศษสำหรับกลุ่ม Rebellion
“แต่ยังมีความเห็นไม่ตรงกันอย่างมากในหมู่ลูกน้องสายตรงของ Chris ว่าจะเริ่มใช้เรื่องนี้อย่างไร” Kirsten กล่าวต่อ “พวกเขาเสียเวลาไปมากกับการถกเถียงว่าควรหรือไม่ควรทำอะไร จนเราเสียเวลาไปหนึ่งสัปดาห์แล้ว—หลายทีมยังคงทำงานฟีเจอร์ของตัวเองตามปกติเหมือนไม่มีอะไรเกิดขึ้น เราต้องการความชัดเจนจากระดับผู้นำมากกว่านี้—ถ้าเป็นแบบนี้ต่อไป ทั้งเดือนก็จะผ่านไปโดยเปล่าประโยชน์ และเราจะมีหนี้ทางเทคนิคเท่าเดิม หรืออาจจะมากกว่าเดิมด้วยซ้ำ”
“ผมแปลกใจที่ไม่มีใครพูดถึงปัญหาที่พวกเขามีกับ environment หรือระบบทดสอบอัตโนมัติ หรือการขาดระบบตรวจวัดใน production (production telemetry) เลย” Kurt กล่าว “เราสร้างขีดความสามารถที่น่าทึ่งซึ่งคนอื่นก็นำไปใช้ได้เหมือนกัน แต่เราจะเป็นฝ่ายที่มีวิธีแก้ปัญหาแล้วเดินไปเสนอขายให้กับคนที่ไม่รู้ตัวว่าตัวเองมีปัญหาไม่ได้หรอกครับ”
Kurt ดูเหมือนจะจนปัญญาและหงุดหงิด
“ฉันอยากช่วยเรื่องนี้สุดๆ เลยค่ะ” Shannon กล่าวพร้อมยกมือขึ้น “ฉันเคยทำงานร่วมกับหลายทีมใน Phoenix เดี๋ยวพรุ่งนี้ฉันจะลองแวะไปหาแต่ละทีมเพื่อเริ่มถามพวกเขาว่าอะไรคือข้อจำกัดของพวกเขา และพวกเขามีไอเดียอะไรในการแก้ไขบ้าง”
“ดีครับ ดีมาก” Kurt กล่าวพลางจดบันทึกในสมุดของเขา
“ฉันก็อยากช่วยเหมือนกันค่ะ Shannon” Maxine กล่าว “แต่ฉันกับ Tom อาจจะยุ่งนิดหน่อยในวันจันทร์ เพราะวันจันทร์คือ ‘วันแห่งการทดสอบ’ (Testing Day) ในที่สุดฉันก็จะได้เอาสิ่งที่แก้ไปทดสอบกับพวก QA เสียที นอกเหนือจากนั้น ฉันพร้อมลุยเต็มที่ค่ะ!” ทันใดนั้นถาดเบียร์เหยือกใหม่และไวน์อีกสองแก้วก็ปรากฏขึ้นบนโต๊ะ
ในไม่ช้าพวกเขาก็เข้าสู่บทสนทนาที่ลึกซึ้งเรื่องหนี้ทางเทคนิค (technical debt) และไอเดียในการใช้ประโยชน์จากโปรเจกต์ Inversion Maxine หันไปเห็น Erik กำลังดึงเก้าอี้มานั่งข้างๆ เธอพอดี
เขาร่วมวงสนทนาราวกับว่าอยู่ที่นี่มาตั้งแต่ต้น “ด้วยโปรเจกต์ Inversion พวกคุณทุกคนกำลังเริ่มต้นการเดินทางที่ยิ่งใหญ่ ยักษ์ใหญ่ด้านเทคโนโลยีทุกรายเกือบจะถูกทำลายโดยหนี้ทางเทคนิคมาแล้วทั้งนั้น ไม่ว่าจะเป็น Facebook, Amazon, Netflix, Google, Microsoft, eBay, LinkedIn, Twitter และอื่นๆ อีกมากมาย เช่นเดียวกับโปรเจกต์ Phoenix พวกเขาติดหล่มหนี้ทางเทคนิคจนไม่สามารถส่งมอบสิ่งที่ลูกค้าต้องการได้อีกต่อไป” Erik กล่าว “ผลที่ตามมาอาจถึงขั้นหายนะ—และสำหรับผู้รอดชีวิตทุกคน ก็ยังมีบริษัทอย่าง Nokia ที่ร่วงหล่นจากจุดสูงสุดเพราะถูกหนี้ทางเทคนิคเล่นงาน”
“หนี้ทางเทคนิคคือความจริงของชีวิต เหมือนกับเส้นตาย (deadlines) นั่นแหละครับ คนฝั่งธุรกิจเข้าใจเรื่องเส้นตาย แต่บ่อยครั้งพวกเขามักไม่รู้เลยว่ามีหนี้ทางเทคนิคดำรงอยู่ หนี้ทางเทคนิคโดยเนื้อแท้แล้วไม่ใช่เรื่องดีหรือร้าย—มันเกิดขึ้นเพราะในงานประจำวัน เราต้องตัดสินใจเลือกสิ่งแลกเปลี่ยน (trade-off) อยู่เสมอ” เขากล่าว “เพื่อให้ทันกำหนดเวลา บางครั้งเราก็เลือกทางลัด หรือข้ามการเขียน automated tests หรือทำ hard-code สำหรับกรณีเฉพาะเจาะจงบางอย่าง ทั้งที่รู้ว่ามันจะใช้ไม่ได้ในระยะยาว บางครั้งเราก็ยอมทนกับวิธีการแก้ปัญหาเฉพาะหน้า (workarounds) ในแต่ละวัน เช่น การสร้าง environment ด้วยมือ หรือการทำ deployment แบบแมนนวล เราทำผิดพลาดอย่างมหันต์เมื่อเราไม่ตระหนักว่าสิ่งนี้ส่งผลกระทบต่อประสิทธิภาพการทำงานในอนาคตของเรามากแค่ไหน”
Erik มองไปรอบโต๊ะ เขารู้สึกพอใจที่เห็นทุกคนกำลังตั้งใจฟังสิ่งที่เขาพูดอย่างจดจ่อ
“ยักษ์ใหญ่ด้านเทคโนโลยีทั้งหมด ในช่วงใดช่วงหนึ่งของประวัติศาสตร์ เคยใช้การแช่แข็งฟีเจอร์เพื่อปรับปรุงสถาปัตยกรรม (rearchitect) ระบบของพวกเขาขนานใหญ่ ลองดู Microsoft ในช่วงต้นทศวรรษ 2000 สิครับ—นั่นคือช่วงที่เวิร์มคอมพิวเตอร์กำลังถล่มอินเทอร์เน็ตเป็นว่าเล่น ที่โด่งดังที่สุดคือ CodeRed, Nimda และแน่นอน SQL Slammer ซึ่งแพร่ระบาดและทำให้เซิร์ฟเวอร์เกือบ 100,000 เครื่องทั่วโลกแครชภายในเวลาไม่ถึงสิบนาที ซีอีโอ Bill Gates กังวลมากจนเขาเขียนบันทึกภายใน (memo) อันโด่งดังถึงพนักงานทุกคน โดยระบุว่าถ้านักพัฒนาต้องเลือกระหว่างการสร้างฟีเจอร์หรือการปรับปรุงความปลอดภัย พวกเขาต้องเลือกความปลอดภัย เพราะมันเดิมพันด้วยความอยู่รอดของบริษัท และนั่นคือนามเริ่มต้นของ ‘security stand-down’ อันโด่งดังที่ส่งผลกระทบต่อทุกผลิตภัณฑ์ของ Microsoft ที่น่าสนใจคือ Satya Nadella ซีอีโอคนปัจจุบันของ Microsoft ยังคงมีวัฒนธรรมที่ว่า ถ้านักพัฒนาต้องเลือกระหว่างการทำงานฟีเจอร์หรือประสิทธิภาพของนักพัฒนา (developer productivity) พวกเขาควรเลือกประสิทธิภาพของนักพัฒนาเสมอ”
“กลับไปที่ปี 2002—ในปีเดียวกันนั้น Jeff Bezos ซีอีโอของ Amazon ได้เขียนบันทึกอันโด่งดังถึงคนทำงานสายเทคโนโลยีทุกคน โดยระบุว่าพวกเขาต้องปรับปรุงสถาปัตยกรรมระบบใหม่เพื่อให้ข้อมูลและฟังก์ชันการทำงานทั้งหมดถูกจัดเตรียมผ่านบริการ (services) เท่านั้น จุดเริ่มต้นแรกของพวกเขาคือระบบ OBIDOS ซึ่งเดิมเขียนขึ้นในปี 1996 ซึ่งรวบรวมตรรกะทางธุรกิจ (business logic), ตรรกะการแสดงผล และฟังก์ชันการทำงานเกือบทั้งหมดที่ทำให้ Amazon.com โด่งดัง”
“แต่เมื่อเวลาผ่านไป มันกลับกลายเป็นสิ่งที่ complected เกินไปจนแต่ละทีมไม่สามารถทำงานอย่างอิสระได้ Amazon น่าจะใช้เงินไปมากกว่า 1 พันล้านดอลลาร์ตลอดหกปีในการปรับปรุงสถาปัตยกรรมบริการภายในทั้งหมดให้แยกขาดจากกัน (decoupled) ผลลัพธ์ที่ได้นั้นน่าทึ่งมาก ภายในปี 2013 พวกเขาสามารถทำ deployment ได้เกือบ 136,000 ครั้งต่อวัน น่าสนใจนะครับที่ซีอีโอที่ผมกล่าวมาทั้งหมดต่างก็มีพื้นฐานมาจากสายซอฟต์แวร์ ใช่ไหมครับ?”
“ลองเปรียบเทียบกับเรื่องราวที่น่าเศร้าของ Nokia ดูสิครับ เมื่อตลาดของพวกเขาถูก Apple และ Android เข้ามาดิสรัปต์ (disrupted) พวกเขาใช้เงินหลายร้อยล้านดอลลาร์ในการจ้างนักพัฒนาและลงทุนในการนำ Agile มาใช้ แต่พวกเขาทำไปโดยไม่รู้ตัวว่าปัญหาที่แท้จริงคืออะไร: หนี้ทางเทคนิคในรูปแบบของสถาปัตยกรรมที่นักพัฒนาไม่สามารถทำงานได้อย่างมีประสิทธิภาพ พวกเขาขาดความมุ่งมั่นที่จะสร้างรากฐานของระบบซอฟต์แวร์ขึ้นมาใหม่ เหมือนกับที่ Amazon ทำในปี 2002 ทุกทีมซอฟต์แวร์ที่ Nokia ไม่สามารถสร้างสิ่งที่พวกเขาต้องการได้เพราะพวกเขาถูกพันธนาการไว้ด้วยแพลตฟอร์ม Symbian”
“ในปี 2010 Risto Siilasmaa ซึ่งเป็นกรรมการบริษัทที่ Nokia เมื่อเขาได้รู้ว่าการรัน Symbian build หนึ่งครั้งต้องใช้เวลาถึงสี่สิบแปดชั่วโมง เขาบอกว่ามันรู้สึกเหมือนมีใครเอาค้อนปอนด์มาทุบที่หัวเขา” Erik กล่าว “เขารู้ว่าถ้าต้องใช้เวลาถึงสองวันกว่าที่ใครสักคนจะรู้ว่าการเปลี่ยนแปลงที่ทำลงไปนั้นใช้งานได้จริงหรือต้องทำใหม่ มันแสดงว่ามีข้อบกพร่องพื้นฐานที่ร้ายแรงในสถาปัตยกรรมของพวกเขา ซึ่งจะทำลายความสามารถในการทำกำไรในระยะสั้นและความอยู่รอดในระยะยาวของบริษัท พวกเขาอาจจะมีนักพัฒนามากกว่าเดิมยี่สิบเท่า แต่นั่นก็ไม่ได้ช่วยให้พวกเขาทำงานได้เร็วขึ้นเลย”
Erik หยุดไปครู่หนึ่ง “มันน่าเหลือเชื่อมากครับ Sensei Siilasmaa รู้ว่าความหวังและสัญญาในทั้งหมดที่องค์กรวิศวกรรมให้ไว้นั้นมันเป็นเพียงภาพลวงตา แม้ว่าจะมีความพยายามภายในมากมายที่จะย้ายออกจาก Symbian แต่มันก็มักถูกปัดตกโดยผู้บริหารระดับสูงเสมอ จนกระทั่งมันสายเกินไป”
“คนฝั่งธุรกิจมองเห็นฟีเจอร์หรือแอป ดังนั้นการของบประมาณเพื่อทำสิ่งเหล่านั้นจึงเป็นเรื่องง่าย” เขากล่าวต่อ “แต่พวกเขาไม่เห็นสถาปัตยกรรมมหาศาลที่อยู่ข้างใต้ที่คอยประคับประคองพวกมันไว้ เชื่อมต่อระบบ ทีม และข้อมูลเข้าด้วยกัน และภายใต้สิ่งนั้นคือสิ่งที่สำคัญอย่างยิ่งยวด: ระบบที่นักพัฒนาใช้ในงานประจำวันเพื่อให้พวกเขาทำงานได้อย่างมีประสิทธิภาพ”
“มันตลกดีนะครับ: ยักษ์ใหญ่ด้านเทคโนโลยีจะมอบหมายวิศวกรที่เก่งที่สุดให้ดูแลเลเยอร์ล่างสุดนั้น เพื่อให้นักพัฒนาทุกคนได้รับประโยชน์ แต่ที่ Parts Unlimited วิศวกรที่เก่งที่สุดจะทำงานฟีเจอร์ที่เลเยอร์บนสุด โดยแทบไม่มีใครนอกจากเด็กฝึกงานที่ทำงานเลเยอร์ล่างเพื่อช่วยเรื่องประสิทธิภาพของนักพัฒนาเลย”
Erik กล่าวต่อ “ดังนั้นภารกิจของพวกคุณชัดเจนแล้วครับ ทุกคนได้รับคำสั่งให้ล้างหนี้ทางเทคนิค ซึ่งจะช่วยให้พวกคุณบรรลุอุดมคติข้อแรกเรื่อง Locality และ Simplicity รวมถึงอุดมคติข้อที่สองเรื่อง Focus, Flow, and Joy แต่ที่แน่นอนที่สุดคือ พวกคุณต้องเชี่ยวชาญในอุดมคติข้อที่สามเรื่อง Improvement of Daily Work ให้ได้ครับ” จากนั้นเขาก็ลุกขึ้นและเดินจากไปอย่างรวดเร็วเหมือนตอนที่เขาเดินเข้ามา
ทุกคนเฝ้ามองเขาเดินจากไป จากนั้น Kirsten ก็ถามขึ้นว่า “เขาจะกลับมาอีกไหมคะ?”
Dave ขี้บ่นยกมือขึ้นกางในอากาศ “สิ่งที่เกิดขึ้นที่ Nokia กำลังเกิดขึ้นที่นี่ครับ เมื่อสองปีก่อน เราสามารถสร้างฟีเจอร์สำคัญๆ ได้ในเวลาสองถึงสี่สัปดาห์ และเราส่งมอบของเจ๋งๆ ออกไปได้เยอะมาก ผมจำวันเวลาเหล่านั้นได้! ถ้าคุณมีไอเดียดีๆ เราสามารถทำให้มันเกิดขึ้นจริงได้”
“แต่ตอนนี้ล่ะ? ฟีเจอร์ระดับเดียวกันนั้นต้องใช้เวลาถึงยี่สิบถึงสี่สิบสัปดาห์ นานขึ้นสิบเท่า! มิน่าล่ะทุกคนถึงได้โกรธแค้นพวกเรานัก” Dave ขี้บ่นตะโกนออกมา “เราจ้างวิศวกรเพิ่มขึ้น แต่ความรู้สึกเหมือนเราทำงานได้น้อยลงเรื่อยๆ และนอกจากจะช้าลงแล้ว การเปลี่ยนแปลงเหล่านั้นยังอันตรายสุดๆ อีกด้วย”
“เรื่องนี้สมเหตุสมผลค่ะ” Kirsten กล่าว “ไม่ว่าจะวัดด้วยเกณฑ์อะไร ประสิทธิภาพการทำงานก็นิ่งหรือลดลง ประสิทธิภาพการส่งมอบฟีเจอร์ตามกำหนดเวลาก็ลดลงอย่างมาก ฉันลองไปค้นข้อมูลมาตั้งแต่การประชุมครั้งที่แล้ว—ฉันให้ผู้จัดการโครงการลองสุ่มตรวจฟีเจอร์สองสามอย่างเพื่อดูว่าต้องใช้กี่ทีมในการสร้างพวกมันขึ้นมา ค่าเฉลี่ยคือ 4.2 ทีมค่ะ ซึ่งน่าตกใจมาก และพวกเขายังบอกอีกว่าหลายฟีเจอร์ต้องประสานงานกับทีมอื่นมากกว่าแปดทีมด้วยซ้ำ” เธอกล่าวต่อ “เราไม่เคยเก็บข้อมูลเรื่องนี้อย่างเป็นทางการ แต่คนของฉันส่วนใหญ่บอกว่าตัวเลขพวกนี้สูงกว่าเมื่อสองปีก่อนแน่นอนค่ะ”
Maxine ถึงกับอ้าปากค้าง ไม่มีทางที่ใครจะทำงานอะไรสำเร็จได้เลยถ้าต้องทำงานร่วมกับอีกแปดทีมอยู่ตลอดเวลา เธอตระหนักได้ เหมือนกับฟีเจอร์ขยายการรับประกันที่เธอเริ่มทำกับ Tom ไม่มีผิด
“เอาล่ะ โปรเจกต์ Inversion คือโอกาสของเราที่จะแก้ไขเรื่องพวกนี้และใช้ความรู้ทางวิศวกรรมหาทางออกไปให้ได้ครับ” Kurt กล่าว “Shannon จะไปหาคำตอบว่าทีม Phoenix ต้องการความช่วยเหลือเรื่องอะไรบ้าง แล้วพวกเราล่ะ? ถ้ามีใครให้อำนาจเรา และเรามีทรัพยากรไม่จำกัดเป็นเวลาหนึ่งเดือน เราจะทำอะไรกันดี?”
Maxine ยิ้มเมื่อได้ยินข้อเสนอต่างๆ พรั่งพรูออกมาอย่างรวดเร็วและดุเดือด พวกเขาเริ่มเขียนรายการสิ่งที่ต้องทำ: นักพัฒนาทุกคนต้องใช้สภาพแวดล้อมการ build ที่เหมือนกัน, นักพัฒนาทุกคนต้องมีระบบ continuous build และ integration คอยสนับสนุน, ทุกคนสามารถรันโค้ดในสภาพแวดล้อมที่เหมือน production ได้, สร้างชุดการทดสอบอัตโนมัติ (automated test scripts) มาแทนที่การทดสอบแบบแมนนวล เพื่อปลดปล่อยคน QA ให้ไปทำงานที่มีคุณค่ามากกว่า, ปรับสถาปัตยกรรมให้แยกส่วนกัน (decoupled) เพื่อให้ทีมฟีเจอร์ทำงานได้อย่างอิสระ, ข้อมูลทั้งหมดที่แต่ละทีมต้องการต้องถูกจัดไว้ในรูปแบบ API ที่ใช้งานง่าย...
Shannon กวาดสายตาดูรายการที่พวกเขาสร้างขึ้นพลางยิ้ม “เดี๋ยวฉันจะโพสต์รายการที่อัปเดตหลังจากสัมภาษณ์ทีมต่างๆ เสร็จพรุ่งนี้นะคะ น่าตื่นเต้นมากเลยค่ะ” เธอกล่าว “นี่แหละคือสิ่งที่นักพัฒนาต้องการ แม้ว่าพวกเขาจะอธิบายออกมาเป็นคำพูดไม่ได้ก็ตาม และนั่นคือสิ่งที่ฉันช่วยพวกเขาได้ค่ะ!”
มันเป็นรายการที่ยอดเยี่ยมมาก Maxine คิดในใจ ทุกคนต่างแสดงความกระตือรือร้นออกมาอย่างเห็นได้ชัด
“นั่นเป็นรายการที่ดีจริงๆ ครับ Shannon มันสามารถเปลี่ยนพลวัต (dynamics) ในวิธีการทำงานของวิศวกรได้อย่างมหาศาลเลย” Erik กล่าวพลางนั่งลงข้าง Kirsten อีกครั้ง Maxine มองไปรอบๆ พลางสงสัยว่าเขาโผล่มาจากไหน เขายังคงผายมือไปทาง Kirsten และพูดต่อว่า “แต่ลองพิจารณาถึงอุปสรรคที่ขวางหน้าพวกคุณดูสิครับ ฝ่าย Project Management ทั้งหมดตั้งเป้าที่จะทำให้โครงการเสร็จตามเวลาและอยู่ในงบประมาณ ทำตามกฎและบังคับใช้สัญญาที่เขียนไว้เมื่อนานมาแล้ว ลองดูการกระทำของลูกน้องสายตรงของ Chris สิครับ—ทั้งที่มีโปรเจกต์ Inversion แต่พวกเขาก็ยังก้มหน้าก้มตาทำงานฟีเจอร์ต่อไปเพราะกลัวว่าจะส่งงานไม่ทันตามกำหนด”
“ทำไมล่ะ? เมื่อศตวรรษก่อน ตอนที่การผลิตจำนวนมาก (mass production) ปฏิวัติวงการอุตสาหกรรม บทบาทของผู้นำคือการออกแบบและย่อยงานออกเป็นส่วนๆ และตรวจสอบว่ามันถูกดำเนินการอย่างถูกต้องโดยกองทัพคนงานที่ทดแทนกันได้ ซึ่งถูกจ้างมาเพื่อใช้แรงงาน ไม่ใช่ใช้สมอง งานถูกทำให้กลายเป็นหน่วยย่อย เป็นมาตรฐาน และถูกปรับปรุงให้มีประสิทธิภาพสูงสุด โดยที่คนงานแทบไม่มีความสามารถในการปรับปรุงระบบที่พวกเขาทำงานอยู่ได้เลย”
“ซึ่งมันแปลกดีใช่ไหมล่ะครับ?” Erik ครุ่นคิด “นวัตกรรมและการเรียนรู้เกิดขึ้นที่ขอบนอก (edges) ไม่ใช่ที่ส่วนกลาง ปัญหาต้องถูกแก้ไขที่หน้างาน ที่ที่งานประจำวันถูกดำเนินการโดยผู้เชี่ยวชาญระดับแนวหน้าของโลกที่ต้องเผชิญกับปัญหาเหล่านั้นบ่อยที่สุด”
“และนั่นคือเหตุผลที่อุดมคติข้อที่สามคือ Improvement of Daily Work (การปรับปรุงงานประจำวัน) มันคือพลวัตที่ช่วยให้เราเปลี่ยนแปลงและปรับปรุงวิธีการทำงานของเรา โดยอาศัยการเรียนรู้ ดังที่ Sensei Dr. Steven Spear ได้กล่าวไว้ว่า ‘ความไม่รู้นี่แหละคือมารดาของปัญหาทั้งปวง และสิ่งเดียวที่สามารถเอาชนะมันได้คือการเรียนรู้’”
“ตัวอย่างที่มีการศึกษามากที่สุดขององค์กรแห่งการเรียนรู้ (learning organization) คือ Toyota ครับ” เขากล่าวต่อ “สายดึงหยุดเครื่องจักร (Andon cord) อันโด่งดังเป็นเพียงหนึ่งในเครื่องมือมากมายที่ช่วยให้เกิดการเรียนรู้ เมื่อใครก็ตามพบปัญหา ทุกคนถูกคาดหวังให้ขอความช่วยเหลือได้ทุกเมื่อ แม้ว่านั่นจะหมายถึงการต้องหยุดสายพานการผลิตทั้งหมดก็ตาม และพวกเขาได้รับคำขอบคุณที่ทำเช่นนั้น เพราะมันคือโอกาสในการปรับปรุงงานประจำวัน”
“และด้วยเหตุนี้ ปัญหาจึงถูกมองเห็นได้อย่างรวดเร็ว ถูกรุมจัดการ และถูกแก้ไข จากนั้นบทเรียนเหล่านั้นก็จะถูกกระจายออกไปในวงกว้าง เพื่อให้ทุกคนได้รับประโยชน์” เขากล่าว “นี่คือสิ่งที่ช่วยให้เกิดนวัตกรรม ความเป็นเลิศ และการเรียนรู้ได้เร็วกว่าคู่แข่ง”
“สิ่งที่ตรงข้ามกับอุดมคติข้อที่สามคือคนที่ให้คุณค่ากับการปฏิบัติตามกระบวนการ (process compliance) และ TWWADI ครับ” เขาพูดพร้อมรอยยิ้มกว้าง “คุณก็รู้ใช่ไหม ‘The Way We’ve Always Done It’ (วิธีที่เราทำกันมาตลอด) มันคือกองตำรากฎระเบียบและข้อบังคับ กระบวนการและขั้นตอนการปฏิบัติ การอนุมัติและด่านตรวจ (stage gates) โดยมีการเพิ่มกฎใหม่ๆ เข้ามาตลอดเวลาเพื่อป้องกันไม่ให้หายนะครั้งล่าสุดเกิดขึ้นซ้ำอีก”
“พวกคุณอาจจะรู้จักพวกมันในรูปแบบของแผนโครงการที่เคร่งครัด กระบวนการจัดซื้อที่ยืดหยุ่นไม่ได้ คณะกรรมการตรวจสอบสถาปัตยกรรม (architecture review boards) ที่ทรงพลัง ตารางการปล่อยตัวที่ไม่บ่อยนัก กระบวนการอนุมัติที่ยืดเยื้อ การแยกหน้าที่ความรับผิดชอบอย่างเด็ดขาด...”
“แต่ละกฎที่เพิ่มเข้ามามีแต่จะเพิ่มต้นทุนในการประสานงาน (coordination cost) ให้กับทุกสิ่งที่เราทำ และทำให้ต้นทุนของความล่าช้า (cost of delay) พุ่งสูงขึ้น และเพราะระยะห่างระหว่างจุดที่มีการตัดสินใจกับจุดที่งานถูกดำเนินการนั้นกว้างขึ้นเรื่อยๆ คุณภาพของผลลัพธ์ที่ได้จึงลดลง ดังที่ Sensei W. Edwards Deming เคยสังเกตไว้ว่า ‘ระบบที่แย่จะเอาชนะคนดีๆ ได้เสมอครับ’”
“พวกคุณอาจต้องเปลี่ยนกฎเกณฑ์เก่าๆ ที่ไม่เหมาะสมอีกต่อไป เปลี่ยนวิธีจัดการคน และปรับสถาปัตยกรรมระบบใหม่” เขากล่าวต่อ “สำหรับผู้นำ มันไม่ได้หมายถึงการสั่งการและควบคุมอีกต่อไป แต่คือการชี้แนะ ส่งเสริม และขจัดอุปสรรค พลเอก Stanley McChrystal ได้กระจายอำนาจการตัดสินใจครั้งใหญ่ในหน่วยเฉพาะกิจปฏิบัติการพิเศษร่วม (Joint Special Operations Task Force) เพื่อเอาชนะกลุ่ม Al Qaeda ในอิรัก ซึ่งเป็นคู่ต่อสู้ที่เล็กกว่าแต่คล่องตัวกว่ามาก ที่นั่นต้นทุนของความล่าช้าไม่ได้วัดกันด้วยตัวเงิน แต่วัดกันด้วยชีวิตมนุษย์และความปลอดภัยของประชาชนที่พวกเขาได้รับมอบหมายให้ปกป้อง”
“นั่นไม่ใช่ภาวะผู้นำแบบรับใช้ (servant leadership) แต่มันคือภาวะผู้นำเพื่อการเปลี่ยนแปลง (transformational leadership) ครับ” Erik กล่าว “มันต้องอาศัยการเข้าใจวิสัยทัศน์ขององค์กร การกระตุ้นทางปัญญาเพื่อตั้งคำถามกับสมมติฐานพื้นฐานของวิธีการทำงาน การสื่อสารที่สร้างแรงบันดาลใจ การให้ความสำคัญกับตัวบุคคล และความเป็นผู้นำที่สนับสนุนทีม”
“บางคนคิดว่ามันเป็นเรื่องของการที่ผู้นำต้องทำตัวใจดี” Erik หัวเราะลั่น “ไร้สาระครับ มันเป็นเรื่องของความเป็นเลิศ การแสวงหาความสมบูรณ์แบบอย่างไม่หยุดยั้ง ความเร่งด่วนในการบรรลุภารกิจ ความไม่พอใจในสถานะที่เป็นอยู่ตลอดเวลา และความกระตือรือร้นที่จะช่วยเหลือผู้ที่องค์กรรับใช้ต่างหาก”
“ซึ่งนั่นนำเราไปสู่อุดมคติข้อที่สี่คือ Psychological Safety (ความปลอดภัยทางจิตวิทยา) จะไม่มีใครกล้ายอมรับความเสี่ยง ทดลอง หรือสร้างนวัตกรรมในวัฒนธรรมแห่งความกลัว ที่ที่ผู้คนกลัวที่จะบอกข่าวร้ายกับเจ้านาย” Erik กล่าวพลางหัวเราะ “ในองค์กรเหล่านั้น สิ่งใหม่ๆ จะถูกขัดขวาง และเมื่อเกิดปัญหาขึ้น พวกเขาจะถามว่า ‘ใครเป็นคนทำ?’ พวกเขาจะระบุชื่อ ตำหนิ และทำให้อับอาย พวกเขาจะสร้างกฎใหม่ เพิ่มการอนุมัติ ฝึกอบรมเพิ่ม และถ้าจำเป็น ก็จะกำจัด ‘แกะดำ’ ออกไป โดยหลอกตัวเองว่าพวกเขาได้แก้ปัญหาแล้ว” เขากล่าว
“อุดมคติข้อที่สี่เน้นย้ำว่าเราต้องการความปลอดภัยทางจิตวิทยา ที่ที่ใครก็สามารถพูดถึงปัญหาได้อย่างปลอดภัย นักวิจัยที่ Google ใช้เวลาหลายปีในโครงการ Project Oxygen และพบว่าความปลอดภัยทางจิตวิทยาเป็นหนึ่งในปัจจัยที่สำคัญที่สุดของทีมที่ยอดเยี่ยม: นั่นคือความมั่นใจว่าทีมจะไม่ทำให้อับอาย ปฏิเสธ หรือลงโทษใครก็ตามที่พูดความจริงออกมา”
“เมื่อมีอะไรผิดพลาด เราจะถามว่า ‘อะไรคือสาเหตุของปัญหา’ ไม่ใช่ถามว่า ‘ใคร’ เรามุ่งมั่นที่จะทำในสิ่งที่จำเป็นเพื่อให้วันพรุ่งนี้ดีกว่าวันนี้ ดังที่ Sensei John Allspaw กล่าวว่า ทุกอุบัติเหตุคือโอกาสในการเรียนรู้ มันคือการลงทุนที่ไม่ได้วางแผนไว้ซึ่งเกิดขึ้นโดยที่เราไม่ได้ยินยอม”
“ลองนึกภาพสถานการณ์นี้ดูนะครับ: คุณอยู่ในองค์กรที่ทุกคนสามารถตัดสินใจ แก้ปัญหาสำคัญๆ ได้ทุกวัน และสอนสิ่งที่พวกเขาได้เรียนรู้ให้กับคนอื่น” Erik กล่าว “คู่ต่อสู้ของคุณคือองค์กรที่เฉพาะผู้นำระดับสูงเท่านั้นที่มีสิทธิ์ตัดสินใจ ใครจะเป็นผู้ชนะ? ชัยชนะของพวกคุณนั้นหลีกเลี่ยงไม่ได้ครับ”
“มันง่ายมากสำหรับผู้นำที่จะพูดคำสวยหรูเกี่ยวกับการสร้างความปลอดภัยทางจิตวิทยา การมอบอำนาจและให้สิทธิ์ส่งเสียงแก่พนักงานหน้างาน” เขากล่าว “แต่แค่การพูดคำสวยหรูซ้ำๆ นั้นไม่พอ ผู้นำต้องคอยเป็นแบบอย่าง คอยโค้ช และคอยส่งเสริมพฤติกรรมที่พึงประสงค์เหล่านี้ในเชิงบวกทุกๆ วัน ความปลอดภัยทางจิตวิทยาหลุดลอยไปได้ง่ายมาก เช่น เมื่อผู้นำเริ่มจ้ำจี้จำไช (micromanage) ไม่กล้าพูดว่า ‘ผมไม่รู้’ หรือทำตัวเหมือนพวกอวดฉลาดที่คิดว่าตัวเองรู้ไปซะทุกเรื่อง และมันไม่ได้ขึ้นอยู่กับแค่ผู้นำเท่านั้นนะครับ มันยังขึ้นอยู่กับพฤติกรรมของเพื่อนร่วมงานด้วย”
บาร์เทนเดอร์คนหนึ่งเดินมาหา Erik และกระซิบที่ข้างหู Erik พึมพำว่า “อีกแล้วเหรอ?” เขาเงยหน้าขึ้นแล้วพูดว่า “เดี๋ยวผมมานะครับ มีบางอย่างที่ผมต้องไปจัดการ” แล้วเขาก็เดินหายไปพร้อมกับบาร์เทนเดอร์คนนั้น
พวกเขาจ้องมอง Erik เดินจากไป ในที่สุด Dwayne ก็พูดขึ้นว่า “เขาพูดถูกเรื่องอุดมคติข้อที่สามและสี่จริงๆ ครับ เราจะทำยังไงกับวัฒนธรรมแห่งความกลัวที่อยู่รอบตัวเราได้บ้าง? ดูสิ่งที่เกิดขึ้นกับ Chad สิครับ เขาพยายามทำสิ่งที่ถูกต้องแต่กลับถูกไล่ออก ผมน่าจะมีเหตุผลที่เกลียด Chad มากกว่าพวกคุณทุกคนซะอีก—ไอ้เรื่องเน็ตเวิร์กล่มตอนกลางวันที่เกิดขึ้นบ่อยๆ นั่นทำเอาผมแทบบ้า แต่การไล่ Chad ออกมันไม่ได้ช่วยให้อนาคตเน็ตเวิร์กจะไม่ล่มอีกเลยสักนิด”
“ผมลองไปสืบดูว่าเกิดอะไรขึ้นจริงๆ” Dwayne กล่าวต่อ “ดูเหมือนว่า Chad จะทำงานติดต่อกันสี่คืนรวด นอกเหนือจากงานปกติในตอนกลางวัน เพื่อสนับสนุนโครงการปรับปรุงร้านค้าให้ทันสมัย เมื่อผมถามเขาว่าทำไม เขาบอกผมว่าเขาไม่อยากให้ทีมหน้าร้านโดนตำหนิในรายงานสถานะเพราะเขาเป็นเหตุ”
Kirsten เลิกคิ้วขึ้น Dwayne พูดต่อ “ผู้จัดการของเขาพยายามไล่ให้เขากลับบ้าน ในที่สุดเขาก็ยอมกลับบ้านตรงเวลาในวันพุธ แต่เขาก็กลับมาออนไลน์ตอนเที่ยงคืนเพราะเขาไม่อยากให้ทีมเปิดตัวร้านค้าต้องผิดหวัง เขากังวลเรื่องงานที่สุมกองอยู่ใน Ticket และในห้องแชทมาก จนเขานอนไม่หลับมาหลายคืนแล้ว”
“ดังนั้นเขาจึงมาทำงานแต่เช้าวันพฤหัสบดี ทั้งที่ยังเหนื่อยล้าจากการอดนอนหลายคืน และเขาก็รับงานด่วนเรื่องการเปลี่ยนเน็ตเวิร์กภายในที่ต้องทำพอดี” เขากล่าว “เขาเปิดแล็ปท็อป มีหน้าต่างเทอร์มินัล (terminal windows) เปิดค้างอยู่ตั้งสามสิบหน้าต่างจากสารพัดงานที่เขาทำ เขาพิมพ์คำสั่งลงไปในหน้าต่างเทอร์มินัลแล้วกด enter และมันกลายเป็นว่าเขาพิมพ์ผิดหน้าต่างครับ”
“ตู้ม! ระบบธุรกิจระดับ Tier 2 ส่วนใหญ่เข้าใช้งานไม่ได้ทันที รวมถึง Data Hub ด้วย” เขากล่าว “วันรุ่งขึ้น เขาก็ถูกไล่ออก พวกคุณว่ามันถูกต้องไหมล่ะ? มันดูยุติธรรมและสมเหตุสมผลไหม?”
“โอ้มายก๊อด” Maxine โพล่งออกมาด้วยความตกใจ เธอรู้ซึ้งเลยว่าความรู้สึกนั้นเป็นอย่างไร เธอเคยทำพลาดแบบนั้นมาหลายครั้งในอาชีพของเธอ คุณพิมพ์อะไรบางอย่าง กด enter แล้วทันใดนั้นคุณก็ตระหนักว่าคุณทำพลาดครั้งใหญ่ไปแล้ว แต่มันก็สายเกินไป เธอเคยเผลอลบตารางฐานข้อมูลลูกค้า (customer database table) เพราะนึกว่าเป็นฐานข้อมูลทดสอบ เธอเคยเผลอรีบูตเซิร์ฟเวอร์ production ผิดเครื่อง จนทำให้ระบบป้อนคำสั่งซื้อล่มไปทั้งบ่าย เธอเคยลบโฟลเดอร์ผิด ปิดคลัสเตอร์เซิร์ฟเวอร์ผิด และปิดบัญชีล็อกอินผิดอันมาแล้ว
ทุกครั้งที่เกิดขึ้น เธอรู้สึกเหมือนเลือดในตัวกลายเป็นน้ำแข็ง ตามมาด้วยอาการตื่นตระหนก ครั้งหนึ่งในช่วงเริ่มทำงานใหม่ๆ เมื่อเธอเผลอลบที่เก็บซอร์สโค้ด (source control repository) ของระบบ production เธอถึงขั้นอยากจะมุดรูหนีไปใต้โต๊ะทำงานเลย เพราะระบบปฏิบัติการที่มันรันอยู่ เธอรู้ดีว่าคงไม่มีใครรู้ว่าเป็นฝีมือเธอ แต่ถึงแม้จะกลัวแค่ไหนที่จะต้องบอกใคร เธอก็ตัดสินใจบอกผู้จัดการของเธอ มันเป็นสิ่งที่น่ากลัวที่สุดอย่างหนึ่งที่เธอเคยทำในฐานะวิศวกรฝึกหัดเลยล่ะ
“มันแย่จริงๆ นะครับ Dwayne” Brent กล่าว “นั่นอาจจะเป็นผมก็ได้... จริงๆ นะ ทุกสัปดาห์ผมตกอยู่ในสถานการณ์ที่ผมอาจจะทำพลาดแบบนั้นได้เหมือนกัน”
เธอกล่าวว่า “มันอาจจะเป็นใครในพวกเราก็ได้ค่ะ ระบบของเราแถวนี้มันผูกมัดกันแน่นเกินไป (tightly coupled) แม้แต่การเปลี่ยนแปลงเล็กน้อยก็ส่งผลกระทบอย่างรุนแรงได้ และที่แย่กว่านั้นคือ Chad ไม่สามารถขอความช่วยเหลือได้ในตอนที่เขาต้องการจริงๆ ไม่มีใครทนทำงานติดต่อกันนานขนาดนั้นได้หรอกค่ะ ใครบ้างจะไม่เริ่มทำผิดพลาดถ้าแม้แต่เวลานอนยังไม่มี?”
“ใช่ครับ!” Dwayne อุทาน “เราปล่อยให้สถานการณ์มันกลายเป็นว่าคนคนหนึ่งทำงานหนักเกินไปจนต้องทำสี่คืนรวดได้ยังไงกัน? ความคาดหวังแบบไหนกันที่ถูกตั้งขึ้นจนคนคนหนึ่งไม่สามารถลางานได้เมื่อเขาต้องการ? และเรากำลังส่งข้อความอะไรออกไป เมื่อรางวัลของความทุ่มเทใส่ใจอย่างมากคือการถูกไล่ออก?”
“เป็นประเด็นที่ยอดเยี่ยมมากครับ Dwayne” Maxine ได้ยินเสียง Erik พูดขึ้น ขณะที่เขากลับมาร่วมโต๊ะอีกครั้ง “คุณจะแปลกใจว่าความรู้สึกถึงความไม่ยุติธรรมนี้ส่งผลกระทบต่อจิตใจของ Steve มากแค่ไหน ถ้าคุณเคยใช้เวลาทำงานในโรงงานผลิตบ้างคุณจะเข้าใจครับ”
“ยังไงเหรอคะ?” Maxine ถาม เธอเคยใช้เวลาทำงานร่วมกับพนักงานในโรงงานมามากพอสมควร
“คุณรู้ไหมครับว่าตอนที่ Steve เซ็นสัญญาเข้ามารับตำแหน่ง COO และรองประธานฝ่ายผลิต เขาตั้งเงื่อนไขว่าบริษัทต้องประกาศเป้าหมายต่อสาธารณะว่าจะลดอุบัติเหตุจากการทำงานให้เหลือศูนย์? ตอนนั้นเขาเกือบถูกหัวเราะเยาะจนไล่ออกจากห้องประชุม ไม่ใช่แค่โดยคณะกรรมการบริษัทเท่านั้นนะครับ แต่รวมถึงพนักงานในโรงงานและแม้แต่ผู้นำสหภาพแรงงานด้วย” Erik กล่าวพร้อมรอยยิ้ม “ผู้คนคิดว่าเขาไร้เดียงสา หรือไม่ก็อาจจะเพี้ยนไปแล้ว เพราะ ‘ผู้นำธุรกิจตัวจริง’ ควรจะถูกวัดผลด้วยกำไรหรือความสามารถในการส่งมอบงานตามกำหนด หรืออาจจะเป็นเรื่องคุณภาพ แต่เรื่องความปลอดภัยเนี่ยนะ?”
“มีข่าวลือว่า Steve บอกกับ Bob Strauss ซึ่งเป็นซีอีโอในขณะนั้นว่า ‘ถ้าคุณไม่สามารถทำให้พนักงานในโรงงานทำงานโดยไม่บาดเจ็บได้ แล้วทำไมคุณถึงควรเชื่อสิ่งที่เราพูดเกี่ยวกับเป้าหมายด้านคุณภาพ? หรือความสามารถในการทำเงินให้คุณล่ะ? ความปลอดภัยคือเงื่อนไขเบื้องต้นของการทำงานครับ’”
Erik หยุดไปครู่หนึ่ง “แม้แต่ในยุคที่อ้างว่าเจริญแล้วแบบนี้ ผู้นำก็น้อยคนนักที่จะพูดแบบนั้น Steve ได้ศึกษาผลงานของ Sensei Paul O’Neill ซีอีโอระดับตำนานของ Alcoa ในช่วงทศวรรษ 80 และ 90 อย่างใกล้ชิด ผู้ซึ่งให้ความสำคัญกับความปลอดภัยในที่ทำงานเหนือสิ่งอื่นใด คณะกรรมการบริษัทของเขาในตอนแรกคิดว่าเขาบ้าไปแล้ว แต่ในช่วงสิบห้าปีที่เขาดำรงตำแหน่งซีอีโอ รายได้สุทธิเพิ่มขึ้นจาก 200 ล้านดอลลาร์เป็น 1.5 พันล้านดอลลาร์ และมูลค่าตลาดของ Alcoa ก็พุ่งจาก 3 พันล้านดอลลาร์เป็น 2.7 หมื่นล้านดอลลาร์ครับ”
“แม้จะมีผลประกอบการทางเศรษฐกิจที่น่าทึ่งขนาดนั้น” Erik กล่าวต่อ “แต่สิ่งที่ Sensei O’Neill พูดถึงมากที่สุดคือมรดกเรื่องความปลอดภัยของเขา เป็นเวลาหลายทศวรรษที่ Alcoa ยังคงเป็นผู้นำที่ไม่มีใครโต้แย้งได้ในเรื่องความปลอดภัยในที่ทำงาน ตอนที่เขาเข้าร่วมงาน Alcoa ภูมิใจมากที่มีสถิติความปลอดภัยดีกว่าค่าเฉลี่ย แต่ด้วยอัตราการบาดเจ็บสองเปอร์เซ็นต์จากพนักงานทั้งหมด 90,000 คนในแต่ละปี นั่นหมายความว่าถ้าคุณทำงานที่ Alcoa ไปตลอดอาชีพการงาน คุณมีโอกาสถึงสี่สิบเปอร์เซ็นต์ที่จะได้รับบาดเจ็บจากการทำงาน”
“Alcoa มีสภาพการทำงานที่อันตรายกว่าในโรงงานผลิตของคุณมากนะครับ” เขากล่าว “ในธุรกิจอะลูมิเนียม คุณต้องรับมือกับความร้อนสูง ความดันสูง สารเคมีที่มีฤทธิ์กัดกร่อน ผลิตภัณฑ์สำเร็จรูปที่มีน้ำหนักหลายตันซึ่งต้องได้รับการขนส่งอย่างปลอดภัย...”
“Sensei O’Neill เคยกล่าวประโยคโด่งดังไว้ว่า ‘ทุกคนต้องรับผิดชอบต่อความปลอดภัยของตนเองและความปลอดภัยของเพื่อนร่วมทีม หากคุณเห็นสิ่งใดที่อาจทำอันตรายต่อใครบางคน คุณต้องแก้ไขให้เร็วที่สุด’ เขาบอกทุกคนว่าการแก้ไขปัญหาความปลอดภัยไม่ต้องรออนุมัติงบประมาณ—แค่แก้ซะ แล้วค่อยมาหาทางจ่ายเงินทีหลัง” Erik เล่าต่อ “เขาให้เบอร์โทรศัพท์บ้านของเขากับคนงานในโรงงานทุกคน บอกให้โทรหาเขาได้เลยถ้าเห็นว่าผู้จัดการโรงงานไม่ได้ดำเนินการเร็วพอหรือไม่จริงจังเรื่องความปลอดภัย”
“Sensei O’Neill เล่าเรื่องการเสียชีวิตในที่ทำงานครั้งแรกของเขา” Erik กล่าวต่อ “ในรัฐแอริโซนา เด็กหนุ่มอายุสิบแปดปีคนหนึ่งเสียชีวิต เขากระโดดเข้าไปในเครื่องรีด (extrusion machine) เพื่อพยายามกำจัดเศษวัสดุ แต่ในขณะที่เขาทำเช่นนั้น แกนบังคับ (boom) ก็หลุดออกมา ฟาดเขาและทำให้เขาเสียชีวิตทันที”
“เด็กหนุ่มคนนี้มีภรรยาที่กำลังตั้งครรภ์ได้หกเดือนครับ” Erik กล่าว “มีหัวหน้างานสองคนอยู่ที่นั่นด้วย Sensei O’Neill บอกว่า พวกเขายืนมองเด็กคนนั้นทำ และอาจจะเป็นคนสอนให้เด็กคนนั้นทำแบบนั้นด้วยซ้ำ”
“สุดท้ายแล้ว Sensei O’Neill ยืนขึ้นต่อหน้าพนักงานทั้งโรงงานและบอกกับทุกคนว่า ‘พวกเราฆ่าเขา พวกเราทุกคนฆ่าเขา ผมนี่แหละเป็นคนฆ่าเขา เพราะผมสื่อสารไม่ดีพอว่าทุกคนต้องไม่บาดเจ็บจากการทำงาน เราอาจจะเคยคิดไปเองว่ามันเป็นเรื่องปกติที่คนจะบาดเจ็บได้ แต่จากนี้ไป เราทุกคนต้องรับผิดชอบในการดูแลตัวเองและทุกคนให้ปลอดภัย’”
“ดังที่เขากล่าวในภายหลังว่า ‘พนักงาน Alcoa เป็นคนที่มีความเห็นอกเห็นใจกันมาก ทุกครั้งที่มีคนบาดเจ็บ พวกเขาจะโศกเศร้าและเสียใจอย่างมาก—แต่พวกเขาไม่เข้าใจว่าพวกเขาต้องรับผิดชอบด้วย มันกลายเป็นสภาวะที่ทุกคนถูกสอนให้ยอมรับความเจ็บปวดว่าเป็นเรื่องปกติไปแล้ว’”
Erik หยุดนิ่งเพื่อปาดน้ำตาออกจากตา “หนึ่งในการกระทำแรกๆ ของ Steve คือการนำ ‘True North’ (เข็มทิศนำทาง) ของ Sensei O’Neill เรื่องการบาดเจ็บในที่ทำงานต้องเป็นศูนย์ มาใช้ในทุกแง่มุมของการปฏิบัติงานโรงงานผลิตที่ Parts Unlimited สิ่งแรกที่เขาทำคือการตั้งนโยบายว่าอุบัติเหตุในที่ทำงานทุกครั้งต้องรายงานตรงต่อเขาภายในยี่สิบสี่ชั่วโมง พร้อมแผนการเยียวยาแก้ไข นี่คือตัวอย่างที่งดงามของอุดมคติข้อที่สามเรื่อง Improvement of Daily Work และอุดมคติข้อที่สี่เรื่อง Psychological Safety ครับ”
ขณะที่ Erik จ้องมองไปที่กำแพงอยู่ครู่หนึ่ง Maxine ก็ตระหนักได้ทันทีว่าทำไม Steve ถึงพูดเรื่องอุบัติเหตุในที่ทำงานในงาน Town Hall ทุกครั้ง เขารู้ดีว่าเขาไม่สามารถเข้าไปมีอิทธิพลต่องานประจำวันของทุกคนได้โดยตรง อย่างไรก็ตาม Steve สามารถตอกย้ำและเป็นแบบอย่างให้กับค่านิยมและบรรทัดฐานที่เขาต้องการได้ ซึ่งเขาทำมันได้อย่างมีประสิทธิภาพมากจริงๆ Maxine เพิ่งเข้าใจ
Maxine จ้องมองกลับไปที่ Erik เธอไม่เคยแม้แต่จะคุยกับ Steve เลยด้วยซ้ำ เธอจะทำตามที่ Erik แนะนำได้อย่างไรกัน？
จาก: Chris Allers (VP, R&D)
ถึง: พนักงาน Dev ทุกคน; Bill Palmer (VP, IT Operations)
วันที่: 23:10 น., 25 กันยายน
เรื่อง: โปรเจกต์ Inversion: การแช่แข็งฟีเจอร์ (feature freeze)
ให้มีผลทันที ในฐานะส่วนหนึ่งของโปรเจกต์ Inversion จะมีการแช่แข็งฟีเจอร์สำหรับโปรเจกต์ Phoenix เราจะทุ่มเทความพยายามอย่างเต็มที่ในช่วงสามสิบวันเพื่อเพิ่มความเสถียรและความเชื่อมั่นของ Phoenix รวมถึงระบบสนับสนุนทั้งหมด
เราจะระงับงานฟีเจอร์ทั้งหมดเพื่อแก้ไข defect และส่วนที่มีปัญหาของโค้ด รวมถึงล้างหนี้ทางเทคนิค การทำเช่นนี้จะช่วยให้เรามีประสิทธิภาพการพัฒนาที่สูงขึ้นและส่งมอบฟีเจอร์ได้เร็วขึ้นในอนาคต
ในช่วงเวลานี้ เราจะระงับการ deploy Phoenix ทั้งหมด ยกเว้นการเปลี่ยนแปลงที่จำเป็นเร่งด่วน และเพื่อนร่วมทีม Ops ของเราจะทำงานเพื่อทำให้การ deployment รวดเร็วและปลอดภัยยิ่งขึ้น รวมถึงเพิ่มความทนทานของบริการ production ของเราด้วย
เรามั่นใจว่าการทำเช่นนี้จะช่วยให้บริษัทบรรลุเป้าหมายเชิงกลยุทธ์ที่สำคัญที่สุด หากมีคำถามหรือข้อกังวลใดๆ โปรดอีเมลหาผม
ขอบคุณครับ, Chris
จาก: Alan Perez (Operating Partner, Wayne-Yokohama Equity Partners)
ถึง: Sarah Moulton (SVP of Retail Operations)
วันที่: 15:15 น., 27 กันยายน
เรื่อง: ทางเลือกเชิงกลยุทธ์ **ความลับ**
Sarah—นี่คือข้อมูลส่วนตัว...
การประชุมเมื่อวานนี้เป็นไปด้วยดีครับ ผมดีใจที่มีโอกาสแบ่งปันปรัชญาของผมในการสร้างมูลค่าให้ผู้ถือหุ้น—โดยทั่วไปแล้ว เราชอบ ‘มูลค่า’ (value) และระเบียบวินัยในการดำเนินงานมากกว่า ‘การเติบโต’ (growth) บริษัทของเราสร้างผลตอบแทนมหาศาลจากการลงทุนในบริษัทอย่าง Parts Unlimited แผนของผมจะสร้างกระแสเงินสดที่สม่ำเสมอและยอดเยี่ยม ในอัตราที่สูงกว่าที่คนส่วนใหญ่จะจินตนาการได้ สำหรับบริษัทอื่นๆ เราได้สร้างความมั่งคั่งมหาศาลให้กับนักลงทุน (รวมถึงผู้บริหารบริษัทด้วย)
ตามสัญญาครับ ผมขอแนะนำให้คุณรู้จักกับซีอีโอหลายคนในกลุ่มบริษัทที่เราลงทุนอยู่ซึ่งคุณอาจสนใจคุยด้วย โปรดถามพวกเขาดูว่าเราช่วยเพิ่มมูลค่าให้ผู้ถือหุ้นได้อย่างไรบ้าง
ด้วยความเคารพ, Alan
ปล. ผมเข้าใจถูกไหมว่าตอนนี้มีการ ‘แช่แข็งฟีเจอร์’ สำหรับ Phoenix? นั่นไม่ยิ่งทำให้คุณตามหลังไปอีกเหรอ? แล้วคราวนี้คุณจะทำยังไงกับบรรดานักพัฒนาใหม่ๆ ที่คุณเล่าให้ฟังครั้งก่อนล่ะ? และพวกเขาจะทำงานอะไรกัน?