El arte de decir no: proteger el enfoque del equipo de ingeniería

// ❌ The yes-to-everything pattern
interface TeamCapacity {
  engineers: number;
  sprintPointsPerEngineer: number;
  totalCapacity: number;
  committedWork: number;
  incomingRequests: WorkRequest[];
}
 
function planSprint(team: TeamCapacity): SprintPlan {
  // Accept everything, hope it works out
  return {
    committed: [
      ...team.committedWork,
      ...team.incomingRequests,
    ],
    // Sprint is 150% over capacity
    // Nothing gets done well
    // Team burns out
  };
}

// ✅ Explicit capacity-based prioritization
interface WorkRequest {
  id: string;
  title: string;
  estimatedPoints: number;
  requestor: string;
  businessImpact: "critical" | "high" | "medium" | "low";
  deadline: Date | null;
  alternatives: string[]; // Can this be solved another way?
}
 
interface CapacityPlan {
  totalPoints: number;
  committed: WorkRequest[];     // Already committed — protected
  newAccepted: WorkRequest[];   // New work that fits
  declined: WorkRequest[];      // Won't fit this sprint
  negotiated: WorkRequest[];    // Reshaped to fit
  remainingCapacity: number;
}
 
function evaluateRequests(
  capacity: number,
  committed: WorkRequest[],
  incoming: WorkRequest[]
): CapacityPlan {
  const committedPoints = committed.reduce(
    (sum, w) => sum + w.estimatedPoints,
    0
  );
  let remaining = capacity - committedPoints;
 
  // Reserve 20% for unexpected work
  remaining = remaining * 0.8;
 
  const sorted = [...incoming].sort((a, b) => {
    const impactOrder = {
      critical: 0,
      high: 1,
      medium: 2,
      low: 3,
    };
    return impactOrder[a.businessImpact] -
      impactOrder[b.businessImpact];
  });
 
  const accepted: WorkRequest[] = [];
  const declined: WorkRequest[] = [];
 
  for (const request of sorted) {
    if (request.estimatedPoints <= remaining) {
      accepted.push(request);
      remaining -= request.estimatedPoints;
    } else {
      declined.push(request);
    }
  }
 
  return {
    totalPoints: capacity,
    committed,
    newAccepted: accepted,
    declined,
    negotiated: [],
    remainingCapacity: remaining,
  };
}

// Negotiation responses for common scenarios
interface NegotiationResponse {
  requestType: string;
  response: string;
  technique: string;
}
 
const negotiationPlaybook: NegotiationResponse[] = [
  {
    requestType: "Urgent feature request",
    response:
      "We can do a minimal version by Friday that covers " +
      "the core use case, or the full version in 3 weeks. " +
      "Which timeline works for your goal?",
    technique: "Scope trade-off — let them choose",
  },
  {
    requestType: "Cross-team integration",
    response:
      "We'd love to support this. Here's our API " +
      "documentation and a sample integration. Your team " +
      "can build the integration, and we'll review and " +
      "support it.",
    technique: "Shift ownership — provide enablement",
  },
  {
    requestType: "Tech debt cleanup",
    response:
      "I agree this needs attention. Let's allocate 20% " +
      "of next quarter's capacity to this area. I'll write " +
      "up a phased plan.",
    technique: "Agree and schedule — don't dismiss",
  },
  {
    requestType: '"Quick" unplanned work',
    response:
      "Happy to help. This is about 3 points of work. " +
      "To fit it in this sprint, which of these items " +
      "should we move out?",
    technique: "Make the trade-off visible",
  },
  {
    requestType: "Executive pet project",
    response:
      "I want to make sure we build the right thing. " +
      "Can we spend 2 days on a spike to validate the " +
      "approach and estimate accurately before committing?",
    technique: "Time-boxed investigation",
  },
];

// Build the case for declining or deferring work
interface DeclineRationale {
  request: string;
  currentCommitments: string[];
  capacityData: {
    totalCapacity: number;
    currentLoad: number;
    utilizationPercent: number;
  };
  riskAssessment: string;
  alternativeProposal: string;
}
 
function buildDeclineCase(
  request: WorkRequest,
  sprintState: CapacityPlan
): DeclineRationale {
  const utilization = Math.round(
    ((sprintState.totalPoints -
      sprintState.remainingCapacity) /
      sprintState.totalPoints) *
      100
  );
 
  return {
    request: request.title,
    currentCommitments: sprintState.committed.map(
      (w) => w.title
    ),
    capacityData: {
      totalCapacity: sprintState.totalPoints,
      currentLoad:
        sprintState.totalPoints -
        sprintState.remainingCapacity,
      utilizationPercent: utilization,
    },
    riskAssessment:
      utilization > 90
        ? "Team is at risk of missing current commitments. " +
          "Adding work increases probability of delays " +
          "across all projects."
        : "Team has minimal buffer for unexpected issues.",
    alternativeProposal:
      `We can start this in Sprint ${
        getCurrentSprint() + 1
      } ` +
      `(${getSprintStartDate(getCurrentSprint() + 1)}). ` +
      `Alternatively, if this is higher priority than ` +
      `${sprintState.committed[sprintState.committed.length - 1]?.title}, ` +
      `we can swap them.`,
  };
}

## For peer teams requesting work
 
Hi [Name],
 
Thanks for thinking of us for [request]. I understand
why this matters for [their goal].
 
Right now, our team is at [X]% capacity with
[list top 2-3 commitments]. Taking this on would risk
[specific consequence].
 
Here's what I can offer:
- [Alternative 1: self-service option]
- [Alternative 2: reduced scope they could use now]
- [Alternative 3: schedule for future sprint]
 
Would any of these work for your timeline? Happy to
chat more about what would be most useful.
 
## For leadership requests
 
I want to make sure we execute this well. Here's our
current capacity picture:
 
Currently committed:
- [Project A] — shipping [date]
- [Project B] — [X]% complete
- [Maintenance/on-call] — [X] points/sprint
 
This new request is approximately [X] points.
To maintain delivery quality, I'd recommend one of:
 
1. Start in [future sprint] after [Project A] ships
2. Reduce scope to [minimal version] and deliver by [date]
3. Replace [Project B] with this — [trade-off description]
 
Which approach best aligns with business priorities?

// ❌ Heroic culture — say yes, work overtime
function handleRequest_heroic(request: WorkRequest): void {
  console.log("We'll make it work somehow");
  team.workWeekend();
  team.skipTests();
  team.ignoreCodeReview();
  // Delivers on time, quality degrades, team burns out
}

// ✅ Sustainable culture — trade-offs are explicit
interface TeamAgreement {
  maxWIPPerEngineer: number;
  capacityReservePercent: number;
  sprintCommitmentPolicy: string;
  escalationPath: string;
}
 
const teamAgreement: TeamAgreement = {
  maxWIPPerEngineer: 2,
  capacityReservePercent: 20,
  sprintCommitmentPolicy:
    "Once committed, work is only replaced by " +
    "P0 incidents or executive override with " +
    "explicit deprioritization of existing items",
  escalationPath:
    "If requestor disagrees with prioritization, " +
    "escalate to shared manager for trade-off decision",
};