ไม่มีใครรักคนที่นำข่าวร้ายมา
— SOPHOCLES
โปรเจกต์จะล่าช้าไปถึงหนึ่งปีได้อย่างไร?
. . . . ทีละวัน
เมื่อมีคนได้ยินเรื่องกำหนดการของโปรเจกต์ที่ล่าช้าอย่างหายนะ เขามักจะนึกภาพว่าต้องเกิดเหตุร้ายแรงใหญ่โตหลายอย่างต่อเนื่องกัน แต่โดยปกติแล้ว หายนะนั้นเกิดจากปลวก ไม่ใช่พายุทอร์นาโด กำหนดการค่อยๆ ล่าช้าอย่างที่แทบมองไม่เห็นแต่ไม่อาจหยุดยั้งได้ ที่จริงแล้ว เหตุร้ายใหญ่ๆ จัดการได้ง่ายกว่า เราสามารถตอบโต้ด้วยกำลังหลัก การปรับโครงสร้างครั้งใหญ่ การคิดค้นแนวทางใหม่ๆ ทีมงานทั้งหมดจะร่วมมือกันเพื่อรับมือกับสถานการณ์
แต่การล่าช้าในแต่ละวันนั้นยากที่จะสังเกตเห็น ยากที่จะป้องกัน และยากที่จะชดเชย เมื่อวานคนสำคัญป่วย ทำให้ไม่สามารถจัดประชุมได้ วันนี้เครื่องทั้งหมดหยุดทำงานเพราะฟ้าผ่าหม้อแปลงไฟฟ้าของตึก พรุ่งนี้ routine ของดิสก์จะเริ่มทดสอบไม่ได้เพราะดิสก์ตัวแรกจากโรงงานมาช้าไปหนึ่งสัปดาห์ หิมะตก ภาระการเป็นลูกขุน ปัญหาครอบครัว ประชุมด่วนกับลูกค้า การตรวจสอบจากผู้บริหาร — รายการนี้ยาวเหยียด แต่ละอย่างแค่เลื่อนกิจกรรมออกไปครึ่งวันหรือหนึ่งวัน และกำหนดการก็ล่าช้าออกไปทีละวัน
Milestones or Millstones? (เหตุการณ์สำคัญหรือเครื่องถ่วงความก้าวหน้า?)
เราจะควบคุมโปรเจกต์ใหญ่ที่มีกำหนดการกระชั้นชิดได้อย่างไร? ขั้นตอนแรกคือการมีกำหนดการ แต่ละรายการของเหตุการณ์ที่เรียกว่า milestone ต้องมีวันที่กำหนด การเลือกวันที่เป็นปัญหาของการประมาณค่า ซึ่งเราได้พูดถึงไปแล้ว และขึ้นอยู่กับประสบการณ์เป็นสำคัญ
สำหรับการเลือก milestone มีกฎที่เกี่ยวข้องอยู่แค่ข้อเดียว Milestone ต้องเป็นเหตุการณ์ที่เป็นรูปธรรม เจาะจง วัดผลได้ และถูกกำหนดไว้อย่างคมชัด ตัวอย่าง反面 เช่น การเขียนโค้ดนั้น "เสร็จไป 90 เปอร์เซ็นต์" ตลอดครึ่งหนึ่งของระยะเวลาเขียนโค้ดทั้งหมด การ debug "เสร็จไป 99 เปอร์เซ็นต์" เกือบตลอดเวลา "การวางแผนเสร็จสมบูรณ์" เป็นเหตุการณ์ที่เราสามารถประกาศได้เกือบเมื่อไหร่ก็ได้ [1]
ในทางกลับกัน Milestone ที่เป็นรูปธรรมคือเหตุการณ์ที่ 100 เปอร์เซ็นต์ "Specifications ที่ลงนามโดย architects และ implementers" "source coding เสร็จ 100 เปอร์เซ็นต์ keypunched และเข้าไปใน disk library" "เวอร์ชันที่ debug แล้วผ่าน test cases ทั้งหมด" Milestone ที่เป็นรูปธรรมเหล่านี้เป็นตัวแบ่งขั้นตอนที่คลุมเครือของการวางแผน การเขียนโค้ด และการ debug
การที่ milestone มีความคมชัดและไม่คลุมเครือสำคัญกว่าการที่หัวหน้าสามารถตรวจสอบได้ง่าย ไม่ค่อยมีใครโกหกเกี่ยวกับความคืบหน้าของ milestone ถ้า milestone นั้นคมชัดจนเขาไม่สามารถหลอกตัวเองได้ แต่ถ้า milestone คลุมเครือ หัวหน้ามักจะเข้าใจรายงานที่แตกต่างจากที่ลูกน้องรายงาน พูดเสริมจาก Sophocles ก็คือ ไม่มีใครชอบที่จะเป็นคนนำข่าวร้ายเช่นกัน ดังนั้นข่าวจึงถูกทำให้เบาลงโดยไม่มีเจตนาที่จะหลอกลวงจริงๆ
ผลการศึกษาที่น่าสนใจสองชิ้นเกี่ยวกับพฤติกรรมการประมาณของบริษัทรับเหมาของรัฐบาลในโปรเจกต์พัฒนาขนาดใหญ่แสดงให้เห็นว่า:
1 . การประมาณระยะเวลาของกิจกรรมหนึ่ง ซึ่งทำและปรับปรุงอย่างระมัดระวังทุกสองสัปดาห์ก่อนที่กิจกรรมจะเริ่มขึ้น ไม่ได้เปลี่ยนแปลงอย่างมีนัยสำคัญเมื่อเวลาเริ่มต้นใกล้เข้ามา ไม่ว่าสุดท้ายแล้วการประมาณนั้นจะผิดแค่ไหนก็ตาม
2 . ระหว่าง ที่กิจกรรมดำเนินไป การประมาณ ระยะเวลาที่มากเกินไปจะค่อยๆ ลดลงเรื่อยๆ
3 . การประมาณที่น้อยเกินไป จะไม่เปลี่ยนแปลงอย่างมีนัยสำคัญระหว่างที่กิจกรรมดำเนินไป จนกระทั่งประมาณสามสัปดาห์ก่อนกำหนดการแล้วเสร็จ [2]
Milestone ที่คมชัดนั้นที่จริงแล้วเป็นบริการต่อทีม และเป็นสิ่งที่ทีมควรได้รับจากผู้จัดการ Milestone ที่คลุมเครือเป็นภาระที่หนักกว่าในการอยู่ร่วมกับมัน ที่จริงแล้วมันเป็น millstone (เครื่องโม่) ที่บั่นทอนขวัญกำลังใจ เพราะมันหลอกให้เราเข้าใจผิดเกี่ยวกับเวลาที่สูญเสียไปจนกว่าจะแก้ไขไม่ได้ และการล่าช้าของกำหนดการเรื้อรังเป็นตัวฆ่าขวัญกำลังใจ
"The Other Piece Is Late, Anyway" (อีกส่วนก็ล่าช้าอยู่แล้ว)
กำหนดการล่าช้าไปหนึ่งวัน แล้วไง? ใครจะไปตื่นเต้นกับความล่าช้าแค่วันเดียว? เดี๋ยวเราก็ชดเชยทีหลังได้ และอีกส่วนที่ส่วนของเราต้องไปประกอบกับมันก็ล่าช้าอยู่แล้ว
ผู้จัดการทีมเบสบอลมองว่าพรสวรรค์ที่ไม่เกี่ยวกับร่างกายอย่าง hustle (ความกระตือรือร้น) เป็นของขวัญสำคัญของนักเตะที่ยอดเยี่ยมและทีมที่ยอดเยี่ยม มันคือลักษณะของการวิ่งให้เร็วกว่าที่จำเป็น เคลื่อนไหวให้เร็วกว่าที่จำเป็น พยายามให้หนักกว่าที่จำเป็น และมันก็จำเป็นสำหรับทีมโปรแกรมเมอร์ที่ยอดเยี่ยมเช่นกัน Hustle เป็นตัวสร้างพื้นที่ปลอดภัย ความสามารถสำรอง ที่ทำให้ทีมสามารถรับมือกับเหตุการณ์ไม่คาดฝันทั่วไป คาดการณ์และป้องกันภัยเล็กๆ น้อยๆ ได้ การตอบสนองที่คำนวณมาอย่างพอดี การใช้ความพยายามที่วัดอย่างพอดี กลับเป็นตัวบั่นทอน hustle ดังที่เราได้เห็นแล้วว่า เราจำเป็น ต้อง ตื่นเต้นกับความล่าช้าแค่วันเดียว สิ่งเหล่านี้คือองค์ประกอบของหายนะ
แต่ไม่ใช่ทุกความล่าช้าหนึ่งวันจะหายนะเท่ากัน ดังนั้นจึงจำเป็นต้องคำนวณการตอบสนองบ้าง แม้ hustle จะถูกบั่นทอนลงก็ตาม เราจะรู้ได้อย่างไรว่าความล่าช้าไหนสำคัญ? ไม่มีอะไรจะมาแทนที่ PERT chart หรือ critical-path schedule เครือข่ายแบบนี้แสดงให้เห็นว่าใครรออะไรอยู่ มันแสดงให้เห็นว่าใครอยู่บน critical path ซึ่งความล่าช้าใดๆ ก็ตามจะเลื่อนวันเสร็จออกไป มันยังแสดงให้เห็นว่ากิจกรรมหนึ่งสามารถล่าช้าได้มากแค่ไหนก่อนที่จะเข้าสู่ critical path
เทคนิค PERT อย่างเคร่งครัดแล้วคือการขยายความจาก critical-path scheduling โดยที่เราประมาณเวลาสามค่าสำหรับทุกเหตุการณ์ ซึ่งสอดคล้องกับความน่าจะเป็นที่แตกต่างกันในการบรรลุกำหนดการที่ประมาณไว้ ผมไม่เห็นว่าการปรับแต่งนี้คุ้มค่ากับความพยายามเพิ่มเติม แต่เพื่อความกระชับ ผมจะเรียกเครือข่าย critical path ใดๆ ว่า PERT chart
การจัดทำ PERT chart เป็นส่วนที่มีค่าที่สุดของการใช้งานมัน การวางโครงสร้างเครือข่าย การระบุ dependencies และการประมาณระยะเวลาของแต่ละช่วง บังคับให้ต้องมีการวางแผนที่เฉพาะเจาะจงมากตั้งแต่เนิ่นๆ ในโปรเจกต์ แผนภูมิแรกมักจะแย่เสมอ และเราต้องคิดค้นและคิดค้นใหม่ในการทำแผนภูมิที่สอง
เมื่อโปรเจกต์ดำเนินไป PERT chart จะให้คำตอบกับข้อแก้ตัวที่บั่นทอนกำลังใจที่ว่า "อีกส่วนก็ล่าช้าอยู่แล้ว" มันแสดงให้เห็นว่าต้องใช้ hustle แค่ไหนเพื่อรักษาส่วนของเราให้อยู่นอก critical path และมันเสนอแนะวิธีชดเชยเวลาที่สูญเสียไปในอีกส่วนนั้น
Under the Rug (ซุกไว้ใต้พรม)
เมื่อผู้จัดการระดับต้นเห็นทีมเล็กๆ ของเขาทำงานล่าช้า เขามักจะไม่ค่อยอยากวิ่งไปหาหัวหน้าพร้อมกับความทุกข์นี้ ทีมน่าจะสามารถชดเชยได้ หรือเขาควรจะคิดค้นหรือปรับโครงสร้างเพื่อแก้ปัญหาได้ แล้วจะไปกังวลให้หัวหน้าทำไม? ถึงตรงนี้ก็ยังดีอยู่ การแก้ปัญหาแบบนี้เป็นหน้าที่ของผู้จัดการระดับต้นพอดี และหัวหน้าก็มีเรื่องที่ต้องจัดการมากพออยู่แล้วจนไม่ต้องการเรื่องเพิ่ม ดังนั้นสิ่งสกปรกทั้งหมดจึงถูกกวาดซุกไว้ใต้พรม
แต่หัวหน้าทุกคนต้องการข้อมูลสองประเภท คือข้อยกเว้นจากแผนที่ต้องดำเนินการ และภาพรวมสถานะเพื่อการเรียนรู้ เพื่อจุดประสงค์นั้น เขาจำเป็นต้องรู้สถานะของทีมทั้งหมดของเขา การได้ภาพสถานะที่แท้จริงนั้นเป็นเรื่องยาก [3]
ผลประโยชน์ของผู้จัดการระดับต้นและหัวหน้ามีความขัดแย้งโดยธรรมชาติในจุดนี้ ผู้จัดการระดับต้นกลัวว่าถ้าเขารายงานปัญหา หัวหน้าจะลงมือจัดการ และการกระทำนั้นจะแย่งหน้าที่ของเขาไป ลดอำนาจของเขา ทำให้แผนอื่นๆ ของเขาพัง ดังนั้นตราบใดที่ผู้จัดการคิดว่าเขาสามารถแก้ไขได้ด้วยตัวเอง เขาก็จะไม่บอกหัวหน้า
มีสองเทคนิคในการยกพรมที่หัวหน้าสามารถใช้ได้ ทั้งสองอย่างต้องใช้ อย่างแรกคือการลดความขัดแย้งในบทบาทและส่งเสริมการแบ่งปันสถานะ อย่างที่สองคือการดึงพรมออก
การลดความขัดแย้งในบทบาท หัวหน้าต้องแยกแยะระหว่างข้อมูลสำหรับการดำเนินการและข้อมูลสถานะก่อน เขาต้องฝึกฝนตนเอง ไม่ ให้ลงมือกับปัญหาที่ผู้จัดการของเขาสามารถแก้ไขได้ และไม่ให้ลงมือกับปัญหาเมื่อเขากำลังตรวจสอบสถานะอย่างชัดเจน ผมเคยรู้จักหัวหน้าคนหนึ่งที่มักจะหยิบโทรศัพท์ขึ้นมาสั่งงานก่อนที่จะอ่านจบย่อหน้าแรกในรายงานสถานะ การตอบสนองแบบนั้นรับประกันได้ว่าจะทำให้ไม่มีการเปิดเผยข้อมูลอย่างเต็มที่
ในทางกลับกัน เมื่อผู้จัดการรู้ว่าหัวหน้าจะยอมรับรายงานสถานะโดยไม่ตื่นตระหนกหรือแทรกแซง เขาก็จะให้การประเมินตามจริง
กระบวนการทั้งหมดนี้จะดีขึ้นถ้าหัวหน้าติดป้ายกำกับการประชุม การทบทวน การสัมมนาว่าเป็นการประชุม status-review เทียบกับการประชุม problem-action และควบคุมตัวเองตามนั้น แน่นอนว่าเราอาจเรียกประชุม problem-action หลังจากประชุม status ได้ ถ้าเขาเชื่อว่าปัญหาเกินควบคุม แต่อย่างน้อยทุกคนก็รู้ว่าสถานการณ์เป็นอย่างไร และหัวหน้าจะคิดให้ดีก่อนที่จะเข้าไปยุ่ง
การดึงพรมออก อย่างไรก็ตาม จำเป็นต้องมีเทคนิคการทบทวนที่ทำให้สถานะที่แท้จริงเป็นที่รับรู้ ไม่ว่าจะด้วยความร่วมมือหรือไม่ก็ตาม PERT chart ที่มี milestone ที่คมชัดบ่อยครั้งเป็นพื้นฐานสำหรับการทบทวนดังกล่าว ในโปรเจกต์ขนาดใหญ่ เราอาจต้องการทบทวนบางส่วนของมันทุกสัปดาห์ โดยวนรอบเดือนละครั้งหรือประมาณนั้น
รายงานที่แสดง milestone และการเสร็จสมบูรณ์จริงเป็นเอกสารสำคัญ รูปที่ 14.1 แสดงตัวอย่างจากรายงานดังกล่าว รายงานนี้แสดงปัญหาบางอย่าง การอนุมัติ specifications ล่าช้าในหลาย component การอนุมัติคู่มือ (SRL) ล่าช้าในอีก component หนึ่ง และอีกชิ้นก็ล่าช้าในการออกจากสถานะแรก (Alpha) ของการทดสอบผลิตภัณฑ์ที่ดำเนินการโดยอิสระ ดังนั้นรายงานดังกล่าวจึงทำหน้าที่เป็นวาระการประชุมสำหรับการประชุมวันที่ 1 กุมภาพันธ์ ทุกคนรู้คำถาม และผู้จัดการ component ควรเตรียมตัวที่จะอธิบายว่าทำไมถึงล่าช้า จะเสร็จเมื่อไหร่ กำลังดำเนินการขั้นตอนใด และต้องการความช่วยเหลืออะไรจากหัวหน้าหรือกลุ่มอื่นๆ หรือไม่
Figure 14.1.
V. Vyssotsky แห่ง Bell Telephone Laboratories เสริมข้อสังเกตดังต่อไปนี้:
ผมพบว่าสะดวกมากที่จะพกทั้งวันที่ "ตามกำหนดการ" และ "ที่ประมาณไว้" ในรายงาน milestone วันที่ตามกำหนดการเป็นสมบัติของผู้จัดการโปรเจกต์ และแสดงถึงแผนงานที่สอดคล้องกันสำหรับโปรเจกต์โดยรวม ซึ่ง a priori เป็นแผนที่สมเหตุสมผล วันที่ที่ประมาณไว้เป็นสมบัติของผู้จัดการระดับต่ำสุดที่รับผิดชอบงานชิ้นนั้น และแสดงถึงการคาดการณ์ที่ดีที่สุดของเขาว่ามันจะเสร็จเมื่อไหร่จริงๆ โดยพิจารณาจากทรัพยากรที่เขามีและเมื่อเขาได้รับ (หรือมีข้อผูกมัดในการจัดส่ง) input ที่จำเป็น ผู้จัดการโปรเจกต์ต้องไม่ไปยุ่งกับวันที่ที่ประมาณไว้ และต้องเน้นให้ได้การประมาณที่แม่นยำและไม่ลำเอียง แทนที่จะเป็นการประมาณที่มองโลกในแง่ดีเพื่อให้ถูกใจ หรือการประมาณที่อนุรักษ์นิยมเพื่อป้องกันตัวเอง เมื่อสิ่งนี้ถูกทำให้ชัดเจนในใจของทุกคนแล้ว ผู้จัดการโปรเจกต์จะสามารถมองเห็นล่วงหน้าได้ไกลว่าเขากำลังจะเจอปัญหาที่ไหนถ้าไม่ทำอะไรสักอย่าง [4]
การจัดทำ PERT chart เป็นหน้าที่ของหัวหน้าและผู้จัดการที่รายงานตรงต่อเขา การอัปเดต แก้ไข และรายงานต้องอาศัยทีมงานขนาดเล็ก (หนึ่งถึงสามคน) ที่ทำหน้าที่เป็นส่วนขยายของหัวหน้า ทีม Plans and Controls เช่นนี้มีค่าอย่างยิ่งสำหรับโปรเจกต์ขนาดใหญ่ มันไม่มีอำนาจใดๆ นอกจากถามผู้จัดการทุกคนว่าเมื่อไหร่จะตั้งหรือเปลี่ยน milestone และ milestone ผ่านหรือไม่ เนื่องจากทีม Plans and Controls จัดการงานเอกสารทั้งหมด ภาระของผู้จัดการสายงานจึงลดลงเหลือเพียงสิ่งสำคัญ—การตัดสินใจ
เรามีทีม Plans and Controls ที่มีทักษะ กระตือรือร้น และมีไหวพริบทางการทูต นำโดย A. M. Pietrasanta ซึ่งทุ่มเทพรสวรรค์ในการคิดสร้างสรรค์อย่างมากในการออกแบบวิธีการควบคุมที่มีประสิทธิภาพแต่ไม่รบกวนเกินไป ผลที่ตามมา ผมพบว่าทีมของเขาได้รับการยอมรับอย่างกว้างขวางและมากกว่าที่จะถูกแค่อดทนอดกลั้น สำหรับทีมที่มีบทบาทเป็นตัวก่อกวนโดยธรรมชาติแล้ว นับว่าเป็นความสำเร็จที่ยิ่งใหญ่
การลงทุนความพยายามที่มีทักษะในระดับพอประมาณในหน้าที่ Plans and Controls ให้ผลตอบแทนที่คุ้มค่ามาก มันสร้างความแตกต่างต่อความสำเร็จของโปรเจกต์มากกว่าการให้คนเหล่านี้ทำงานสร้างโปรแกรมผลิตภัณฑ์โดยตรง เพราะทีม Plans and Controls คือสุนัขเฝ้าบ้านที่ทำให้ความล่าช้าที่มองไม่เห็นกลายเป็นสิ่งที่เห็นได้ และชี้ให้เห็นองค์ประกอบที่สำคัญ มันคือระบบเตือนภัยล่วงหน้าที่ป้องกันการสูญเสียหนึ่งปี ทีละวัน