WBS 뒤에 숨은 심리: 왜 우리의 뇌는 대규모 작업 추정에 실패할까

Source: Dev.to

인지 추정 결함

계획 오류
심리학자 다니엘 카너먼의 연구에 따르면 인간은 작업 기간을 평균 2.5 × 정도 체계적으로 과소평가합니다.

# Industry analysis (1000 tasks examined)
estimation_accuracy = {
    "1-hour task": {"estimated": 1, "actual": 1.2, "error": "20%"},
    "8-hour task": {"estimated": 8, "actual": 12, "error": "50%"},
    "40-hour task": {"estimated": 40, "actual": 100, "error": "150%"},
    "200-hour project": {"estimated": 200, "actual": 500, "error": "250%"},
}
# Observation: Estimation error grows exponentially with task size

대규모 작업이 예측을 거스르는 이유

조지 밀러의 “마법의 숫자 일곱, 플러스 혹은 마이너스 두”를 기억하세요. 인간의 작업 기억은 한 번에 7 ± 2 항목만 처리할 수 있으며, 이를 초과하면 인지 처리가 붕괴됩니다.

// Cognitive capacity constraints
const cognitive_limits = {
  working_memory: "7±2 items", // Miller's Law

  // 8‑hour task = cognitively manageable
  small_task: {
    components: 5,
    interactions: 10,
    complexity: "linear",
  },

  // 200‑hour task = cognitive overload
  large_task: {
    components: 50,
    interactions: 1225, // 50 * 49 / 2
    complexity: "exponential",
    hidden_work: "40% of total", // Unseen complexity
  },
};

숨겨진 작업 현상

우리가 간과하는 것

PMI 연구에 따르면 “보이지 않는 작업”이 프로젝트 지연의 78 %를 차지한다고 합니다. 개발자들은 종종 코딩 시간만을 고려하고 테스트, 디버깅, 문서화 등을 무시합니다.

# Developer's initial (incomplete) estimate
developer_estimate = {"coding": 20, "done": "Complete!"}  # Cognitive bias

# Reality of required work (industry data)
actual_work = {
    "coding": 20,
    "debugging": 8,
    "edge cases": 5,
    "refactoring": 4,
    "code review": 3,
    "review fixes": 3,
    "test writing": 5,
    "documentation": 2,
    "deployment prep": 2,
    "monitoring setup": 1,
    "rollback plan": 1,
}
# Total: 54 hours (2.7 × the original estimate)

산업 연구에 따르면 “보이지 않는 작업”이 전체 노력의 약 70 %를 차지합니다.

빙산 모델

Visible above water (30%)
├── Core feature development
├── Basic testing
└── Deployment

Hidden below water (70%)
├── Exception handling
├── Edge case coverage
├── Performance tuning
├── Security measures
├── Error handling
├── Logging infrastructure
├── Monitoring systems
├── Documentation
├── Compatibility testing
├── Load testing
├── Disaster recovery
└── Operational readiness

파킨슨 법칙과 학생 증후군

파킨슨 법칙

시릴 파킨슨은 **“작업은 할당된 시간을 채우도록 확장된다.”**라고 관찰했습니다. 실제 A/B 테스트는 더 촉박한 마감이 효율성과 품질을 향상시킨다는 것을 확인했습니다.

// Experimental results (real A/B testing)
const experiment = {
  group_A: {
    deadline: "3 days",
    actual_work: "8 hours",
    total_time: "3 days", // Consumed all allotted time
    quality: 7,
    notes: "Started relaxed, panicked at deadline",
  },
  group_B: {
    deadline: "1 day",
    actual_work: "8 hours",
    total_time: "1 day", // Completed efficiently
    quality: 8,
    notes: "Intense focus, eliminated waste",
  },
};
// Conclusion: Smaller time units yield better efficiency and quality

연장된 마감은 종종 역효과를 낳습니다.

학생 증후군

미루기는 예측 가능한 패턴을 따릅니다: 노력은 마감이 다가올 때만 급증합니다.

def work_intensity(days_until_deadline):
    """Work intensity pattern (psychological research)"""
    if days_until_deadline > 7:
        return "5%"   # Plenty of time → Procrastination
    elif days_until_deadline > 3:
        return "20%"  # Should start → Planning only
    elif days_until_deadline > 1:
        return "50%"  # Must start now → Finally coding
    else:
        return "200%" # Crunch time → Overtime hell

# WBS approach: create multiple short deadlines
# Monday: Finish Task 1 (8 h)
# Tuesday: Finish Task 2 (8 h)
# Wednesday: Finish Task 3 (8 h)
# → Consistent daily intensity, no overtime

짧고 빈번한 마감일을 사용하는 팀은 초과 근무를 주당 3 × 에서 월 1회로 줄였습니다.

추정 불확실성의 수학

확률 기반 추정

import numpy as np

def task_completion_probability(estimated_hours):
    """Return a simple probability distribution for task completion."""
    if estimated_hours <= 8:
        # Small task: Normal distribution
        mean = estimated_hours
        std = estimated_hours * 0.2
    else:
        # Large task: Log‑normal distribution (long tail)
        mean = estimated_hours * 2.5  # Average 2.5× underestimate
        std = estimated_hours * 1.5

    return {
        "50%_probability": mean,
        "90%_probability": mean + 2 * std,
        "worst_case": mean + 3 * std,
    }

# Example usage
small_task = task_completion_probability(8)
# {'50%_probability': 8, '90%_probability': 11.2, 'worst_case': 12.8}

large_task = task_completion_probability(80)
# {'50%_probability': 200, '90%_probability': 440, 'worst_case': 560}
# Can balloon up to 7×!

앵커링 효과와 확증 편향

앵커링

첫 번째 추정이 이후 판단에 크게 영향을 미칩니다.

// Experiment: PM provides initial estimate
const anchoring_effect = {
  scenario_1: {
    pm_suggestion: "1 week",
    developer_estimate: "1.5 weeks", // Influenced by PM
    actual_time: "3 weeks",          // Missed target
  },
  // Additional scenarios would follow the same pattern
};