team overload అయినప్పుడు, మొదట దేనిపై పని చేయాలో నిర్ణయించడానికి మీరు ఏ ప్రమాణాలను ఉపయోగిస్తారు?

Question

Accepted Answer

**ముందుగా నేను overload ను కనిపించేలా చేసి అన్నీ సరిపోతాయని నటించడం ఆపేస్తాను.** ఒక team overload అయినప్పుడు, వైఫల్య విధానం ప్రతిదానిలో కొంచెం చేయడం మరియు ఏదీ పూర్తి చేయకపోవడం. స్పష్టమైన prioritization ను బలవంతం చేయడం మరియు thrash నుండి team ను రక్షించడం నా పని.

## నేను వర్తింపజేసే ప్రమాణాలు

- **Impact vs. effort.** నేను పనిని ఖర్చుతో పోలిస్తే అందించిన విలువ ద్వారా rank చేస్తాను. High-impact, low-effort items మొదట వెళ్తాయి; high-effort, low-impact items బహిరంగంగా కత్తిరించబడతాయి లేదా వాయిదా వేయబడతాయి.
- **Reversibility మరియు urgency.** irreversible లేదా time-boxed అయిన ఏదైనా (ఒక security fix, ఒక contractual deadline, ఒక launch dependency) queue ను దాటి దూకుతుంది.
- **Cost of delay.** కొంత పని ఎక్కువసేపు వేచి ఉంటే ఖరీదు అవుతుంది (compounding **tech debt**, ఒక deadline penalty); కొన్ని వచ్చే నెలలో అదే ఉంటాయి. ఖర్చు ఎంత వేగంగా పెరుగుతుందనే దాని ద్వారా నేను prioritize చేస్తాను.
- **ఇతరులను blocking చేయడం.** ఇతర వ్యక్తులను లేదా teams ను unblock చేసే పనికి దాని స్వంత విలువకు మించి ఒక multiplier ఉంటుంది.
- **Risk.** ఇది తప్పు లేదా ఆలస్యం అయితే ఖర్చు ఏమిటి? ముందుగా ఖరీదైన వైఫల్యం నుండి రక్షించండి.

## ఒక సరళమైన framework

| Bucket | ఉదాహరణలు | చర్య |
|---|---|---|
| Critical + urgent | Production incident, security hole | ఇప్పుడే చేయండి, ఇతర పనిని వదలండి |
| High value, not urgent | కీలక roadmap feature | Schedule చేసి రక్షించండి |
| Low value, urgent | బిగ్గరగా కానీ చిన్న request | తిరిగి నెట్టండి లేదా delegate చేయండి |
| Low value, not urgent | Nice-to-haves | వద్దు అనండి, స్పష్టంగా కత్తిరించండి |

## నేను దాన్ని ఎలా నడుపుతాను

- ఐదు సమాంతర priority-ones కాకుండా, ఒక **single ranked list** ను తయారు చేయండి. అన్నీ priority అయితే, ఏదీ కాదు.
- **stakeholders** కు సాదా పదాలలో trade-offs ను communicate చేయండి: "మేము ఈ sprint లో A లేదా B చేయగలము, రెండూ కాదు. ఏది ఎక్కువ ముఖ్యం?"
- focus ను రక్షించండి: work in progress ను పరిమితం చేయండి, context switching ను తగ్గించండి, మరియు sprint మధ్యలో కొత్త interrupts నుండి team ను కాపాడండి.

## లోపాలు

- data కు బదులుగా అత్యంత బిగ్గరగా ఉన్న stakeholder ను priority నిర్ణయించనివ్వడం.
- ప్రతిదానికీ yes అనడం, ఇది నిజంగా "నేను randomness ను నిర్ణయించనిస్తాను" అనడం.
- scope కు సరిపోయేలా నాణ్యతను నిశ్శబ్దంగా కత్తిరించడం; అది కేవలం ఖర్చును production కు తరలిస్తుంది.

## ఇది ఎందుకు ముఖ్యం

Overload కింద, నిర్దాక్షిణ్యమైన, పారదర్శక prioritization అనేది ఒక ఒత్తిడిలో ఉన్న, thrashing team ను నిజంగా ముఖ్యమైన విషయాలను ship చేసే team గా మారుస్తుంది, మరియు అన్నింటినీ నిశ్శబ్దంగా కోల్పోవడానికి బదులుగా trade-offs గురించి నిజాయితీగా ఉండటం ద్వారా stakeholders తో నమ్మకాన్ని కాపాడుతుంది.

Bucket	ఉదాహరణలు	చర్య
Critical + urgent	Production incident, security hole	ఇప్పుడే చేయండి, ఇతర పనిని వదలండి
High value, not urgent	కీలక roadmap feature	Schedule చేసి రక్షించండి
Low value, urgent	బిగ్గరగా కానీ చిన్న request	తిరిగి నెట్టండి లేదా delegate చేయండి
Low value, not urgent	Nice-to-haves	వద్దు అనండి, స్పష్టంగా కత్తిరించండి