ในเวลานั้นทั้งโลกใช้ภาษาเดียวกัน มีคำพูดไม่กี่คำ ในการอพยพจากทิศตะวันออก ผู้คนได้พบที่ราบแห่งหนึ่งในแผ่นดินชินาร์ และตั้งถิ่นฐานอยู่ที่นั่น จากนั้นพวกเขาพูดกันว่า "มาเถิด ให้เราทำอิฐ เผามันให้ดี" ดังนั้นพวกเขาจึงใช้อิฐแทนหิน และใช้ยางมะตอยเป็นปูน แล้วพวกเขาก็พูดว่า "มาเถิด ให้เราสร้างเมืองและหอคอยให้ยอดขึ้นไปถึงฟ้าสวรรค์ (เพื่อสร้างชื่อเสียงให้แก่เรา) เพื่อเราจะได้ไม่ต้องกระจัดกระจายไปทั่วแผ่นดิน" แล้วพระเจ้าลงมาทอดพระเนตรเมืองและหอคอยที่มนุษย์ได้สร้างขึ้น พระเจ้าตรัสว่า "พวกเขาเป็นชนชาติเดียวกัน และมีภาษาเดียวกัน ถ้าพวกเขาทำได้อย่างนี้เป็นจุดเริ่มต้น แล้วอะไรที่พวกเขาตั้งใจจะทำก็จะไม่มีอะไร impossible สำหรับพวกเขา มาเถิด ให้เราลงไป ทำให้ภาษาของพวกเขาสับสนจนไม่เข้าใจกัน" ดังนั้นพระเจ้าจึงทำให้พวกเขากระจัดกระจายไปทั่วแผ่นดิน ทำให้พวกเขาต้องหยุดสร้างเมือง
— ปฐมกาล 11:1–8
A Management Audit of the Babel Project (การตรวจสอบการจัดการของโครงการบาเบล)
ตามบันทึกในปฐมกาล หอคอยบาเบลเป็นโครงการวิศวกรรมใหญ่ลำดับที่สองของมนุษยชาติ รองจากเรือของโนอาห์ บาเบลเป็นความล้มเหลวทางวิศวกรรมครั้งแรก
เรื่องราวนี้ลึกซึ้งและมีข้อคิดในหลายระดับ อย่างไรก็ตาม ขอให้เรามองมันในฐานะโครงการวิศวกรรมล้วนๆ และดูว่ามีบทเรียนด้าน management อะไรบ้างที่เราได้เรียนรู้ โครงการของพวกเขามีปัจจัยพื้นฐานของความสำเร็จครบถ้วนแค่ไหน? พวกเขามี:
1 . มี เป้าหมายที่ชัดเจน? มี แต่ถึงแม้จะ naïve และเป็นไปไม่ได้ โครงการล้มเหลวไปนานแล้วก่อนที่จะถึงข้อจำกัดพื้นฐานนี้
2 . กำลังคน? มีมากมาย
3 . วัสดุ? ดินเหนียวและยางมะตอยมีอยู่อย่างอุดมสมบูรณ์ในเมโสโปเตเมีย
4 . มี เวลา เพียงพอ? มี ไม่มีข้อบ่งชี้ถึงข้อจำกัดด้านเวลาแต่อย่างใด
5 . มี เทคโนโลยี ที่เพียงพอ? มี โครงสร้างแบบพีระมิดหรือทรงกรวยนั้น stable โดยธรรมชาติและกระจายน้ำหนัก compressive ได้ดี เห็นได้ชัดว่างานก่ออิฐเป็นที่เข้าใจอย่างถ่องแท้ โครงการล้มเหลวก่อนที่จะถึงข้อจำกัดทางเทคโนโลยี
ถ้าพวกเขามีทุกอย่างครบถ้วน ทำไมโครงการถึงล้มเหลว? พวกเขาขาดอะไร? สองอย่าง— การสื่อสาร และผลที่ตามมาคือ การจัดองค์กร พวกเขาไม่สามารถพูดคุยกันได้ จึงไม่สามารถประสานงานกันได้ เมื่อการประสานงานล้มเหลว งานก็หยุดชะงัก อ่านระหว่างบรรทัด เราพบว่าการขาดการสื่อสารนำไปสู่ข้อพิพาท ความรู้สึกไม่ดี และความอิจฉากันระหว่างกลุ่ม ไม่นานนัก แต่ละเผ่าก็เริ่มแยกย้ายกันไป เลือกที่จะแยกตัวมากกว่าทะเลาะกัน
Communication in the Large Programming Project (การสื่อสารในโครงการซอฟต์แวร์ขนาดใหญ่)
และในปัจจุบันก็เช่นกัน ภัยพิบัติด้านตารางเวลา ฟังก์ชันที่ไม่ตรงกัน และ bugs ในระบบ ล้วนเกิดขึ้นเพราะมือซ้ายไม่รู้ว่ามือขวาทำอะไรอยู่ เมื่องานดำเนินไป ทีมต่างๆ ก็ค่อยๆ เปลี่ยนฟังก์ชัน ขนาด และความเร็วของโปรแกรมของตัวเอง และไม่ว่าจะโดยชัดแจ้งหรือโดยนัย พวกเขาก็เปลี่ยนสมมติฐานเกี่ยวกับ input ที่มีอยู่และการนำ output ไปใช้
ตัวอย่างเช่น คนที่ implement ฟังก์ชัน program-overlaying อาจเจอปัญหาและลด speed ลง โดยอาศัยสถิติที่บอกว่าฟังก์ชันนี้ไม่ค่อยได้ถูกเรียกใช้ใน application programs ในขณะเดียวกัน เพื่อนร่วมงานอีกคนอาจกำลังออกแบบส่วนหลักของ supervisor ที่ต้องพึ่งพา speed ของฟังก์ชันนี้อย่างมาก การเปลี่ยนแปลง speed นี้กลายเป็น specification change ที่สำคัญ และจำเป็นต้องประกาศให้ทั่วถึงและประเมินจากมุมมองของทั้งระบบ
แล้วทีมจะสื่อสารกันได้อย่างไร? ให้ใช้ให้มากที่สุดเท่าที่จะทำได้
• แบบไม่เป็นทางการ. บริการโทรศัพท์ที่ดีและการกำหนดความสัมพันธ์ระหว่างทีมที่ชัดเจน จะช่วยส่งเสริมให้เกิดการโทรศัพท์นับร้อยครั้งซึ่งเป็นพื้นฐานของการตีความเอกสารที่เป็นลายลักษณ์อักษรให้ตรงกัน
• การประชุม. การประชุมโครงการอย่างสม่ำเสมอ โดยให้แต่ละทีมผลัดกันนำเสนอ technical briefings นั้นมีค่าอย่างยิ่ง ความเข้าใจผิดเล็กๆ น้อยๆ นับร้อยๆ เรื่องถูกขจัดออกไปด้วยวิธีนี้
• Workbook. ควรเริ่มจัดทำ project workbook อย่างเป็นทางการตั้งแต่ต้น ซึ่งสมควรมีหัวข้อแยกต่างหากสำหรับเรื่องนี้
The Project Workbook (Project Workbook)
What (คืออะไร). Project workbook ไม่ใช่เอกสารแยกต่างหาก แต่เป็นโครงสร้างที่วางบนเอกสารต่างๆ ที่โปรเจกต์จะต้องผลิตอยู่แล้ว
เอกสารทั้งหมด ของโครงการต้องเป็นส่วนหนึ่งของโครงสร้างนี้ ซึ่งรวมถึง objectives, external specifications, interface specifications, technical standards, internal specifications และ administrative memoranda
Why (ทำไม). งานเขียนเชิงเทคนิคนั้นแทบจะเป็นอมตะ ถ้าเราลองสืบ genealogy ของคู่มือลูกค้าสำหรับ hardware หรือ software สักชิ้น เราจะพบว่าไม่ใช่แค่แนวคิดเท่านั้น แต่รวมถึงประโยคและย่อหน้าจำนวนมากที่ย้อนกลับไปถึง memo ฉบับแรกที่เสนอผลิตภัณฑ์หรืออธิบายการออกแบบครั้งแรก สำหรับนักเขียนเทคนิคแล้ว กาวและปากกามีพลังไม่แพ้กัน
เมื่อเป็นเช่นนี้ และเมื่อคู่มือคุณภาพของผลิตภัณฑ์ในวันพรุ่งนี้จะเติบโตมาจาก memo ในวันนี้ การทำให้โครงสร้างของ documentation ถูกต้องตั้งแต่แรกจึงเป็นสิ่งสำคัญมาก การออกแบบ project workbook ตั้งแต่ช่วงแรกช่วยให้มั่นใจว่าโครงสร้างของ documentation ถูกสร้างขึ้นอย่างตั้งใจ ไม่ใช่แบบสุ่ม นอกจากนี้ การสร้างโครงสร้างยังช่วยหล่อหลอมงานเขียนในภายหลังให้เป็นส่วนที่สอดคล้องกับโครงสร้างนั้น
เหตุผลที่สองสำหรับ project workbook คือการควบคุมการกระจายข้อมูล ปัญหาไม่ใช่การจำกัดข้อมูล แต่คือการทำให้แน่ใจว่าข้อมูลที่เกี่ยวข้องไปถึงทุกคนที่ต้องการ
ขั้นตอนแรกคือการกำหนดหมายเลข memo ทั้งหมด เพื่อให้มีรายการหัวเรื่องที่เรียงลำดับ และพนักงานแต่ละคนสามารถดูได้ว่าตนมีสิ่งที่ต้องการหรือไม่ การจัดระเบียบของ workbook ไปไกลกว่านั้น โดยสร้าง tree-structure ของ memo ซึ่ง tree-structure นี้ช่วยให้สามารถดูแล distribution lists เป็น subtree ได้ ถ้าต้องการ
Mechanics (กลไก). เช่นเดียวกับปัญหาการจัดการโปรแกรมอื่นๆ ปัญหา technical memorandum จะแย่ลงแบบ nonlinear เมื่อขนาดใหญ่ขึ้น ถ้ามี 10 คน เอกสารก็แค่กำหนดหมายเลขก็พอ ถ้ามี 100 คน การเรียงลำดับเชิงเส้นหลายชุดก็มักจะเพียงพอ แต่เมื่อมี 1,000 คน ซึ่งกระจายอยู่ตามสถานที่ต่างๆ หลายแห่ง ความจำเป็น สำหรับ structured workbook จะเพิ่มขึ้น และ ขนาด ของ workbook ก็เพิ่มขึ้น แล้วกลไกควรจัดการอย่างไร?
ผมคิดว่าสิ่งนี้ทำได้ดีในโครงการ OS/360 ความจำเป็นสำหรับ structured workbook ที่ดีถูกผลักดันอย่างหนักโดย O. S. Locken ซึ่งเคยเห็นประสิทธิภาพของมันในโครงการก่อนหน้าของเขา คือระบบปฏิบัติการ 1410-7010
เราตัดสินใจอย่างรวดเร็วว่า โปรแกรมเมอร์ทุกคน ควรเห็น เอกสารทั้งหมด กล่าวคือ แต่ละคนควรมีสำเนา workbook ไว้ในห้องทำงานของตนเอง
สิ่งที่สำคัญอย่างยิ่งคือการอัปเดตให้ทันเวลา Workbook ต้องเป็น current เสมอ ซึ่งเป็นเรื่องยากถ้าต้องพิมพ์เอกสารทั้งฉบับใหม่ทุกครั้งที่มีการเปลี่ยนแปลง แต่ในสมุดแบบห่วง เราแค่เปลี่ยนหน้าเท่านั้น เรามีระบบ text-editing ที่ขับเคลื่อนด้วยคอมพิวเตอร์ ซึ่งพิสูจน์ได้ว่ามีค่าอย่างยิ่งสำหรับการ maintenance ที่ทันเวลา Offset masters ถูกจัดเตรียมโดยตรงจากเครื่องพิมพ์คอมพิวเตอร์ และ turnaround time น้อยกว่าหนึ่งวัน อย่างไรก็ตาม ผู้รับหน้าที่อัปเดตหน้าก็มีปัญหาในการซึมซับข้อมูลเช่นกัน เมื่อได้รับหน้าใหม่ครั้งแรก เขาอยากรู้ว่า "อะไรเปลี่ยนไปบ้าง?" และเมื่อเขามาดูทีหลัง เขาอยากรู้ว่า "นิยามวันนี้คืออะไร?"
ความต้องการหลังนั้นตอบสนองได้ด้วยการ maintain เอกสารอย่างต่อเนื่อง การเน้นการเปลี่ยนแปลงต้องมีขั้นตอนอื่นเพิ่มเติม ขั้นแรก ต้องทำเครื่องหมายข้อความที่เปลี่ยนไปบนหน้า เช่น โดยใช้ขีดแนวตั้งที่ขอบข้างบรรทัดที่มีการเปลี่ยนแปลงทุกบรรทัด ขั้นที่สอง ต้องแจกจ่าย summary การเปลี่ยนแปลงที่เขียนแยกต่างหากสั้นๆ พร้อมกับหน้าใหม่ ซึ่งระบุการเปลี่ยนแปลงและข้อสังเกตเกี่ยวกับความสำคัญของมัน
โครงการของเราดำเนินไปได้ไม่ถึงหกเดือนก่อนที่เราจะเจอปัญหาใหม่ Workbook หนาประมาณห้าฟุต! ถ้าเรานำสำเนา 100 ชุดที่ให้บริการโปรแกรมเมอร์ในสำนักงานของเราที่ Time-Life Building ในแมนฮัตตันมาซ้อนกัน มันคงสูงกว่าตัวตึกเสียอีก ยิ่งไปกว่านั้น การแจกจ่ายการเปลี่ยนแปลงประจำวันเฉลี่ยสองนิ้ว คิดเป็นประมาณ 150 หน้าที่ต้องแทรกเข้าไปใน workbook ทั้งหมด การดูแลรักษา workbook เริ่มใช้เวลาส่วนสำคัญของแต่ละวันทำงาน
ณ จุดนี้เราเปลี่ยนมาใช้ microfiche ซึ่งช่วยประหยัดเงินได้ถึงหนึ่งล้านดอลลาร์ แม้จะรวมค่าเครื่องอ่าน microfiche สำหรับแต่ละสำนักงานแล้วก็ตาม เราสามารถจัดการให้การผลิต microfiche มี turnaround ที่ยอดเยี่ยม workbook หดลงจากสามลูกบาศก์ฟุตเหลือเพียงหนึ่งในหกของลูกบาศก์ฟุต และที่สำคัญที่สุด การอัปเดตมาเป็นชิ้นๆ ละร้อยหน้า ลดปัญหาการแทรกเอกสารลงได้ร้อยเท่า
Microfiche ก็มีข้อเสียเช่นกัน จากมุมมองของผู้จัดการ การแทรกเอกสารกระดาษที่ยุ่งยากทำให้แน่ใจว่าการเปลี่ยนแปลงได้ถูก อ่าน ซึ่งเป็นจุดประสงค์ของ workbook ส่วน Microfiche จะทำให้การดูแลรักษา workbook ง่ายเกินไป เว้นแต่ fiche อัปเดตจะถูกแจกจ่ายพร้อมกับเอกสารกระดาษที่ระบุการเปลี่ยนแปลง
นอกจากนี้ microfiche ไม่สามารถขีดเส้นเน้น ทำเครื่องหมาย หรือเขียนข้อความโดยผู้อ่านได้ง่าย เอกสารที่ผู้อ่านมีปฏิสัมพันธ์ด้วยจะมีประสิทธิภาพมากกว่าสำหรับผู้เขียนและมีประโยชน์มากกว่าสำหรับผู้อ่าน
โดยรวมแล้วผมคิดว่า microfiche เป็นกลไกที่ดีมาก และผมจะแนะนำให้ใช้แทน workbook กระดาษสำหรับโครงการขนาดใหญ่
แล้วในปัจจุบันนี้จะทำอย่างไร? ด้วยเทคโนโลยีระบบที่มีอยู่ในปัจจุบัน ผมคิดว่าเทคนิคที่ควรเลือกคือเก็บ workbook ไว้ใน direct-access file โดยมี change bars และ revision dates กำกับไว้ ผู้ใช้แต่ละคนจะเรียกดูจาก display terminal (typewriter ช้าเกินไป) สรุปการเปลี่ยนแปลงที่จัดเตรียมทุกวัน จะถูกเก็บแบบ LIFO ไว้ที่ access point ที่คงที่ โปรแกรมเมอร์น่าจะอ่านสรุปนั้นทุกวัน แต่ถ้าพลาดไปหนึ่งวัน ก็แค่อ่านนานขึ้นเล็กน้อยในวันถัดไป ขณะที่อ่านสรุปการเปลี่ยนแปลง เขาสามารถขัดจังหวะเพื่อดูเนื้อหาที่เปลี่ยนไปได้
สังเกตว่า workbook ตัวมันเองไม่ได้เปลี่ยนไป มันยังคงเป็นที่รวบรวมเอกสารโครงการทั้งหมดที่มีโครงสร้างตามการออกแบบที่รอบคอบ สิ่งที่เปลี่ยนไปมีเพียงกลไกในการกระจายและการเข้าถึงเท่านั้น D. C. Engelbart และเพื่อนร่วมงานของเขาที่ Stanford Research Institute ได้สร้างระบบดังกล่าวขึ้นมาและใช้มันในการสร้างและดูแล documentation สำหรับเครือข่าย ARPA
D. L. Parnas จาก Carnegie-Mellon University ได้เสนอวิธีแก้ที่ radical กว่า [1] ข้อเสนอของเขาคือโปรแกรมเมอร์จะมีประสิทธิภาพมากที่สุดถ้าถูกป้องกันจากรายละเอียดการสร้างส่วนอื่นๆ ของระบบที่ไม่ใช่ของตัวเอง แทนที่จะเปิดรับรายละเอียดเหล่านั้น สิ่งนี้ presuppose ว่า interface ทั้งหมดถูกกำหนดอย่างสมบูรณ์และแม่นยำ แม้ว่านั่นจะเป็นการออกแบบที่ถูกต้อง แต่การพึ่งพาว่ามันจะสำเร็จสมบูรณ์แบบนั้นเป็นสูตรแห่งหายนะ ระบบข้อมูลที่ดีทั้งช่วยเปิดเผยข้อผิดพลาดของ interface และกระตุ้นให้เกิดการแก้ไข
Organization in the Large Programming Project (การจัดองค์กรในโครงการซอฟต์แวร์ขนาดใหญ่)
ถ้ามี n คนทำงานในโครงการ จะมี ( n 2 – n )/2 interfaces ที่อาจมีการสื่อสารเกิดขึ้น และมีทีมย่อยเกือบ 2 n ทีมที่ต้องมีการประสานงาน จุดประสงค์ของ organization คือการลดปริมาณการสื่อสารและการประสานงานที่จำเป็น ดังนั้น organization จึงเป็นการโจมตีอย่างรุนแรงต่อปัญหาการสื่อสารที่กล่าวมาข้างต้น
วิธีการลดการสื่อสารคือ การแบ่งงานกันทำ และ การเชี่ยวชาญเฉพาะด้าน โครงสร้างแบบ tree-like ขององค์กรสะท้อนถึงความต้องการการสื่อสารแบบละเอียดที่ลดลงเมื่อมีการแบ่งงานและความเชี่ยวชาญเฉพาะด้าน
ในความเป็นจริง องค์กรแบบ tree เกิดขึ้นจากโครงสร้างของอำนาจและความรับผิดชอบ หลักการที่ว่าไม่มีใครสามารถรับใช้เจ้านายสองคนได้ ทำให้โครงสร้างอำนาจต้องเป็นแบบ tree-like แต่โครงสร้างการสื่อสารไม่ได้ถูกจำกัดเช่นนั้น และ tree เป็นเพียงการประมาณที่พอใช้ได้สำหรับโครงสร้างการสื่อสารซึ่งเป็น network ข้อจำกัดของการประมาณแบบ tree ก่อให้เกิด staff groups, task forces, committees และแม้แต่ matrix-type organization ที่ใช้ในห้องปฏิบัติการวิศวกรรมหลายแห่ง
ลองพิจารณาองค์กรซอฟต์แวร์แบบ tree-like และดูว่าสิ่งจำเป็นที่ subtree ใดๆ ต้องมีเพื่อให้มีประสิทธิภาพคืออะไร:
1 . ภารกิจ (mission)
2 . ผู้ผลิต (producer)
3 . ผู้กำกับเทคนิคหรือสถาปนิก (technical director or architect)
4 . ตารางเวลา (schedule)
5 . การแบ่งงาน (division of labor)
6 . นิยาม interface ระหว่างส่วนต่างๆ (interface definitions among the parts)
ทั้งหมดนี้ชัดเจนและเป็นธรรมดา ยกเว้นความแตกต่างระหว่าง producer และ technical director ขอให้เราพิจารณาสองบทบาทนี้ก่อน จากนั้นจึงดูความสัมพันธ์ของพวกเขา
บทบาทของ producer คืออะไร? เขารวบรวมทีม แบ่งงาน และกำหนดตารางเวลา เขาหาทรัพยากรที่จำเป็นและหามาเรื่อยๆ ซึ่งหมายความว่าส่วนสำคัญของบทบาทของเขาคือการสื่อสารภายนอกทีม ทั้งขึ้นไปข้างบนและไปด้านข้าง เขากำหนดรูปแบบการสื่อสารและการรายงานภายในทีม สุดท้าย เขาทำให้แน่ใจว่าตารางเวลาเป็นไปตามแผน โดยปรับเปลี่ยนทรัพยากรและองค์กรเพื่อตอบสนองต่อสถานการณ์ที่เปลี่ยนแปลง
แล้ว technical director ล่ะ? เขาคิดค้นการออกแบบที่จะสร้าง ระบุส่วนย่อย กำหนดว่ามันจะมีหน้าตาอย่างไรจากภายนอก และร่างโครงสร้างภายใน เขามอบความ unity และความสมบูรณ์ของแนวคิดให้กับการออกแบบทั้งหมด ดังนั้นเขาจึงทำหน้าที่เป็นข้อจำกัดต่อความซับซ้อนของระบบ เมื่อปัญหาเทคนิคเฉพาะเกิดขึ้น เขาคิดค้นวิธีแก้ไขหรือปรับเปลี่ยนการออกแบบของระบบตามความจำเป็น เขาคือ "inside-man at the skunk works" ในวลีที่ไพเราะของ Al Capp การสื่อสารของเขาส่วนใหญ่อยู่ภายในทีม งานของเขาเป็นเทคนิคล้วนๆ เกือบทั้งหมด
เห็นได้ชัดว่าพรสวรรค์ที่จำเป็นสำหรับสองบทบาทนี้แตกต่างกันมาก พรสวรรค์มีหลากหลายรูปแบบ และการผสมผสานเฉพาะที่อยู่ในตัว producer และ director จะต้องกำหนดความสัมพันธ์ระหว่างพวกเขา องค์กรต้องถูกออกแบบตามคนที่มีอยู่ ไม่ใช่การนำคนมาใส่ในองค์กรตามทฤษฎีล้วนๆ
ความสัมพันธ์สามแบบเป็นไปได้ และทั้งสามแบบก็พบได้ในทางปฏิบัติที่ประสบความสำเร็จ
Producer และ technical director อาจเป็นคนเดียวกัน. ซึ่งใช้ได้ผลดีในทีมขนาดเล็กมาก ประมาณสามถึงหกโปรแกรมเมอร์ ในโครงการใหญ่กว่าแทบจะไม่เคยใช้ได้ผล ด้วยสองเหตุผลแรก คนที่มีทั้งพรสวรรค์ด้าน management และพรสวรรค์ด้านเทคนิคที่แข็งแกร่งนั้นหาได้ยาก นักคิดหายาก นักปฏิบัติหายากยิ่งกว่า และคนที่เป็นทั้งนักคิดและนักปฏิบัติหายากที่สุด
ประการที่สอง ในโครงการขนาดใหญ่ แต่ละบทบาทจำเป็นต้องเป็นงานเต็มเวลา หรือมากกว่านั้น เป็นเรื่องยากที่ producer จะมอบหมายหน้าที่ของเขาให้เพียงพอเพื่อให้มีเวลาเหลือสำหรับงานเทคนิค เป็นไปไม่ได้ที่ director จะมอบหมายหน้าที่ของเขาโดยไม่กระทบต่อความสมบูรณ์ของแนวคิดในการออกแบบ
Producer อาจเป็นเจ้านาย และ director เป็นมือขวาของเขา. ปัญหาที่นี่คือการสร้าง อำนาจ ของ director ในการตัดสินใจทางเทคนิค โดยไม่กระทบเวลาของเขาเหมือนกับการวางเขาไว้ในสายการบังคับบัญชาของ management
แน่นอนว่า producer ต้องประกาศอำนาจทางเทคนิคของ director และต้องสนับสนุนในสัดส่วนที่สูงมากของกรณีทดสอบที่จะเกิดขึ้น เพื่อให้เป็นไปได้ producer และ director ต้องมีมุมมองเดียวกันในปรัชญาเทคนิคพื้นฐาน พวกเขาต้องพูดคุยประเด็นเทคนิคหลักเป็นการส่วนตัว ก่อนที่จะถึงเวลา และ producer ต้องมีความเคารพสูงต่อความสามารถทางเทคนิคของ director
ที่ไม่ชัดเจนนัก producer สามารถทำสิ่งละเอียดอ่อนต่างๆ กับสัญลักษณ์ของสถานะ (ขนาดห้องทำงาน พรม เฟอร์นิเจอร์ สำเนาคาร์บอน ฯลฯ) เพื่อประกาศว่า director แม้จะอยู่นอกสายการบริหาร แต่ก็เป็นแหล่งของอำนาจในการตัดสินใจ
วิธีนี้สามารถใช้ได้ผลอย่างมีประสิทธิภาพมาก น่าเสียดายที่แทบไม่ค่อยมีใครลอง สิ่งที่ผู้จัดการโครงการทำได้แย่ที่สุดคือการไม่ใช้อัจฉริยะทางเทคนิคที่ไม่มีพรสวรรค์ด้าน management
Director อาจเป็นเจ้านาย และ producer เป็นมือขวา. Robert Heinlein ใน The Man Who Sold the Moon บรรยายการจัดการแบบนี้ไว้ในตัวอย่างที่ชัดเจน:
Coster ซุกหน้าลงในมือทั้งสองข้าง แล้วเงยหน้าขึ้น "ผมรู้ ผมรู้ว่าต้องทำอะไร—แต่ทุกครั้งที่ผมพยายามจัดการปัญหาทางเทคนิค ก็มีคนโง่บางคนอยากให้ผมตัดสินใจเรื่องรถบรรทุก—หรือโทรศัพท์—หรืออะไรก็ตาม ผมขอโทษครับ Mr. Harriman ผมคิดว่าผมทำได้"
Harriman พูดอย่างนุ่มนวล "อย่าปล่อยให้มันทำให้คุณท้อสิ Bob คุณไม่ได้นอนมากพอเมื่อเร็วๆ นี้ใช่ไหม? รู้ไหม—เราจะจัดการ Ferguson ซะ เราจะย้ายโต๊ะที่คุณนั่งอยู่ไปไว้ที่อื่นสักสองสามวัน แล้วจัด set-up ให้คุณเพื่อป้องกันเรื่องพวกนี้ ผมต้องการให้สมองของคุณคิดแต่เรื่อง reaction vectors และ fuel efficiencies และ design stresses ไม่ใช่เรื่องสัญญารถบรรทุก" Harriman เดินไปที่ประตู มองไปรอบๆ ห้องด้านนอก และมองหาชายคนหนึ่งที่อาจจะเป็นหรือไม่ใช่หัวหน้าแผนกก็ได้ "เฮ้ย คุณ! มาหน่อย"
ชายคนนั้นสะดุ้ง ลุกขึ้น เดินมาที่ประตูแล้วพูดว่า "ครับ?"
"ผมต้องการโต๊ะตัวนั้นที่มุมห้อง รวมถึงของทุกอย่างที่อยู่บนนั้น ไปไว้ในห้องว่างบนชั้นนี้ เดี๋ยวนี้"
เขาดูแลการย้าย Coster และโต๊ะอีกตัวไปไว้ในอีกห้องหนึ่ง ดูแลให้โทรศัพท์ในห้องใหม่ถูกถอดสายออก และนึกขึ้นได้ก็ให้ย้ายโซฟาเข้าไปด้วย "คืนนี้เราจะติดตั้ง projector, drafting machine, และตู้หนังสือกับขยะอื่นๆ" เขาบอก Coster "แค่ทำ list สิ่งที่คุณต้องการ—เพื่อทำงานด้านวิศวกรรม" เขากลับไปที่ห้องที่เรียกกันว่าหัวหน้าวิศวกร และเริ่มทำงานอย่างมีความสุขเพื่อพยายามคิดว่าองค์กรอยู่จุดไหนและมีอะไรผิดปกติ
ประมาณสี่ชั่วโมงต่อมา เขาพา Berkeley มาพบ Coster หัวหน้าวิศวกรกำลังหลับอยู่ที่โต๊ะ ศีรษะซบอยู่บนแขน Harriman กำลังจะถอยออกไป แต่ Coster สะดุ้งตื่น "โอ้! ขอโทษครับ" เขาพูดพร้อมหน้าน้ำแดง "ผมคงเผลอหลับไป"
"นั่นคือสาเหตุที่ผมเอาโซฟามาให้" Harriman กล่าว "มันนอนสบายกว่า Bob นี่ Jock Berkeley เขาเป็นทาสคนใหม่ของคุณ คุณยังคงเป็นหัวหน้าวิศวกรและเจ้านายสูงสุดที่ไม่มีใครโต้แย้ง Jock คือ Lord High Everything Else จากนี้ไปคุณไม่ต้องกังวลอะไรทั้งนั้น—ยกเว้นเรื่องเล็กน้อยคือการสร้างยานจันทรา"
พวกเขาจับมือกัน "ผมขออย่างเดียว Mr. Coster" Berkeley พูดอย่างจริงจัง "คุณสามารถ bypass ผมได้ทุกเมื่อที่ต้องการ—คุณต้องควบคุมงานเทคนิคอยู่แล้ว—แต่เพื่อเห็นแก่พระเจ้า กรุณาบันทึกไว้ด้วยเพื่อผมจะได้รู้ว่าเกิดอะไรขึ้น ผมจะให้ติดสวิตช์บนโต๊ะของคุณที่เชื่อมต่อกับเครื่องบันทึก sealed ที่โต๊ะของผม"
"ดี!" Coster ดูเหมือนจะอ่อนวัยลงแล้ว Harriman คิด
"และถ้าคุณต้องการอะไรที่ไม่ใช่เรื่องเทคนิค อย่าทำด้วยตัวเอง แค่กดสวิตช์แล้วผิวปาก มันจะถูกจัดการให้!" Berkeley มองไปที่ Harriman "Boss บอกว่าอยากคุยกับคุณเรื่องงานจริง ผมขอตัวก่อน" เขาจากไป
Harriman นั่งลง Coster ทำตามแล้วพูดว่า "เฮ้อ!"
"รู้สึกดีขึ้นไหม?"
"ผมชอบท่าทางของ Berkeley คนนั้น"
"ดีแล้ว เขาคือฝาแฝดของคุณจากนี้ไป ไม่ต้องกังวล ผมเคยใช้เขามาก่อน คุณจะรู้สึกเหมือนอยู่ในโรงพยาบาลที่บริหารจัดการดี" [2]
เรื่องนี้แทบไม่ต้องมีคำวิจารณ์ใดๆ การจัดการแบบนี้ก็สามารถใช้ได้ผลเช่นกัน
ผมคิดว่ารูปแบบสุดท้ายดีที่สุดสำหรับทีมขนาดเล็ก ดังที่กล่าวไว้ใน Chapter 3 , "The Surgical Team" ส่วนรูปแบบที่ producer เป็นเจ้านายนั้นเหมาะสมกว่าสำหรับ subtree ที่ใหญ่กว่าในโครงการขนาดใหญ่จริงๆ
หอคอยบาเบลอาจเป็นความล้มเหลวทางวิศวกรรมครั้งแรก แต่ไม่ใช่ครั้งสุดท้าย การสื่อสารและผลที่ตามมาคือการจัดองค์กร เป็นสิ่งสำคัญสำหรับความสำเร็จ เทคนิคของการสื่อสารและการจัดองค์กรต้องการความคิดและการมีประสบการณ์ที่เชี่ยวชาญจากผู้จัดการไม่น้อยไปกว่าตัวเทคโนโลยีซอฟต์แวร์เอง