เหตุใดการประมาณจึงล้มเหลว (และทำไมมันยังคงจำเป็นอยู่)

• ในการพัฒนาซอฟต์แวร์ การประมาณงานอยู่ในขอบเขตของ Complex โดยเนื้อแท้ และไม่ว่าทีมจะชำนาญเพียงใดก็ไม่สามารถประมาณได้อย่างแม่นยำโดยพื้นฐาน
• ขบวนการ #NoEstimates เป็นการโต้กลับที่ชอบธรรมต่อความจริงที่ว่าการประมาณถูก นำไปใช้ผิดเป็นเป้าหมายผลงาน แต่หากปฏิเสธการประมาณไปเลย องค์กรก็จะสูญเสียความสามารถในการประสานงาน
• คุณค่าหลักของการประมาณไม่ใช่การทำนายอนาคต แต่คือ การสื่อสารและการประสานงานภายใต้ความไม่แน่นอน และเป็นสิ่งจำเป็นต่อสัญญาภายนอก การพึ่งพากันระหว่างทีม และการตัดสินใจด้าน ROI
• ตามแนวคิด Cone of Uncertainty ของ Steve McConnell ในช่วงต้นของโครงการ ความคลาดเคลื่อนของการประมาณอาจมากได้ถึง 4 เท่า และจะค่อยๆ แคบลงได้ผ่านการเรียนรู้เท่านั้น
• ต้องเปลี่ยนนิสัยระดับองค์กรที่เปลี่ยนการประมาณให้กลายเป็นคำมั่นสัญญา และหันมาใช้แนวทางประมาณแบบ อิงขอบเขต ระบุสมมติฐาน และปรับแก้อย่างค่อยเป็นค่อยไป

---

ปัญหาที่ขบวนการ #NoEstimates แก้ได้จริง

• มักเกิดรูปแบบซ้ำๆ ที่ทีมถูกขอให้ประมาณทั้งที่แทบยังไม่รู้อะไรเกี่ยวกับปัญหา และตัวเลขนั้นก็ถูกนำไปใส่ในโรดแมปแล้วสัญญากับลูกค้า
• เมื่อความเป็นจริงคลาดเคลื่อนจากที่ประมาณ ทีมกลับถูกตำหนิว่า "พลาดเดดไลน์" ทั้งที่เดดไลน์นั้นไม่เคยเป็นสิ่งที่ตกลงร่วมกันตั้งแต่แรก
• พยาธิสภาพสำคัญคือการที่การประมาณถูกบิดจากการคาดการณ์ให้กลายเป็น คำมั่นสัญญา (commitment)
• วิธีแก้แบบ "อย่าประมาณเลย" ก็คล้ายกับการตอบสนองต่อเทอร์โมมิเตอร์ที่เสียด้วยการ ปฏิเสธแนวคิดเรื่องอุณหภูมิไปทั้งระบบ
• ดังที่ Maarten Dalmijn กล่าวไว้ การประมาณไม่ได้เปลี่ยนปริมาณงานจริงแต่อย่างใด การพัฒนาฟีเจอร์จะใช้เวลานานเท่าที่มันต้องใช้
  • สิ่งที่การประมาณมีผลกระทบไม่ใช่ตัวงาน แต่คือ ความคาดหวัง (expectations) ที่รายล้อมงานนั้น
  • การจัดการความคาดหวังอย่างซื่อสัตย์และชัดเจนเป็นงานที่คุ้มค่ามากพออยู่แล้ว

เหตุใดองค์กรจึงยังต้องการการประมาณจริงๆ

• ประเด็นที่แทบไม่ถูกพูดถึงในวงสนทนา #NoEstimates คือ การประมาณไม่ได้มีไว้เพื่อทีมที่ลงมือทำงานเท่านั้น แต่มีไว้เพื่อองค์กรรอบข้างด้วย

• มี 3 สถานการณ์ที่เลี่ยงการประมาณไม่ได้

• คำมั่นสัญญาภายนอก (External commitments): เช่น สัญญาลูกค้า การเปิดตัวที่ต้องผูกกับแคมเปญการตลาด หรือเส้นตายด้านกฎระเบียบ ซึ่งล้วนต้องมีแบบจำลองเวลาที่งานจะใช้เพื่อประเมินความเป็นไปได้

  • คำตอบว่า "เราไม่ทำการประมาณ" ไม่ใช่คำตอบที่ให้กับลูกค้าได้ และอาจนำไปสู่การสิ้นสุดสัญญา

• การพึ่งพากันระหว่างทีม (Inter-team dependencies): หากทีม B ต้องรอให้ทีม A ทำเสร็จก่อน แล้วทีม A ไม่ให้การคาดการณ์ใดๆ เลย ทีม B ก็ไม่สามารถวางแผนได้

  • สัญญาณคร่าวๆ เช่น "น่าจะประมาณ 6 สัปดาห์ มากสุด 8 สัปดาห์" มีประโยชน์มากกว่าความเงียบอย่างเทียบกันไม่ได้ และนี่ไม่ใช่การควบคุม แต่เป็น การให้เกียรติสมาชิกทีมปลายน้ำ

• การคำนวณ ROI: หากต้องตัดสินใจว่าจะสร้างฟีเจอร์ X หรือฟีเจอร์ Y ก็จำเป็นต้องมีแบบจำลองต้นทุนเชิงเปรียบเทียบ

  • หากทุกอย่างไม่อาจรู้ได้ ก็จะไม่สามารถทำ trade-off อย่างมีเหตุผลได้ และถ้ายังไงก็ต้องเดาอยู่ดี การเดาแบบมีโครงสร้างพร้อม สมมติฐานที่ระบุชัด ย่อมดีกว่า

แก่นของความยากในการประมาณตามที่ Joseph Pelrine ชี้ให้เห็น

• Joseph Pelrine เป็น Certified Scrum Trainer คนแรกของยุโรป และศึกษาซอฟต์แวร์แบบ Agile ผ่านเลนส์ของวิทยาศาสตร์ความซับซ้อนทางสังคม
• เขาทำการทดลองกับผู้ที่ทำงานด้านการพัฒนาซอฟต์แวร์แบบ Agile มากกว่า 300 คน โดยให้นำกิจกรรมงานประจำวันไปจัดวางลงในขอบเขตของ Cynefin framework (โมเดล sensemaking ของ Dave Snowden)
  • Cynefin แบ่งปัญหาออกเป็น 4 ขอบเขต ได้แก่ Clear, Complicated, Complex และ Chaotic
• การประมาณงานถูกจัดให้อยู่ในขอบเขต Complex อย่างสม่ำเสมอและซ้ำแล้วซ้ำเล่า
• ประเด็นสำคัญอยู่ที่ ความต่างระหว่าง Complicated กับ Complex:
  • ในขอบเขต Complicated ความสัมพันธ์เชิงเหตุและผลสามารถทำความเข้าใจได้ ผู้เชี่ยวชาญสามารถไล่ตามได้ และ ความเชี่ยวชาญสามารถสร้างการคาดการณ์ที่เชื่อถือได้
  • ในขอบเขต Complex ความสัมพันธ์เชิงเหตุและผลจะ เข้าใจได้ก็ต่อเมื่อมองย้อนหลัง ระบบพันกันเกินไป ขึ้นอยู่กับบริบท และไวต่อการเปลี่ยนแปลงเล็กน้อย
• นี่คือเหตุผลที่การพัฒนาซอฟต์แวร์ไม่เหมือนงานผลิต: แทบทุกครั้งคือการสร้างสิ่งที่ไม่เคยมีมาก่อน บน codebase ที่ไม่เหมือนใคร พร้อมพลวัตทีมที่ไม่เหมือนใคร
  • เหตุที่อุปมาเรื่องช่างไม้ใช้ไม่ได้ ก็เพราะตู้หนึ่งกับอีกตู้หนึ่งยังพอคล้ายกัน แต่ ฟีเจอร์หนึ่งกับอีกฟีเจอร์หนึ่งไม่ได้คล้ายกันโดยประมาณ
• แม้แต่ทีมที่ยอดเยี่ยมก็ทำได้เพียง การประมาณระดับธรรมดา และไม่ใช่เพราะขาดทักษะ แต่เพราะความแม่นยำในขอบเขต Complex มีข้อจำกัดโดยเนื้อแท้
• เป้าหมายจึงไม่ใช่การประมาณให้ตรงเป๊ะ แต่คือ การตัดสินใจที่เป็นประโยชน์แม้การประมาณจะคลาดเคลื่อนโดยธรรมชาติ

สิ่งที่ Cone of Uncertainty บอกเรา

• แนวคิด Cone of Uncertainty ของ Steve McConnell ระบุว่าในช่วงต้นโครงการ ความคลาดเคลื่อนของการประมาณสามารถแกว่งได้ถึง 4 เท่า ในทั้งสองทิศทาง (รวมเป็นช่วงกว้าง 16 เท่า)
• เมื่อโครงการเดินหน้าและสิ่งที่ยังไม่รู้ถูกคลี่คลายออก (เช่น ความชัดเจนของ requirement การยืนยันสถาปัตยกรรม การค้นพบและแก้ปัญหาที่ยาก) กรวยนี้จะแคบลง
• ความย้อนแย้งคือ จุดที่การประมาณ แม่นที่สุดคือช่วงใกล้เสร็จงาน ซึ่งกลับเป็นช่วงที่ต้องการการประมาณน้อยที่สุด
  • ช่วงต้นที่การประมาณมีประโยชน์ที่สุด (ตอนที่ยังเปลี่ยนทิศหรือยุติโครงการได้) เรากลับรู้น้อยที่สุด
  • แต่องค์กรส่วนใหญ่กลับ ให้คำมั่นที่หนักแน่นที่สุดในช่วงต้นนี่เอง
• ยังมีนัยสำคัญเพิ่มเติมอีก 2 ข้อ:
  • กรวยนี้เป็นกรณี ดีที่สุดของผู้ประเมินที่มีทักษะ และทีมส่วนใหญ่ทำได้แย่กว่านั้น
  • การล็อกวันที่ตั้งแต่ช่วงแนวคิดเริ่มต้นไม่ใช่การวางแผน แต่คือ การอธิษฐานขอให้เป็นเช่นนั้นแล้วจัดตารางตามความหวัง
  • กรวยนี้แคบลงได้ไม่ใช่เพราะเวลา แต่เพราะ การตัดสินใจที่ช่วยกำจัดความไม่แน่นอน
  • การนิยามขอบเขต การคลี่คลายสิ่งที่ยังไม่รู้ทางสถาปัตยกรรม การลงมือเขียนโค้ดจริงและพบอุปสรรค คือสิ่งที่ทำให้กรวยแคบลง ส่วนการประชุม 3 สัปดาห์ติดไม่ได้ช่วยให้แคบลง
• ควรสื่อสารกับผู้มีส่วนได้ส่วนเสียอย่างชัดเจนว่า "คุณภาพของการประมาณขึ้นอยู่กับว่าเรายืนอยู่ตรงไหนในกรวยนี้"
  • ในสัปดาห์แรกเราอาจให้ตัวเลขแบบงาน 2 สัปดาห์ไม่ได้ แต่สามารถให้เป็นช่วงและอธิบายได้ว่าต้องตรวจสอบอะไรบ้างจึงจะทำให้ช่วงนั้นแคบลง
  • ผู้มีส่วนได้ส่วนเสียส่วนใหญ่ยอมรับได้เมื่ออธิบายเรื่องกรวยนี้ เพียงแต่ ไม่เคยมีใครบอกพวกเขาว่าพวกเขาขอเป็นช่วงได้

เหตุใดจึงใช้สเกล Fibonacci

• ความเป็น nonlinear ของสเกล Fibonacci (1, 2, 3, 5, 8, 13, 21) ทำหน้าที่เชิงญาณวิทยา
• ความต่างระหว่าง 2 กับ 3 เป็นเพียงระดับ "พอมองออกว่าต่างกันคร่าวๆ" แต่การกระโดดจาก 8 ไป 13 นั้นเข้ารหัสความจริงว่า แถบความไม่แน่นอนกว้างกว่าค่าประมาณเสียอีก
  • สตอรี่ 13 แต้มไม่ได้หมายถึง "13 เป๊ะๆ" แต่หมายถึง "อยู่ในหมวดที่ไม่แน่นอนกว่า 8 แน่ๆ แต่ยังไม่ถึง 21"
• ช่องว่างระหว่างตัวเลข Fibonacci สะท้อน วิธีที่ความซับซ้อนขยายตัวจริง
  • งานเล็กพอจะประมาณคร่าวๆ ได้ แต่งานใหญ่จะมีสิ่งที่ยังไม่รู้ จุดเชื่อมต่อ และสถานการณ์ไม่คาดคิดมากมายจนคาดการณ์ยากขึ้นแบบทวีคูณ
  • สตอรี่ที่ 21 (หรือ 13) ขึ้นไป หมายถึง "เรายังไม่เข้าใจงานนี้ดีพอ ดังนั้น ต้องแตกย่อย"
• ฟังก์ชันอีกอย่างของการประมาณแบบ Fibonacci ที่มักถูกประเมินค่าต่ำ คือ สิ่งที่เกิดขึ้นระหว่างบทสนทนาการประมาณ
  • ถ้าคนหนึ่งบอก 3 แต่อีกคนบอก 13 ตัวเลขแทบไม่สำคัญ สิ่งสำคัญคือทำไมคนในทีมเดียวกันจึงมองสตอรี่เดียวกันต่างกันขนาดนั้น
  • อาจเป็นเพราะอีกฝ่ายพบ dependency หรือรู้ข้อจำกัดทางเทคนิคที่ไม่ได้อยู่ใน ticket
• คุณค่าที่ใหญ่ที่สุดของการประมาณไม่ใช่ตัวเลข แต่คือการตรวจสอบว่าได้สร้างความเข้าใจร่วมกันแล้วหรือยัง
  • หากเอากลไกบังคับนี้ออกไป ความเข้าใจร่วมกันมักไม่เกิดจนกว่าจะมีใครไปเจอความซับซ้อนที่ซ่อนอยู่ในวันที่ 3 ของการลงมือทำงาน
• นี่จึงเป็นเหตุผลที่ยากจะเห็นด้วยกับข้ออ้างของ #NoEstimates ที่ว่า "การประชุมประมาณเป็นเรื่องเสียเวลา": หากดำเนินการได้ดี บทสนทนานั้นเองคือที่ที่เกิด alignment
  • คำตอบของการประชุมที่จัดได้ไม่ดีไม่ใช่การยกเลิกประชุม

กับดักของคำมั่นสัญญา (Commitment Trap) และวิธีหลีกเลี่ยง

• ความผิดปกติที่ลึกที่สุดซึ่งขบวนการ #NoEstimates กำลังตอบโต้ คือ การที่การประมาณถูกเปลี่ยนให้เป็นคำมั่นสัญญาผ่านแรงกดดันทางสังคม แทนที่จะเป็นตรรกะ
• รูปแบบความล้มเหลวที่เกี่ยวข้องคือ เมื่อคนที่ไม่ได้ลงมือทำงานเป็นคนสร้างไทม์ไลน์แล้วโยนให้ทีม ก็จะได้ส่วนผสมที่เลวร้ายที่สุดคือ การประมาณที่ไม่แม่น + ทีมที่ไม่ได้รู้สึกเป็นเจ้าของตัวเลขนั้น
  • เมื่อความจริงคลาดเคลื่อน ก็ไม่รู้ว่าเป็นความรับผิดชอบของใคร ทุกคนจึงโทษกันไปมา
  • ผู้ที่ลงมือทำงานต้องเป็นเจ้าของการประมาณเสมอ และการยัดเยียดการประมาณจากคนนอกไม่ใช่ความมองโลกในแง่ดี แต่เป็น สัญญาณเตือนของเกมโยนความผิด
• เมื่อหมกมุ่นกับเดดไลน์ บทสนทนาทุกอย่างจะไหลไปสู่คำถามว่า "จะทำอย่างไรให้ทันเดดไลน์?" และคำถามว่า เรากำลังสร้างสิ่งที่ถูกต้องอยู่หรือไม่ ก็จะหายไปจากสายตา
• ต้องแยก 3 สิ่งที่องค์กรส่วนใหญ่มักสับสนออกจากกัน:
  1. การประมาณ (Estimate): การคาดการณ์เชิงความน่าจะเป็นภายใต้ระดับความไม่แน่นอนปัจจุบัน ซึ่งต้องมาพร้อมการระบุช่วงและสมมติฐานอย่างชัดเจน
     • เช่น: "ถ้า requirement ไม่เปลี่ยน และเราได้คำตอบเรื่อง API ภายในวันศุกร์หน้า คิดว่าใช้เวลา 4–6 สัปดาห์"
  2. แผน (Plan): คำมั่นต่อ กระบวนการ ไม่ใช่ต่อผลลัพธ์
     • เช่น: "เราจะทำงาน 2 สัปดาห์ แล้วทบทวนความคืบหน้าและให้การคาดการณ์ที่อัปเดตแล้ว"
  3. คำมั่นสัญญา (Commitment): คำมั่นที่ผูกกับผลลัพธ์ ซึ่งควรให้ไม่บ่อยและอย่างระมัดระวังเฉพาะเมื่อกรวยแคบลงมากพอแล้ว
     • การให้คำมั่นตั้งแต่ช่วงแนวคิดเริ่มต้นไม่ใช่ความกล้า แต่คือ ความประมาท
     • หากถูกบีบให้ต้องให้คำมั่น ควรพยายามให้คำมั่นกับ ลำดับความสำคัญ แทนไทม์ไลน์ และหากทำไม่ได้ อย่างน้อยก็ควรทำให้ ระดับความเชื่อมั่นเป็นส่วนหนึ่งของคำมั่นนั้น
• รากของความผิดปกติคือแนวปฏิบัติในองค์กรที่ปฏิบัติต่อการประมาณเหมือนเป็นคำมั่นทันทีที่ถูกเอ่ยออกมา
  • เข้าใจได้ว่าทำไม #NoEstimates จึงเสนอทางออกเชิงการเมืองแบบไม่พูดตัวเลขเลย แต่ต้นทุนคือองค์กรจะสูญเสียความสามารถในการจัดสรรทรัพยากร จัดลำดับ dependency และสนทนากับผู้มีส่วนได้ส่วนเสียภายนอกอย่างตรงไปตรงมา
• ทางออกที่ดีกว่าคือ สอนเรื่องกรวยนี้ ให้ความรู้กับผู้มีส่วนได้ส่วนเสีย และทุกครั้งที่ให้ตัวเลขต้องระบุให้ชัดว่าอะไรคือการประมาณ อะไรคือคำมั่น
  • มันยากกว่าและใช้เวลามากกว่าการปฏิเสธการประมาณ แต่แทนที่จะหลีกเลี่ยงสถานการณ์ที่ความเชื่อใจอาจพัง ก็เป็นการ สร้างความเชื่อใจ

วิธีปฏิบัติที่ดีในการประมาณ

• ประมาณให้ช้าที่สุดเท่าที่จำเป็น: เพราะกรวยนี้จะแคบลงได้ผ่านการเรียนรู้เท่านั้น จึงควรทำ spike เขียนโค้ดเชิงสำรวจ และคุยกับทีมที่ต้องเชื่อมต่อก่อน
  • ต้องต้านแรงกดดันที่ให้ตัวเลขก่อนจะได้เรียนรู้มากพอจะสร้างตัวเลขที่มีความหมาย
• อย่าแตกงานละเอียดเกินไปก่อนเริ่ม: เมื่อเผชิญความไม่แน่นอน เรามักอยากหั่นงานเป็นชิ้นเล็กลง แต่การแตกงานมากพอไม่ได้แปลว่าจะได้การประมาณที่เชื่อถือได้
  • การวางแผนล่วงหน้าอย่างประณีตมัก แข็งตัว จนทีมยังยึดติดกับมันแม้จะไม่สะท้อนความจริงแล้ว และสุดท้ายยิ่งทำให้ความคลาดเคลื่อนดูสับสน
  • ควรเริ่มจาก แผนง่ายๆ ที่ปรับได้ง่าย
• ให้เป็นช่วง ไม่ใช่จุดเดียว: "3–5 สัปดาห์" ซื่อสัตย์กว่า "4 สัปดาห์" แต่ยังใช้งานได้แทบเท่ากัน
  • หากจำเป็นต้องให้เลขเดียว ก็ให้ค่ากลางของช่วง พร้อมระบุว่านั่นคือค่ากลาง
  • ควรตกลงกับผู้มีส่วนได้ส่วนเสียเรื่อง การใช้ Cone of Uncertainty และอ้างอิงมันทุกครั้งที่ส่งมอบการประมาณ
• ทำให้สมมติฐานมองเห็นได้: การประมาณดีได้เท่ากับสมมติฐานของมัน จึงต้องระบุให้ชัด เช่น สมมติว่า scope ไม่เปลี่ยน สมมติว่าใช้แนวทางเทคนิคแบบใด หรือสมมติว่าอีกทีมจะส่งมอบภายในวันไหน
  • สมมติฐานที่มีอยู่แค่ในหัวจะกลายเป็น ความเข้าใจผิด ที่โผล่ออกมาในเวลาที่เลวร้ายที่สุด
• ติดตามความแม่นยำได้ แต่ห้ามลงโทษ: เป้าหมายคือการปรับเทียบ (calibration) ไม่ใช่การตำหนิ
  • ทีมที่ประมาณร่วมกันมา 6 เดือนและทบทวนความแม่นยำ จะพัฒนาความรู้สึกร่วมกันว่าโดยระบบแล้วตัวเองมักประเมินเกินหรือต่ำในจุดไหน
  • หากลงโทษการประมาณที่ไม่แม่น ทีมก็จะป้องกันตัวด้วยการเผื่อเกิน และ การประมาณที่เผื่อเกินมีประโยชน์น้อยกว่าการประมาณที่ซื่อสัตย์แม้ไม่แน่นอน
  • การประมาณพลาดในขอบเขต Complex ไม่ใช่ข้อบกพร่องด้านนิสัย แต่เป็น คุณสมบัติของขอบเขตนั้นเอง
• เกิน 8 ให้แตกย่อย: สตอรี่ Fibonacci ขนาด 13 หรือ 21 แทบทุกครั้งมักมีความซับซ้อนซ่อนอยู่ที่ยังไม่ถูกเปิดเผย
  • การแตกย่อยบังคับให้เราอธิบายอย่างชัดเจนว่าแท้จริงแล้วเรารู้อะไรอยู่บ้าง
  • บ่อยครั้งจะพบว่าใน 3 สตอรี่ย่อย มี 2 อันเล็ก และ ความไม่แน่นอนทั้งหมดไปรวมอยู่ในอีก 1 อัน

ความจริงที่ทำให้ทั้งสองฝั่งอึดอัด

• การประมาณไม่ใช่การคำนวณ แต่เป็น รูปแบบหนึ่งของการสื่อสาร และจุดประสงค์ไม่ใช่การทำนายอนาคต แต่คือ การประสานงานและสนับสนุนการตัดสินใจภายใต้ความไม่แน่นอน
• รูปแบบความล้มเหลวของการประมาณไม่ได้เกิดแบบสุ่ม แต่เป็นแบบ เป็นระบบ: ประมาณเร็วเกินไป ปฏิบัติต่อช่วงเหมือนเป็นจุดเดียว ปฏิบัติต่อการประมาณเหมือนเป็นคำมั่น มองข้ามตำแหน่งทางญาณวิทยาใน Cone of Uncertainty และยัดเยียดการประมาณให้ผู้ลงมือทำ
• สิ่งที่ Dalmijn เรียกว่า Complex Work Estimation Fallacy คือความเชื่อที่ว่าถ้าประมาณให้บ่อยขึ้น ปรับปรุงกระบวนการ และทำงานร่วมกันนานขึ้น สุดท้ายก็จะได้การประมาณที่แม่นยำ
  • ในขอบเขต Complex ขีดจำกัดของความแม่นยำในการประมาณไม่ได้เป็นฟังก์ชันของความเป็นผู้ใหญ่ของทีม แต่เป็น ฟังก์ชันของขอบเขตนั้นเอง
  • เราอาจดีขึ้นได้ แต่จะไม่แม่นยำแบบเป๊ะขึ้น และหากสับสนสองสิ่งนี้ องค์กรก็จะลงโทษทีมในเรื่องที่โดยเนื้อแท้อยู่เหนือการควบคุมของทีม
• การปฏิเสธการประมาณเป็นเพียง การถอนตัวออกจากเกมการประสานงาน
  • มันอาจใช้ได้กับทีมที่ทำงานเป็นอิสระเต็มที่ ปล่อยของต่อเนื่อง และไม่มีคำมั่นภายนอก แต่ในเส้นทางอาชีพส่วนใหญ่ เราไม่ได้อยู่ในบริบทแบบนั้น
• ตัวเลือกที่แท้จริงไม่ใช่ "การประมาณที่แย่" กับ "ไม่มีการประมาณ" แต่คือ การประมาณแบบไร้สำนึกและคุณภาพต่ำ (ซึ่งองค์กรจะสร้างขึ้นมาอยู่ดีแม้ไม่มีคุณ) เทียบกับ การประมาณแบบชัดเจน ถ่อมตน อิงช่วง และมองเห็นสมมติฐานได้
• เพราะการประมาณงานอยู่ในขอบเขต Complex เราจึงต้องเข้าหามันด้วย กรอบคิดแบบความซับซ้อน: สำรวจ สังเกต ตอบสนอง ประมาณ ติดตาม และปรับเทียบอย่างวนซ้ำ
• กรวยนี้ไม่ได้แคบลงด้วยการรอคอย แต่แคบลงด้วย การเรียนรู้