Why Did the Tower of Babel Fail?

ทั่วทั้งโลกเคยใช้เพียงภาษาเดียวและมีถ้อยคำเพียงไม่กี่คำ ในโอกาสที่มีการอพยพมาจากทางทิศตะวันออก ผู้คนได้พบที่ราบในดินแดนชินาร์และตั้งถิ่นฐานอยู่ที่นั่น พวกเขาพูดกันว่า "มาเถอะ ให้เราทำอิฐและเผาให้สุกดี" พวกเขาจึงใช้อิฐแทนหิน และใช้ยางมะตอยแทนปูน จากนั้นพวกเขาพูดว่า "มาเถอะ ให้เราสร้างเมืองที่มีหอคอยซึ่งยอดสูงถึงสวรรค์สำหรับพวกเราเอง (เพื่อสร้างชื่อเสียงให้กับพวกเรา) เพื่อที่เราจะได้ไม่กระจัดกระจายไปทั่วทั้งโลก" จากนั้นพระเจ้าได้เสด็จลงมาทอดพระเนตรเมืองและหอคอยซึ่งมนุษย์ได้สร้างขึ้น พระเจ้าตรัสว่า "พวกเขาก็เป็นเพียงชนชาติเดียว และพวกเขาทั้งหมดมีภาษาเดียวกัน หากนี่คือสิ่งที่พวกเขาทำได้เป็นการเริ่มต้น เช่นนั้นแล้วจะไม่มีสิ่งใดที่พวกเขาตั้งใจทำที่เป็นไปไม่ได้สำหรับพวกเขา มาเถอะ ให้เราลงไปที่นั่นและทำให้ภาษาของเขายุ่งเหยียดจนพวกเขาไม่เข้าใจคำพูดของกันและกัน" ด้วยเหตุนี้พระเจ้าจึงทรงทำให้พวกเขากระจัดกระจายจากที่นั่นไปทั่วทั้งโลก จนพวกเขาต้องหยุดสร้างเมืองนั้น — ปฐมกาล 11:1-8 (GENESIS 11:1-8)

P. Breughel ผู้เป็นพ่อ, "Turmbau zu Babel," 1563 พิพิธภัณฑ์ Kunsthistorisches กรุงเวียนนา

A Management Audit of the Babel Project

ตามบันทึกในปฐมกาล หอคอยบาเบลคืองานวิศวกรรมชิ้นสำคัญชิ้นที่สองของมนุษย์ ต่อจากเรือของโนอาห์ บาเบลคือความล้มเหลวทางวิศวกรรมครั้งแรก เรื่องนี้มีความลึกซึ้งและให้บทเรียนในหลายระดับ อย่างไรก็ตาม ให้เราลองพิจารณามันในฐานะโครงการทางวิศวกรรมอย่างแท้จริง และดูว่ามีบทเรียนด้านการบริหารจัดการอะไรที่สามารถเรียนรู้ได้บ้าง โครงการของพวกเขามีความพร้อมสำหรับความสำเร็จเพียงใด? พวกเขามีสิ่งเหล่านี้หรือไม่:

  1. ภารกิจที่ชัดเจน? ใช่ แม้ว่าจะเป็นไปไม่ได้อย่างไร้เดียงสา โครงการล้มเหลวก่อนที่จะไปถึงขีดจำกัดพื้นฐานนั้นนานนัก
  2. กำลังคน? มีเหลือเฟือ
  3. วัสดุ? ดินเหนียวและยางมะตอยมีอยู่มากมายในเมโสโปเตเมีย
  4. เวลาที่เพียงพอ? ใช่ ไม่มีการกล่าวถึงข้อจำกัดเรื่องเวลาเลย
  5. เทคโนโลยีที่เหมาะสม? ใช่ โครงสร้างรูปพีระมิดหรือทรงกรวยมีความมั่นคงโดยธรรมชาติและกระจายแรงอัดได้ดี เห็นได้ชัดว่างานก่ออิฐนั้นเป็นที่เข้าใจกันดี โครงการล้มเหลวก่อนจะพบขีดจำกัดทางเทคโนโลยี

เอาล่ะ หากพวกเขามีสิ่งเหล่านี้ครบถ้วน แล้วทำไมโครงการถึงล้มเหลว? พวกเขาขาดอะไรไป? พวกเขาขาดในสองเรื่อง คือ การสื่อสาร และผลที่ตามมาคือ องค์กร พวกเขาไม่สามารถพูดคุยกันได้ ดังนั้นจึงไม่สามารถประสานงานกันได้ เมื่อการประสานงานล้มเหลว งานก็หยุดชะงัก เมื่ออ่านระหว่างบรรทัด เราจะเห็นว่าการขาดการสื่อสารนำไปสู่ข้อพิพาท ความรู้สึกแย่ๆ และความอิจฉาริษยาระหว่างกลุ่ม ในไม่ช้ากลุ่มต่างๆ ก็เริ่มแยกตัวออกจากกัน โดยเลือกที่จะอยู่อย่างสันโดษมากกว่าการทะเลาะเบาะแว้ง

Communication in the Large Programming Project

วันนี้ก็ยังเป็นเช่นนั้น หายนะของกำหนดการ ความไม่เข้ากันของคุณสมบัติการทำงาน และข้อผิดพลาดของระบบ (system bugs) ทั้งหมดเกิดขึ้นเพราะ "มือซ้ายไม่รู้ว่ามือขวาทำอะไร" ในขณะที่งานดำเนินไป ทีมต่างๆ ค่อยๆ เปลี่ยนแปลงหน้าที่การทำงาน ขนาด และความเร็วของโปรแกรมของตนเอง และพวกเขาเปลี่ยนสมมติฐานเกี่ยวกับอินพุตที่มีอยู่และการใช้งานเอาต์พุตอย่างชัดเจนหรือโดยนัย ตัวอย่างเช่น ผู้ลงมือทำฟังก์ชันการวางซ้อนโปรแกรม (program-overlaying function) อาจประสบปัญหาและลดความเร็วลง โดยอ้างอิงจากสถิติที่แสดงว่าฟังก์ชันนี้จะเกิดขึ้นได้ยากเพียงใดในโปรแกรมประยุกต์ ในขณะเดียวกัน เพื่อนบ้านของเขาอาจกำลังออกแบบส่วนสำคัญของตัวควบคุม (supervisor) โดยให้มันพึ่งพาความเร็วของฟังก์ชันนี้อย่างยิ่งยวด การเปลี่ยนแปลงความเร็วนี้ตัวมันเองกลายเป็นการเปลี่ยนแปลงข้อกำหนดครั้งใหญ่ และจำเป็นต้องได้รับการประกาศให้ทราบโดยทั่วกันและพิจารณาจากมุมมองของทั้งระบบ

ถ้าอย่างนั้น ทีมงานควรสื่อสารกันอย่างไร? ในหลายๆ วิธีเท่าที่จะเป็นไปได้:

  • อย่างไม่เป็นทางการ: บริการโทรศัพท์ที่ดีและการนิยามความสัมพันธ์ระหว่างกลุ่มที่ชัดเจนจะส่งเสริมให้เกิดการพูดคุยกันนับร้อยครั้ง ซึ่งการตีความเอกสารที่เป็นลายลักษณ์อักษรร่วมกันนั้นขึ้นอยู่กับการสื่อสารเหล่านี้
  • การประชุม: การประชุมโครงการตามปกติ โดยให้ทีมหนึ่งนำเสนอข้อมูลทางเทคนิคและทีมอื่นๆ รับฟัง มีคุณค่าอย่างยิ่ง ความเข้าใจผิดเล็กๆ น้อยๆ นับร้อยครั้งจะถูกกำจัดออกไปได้ด้วยวิธีนี้
  • สมุดงาน (Workbook): ต้องเริ่มทำสมุดงานของโครงการอย่างเป็นทางการตั้งแต่เริ่มต้น เรื่องนี้สมควรมีหัวข้อแยกต่างหากเป็นของตัวเอง

The Project Workbook

คืออะไร?: สมุดงานโครงการไม่ได้เป็นเพียงเอกสารที่แยกต่างหาก แต่เป็นโครงสร้างที่ถูกกำหนดให้กับเอกสารที่โครงการจะผลิตขึ้นอยู่แล้ว เอกสารทั้งหมดของโครงการจำเป็นต้องเป็นส่วนหนึ่งของโครงสร้างนี้ ซึ่งรวมถึง วัตถุประสงค์, ข้อกำหนดภายนอก (external specifications), ข้อกำหนดอินเทอร์เฟซ (interface specifications), มาตรฐานทางเทคนิค, ข้อกำหนดภายใน และบันทึกข้อความทางการบริหาร (administrative memoranda)

ทำไมต้องมี?: ร้อยแก้วทางเทคนิคนั้นแทบจะเป็นอมตะ หากใครตรวจสอบลำดับวงศ์ตระกูลของคู่มือสำหรับฮาร์ดแวร์หรือซอฟต์แวร์สักชิ้นหนึ่ง เขาจะสามารถติดตามไม่เพียงแต่ไอเดียเท่านั้น แต่ยังรวมถึงประโยคและย่อหน้าอีกมากมายย้อนกลับไปถึงบันทึกฉบับแรกที่เสนอผลิตภัณฑ์หรืออธิบายงานออกแบบชิ้นแรก สำหรับนักเขียนทางเทคนิค หม้อกาวนั้นมีพลังพอๆ กับปากกา ในเมื่อเป็นเช่นนี้ และในเมื่อคู่มือคุณภาพของผลิตภัณฑ์ในวันหน้าจะเติบโตมาจากบันทึกในวันนี้ จึงเป็นเรื่องสำคัญมากที่จะต้องสร้างโครงสร้างของเอกสารประกอบให้ถูกต้อง การออกแบบสมุดงานโครงการล่วงหน้าจะรับประกันว่าโครงสร้างของเอกสารประกอบนั้นถูกสร้างขึ้นอย่างประณีต ไม่ใช่ทำไปตามยถากรรม ยิ่งไปกว่านั้น การจัดตั้งโครงสร้างจะช่วยหล่อหลอมงานเขียนในภายหลังให้เป็นส่วนๆ ที่ลงตัวกับโครงสร้างนั้นพอดี

เหตุผลที่สองสำหรับสมุดงานโครงการคือการควบคุมการแจกจ่ายข้อมูล ปัญหาไม่ใช่การจำกัดข้อมูล แต่เป็นการรับประกันว่าข้อมูลที่เกี่ยวข้องจะไปถึงทุกคนที่จำเป็นต้องใช้ ขั้นตอนแรกคือการให้ลำดับหมายเลขแก่บันทึกข้อความทั้งหมด เพื่อให้สามารถจัดรายการชื่อเรื่องตามลำดับได้ และพนักงานแต่ละคนสามารถตรวจสอบได้ว่าเขามีสิ่งที่เขาต้องการครบถ้วนหรือไม่ การจัดองค์กรของสมุดงานนั้นไปไกลกว่านี้โดยการจัดตั้งโครงสร้างแบบต้นไม้ (tree-structure) ของบันทึกข้อความ โครงสร้างแบบต้นไม้ช่วยให้สามารถรักษาบัญชีรายชื่อผู้รับแจกจ่ายตามกิ่งก้านของต้นไม้ (subtree) ได้หากต้องการ

กลไก: เช่นเดียวกับปัญหาการบริหารจัดการการเขียนโปรแกรมอื่นๆ ปัญหาเรื่องบันทึกทางเทคนิคนั้นแย่ลงแบบไม่เป็นเส้นตรง (nonlinearly) เมื่อขนาดเพิ่มขึ้น เมื่อมี 10 คน เอกสารสามารถระบุตัวเลขง่ายๆ ได้ เมื่อมี 100 คน การเรียงลำดับแบบเชิงเส้นหลายลำดับมักจะเพียงพอ เมื่อมี 1,000 คน ซึ่งจะกระจัดกระจายไปตาม...

หลายสถานที่ทางกายภาพ ความต้องการสมุดงานที่มีโครงสร้างจึงเพิ่มขึ้น และขนาดของสมุดงานก็เพิ่มขึ้นด้วย ถ้าอย่างนั้นจะจัดการกลไกเหล่านี้อย่างไร?

ผมคิดว่าเรื่องนี้ทำได้ดีในโครงการ OS/360 ความต้องการสมุดงานที่มีโครงสร้างดีได้รับการผลักดันอย่างหนักจาก O. S. Locken ซึ่งเคยเห็นประสิทธิภาพของมันในโครงการก่อนหน้าของเขา คือระบบปฏิบัติการ 1410-7010 เราตัดสินใจอย่างรวดเร็วว่านักเขียนโปรแกรมแต่ละคนควรเห็นเนื้อหาทั้งหมด นั่นคือควรมีสำเนาสมุดงานในห้องทำงานของตนเอง

สิ่งที่สำคัญอย่างยิ่งคือการอัปเดตให้ทันเวลา สมุดงานจะต้องทันสมัยอยู่เสมอ ซึ่งเป็นเรื่องที่ยากมากหากเอกสารทั้งฉบับต้องถูกพิมพ์ใหม่เพื่อการเปลี่ยนแปลง อย่างไรก็ตาม ในสมุดแบบถอดเปลี่ยนหน้าได้ (looseleaf book) เฉพาะหน้าเท่านั้นที่ต้องเปลี่ยน เรามีระบบแก้ไขข้อความที่ขับเคลื่อนด้วยคอมพิวเตอร์ และสิ่งนี้ได้รับการพิสูจน์แล้วว่ามีค่าอย่างยิ่งสำหรับการบำรุงรักษาให้ทันเวลา ต้นฉบับออฟเซ็ต (offset masters) ถูกจัดเตรียมโดยตรงจากเครื่องพิมพ์คอมพิวเตอร์ และเวลาดำเนินการก็น้อยกว่าหนึ่งวัน

อย่างไรก็ตาม ผู้รับหน้ากระดาษที่อัปเดตเหล่านี้มีปัญหาในการรับรู้ข้อมูล เมื่อเขาได้รับหน้าที่เปลี่ยนแปลงเป็นครั้งแรก เขาต้องการทราบว่า "มีอะไรเปลี่ยนไปบ้าง?" เมื่อเขามาเปิดดูในภายหลัง เขาต้องการทราบว่า "นิยามในวันนี้คืออะไร?" ความต้องการประการหลังตอบสนองได้ด้วยเอกสารที่มีการบำรุงรักษาอย่างต่อเนื่อง ส่วนการเน้นจุดที่เปลี่ยนแปลงต้องใช้ขั้นตอนอื่น ประการแรก จะต้องทำเครื่องหมายที่ข้อความที่เปลี่ยนบนหน้ากระดาษ เช่น โดยใช้แถบแนวตั้งที่ขอบกระดาษข้างๆ บรรทัดที่มีการแก้ไข ประการที่สอง จำเป็นต้องแจกจ่ายบทสรุปการเปลี่ยนแปลงสั้นๆ ที่เขียนแยกต่างหากพร้อมกับหน้าใหม่ ซึ่งระบุรายการการเปลี่ยนแปลงและหมายเหตุถึงความสำคัญของพวกมัน

โครงการของเราดำเนินไปได้ไม่ถึงหกเดือนก่อนจะพบกับปัญหาอื่น คือสมุดงานมีความหนาประมาณห้าฟุต! หากเรานำสำเนา 100 ชุดที่แจกจ่ายให้นักเขียนโปรแกรมในสำนักงานของเราในตึก Time-Life ของแมนฮัตตันมาวางซ้อนกัน พวกมันจะสูงกว่าตัวตึกเองเสียอีก ยิ่งไปกว่านั้น การแจกจ่ายการเปลี่ยนแปลงรายวันเฉลี่ยอยู่ที่สองนิ้ว หรือประมาณ 150 หน้าที่จะต้องนำไปแทรกในเล่ม การบำรุงรักษาสมุดงานเริ่มกินเวลาส่วนสำคัญของแต่ละวันทำงาน ณ จุดนี้เราจึงเปลี่ยนมาใช้ไมโครฟิช (microfiche) ซึ่งเป็นการเปลี่ยนแปลงที่ช่วยประหยัดเงินได้ล้านดอลลาร์ แม้จะรวมค่าเครื่องอ่านไมโครฟิชสำหรับแต่ละห้องทำงานแล้วก็ตาม เราสามารถจัดเตรียมเวลาดำเนินการที่ยอดเยี่ยมในการผลิตไมโครฟิชได้ สมุดงานหดตัวจากสามลูกบาศก์ฟุตเหลือเพียงหนึ่งในหกของลูกบาศก์ฟุต และที่สำคัญที่สุดคือ การอัปเดตจะมาในรูปแบบแผ่นละร้อยหน้า ช่วยลดปัญหาการแทรกหน้ากระดาษลงไปได้ร้อยเท่า

ไมโครฟิชมีข้อเสียอยู่บ้าง จากมุมมองของผู้จัดการ การแทรกหน้ากระดาษที่ยุ่งยากช่วยรับประกันว่ามีการอ่านการเปลี่ยนแปลงที่เกิดขึ้น ซึ่งนั่นคือจุดประสงค์ของสมุดงาน ไมโครฟิชทำให้การบำรุงรักษาสมุดงานง่ายเกินไป เว้นแต่จะมีการแจกจ่ายฟิชที่อัปเดตพร้อมกับเอกสารกระดาษที่ระบุรายการการเปลี่ยนแปลง นอกจากนี้ ไมโครฟิชยังไม่สามารถเน้นข้อความ ทำเครื่องหมาย และเขียนความเห็นโดยผู้อ่านได้ง่ายนัก เอกสารที่ผู้อ่านได้มีปฏิสัมพันธ์ด้วยจะมีประสิทธิภาพมากกว่าสำหรับผู้เขียน และมีประโยชน์มากกว่าสำหรับผู้อ่าน

เมื่อชั่งน้ำหนักแล้ว ผมคิดว่าไมโครฟิชเป็นกลไกที่น่าพอใจมาก และผมจะแนะนำให้ใช้แทนสมุดงานแบบกระดาษสำหรับโครงการขนาดใหญ่มาก

ในปัจจุบันเราจะทำอย่างไร? ด้วยเทคโนโลยีระบบที่มีอยู่ในปัจจุบัน ผมคิดว่าเทคนิคที่ควรเลือกคือการเก็บสมุดงานไว้ในไฟล์ที่เข้าถึงได้โดยตรง (direct-access file) โดยทำเครื่องหมายแถบการเปลี่ยนแปลงและวันที่แก้ไขไว้ ผู้ใช้แต่ละคนจะเข้าถึงมันผ่านเทอร์มินัลแบบจอภาพ (เครื่องพิมพ์ดีดช้าเกินไป) บทสรุปการเปลี่ยนแปลงที่จัดทำขึ้นทุกวันจะถูกจัดเก็บแบบเข้าก่อนออกหลัง (LIFO) ที่จุดเข้าถึงที่กำหนดไว้ นักเขียนโปรแกรมมักจะอ่านข้อมูลนั้นทุกวัน แต่หากเขาพลาดไปหนึ่งวัน เขาก็แค่ต้องอ่านให้นานขึ้นในวันถัดไป ในขณะที่เขาอ่านบทสรุปการเปลี่ยนแปลง เขาสามารถหยุดพักเพื่อไปเปิดดูข้อความที่เปลี่ยนแปลงได้

สังเกตว่าสมุดงานนั้นไม่ได้เปลี่ยนแปลงอะไร มันยังคงเป็นการรวบรวมเอกสารประกอบของโครงการทั้งหมด ซึ่งมีโครงสร้างตามการออกแบบที่ระมัดระวัง สิ่งเดียวที่เปลี่ยนไปคือกลไกการแจกจ่ายและการเรียกดู D. C. Engelbart และเพื่อนร่วมงานที่สถาบันวิจัยสแตนฟอร์ดได้สร้างระบบดังกล่าวขึ้นและใช้มันเพื่อสร้างและบำรุงรักษาเอกสารประกอบสำหรับเครือข่าย ARPA

D. L. Parnas จากมหาวิทยาลัยคาร์เนกีเมลลอนได้เสนอวิธีที่รุนแรงยิ่งกว่านั้น วิทยานิพนธ์ของเขาคือ นักเขียนโปรแกรมจะมีประสิทธิภาพสูงสุดหากได้รับการปกป้องจากรายละเอียดการสร้างระบบในส่วนอื่นๆ นอกเหนือจากส่วนของตนเอง แทนที่จะเปิดรับข้อมูลเหล่านั้น สิ่งนี้สันนิษฐานว่าอินเทอร์เฟซทั้งหมดต้องได้รับการนิยามอย่างสมบูรณ์และแม่นยำ แม้ว่านั่นจะเป็นการออกแบบที่ถูกต้องอย่างแน่นอน แต่การพึ่งพาความสำเร็จที่สมบูรณ์แบบของมันคือสูตรสำเร็จของหายนะ ระบบข้อมูลที่ดีจะต้องทั้งเปิดเผยข้อผิดพลาดของอินเทอร์เฟซและกระตุ้นให้เกิดการแก้ไขพวกมัน

Organization in the Large Programming Project

หากมีพนักงาน $n$ คนในโครงการ จะมีอินเทอร์เฟซ $(n^2 - n) / 2$ ที่อาจต้องใช้ในการสื่อสาร และอาจมีทีมเกือบ $2^n$ ทีมที่จะต้องมีการประสานงานกัน จุดประสงค์ขององค์กรคือการลดปริมาณการสื่อสารและการประสานงานที่จำเป็น ดังนั้นองค์กรจึงเป็นการจัดการกับปัญหาการสื่อสารที่กล่าวถึงข้างต้นอย่างจริงจัง

วิธีการที่ใช้หลีกเลี่ยงการสื่อสารคือการแบ่งงาน (division of labor) และการทำหน้าที่เฉพาะทาง (specialization of function) โครงสร้างองค์กรแบบต้นไม้สะท้อนถึงความต้องการสื่อสารที่ลดน้อยลงเมื่อมีการประยุกต์ใช้การแบ่งงานและหน้าที่เฉพาะทาง ในความเป็นจริง องค์กรแบบต้นไม้เกิดขึ้นในฐานะโครงสร้างของอำนาจหน้าที่และความรับผิดชอบ หลักการที่ว่าคนเราไม่สามารถรับใช้เจ้านายสองคนได้กำหนดให้โครงสร้างอำนาจหน้าที่ต้องเป็นแบบต้นไม้

แต่โครงสร้างการสื่อสารนั้นไม่ได้ถูกจำกัดเช่นนั้น และโครงสร้างแบบต้นไม้นั้นเป็นเพียงการประมาณที่พอใช้ได้สำหรับโครงสร้างการสื่อสารซึ่งแท้จริงแล้วเป็นแบบโครงข่าย (network) ความไม่เพียงพอของการประมาณแบบต้นไม้นำไปสู่การเกิดกลุ่มเจ้าหน้าที่สนับสนุน (staff groups), หน่วยเฉพาะกิจ (task forces), คณะกรรมการ และแม้แต่การจัดองค์กรแบบเมทริกซ์ (matrix-type organization) ที่ใช้ในห้องปฏิบัติการทางวิศวกรรมหลายแห่ง

ให้เราลองพิจารณาองค์กรการเขียนโปรแกรมแบบต้นไม้ และตรวจสอบสิ่งจำเป็นที่กิ่งก้านของต้นไม้ (subtree) จะต้องมีเพื่อให้มีประสิทธิภาพ ซึ่งประกอบด้วย:

  1. ภารกิจ (mission)
  2. ผู้ผลิต (producer)
  3. ผู้อำนวยการด้านเทคนิคหรือสถาปนิก (technical director or architect)
  4. กำหนดการ (schedule)
  5. การแบ่งงาน (division of labor)
  6. คำจำกัดความของอินเทอร์เฟซระหว่างส่วนต่างๆ

สิ่งเหล่านี้ล้วนเป็นเรื่องที่เห็นได้ชัดและเป็นธรรมเนียมปฏิบัติ ยกเว้นการแยกแยะระหว่างผู้ผลิต (producer) และผู้อำนวยการด้านเทคนิค (technical director) ให้เราพิจารณาสองบทบาทนี้ก่อน จากนั้นจึงพิจารณาความสัมพันธ์ของพวกเขา

บทบาทของผู้ผลิตคืออะไร?: เขาเป็นคนรวบรวมทีม แบ่งงาน และกำหนดตารางเวลา เขาจัดหาและหมั่นแสวงหาทรัพยากรที่จำเป็นอยู่เสมอ ซึ่งหมายความว่าส่วนสำคัญของบทบาทของเขาคือการสื่อสารภายนอกทีม ทั้งในระดับบนและระดับข้าง เขาเป็นผู้กำหนดรูปแบบการสื่อสารและการรายงานผลภายในทีม และสุดท้าย เขาคือผู้รับประกันว่ากำหนดการจะเป็นไปตามเป้าหมาย โดยการสับเปลี่ยนทรัพยากรและองค์กรเพื่อตอบสนองต่อสถานการณ์ที่เปลี่ยนแปลงไป

แล้วผู้อำนวยการด้านเทคนิคล่ะ?: เขาเป็นผู้นิยามงานออกแบบที่จะสร้าง ระบุส่วนประกอบย่อย กำหนดว่างานจะมองจากภายนอกอย่างไร และร่างโครงสร้างภายในของมัน เขาเป็นผู้ให้ความเป็นหนึ่งเดียวกันและความสอดคล้องทางแนวคิด (conceptual integrity) แก่งานออกแบบทั้งหมด ดังนั้นเขาจึงทำหน้าที่เป็นผู้จำกัดความซับซ้อนของระบบ เมื่อมีปัญหาทางเทคนิคเกิดขึ้น เขาจะคิดค้นวิธีแก้ปัญหาหรือปรับเปลี่ยนงานออกแบบระบบตามความจำเป็น เขาคือ "คนภายในที่ทำงานลับ" (inside-man at the skunk works) การสื่อสารของเขาเน้นหนักไปที่ภายในทีม งานของเขาเป็นเรื่องทางเทคนิคเกือบทั้งหมด

ชัดเจนว่าพรสวรรค์ที่จำเป็นสำหรับสองบทบาทนี้แตกต่างกันค่อนข้างมาก พรสวรรค์มาในรูปแบบที่ผสมผสานกันได้หลากหลาย และการผสมผสานเฉพาะตัวที่อยู่ในตัวของผู้ผลิตและผู้อำนวยการจะต้องเป็นตัวกำหนดความสัมพันธ์ระหว่างพวกเขา องค์กรจะต้องถูกออกแบบตามบุคลากรที่มีอยู่ ไม่ใช่การนำคนไปใส่ในองค์กรตามทฤษฎีบริสุทธิ์ ความสัมพันธ์สามรูปแบบที่เป็นไปได้และพบได้ในทางปฏิบัติที่ประสบความสำเร็จคือ:

  1. ผู้ผลิตและผู้อำนวยการด้านเทคนิคเป็นคนคนเดียวกัน: วิธีนี้ใช้ได้ผลดีกับทีมขนาดเล็กมาก เช่น มีนักเขียนโปรแกรมสามถึงหกคน ในโครงการขนาดใหญ่ วิธีนี้แทบจะไม่ได้ผลด้วยเหตุผลสองประการ ประการแรก คนที่มีทั้งพรสวรรค์ด้านการบริหารจัดการที่แข็งแกร่งและพรสวรรค์ด้านเทคนิคที่แข็งแกร่งนั้นหาได้ยากมาก "นักคิด" นั้นหายาก "นักปฏิบัติ" นั้นหายากกว่า และ "นักคิดที่เป็นนักปฏิบัติด้วย" นั้นหายากที่สุด ประการที่สอง ในโครงการขนาดใหญ่ แต่ละบทบาทจำเป็นต้องเป็นงานเต็มเวลาหรือมากกว่านั้น เป็นเรื่องยากสำหรับผู้ผลิตที่จะมอบหมายหน้าที่ออกไปมากพอที่จะทำให้เขามีเวลาสำหรับเรื่องเทคนิค และเป็นไปไม่ได้ที่ผู้อำนวยการจะมอบหมายหน้าที่ของตนออกไปโดยไม่ส่งผลเสียต่อความสอดคล้องทางแนวคิดของงานออกแบบ

  2. ผู้ผลิตเป็นหัวหน้า โดยมีผู้อำนวยการเป็นมือขวา: ความยากของวิธีนี้คือการสร้างอำนาจหน้าที่ให้ผู้อำนวยการในการตัดสินใจด้านเทคนิคโดยไม่ไปกระทบต่อเวลาของเขาเหมือนกับการนำเขาไปใส่ไว้ในสายการบังคับบัญชาฝ่ายบริหาร ชัดเจนว่าผู้ผลิตจะต้องประกาศถึงอำนาจทางเทคนิคของผู้อำนวยการ และต้องสนับสนุนการตัดสินใจนั้นในกรณีทดสอบส่วนใหญ่ที่จะเกิดขึ้น เพื่อให้สิ่งนี้เป็นไปได้ ผู้ผลิตและผู้อำนวยการต้องมีมุมมองที่สอดคล้องกันในเรื่องปรัชญาทางเทคนิคพื้นฐาน พวกเขาต้องพูดคุยประเด็นทางเทคนิคหลักๆ เป็นการส่วนตัวก่อนที่มันจะกลายเป็นประเด็นที่ต้องตัดสินใจจริงๆ และผู้ผลิตต้องมีความเคารพอย่างสูงต่อความเชี่ยวชาญทางเทคนิคของผู้อำนวยการ นอกจากนี้ ผู้ผลิตสามารถใช้สิ่งต่างๆ ที่เป็นสัญลักษณ์ของสถานะ (ขนาดห้องทำงาน, พรม, เครื่องเรือน, สำเนาเอกสาร ฯลฯ) เพื่อประกาศว่าผู้อำนวยการนั้นมีอำนาจในการตัดสินใจ แม้จะอยู่นอกสายงานบริหาร วิธีนี้สามารถทำให้ได้ผลอย่างมีประสิทธิภาพมาก แต่น่าเสียดายที่แทบไม่มีใครทำ งานที่ผู้จัดการโครงการทำได้แย่ที่สุดคือการใช้ประโยชน์จากอัจฉริยะทางเทคนิคที่ไม่มีทักษะด้านการบริหารจัดการ

  3. ผู้อำนวยการเป็นหัวหน้า และมีผู้ผลิตเป็นมือขวา: Robert Heinlein ในหนังสือ The Man Who Sold the Moon ได้อธิบายถึงการจัดแจงเช่นนี้ไว้อย่างเห็นภาพ:

คอสเตอร์ซบหน้าลงกับฝ่ามือแล้วเงยหน้าขึ้น "ผมรู้ครับ ผมรู้ว่าต้องทำอะไร แต่ทุกครั้งที่ผมพยายามจะแก้ปัญหาทางเทคนิค ก็มักจะมีคนโง่เง่าบางคนอยากให้ผมตัดสินใจเรื่องรถบรรทุก หรือโทรศัพท์ หรือเรื่องบ้าบออะไรสักอย่าง ผมขอโทษครับคุณแฮร์ริแมน ผมคิดว่าผมจะทำได้"

แฮร์ริแมนกล่าวอย่างนุ่มนวล "อย่าปล่อยให้มันทำให้คุณไขว้เขวเลย บ็อบ ช่วงนี้คุณไม่ค่อยได้นอนเลยใช่ไหม? เอาอย่างนี้ เราจะจัดการเรื่องนี้ให้เร็วขึ้น ผมจะรับหน้าที่ดูแลโต๊ะทำงานของคุณสักสองสามวัน และจัดระบบเพื่อปกป้องคุณจากเรื่องพวกนี้ ผมต้องการให้สมองของคุณคิดเรื่องเวกเตอร์ของปฏิกิริยา ประสิทธิภาพของเชื้อเพลิง และแรงเค้นจากการออกแบบ ไม่ใช่เรื่องสัญญารถบรรทุก" แฮร์ริแมนก้าวไปที่ประตู มองไปที่สำนักงานด้านนอกและสังเกตเห็นชายคนหนึ่งที่น่าจะเป็นเสมียนอาวุโสของสำนักงาน "เฮ้ คุณ! มานี่หน่อย"

ชายคนนั้นดูตกใจ ลุกขึ้นเดินมาที่ประตูแล้วถามว่า "ครับ?"

"ผมต้องการให้ย้ายโต๊ะที่มุมนั้นและของทั้งหมดบนโต๊ะไปที่ห้องทำงานว่างๆ บนชั้นนี้ เดี๋ยวนี้เลย"

เขาควบคุมดูแลการย้ายคอสเตอร์และโต๊ะทำงานของเขาไปยังอีกห้องหนึ่ง ตรวจดูให้แน่ใจว่าโทรศัพท์ในห้องใหม่ถูกตัดสัญญาณ และเมื่อนึกขึ้นได้ เขาก็ให้ย้ายโซฟาเข้าไปในนั้นด้วย "เราจะติดตั้งเครื่องฉายภาพ เครื่องร่างแบบ ชั้นหนังสือ และของกระจุกกระจิกอื่นๆ ในคืนนี้" เขาบอกคอสเตอร์ "แค่ลิสต์รายการสิ่งที่คุณต้องการสำหรับการทำงานด้านวิศวกรรมมา" เขาเดินกลับไปที่ห้องทำงานของหัวหน้าวิศวกรและเริ่มทำงานอย่างมีความสุขเพื่อดูว่าสถานะขององค์กรเป็นอย่างไรและมีอะไรผิดปกติบ้าง

ประมาณสี่ชั่วโมงต่อมา เขาพาเบิร์กลีย์เข้าไปพบคอสเตอร์ หัวหน้าวิศวกรกำลังหลับอยู่ที่โต๊ะทำงานโดยซบศีรษะลงบนแขน แฮร์ริแมนเริ่มถอยออกมา แต่คอสเตอร์ตื่นขึ้น "โอ้! ขอโทษครับ" เขาพูดด้วยความเขินอาย "ผมเผลอหลับไป"

"นั่นคือเหตุผลที่ผมเอาโซฟามาให้คุณไง" แฮร์ริแมนกล่าว "มันพักผ่อนได้ดีกว่า บ็อบ นี่คือ จ็อก เบิร์กลีย์ เขาคือทาสคนใหม่ของคุณ คุณยังคงเป็นหัวหน้าวิศวกรและเป็นเจ้านายสูงสุดที่ไม่มีใครโต้แย้งได้ ส่วนจ็อกคือ 'เจ้ากรมทุกอย่างที่เหลือ' จากนี้ไปคุณไม่มีอะไรต้องกังวลเลย—ยกเว้นรายละเอียดเล็กๆ น้อยๆ เรื่องการสร้างยานไปดวงจันทร์"

พวกเขาเชคแฮนด์กัน "ผมขออย่างเดียวครับ คุณคอสเตอร์" เบิร์กลีย์กล่าวอย่างจริงจัง "คุณจะข้ามหัวผมไปทำอะไรก็ได้ตามต้องการ—คุณต้องเป็นคนคุมเรื่องทางเทคนิค—แต่ขอร้องล่ะ ช่วยบันทึกมันไว้ด้วยเพื่อที่ผมจะได้รู้ว่าเกิดอะไรขึ้น ผมจะติดตั้งสวิตช์ไว้ที่โต๊ะของคุณซึ่งจะเชื่อมต่อกับเครื่องบันทึกที่โต๊ะของผม"

"เยี่ยมเลย!" แฮร์ริแมนคิดว่าคอสเตอร์ดูเด็กลงไปแล้ว

"และถ้าคุณต้องการอะไรที่ไม่ใช่เรื่องเทคนิค อย่าทำด้วยตัวเอง แค่กดสวิตช์แล้วผิวปาก เดี๋ยวจัดการให้!" เบิร์กลีย์เหลือบมองแฮร์ริแมน "บอสบอกว่าเขาอยากคุยกับคุณเรื่องงานจริงๆ ผมจะปล่อยให้พวกคุณคุยกันแล้วไปลุยงานต่อละ" เขาเดินออกไป

แฮร์ริแมนนั่งลง คอสเตอร์นั่งตามแล้วอุทานว่า "เฮ้อ!"

"รู้สึกดีขึ้นไหม?"

"ผมชอบท่าทางของเบิร์กลีย์นะ"

"นั่นก็ดีแล้ว เขาจะเป็นเหมือนฝาแฝดของคุณนับจากนี้ไป เลิกกังวลได้เลย ผมเคยใช้งานเขามาก่อน คุณจะรู้สึกเหมือนได้อยู่ในโรงพยาบาลที่จัดการอย่างดีเลยล่ะ"

เรื่องราวนี้แทบไม่ต้องมีคำวิจารณ์เชิงวิเคราะห์เลย การจัดแจงเช่นนี้ก็สามารถทำให้ได้ผลอย่างมีประสิทธิภาพเช่นกัน ผมสงสัยว่าการจัดแจงแบบหลังนี้ดีที่สุดสำหรับทีมขนาดเล็ก ดังที่ได้อภิปรายไว้ในบทที่ 3 "ทีมผ่าตัด" (The Surgical Team) ผมคิดว่าการให้ผู้ผลิตเป็นหัวหน้าเป็นรูปแบบที่เหมาะสมกว่าสำหรับกิ่งก้านขนาดใหญ่ (larger subtrees) ของโครงการที่ใหญ่จริงๆ หอคอยบาเบลอาจเป็นความล้มเหลวทางวิศวกรรมครั้งแรก แต่มันไม่ใช่ครั้งสุดท้าย การสื่อสารและผลที่ตามมาคือ องค์กร เป็นสิ่งสำคัญต่อความสำเร็จ เทคนิคของการสื่อสารและองค์กรต้องการการขบคิดจากผู้จัดการและทักษะจากประสบการณ์ที่มากพอๆ กับเทคโนโลยีซอฟต์แวร์นั่นเอง