สมมติฐาน:
ท่ามกลางเอกสารจำนวนมหาศาล เอกสารเพียงไม่กี่ฉบับกลับกลายเป็นจุดหมุนสำคัญที่การบริหารโครงการทุกโครงการต้องพึ่งพา เอกสารเหล่านี้คือเครื่องมือส่วนตัวที่สำคัญที่สุดของผู้จัดการ
เทคโนโลยี องค์กรโดยรอบ และธรรมเนียมปฏิบัติของวิชาชีพร่วมกันกำหนดเอกสารบางอย่างที่โปรเจกต์ต้องเตรียมขึ้น สำหรับผู้จัดการหน้าใหม่ที่เพิ่งเปลี่ยนบทบาทจากผู้ปฏิบัติงานมาก่อน เอกสารเหล่านี้ดูเหมือนจะเป็นภาระที่ไร้ประโยชน์ สร้างความรำคาญโดยไม่จำเป็น และเป็นคลื่นสีขาวที่พร้อมจะกลืนเขาเข้าไป และแน่นอนว่า ส่วนใหญ่แล้วมันก็เป็นอย่างนั้นจริง ๆ
แต่ทีละเล็กทีละน้อย เขาจะเริ่มตระหนักว่าเอกสารจำนวนหนึ่งในกลุ่มนี้ได้รวบรวมและแสดงถึงงานบริหารส่วนใหญ่ของเขา การเตรียมเอกสารแต่ละฉบับกลายเป็นโอกาสสำคัญในการรวบรวมความคิดและตกผลึกการอภิปรายที่มิฉะนั้นก็จะยืดเยื้อไปไม่มีที่สิ้นสุด การบำรุงรักษาเอกสารกลายเป็นกลไกเฝ้าระวังและแจ้งเตือนของเขา ตัวเอกสารเองทำหน้าที่เป็นรายการตรวจสอบ การควบคุมสถานะ และฐานข้อมูลสำหรับการรายงาน
เพื่อให้เห็นว่าสิ่งนี้ควรทำงานอย่างไรสำหรับโปรเจกต์ซอฟต์แวร์ เรามาดูเอกสารเฉพาะที่มีประโยชน์ในบริบทอื่น ๆ แล้วดูว่ามีรูปแบบทั่วไปที่เกิดขึ้นหรือไม่
Documents for a Computer Product (เอกสารสำหรับผลิตภัณฑ์คอมพิวเตอร์)
สมมติว่าเรากำลังสร้างเครื่องจักรเครื่องหนึ่ง เอกสารสำคัญมีอะไรบ้าง?
Objectives (วัตถุประสงค์). เอกสารนี้กำหนดความต้องการที่ต้องตอบสนอง รวมถึงเป้าหมาย สิ่งที่พึงประสงค์ ข้อจำกัด และลำดับความสำคัญ
Specifications (ข้อกำหนด). นี่คือคู่มือคอมพิวเตอร์พร้อมกับข้อกำหนดด้านประสิทธิภาพ เป็นเอกสารแรก ๆ ที่ถูกสร้างขึ้นในการเสนอผลิตภัณฑ์ใหม่ และเป็นเอกสารสุดท้ายที่เสร็จสมบูรณ์
Schedule (ตารางเวลา)
Budget (งบประมาณ). ไม่ใช่แค่ข้อจำกัด งบประมาณเป็นหนึ่งในเอกสารที่มีประโยชน์ที่สุดของผู้จัดการ การมีงบประมาณบังคับให้เกิดการตัดสินใจทางเทคนิคที่มิฉะนั้นก็จะถูกเลี่ยง และที่สำคัญกว่านั้นคือมันบังคับและทำให้การตัดสินใจเชิงนโยบายชัดเจนขึ้น
Organization chart (แผนผังองค์กร)
Space allocations (การจัดสรรพื้นที่)
Estimate, forecast, prices (การประมาณ การคาดการณ์ ราคา). สามสิ่งนี้มีการเชื่อมโยงกันเป็นวัฏจักร ซึ่งเป็นตัวกำหนดความสำเร็จหรือความล้มเหลวของโปรเจกต์:
ในการสร้างการคาดการณ์ตลาด เราจำเป็นต้องมีข้อกำหนดด้านประสิทธิภาพและราคาที่ตั้งสมมติฐานไว้ ปริมาณจากการคาดการณ์รวมกับจำนวนชิ้นส่วนจากการออกแบบเพื่อกำหนดต้นทุนการผลิตโดยประมาณ และยังกำหนดส่วนแบ่งต้นทุนการพัฒนาและต้นทุนคงที่ต่อหน่วยอีกด้วย ต้นทุนเหล่านี้กลับไปกำหนดราคาอีกทีหนึ่ง
หากราคา ต่ำกว่า ที่ตั้งสมมติฐานไว้ เกลียวแห่งความสำเร็จอันน่าชื่นชมก็จะเริ่มต้นขึ้น การคาดการณ์สูงขึ้น ต้นทุนต่อหน่วยลดลง และราคาก็ลดลงไปอีก
หากราคา สูงกว่า ที่ตั้งสมมติฐานไว้ เกลียวแห่งหายนะก็จะเริ่มต้นขึ้น และทุกคนต้องดิ้นรนเพื่อทำลายมันลง สมรรถนะต้องถูกบีบให้สูงขึ้นและพัฒนาแอปพลิเคชันใหม่ ๆ เพื่อรองรับการคาดการณ์ที่มากขึ้น ต้นทุนต้องถูกกดลงเพื่อให้ได้ค่าประมาณที่ต่ำลง ความเครียดของวัฏจักรนี้เป็นระเบียบวินัยที่มักจะดึงผลงานที่ดีที่สุดของนักการตลาดและวิศวกรออกมา
และมันก็สามารถนำมาซึ่งการกลับไปกลับมาอย่างไร้สาระได้เช่นกัน ผมจำเครื่องจักรเครื่องหนึ่งได้ ซึ่ง instruction counter ของมันโผล่เข้าและออกจากหน่วยความจำทุก ๆ หกเดือนระหว่างรอบการพัฒนาสามปี ในช่วงหนึ่งต้องการประสิทธิภาพเพิ่มขึ้นอีกนิด ดังนั้น instruction counter จึงถูก implement ด้วย transistor ในช่วงถัดไป การลดต้นทุนกลายเป็นประเด็นหลัก ดังนั้น counter จึงถูก implement เป็นตำแหน่งในหน่วยความจำ ในอีกโปรเจกต์หนึ่ง ผู้จัดการฝ่ายวิศวกรรมที่ดีที่สุดเท่าที่ผมเคยเห็นมาทำหน้าที่เหมือนมู่เล่ย์ขนาดใหญ่ ความเฉื่อยของเขาช่วยลดความผันผวนที่มาจากฝ่ายการตลาดและฝ่ายบริหาร
Documents for a University Department (เอกสารสำหรับภาควิชามหาวิทยาลัย)
แม้จะมีความแตกต่างอย่างใหญ่หลวงในด้านวัตถุประสงค์และกิจกรรม แต่เอกสารจำนวนใกล้เคียงกันในลักษณะคล้ายกันก็เป็นชุดเอกสารสำคัญสำหรับหัวหน้าภาควิชามหาวิทยาลัย การตัดสินใจเกือบทุกครั้งของคณบดี ที่ประชุมคณะ หรือหัวหน้าภาควิชาล้วนเป็นการกำหนดหรือเปลี่ยนแปลงเอกสารเหล่านี้:
Objectives (วัตถุประสงค์)
Course descriptions (คำอธิบายรายวิชา)
Degree requirements (ข้อกำหนดปริญญา)
Research proposals (hence plans, when funded) (ข้อเสนอวิจัย — ซึ่งก็คือแผนงาน เมื่อได้รับทุน)
Class schedule and teaching assignments (ตารางเรียนและการมอบหมายการสอน)
Budget (งบประมาณ)
Space allocation (การจัดสรรพื้นที่)
Assignment of staff and graduate students (การมอบหมายงานของบุคลากรและนักศึกษาบัณฑิต)
สังเกตว่าส่วนประกอบต่าง ๆ คล้ายคลึงกับของโปรเจกต์คอมพิวเตอร์มาก ได้แก่ วัตถุประสงค์ ข้อกำหนดผลิตภัณฑ์ การจัดสรรเวลา การจัดสรรเงิน การจัดสรรพื้นที่ และการจัดสรรคน มีเพียงเอกสารด้านราคาที่หายไป เพราะที่นี่สภานิติบัญญัติเป็นคนทำงานนั้นแทน ความคล้ายคลึงกันนี้ไม่ได้เกิดขึ้นโดยบังเอิญ — ความกังวลของงานบริหารใด ๆ ก็คือ อะไร เมื่อไร เท่าไหร่ ที่ไหน และใคร
Documents for a Software Project (เอกสารสำหรับโปรเจกต์ซอฟต์แวร์)
ในหลายโปรเจกต์ซอฟต์แวร์ ผู้คนเริ่มต้นด้วยการประชุมเพื่อถกเถียงโครงสร้าง จากนั้นก็เริ่มเขียนโปรแกรม อย่างไรก็ตาม ไม่ว่าโปรเจกต์จะเล็กแค่ไหน ผู้จัดการก็ควรเริ่มต้นสร้างอย่างน้อยเอกสารขนาดเล็กเพื่อใช้เป็นฐานข้อมูลของตัวเองทันที และสุดท้ายเขาก็พบว่าต้องการเอกสารที่ไม่ต่างจากผู้จัดการคนอื่น ๆ มากนัก
What: objectives (อะไร: วัตถุประสงค์). เอกสารนี้กำหนดความต้องการที่ต้องตอบสนอง รวมถึงเป้าหมาย สิ่งที่พึงประสงค์ ข้อจำกัด และลำดับความสำคัญ
What: product specifications (อะไร: ข้อกำหนดผลิตภัณฑ์). เอกสารนี้เริ่มต้นจากข้อเสนอและจบลงที่คู่มือและเอกสารภายใน ข้อกำหนดด้านความเร็วและพื้นที่เป็นส่วนที่สำคัญ
When: Schedule (เมื่อไร: ตารางเวลา)
How much: budget (เท่าไหร่: งบประมาณ)
Where: space allocation (ที่ไหน: การจัดสรรพื้นที่)
Who: organization chart (ใคร: แผนผังองค์กร). เอกสารนี้จะเชื่อมโยงกับข้อกำหนดอินเทอร์เฟซ ดังที่ Conway's Law ทำนายไว้ว่า "องค์กรที่ออกแบบระบบจะถูกจำกัดให้ผลิตระบบที่เป็นภาพสะท้อนของโครงสร้างการสื่อสารขององค์กรนั้น" [1] Conway อธิบายต่อไปว่าแผนผังองค์กรในตอนแรกจะสะท้อนถึงการออกแบบระบบครั้งแรก ซึ่งเกือบจะแน่นอนว่าไม่ใช่การออกแบบที่ถูกต้อง หากต้องการให้การออกแบบระบบเปลี่ยนแปลงได้อย่างอิสระ องค์กรก็ต้องพร้อมที่จะเปลี่ยนแปลงเช่นกัน
Why Have Formal Documents? (ทำไมต้องมีเอกสารทางการ?)
ประการแรก การเขียนการตัดสินใจลงไปเป็นสิ่งจำเป็น เมื่อเราเขียนเท่านั้นที่ช่องว่างจะปรากฏและความไม่สอดคล้องกันจะเด่นชัดขึ้น การเขียนต้องอาศัยการตัดสินใจย่อยหลายร้อยครั้ง และการมีอยู่ของการตัดสินใจเหล่านี้คือสิ่งที่ทำให้นโยบายที่ชัดเจนและแม่นยำแตกต่างจากนโยบายที่คลุมเครือ
ประการที่สอง เอกสารจะสื่อสารการตัดสินใจไปยังผู้อื่น ผู้จัดการจะต้องประหลาดใจอยู่เสมอที่นโยบายที่เขาคิดว่าเป็นความรู้ทั่วไปกลับไม่เป็นที่รู้จักของสมาชิกในทีมบางคน เนื่องจากหน้าที่พื้นฐานของเขาคือการทำให้ทุกคนเดินไปในทิศทางเดียวกัน งานประจำวันหลักของเขาจึงเป็นการสื่อสาร ไม่ใช่การตัดสินใจ และเอกสารของเขาจะช่วยแบ่งเบาภาระนี้ได้อย่างมหาศาล
สุดท้าย เอกสารของผู้จัดการเป็นฐานข้อมูลและรายการตรวจสอบให้เขา การทบทวนเอกสารเหล่านี้เป็นระยะช่วยให้เขาเห็นว่าตอนนี้เขาอยู่จุดไหน และเห็นว่าต้องเปลี่ยนแปลงจุดเน้นหรือเปลี่ยนทิศทางใดบ้าง
ผมไม่ได้เห็นด้วยกับวิสัยทัศน์ที่พนักงานขายโปรเจกต์เกี่ยวกับ "ระบบข้อมูลรวมเพื่อการบริหารจัดการ" ที่ผู้บริหารจะป้อนคำถามลงในคอมพิวเตอร์ แล้วหน้าจอก็จะแสดงคำตอบทันที มีเหตุผลพื้นฐานหลายประการที่สิ่งนี้จะไม่มีวันเกิดขึ้น เหตุผลหนึ่งคือมีเพียงส่วนน้อย — อาจประมาณ 20 เปอร์เซ็นต์ — ของเวลาผู้บริหารที่ใช้ไปกับงานที่ต้องการข้อมูลจากภายนอกสมองของเขา ส่วนที่เหลือคือการสื่อสาร: การฟัง การรายงาน การสอน การปลุกเร้า การให้คำปรึกษา การให้กำลังใจ แต่สำหรับส่วนที่ เป็น การใช้ข้อมูล เอกสารสำคัญไม่กี่ฉบับนั้นมีความจำเป็น และจะตอบสนองความต้องการได้เกือบทั้งหมด
หน้าที่ของผู้จัดการคือการพัฒนาแผนแล้วทำให้เป็นจริง แต่มีเพียงแผนที่เขียนไว้เท่านั้นที่แม่นยำและสามารถสื่อสารได้ แผนดังกล่าวประกอบด้วยเอกสารเกี่ยวกับอะไร เมื่อไร เท่าไหร่ ที่ไหน และใคร เอกสารสำคัญจำนวนไม่มากนี้ encapsulate งานส่วนใหญ่ของผู้จัดการ หากธรรมชาติที่ครอบคลุมและสำคัญของเอกสารเหล่านี้ได้รับการยอมรับตั้งแต่เริ่มต้น ผู้จัดการจะมองมันเป็นเครื่องมือที่เป็นมิตรแทนที่จะเป็นงานจุกจิกที่น่ารำคาญ และเขาจะกำหนดทิศทางได้คมชัดและรวดเร็วยิ่งขึ้นด้วยการทำเช่นนั้น