แน่นอนครับ นี่คือคำแปลเนื้อหาจากภาษาอังกฤษเป็นภาษาไทย (ไทย) ตามที่ร้องขอ โดยคงรูปแบบ Markdown ไว้ทั้งหมด
เมื่อต้นปีนี้ ทีมงานของเราที่ 8090 ได้แยกชิ้นส่วนระบบคิดเงินขององค์กรขนาดใหญ่แห่งหนึ่ง มันเป็นโค้ด COBOL และ Assembly จำนวน 18 ล้านบรรทัด ที่ถูกสะสมมาตั้งแต่ก่อนที่วิศวกรบางคนของเราจะเกิดเสียอีก ไม่มีใครเข้าใจมันอย่างถ่องแท้อีกต่อไป แต่ด้วยการใช้ Software Factory ของเรา เราก็สามารถย้อนวิศวกรรมมันกลับมาเป็นกฎเกณฑ์ภาษาอังกฤษธรรมดากว่า 100,000 ข้อได้ภายใน 40 วัน เมื่อเสร็จงานนั้น ฉันก็ตระหนักได้ว่าทำไมถึงมีคนอื่นๆ ใช้คำว่า "software factory" กันอย่างกระทันหัน
แนวคิดนี้กำลังถูกนำไปใช้เพราะมันสื่อถึงความน่าเชื่อถือในระดับอุตสาหกรรมที่องค์กรธุรกิจต้องการแต่ไม่ได้รับ ซอฟต์แวร์แฟคทอรีมีประวัติศาสตร์ยาวนานกว่าห้าสิบปีเบื้องหลัง และคุณลักษณะเฉพาะที่โดดเด่นของมันคือสิ่งที่องค์กรต้องการมากกว่าที่เคย นั่นคือระบบการผลิตที่รับประกันผลลัพธ์ สิ่งนี้ตรงกันข้ามกับความหงุดหงิดที่เพิ่มขึ้นเกี่ยวกับชุดเครื่องมือที่แผ่ขยายออกไปซึ่งช่วยให้แต่ละบุคคลมีพลัง แต่กำลังทำให้ระบบทั้งหมดวุ่นวายมากขึ้น
คำนี้เก่ากว่าที่คนส่วนใหญ่คิด
ฮิตาชิเปิด "Software Works" ในปี 1969 ในฐานะโรงงานตามตัวอักษร นั่นคืออาคารที่ใช้ผลิตซอฟต์แวร์ภายใต้การควบคุมคุณภาพเชิงสถิติ โดยมีอัตราข้อบกพร่องวัดต่อพันบรรทัดของโค้ด มีกระบวนการที่ได้มาตรฐาน และทีมจัดการที่รับผิดชอบต่อคุณภาพของผลผลิต โตชิบา NEC และฟูจิตสึตามมา และตลอดช่วงทศวรรษ 1970 และ 1980 ซอฟต์แวร์แฟคทอรีของญี่ปุ่นเหล่านี้ได้ส่งมอบโค้ดที่เชื่อถือได้มากที่สุดเท่าที่เคยเขียนมา ระบบที่พวกเขาผลิตขับเคลื่อนโครงสร้างพื้นฐานด้านการธนาคาร การรถไฟ และพลังงานมานานหลายทศวรรษ
ในปี 2004 สถาปนิกของไมโครซอฟท์สองคนได้ตีพิมพ์หนังสือชื่อ "Software Factories" โดยโต้แย้งว่าซอฟต์แวร์ควรถูกสร้างขึ้นในแบบที่รถยนต์ถูกสร้างขึ้น นั่นคือจากส่วนประกอบที่ผ่านการพิสูจน์แล้ว บนสายการผลิตที่ทำซ้ำได้ โดยมีการเปลี่ยนแปลงที่ควบคุมโดยการออกแบบตั้งแต่ต้น แทนที่จะแก้ไขด้วยความพยายามอย่างกล้าหาญในภายหลัง กองทัพอากาศสหรัฐฯ ดำเนินการซอฟต์แวร์แฟคทอรีในปัจจุบัน Kessel Run สร้างและดำเนินการซอฟต์แวร์ภารกิจสำหรับกระทรวงกลาโหม และเมื่อซอฟต์แวร์นั้นเสีย พวกเขาก็รับผิดชอบมัน
ตลอดหกสิบปี สิ่งหนึ่งที่คงที่จนกระทั่งถึงคลื่น AI นี้ โรงงานไม่เคยเป็นแค่เครื่องมือหรือเคล็ดลับเพิ่มประสิทธิภาพ ไม่ว่ามันจะดีแค่ไหนก็ตาม โรงงานคือระบบการผลิตที่รับปัจจัยนำเข้า ผลิตสินค้าสำเร็จรูป และรับผิดชอบต่อคุณภาพของสินค้าเหล่านั้น พูดอีกอย่างคือ ฟอร์ดไม่เคยขายประแจ อะไหล่บางชิ้นให้คุณแล้วอวยพรให้โชคดี ฟอร์ดขายรถให้คุณ และถ้ารถเสีย ฟอร์ดเรียกคืนมัน เพราะมันเป็นโรงงานของพวกเขาที่ผลิตมันขึ้นมา
นั่นคือมาตรฐาน และฉันจะโต้แย้งว่าซอฟต์แวร์แฟคทอรีสมัยใหม่ต้องปฏิบัติตามมาตรฐานนั้นด้วย
การทดสอบห้าประการ
ซอฟต์แวร์แฟคทอรีควรผ่านการทดสอบห้าประการ พลาดข้อใดข้อหนึ่งแล้วคุณจะมีสิ่งอื่น สิ่งอื่นนั้นมีแนวโน้มสูงสุดว่าจะเป็นเครื่องมือสำหรับนักพัฒนา ซึ่งมีประโยชน์ได้ แต่มันเป็นผลิตภัณฑ์คนละประเภทที่มีภาระผูกพันต่างกัน
การทดสอบที่หนึ่ง: โรงงานเริ่มต้นจากความต้องการทางธุรกิจ ปัจจัยนำเข้าของโรงงานคือสิ่งที่ธุรกิจต้องการ ซึ่งแสดงออกในภาษาของธุรกิจ: ข้อกำหนด กฎเกณฑ์ ข้อจำกัดด้านกฎระเบียบ ผลลัพธ์ที่ต้องการ ถ้าปัจจัยนำเข้า กลับเป็น Jira ticket ที่เขียนโดยวิศวกรให้วิศวกรอีกคนอ่าน คุณกำลังมองหาเครื่องมือไฟฟ้าที่ถูกต่อเข้ากับกระบวนการที่มีอยู่ จุดรวมของโรงงานคือลูกค้าอธิบายผลิตภัณฑ์และโรงงานก็หาวิธีผลิตเอง
การทดสอบที่สอง: โรงงานรักษาความสอดคล้องภายใต้การเปลี่ยนแปลงอย่างต่อเนื่อง นี่คือการทดสอบที่ยากที่สุด และเป็นสิ่งที่แทบไม่มีใครในตลาดเครื่องมือ AI พูดถึง เพราะผลิตภัณฑ์ของพวกเขาทำให้มันแย่ลง
การเขียนโค้ดใหม่ไม่เคยเป็นคอขวดในซอฟต์แวร์องค์กร คอขวดคือระบบจริงๆ ถูกเปลี่ยนแปลงทุกสัปดาห์โดยคนหลายสิบคน ทุกการเปลี่ยนแปลงคือโอกาสที่ระบบจะแยกออกจากกัน ข้อกำหนดเบี่ยงเบนไปจากเอกสาร เอกสารเบี่ยงเบนไปจากโค้ด โค้ดเบี่ยงเบนไปจากการทดสอบ ให้เวลาเบี่ยงเบนนี้ทบต้นกันยี่สิบปี แล้วคุณจะได้ระบบคิดเงินที่ฉันอธิบายไว้ตอนต้น: 18 ล้านบรรทัดที่ไม่มีใครเข้าใจทั้งหมด สัญญาบำรุงรักษากับผู้ขายที่เพิ่มขึ้นปีละ 5 ถึง 8% และองค์กรที่ไม่สามารถเปลี่ยนแปลงซอฟต์แวร์ของตัวเองได้อีกต่อไปโดยไม่ต้องกลัว
ความจริงคือ การสร้างโค้ดเร่งให้เกิดการเบี่ยงเบน ถ้าเอเจนต์ของคุณผลิตโค้ดเพิ่มขึ้นสิบเท่าโดยเทียบกับข้อกำหนดที่ไม่ได้รับการซิงโครไนซ์ไว้ คุณกำลังสร้างการเบี่ยงเบนด้วยความเร็วที่ไม่เคยมีมาก่อน ปัญหา 18 ล้านบรรทัดใช้เวลาสี่ทศวรรษในการสร้างด้วยมือ แต่ฝูงเอเจนต์ที่ไม่มีธรรมาภิบาลจะสร้างสิ่งนี้ได้ภายในไม่กี่ปี
ซอฟต์แวร์แฟคทอรีที่ทำงานได้ดีจะรักษาความตั้งใจ ข้อกำหนด โค้ด การทดสอบ และพฤติกรรมในระบบผลิตให้ซิงโครไนซ์กันเป็นวัตถุที่ถูกควบคุมชิ้นเดียว เปลี่ยนข้อกำหนดแล้วโค้ดก็เปลี่ยน แก้ไขโค้ดด่วนแล้วข้อกำหนดก็อัปเดต ขอให้ผู้ขายแสดงให้คุณเห็นลูปนี้ที่ปิดได้แบบเรียลไทม์บนระบบจริง ถ้าพวกเขาทำไม่ได้ พวกเขากำลังขายการสร้างโค้ด และถึงแม้จะมีประโยชน์ แต่มันก็เป็นคนละสิ่งกัน
การทดสอบที่สาม: โรงงานทำงานโดยไม่พึ่งพาบุคคลใดบุคคลหนึ่งโดยเฉพาะ เครื่องมือจะดีได้ก็ต่อเมื่อคนที่ถือมันดีเท่านั้น ส่งเอเจนต์เขียนโค้ดตัวเดียวกันให้วิศวกรสองคน คุณจะได้ผลลัพธ์ที่แตกต่างกันอย่างสิ้นเชิง ขึ้นอยู่กับว่าใครเป็นคนเขียนพรอมต์ ใครเป็นคนตรวจสอบ diffs และใครเป็นคนจับข้อผิดพลาด ความแปรปรวนนั้นเป็นที่ยอมรับได้ในเครื่องมือ แต่มันเป็นสิ่งที่ทำให้ไม่มีคุณสมบัติในระบบการผลิต โรงงานควรผลิตด้วยความเร็วและคุณภาพที่คาดเดาได้ โดยไม่คำนึงว่าใครอยู่กะนั้น ซึ่งก็คือสิ่งที่การควบคุมเชิงสถิติของฮิตาชิถูกสร้างขึ้นเพื่อรับประกัน: คุณภาพเป็นสมบัติของสายการผลิต ไม่ใช่ผู้ปฏิบัติงาน
วิธีที่โรงงานบรรลุสิ่งนี้คือความรู้สะสมอยู่ในระบบแทนที่จะอยู่ในตัวบุคคล เมื่อมีคนมาใหม่ โรงงานจะส่งมอบทุกสิ่งที่ได้เรียนรู้ไปแล้วให้พวกเขา เมื่อมีคนจากไป ก็ไม่มีอะไรเดินออกไปนอกประตู ซอฟต์แวร์องค์กรส่วนใหญ่ล้มเหลวในการทดสอบนี้อย่างมหันต์ เหตุผลที่ระบบคิดเงินอ่านไม่เข้าใจไม่ใช่เพราะโค้ดไม่ดี แต่มันคือความเข้าใจเกี่ยวกับโค้ดนั้นอยู่ในตัวคน และตลอดหลายปีที่ผ่านมา คนก็เปลี่ยนไป ถ้าความรู้ของพวกเขาไม่เคยถูกบันทึกโดยระบบ ระบบจะค่อยๆ กลายเป็นกล่องดำ
เพื่อให้ชัดเจน นี่ไม่ได้หมายความว่าคนไม่สำคัญ หรือว่าโรงงานไม่ต้องการความรับผิดชอบ โรงงานมักจะมีใครสักคนที่รับผิดชอบผลลัพธ์เสมอ มันแค่ไม่เคยพึ่งพาใครคนใดคนหนึ่งว่าเป็นคนที่ขาดไม่ได้ ระบบที่ต้องการฮีโร่เพื่อทำงานนั้นไม่มีทั้งความรับผิดชอบและโรงงาน มันมีฮีโร่ และฮีโร่ก็มักจะไปผจญภัยใหม่ๆ ในที่สุด
การทดสอบที่สี่: ทุกหน่วยของผลผลิตสามารถสืบย้อนกลับได้ ในโรงงานจริง ทุกชิ้นส่วนมี "หมายเลขล็อต" เมื่อมีอะไรเสีย คุณจะสืบย้อนกลับไปผ่านสายการผลิตถึงชุดการผลิต เครื่องจักร และกะทำงาน อุตสาหกรรมที่มีการกำกับดูแลต้องการสิ่งนี้จากซอฟต์แวร์อย่างแม่นยำ และนั่นคือสาเหตุที่พวกเขาช้าที่สุดในการนำเครื่องมือเขียนโค้ด AI มาใช้ "โมเดลเขียนมันมา" ไม่ใช่คำตอบที่ผู้ตรวจสอบบัญชียอมรับ ซอฟต์แวร์แฟคทอรีสร้างร่องรอยการตรวจสอบเป็นผลพลอยได้จากการผลิต: กฎนี้มีอยู่เพราะ ข้อกำหนดนี้ ได้รับการอนุมัติโดย บุคคลนี้ ถูกนำไปใช้ใน การเปลี่ยนแปลงนี้ ตรวจสอบโดย การทดสอบนี้ ถูกปรับใช้ที่ เวลานี้ ที่มาที่ไปต้องถูกสร้างไว้ในสายการผลิต ซึ่งหมายความว่าเอกสารที่เขียนขึ้นภายหลังไม่มีผล
การทดสอบที่ห้า: มีคนรับผิดชอบต่อผลิตภัณฑ์สำเร็จรูป นี่คือการทดสอบที่แยกซอฟต์แวร์แฟคทอรีออกจากเครื่องมือนักพัฒนา เพราะมันเป็นสิ่งที่ผู้ขายเครื่องมือส่วนใหญ่ไม่เต็มใจที่จะทำให้สำเร็จ
โรงงานจัดส่งผลิตภัณฑ์ที่มันรับผิดชอบ เมื่อระบบคิดเงินคำนวณการเคลมผิดพลาด เมื่อระบบซื้อขายสร้างตัวเลขที่ผิด เมื่อการตรวจสอบการผลิตอนุมานชิ้นส่วนที่ไม่ดี มีใครสักคนที่รับผิดชอบมัน แก้ไขมัน และรับผิดชอบค่าใช้จ่าย ตอนนี้ฉันได้อ่านสัญญาเครื่องมือ AI มาเยอะแล้ว และส่วนทรัพย์สินทางปัญญากินเนื้อที่หลายหน้า แต่ส่วนความรับผิดชอบมักจะเป็นประโยคเดียว และประโยคนั้นบอกว่าผลลัพธ์ถูกจัดส่ง ตามสภาพและการตรวจสอบเป็นปัญหาของคุณ นี่ทำให้ไม่มีคุณสมบัติเป็นโรงงานโดยสิ้นเชิง
ลูกค้ารายหนึ่งของเรา ซึ่งเป็นบริษัทประกันสุขภาพที่ซื้อขายในตลาดหลักทรัพย์ ได้เปลี่ยนกฎการจ่ายเงินเคลมของมันให้เป็นตัวกรองล่วงหน้าที่แน่นอน และลดการเคลมที่ส่งต่อไปยังผู้ขายแบบจ่ายตามการจับผิดลงมากกว่า 80% ประหยัดเงินไปมากกว่า 20 ล้านดอลลาร์ในสี่ปี ตัวเลขแบบนั้นจะเกิดขึ้นได้ก็ต่อเมื่อฝ่ายที่ทำงานรับผิดชอบต่อผลลัพธ์
สิ่งที่ไม่ใช่โรงงาน
ลองใช้การทดสอบดู แล้วหลายคนที่เรียกตัวเองว่าโรงงาน แท้จริงแล้วคือสิ่งอื่น
เอเจนต์เขียนโค้ด ไม่ว่ามันจะดีแค่ไหน ก็คือเครื่องมือ พวกมันรับงานวิศวกรรมเป็นปัจจัยนำเข้า ผลิตโค้ดเป็นผลลัพธ์ และส่งต่อการตรวจสอบและความรับผิดชอบทั้งหมดให้กับวิศวกรของลูกค้า การเรียกฝูงพวกมันว่าโรงงานไม่ได้เปลี่ยนสิ่งนี้
แดชบอร์ดสำหรับจัดการเอเจนต์คือเครื่องมือกำกับดูแล พวกมันทำให้ดูเอเจนต์ทำงานได้ง่ายขึ้น
เบนช์มาร์กคือเครื่องมือวัดสำหรับเครื่องมือ คะแนนสูงบอกคุณได้ว่าเครื่องมือทำได้ดีในงานที่ถูกวัด มันไม่สามารถบอกคุณได้ว่าระบบของคุณยังคงสอดคล้องกันหรือไม่หลังจากสองปีของการเปลี่ยนแปลงอย่างต่อเนื่องโดยทีมผสมของมนุษย์และเอเจนต์
ทำไมคำจำกัดความถึงสำคัญในตอนนี้
ต้นทุนในการผลิตซอฟต์แวร์กำลังลดลงอย่างรวดเร็ว และเมื่อต้นทุนการผลิตลดลง มูลค่าจะย้ายไปยังใครก็ตามที่สามารถรับประกันผลลัพธ์ได้ สิ่งนี้เกิดขึ้นในทุกกระบวนการอุตสาหกรรมก่อนหน้านี้ และมันจะเกิดขึ้นอีกครั้งในตอนนี้กับ AI
สตาร์ทอัพที่คว้าคำว่า "factory" มาครอบครองเข้าใจสิ่งนี้โดยสัญชาตญาณ แต่หลายคนกำลังเอื้อมถึงความน่าเชื่อถือของการผลิตในภาคอุตสาหกรรม โดยไม่ยอมรับภาระผูกพันที่สร้างความน่าเชื่อถือนั้นตั้งแต่แรก
ดังนั้น จงไม่สนใจเดโมและเบนช์มาร์ก และถามทุกซอฟต์แวร์แฟคทอรีหนึ่งคำถาม: เมื่อระบบพังในระบบการผลิต ใครเป็นคนรับสาย?
ในกรณีของซอฟต์แวร์แฟคทอรี คำตอบต้องเป็น "เรารับผิดชอบเอง"
