team overload ஆகும்போது, முதலில் எதில் வேலை செய்வது என்று தீர்மானிக்க நீங்கள் என்ன அளவுகோல்களைப் பயன்படுத்துகிறீர்கள்?

Question

IT Interview Practice · Accepted Answer

**முதலில் நான் overload-ஐ புலப்படுத்துகிறேன் மற்றும் எல்லாம் பொருந்துகிறது என்று பாசாங்கு செய்வதை நிறுத்துகிறேன்.** ஒரு team overload ஆகும்போது, தோல்வி முறை என்னவென்றால் எல்லாவற்றிலும் கொஞ்சம் செய்து எதையும் முடிக்காதது. வெளிப்படையான முன்னுரிமைப்படுத்தலை வற்புறுத்தி, thrash-இலிருந்து team-ஐ பாதுகாப்பது என் வேலை.

## நான் பயன்படுத்தும் அளவுகோல்கள்

- **Impact vs. effort.** வழங்கப்பட்ட மதிப்பை செலவுக்கு எதிராக வேலையை தரவரிசைப்படுத்துகிறேன். High-impact, low-effort items முதலில் செல்கின்றன; high-effort, low-impact items வெட்டப்படுகின்றன அல்லது வெளிப்படையாக ஒத்திவைக்கப்படுகின்றன.
- **Reversibility மற்றும் urgency.** மீள முடியாத அல்லது time-boxed எதுவும் (ஒரு security fix, ஒரு contractual deadline, ஒரு launch dependency) வரிசையில் முன்னேறுகிறது.
- **தாமதத்தின் செலவு.** சில வேலைகள் காத்திருக்கும் நேரம் அதிகமாகும்போது அதிக விலையாகின்றன (கூட்டாகும் **tech debt**, ஒரு deadline அபராதம்); சில அடுத்த மாதமும் அதேதான். செலவு எவ்வளவு வேகமாக வளர்கிறது என்பதன்படி முன்னுரிமைப்படுத்துகிறேன்.
- **மற்றவர்களை block செய்வது.** மற்றவர்களையோ teams-ஐயோ unblock செய்யும் வேலை அதன் சொந்த மதிப்பைத் தாண்டி ஒரு multiplier கொண்டுள்ளது.
- **Risk.** இது தவறாகவோ தாமதமாகவோ இருந்தால் செலவு என்ன? முதலில் விலையுயர்ந்த failure-க்கு எதிராக பாதுகாக்கவும்.

## ஒரு எளிய framework

| Bucket | எடுத்துக்காட்டுகள் | நடவடிக்கை |
|---|---|---|
| Critical + urgent | Production incident, security hole | இப்போது செய்யவும், மற்ற வேலையை விடவும் |
| High value, not urgent | முக்கிய roadmap feature | திட்டமிட்டு பாதுகாக்கவும் |
| Low value, urgent | சத்தமான ஆனால் சிறிய கோரிக்கை | பின்னுக்குத் தள்ளவும் அல்லது delegate செய்யவும் |
| Low value, not urgent | Nice-to-haves | இல்லை என்று சொல்லவும், வெளிப்படையாக வெட்டவும் |

## நான் அதை எப்படி இயக்குகிறேன்

- ஐந்து இணை priority-ones அல்ல, ஒரு **ஒற்றை தரவரிசை பட்டியலை** உருவாக்குங்கள். எல்லாம் ஒரு முன்னுரிமை என்றால், எதுவும் இல்லை.
- trade-offs-ஐ **stakeholders**-க்கு எளிய சொற்களில் தெரிவிக்கவும்: "இந்த sprint-இல் A அல்லது B செய்யலாம், இரண்டும் அல்ல. எது முக்கியம்?"
- கவனத்தை பாதுகாக்கவும்: work in progress-ஐ வரம்பிடவும், context switching-ஐ குறைக்கவும், மற்றும் sprint நடுவில் புதிய interrupts-இலிருந்து team-ஐ பாதுகாக்கவும்.

## தவறுகள்

- data-வுக்குப் பதிலாக சத்தமான stakeholder முன்னுரிமையை அமைக்க அனுமதிப்பது.
- எல்லாவற்றுக்கும் yes சொல்வது, இது உண்மையில் "randomness தீர்மானிக்க விடுகிறேன்" என்று சொல்வது.
- scope-க்கு பொருந்த தரத்தை அமைதியாக வெட்டுவது; அது செலவை production-க்கு நகர்த்துகிறது.

## இது ஏன் முக்கியம்

overload-இன் கீழ், இரக்கமற்ற, வெளிப்படையான முன்னுரிமைப்படுத்தல்தான் ஒரு மன அழுத்தமான, thrashing team-ஐ உண்மையில் முக்கியமான விஷயங்களை ship செய்யும் ஒன்றாக மாற்றுகிறது, மேலும் அமைதியாக எல்லாவற்றையும் தவறவிடுவதற்குப் பதிலாக trade-offs பற்றி நேர்மையாக இருப்பதன் மூலம் stakeholders-உடன் நம்பிக்கையைப் பேணுகிறது.

Bucket	எடுத்துக்காட்டுகள்	நடவடிக்கை
Critical + urgent	Production incident, security hole	இப்போது செய்யவும், மற்ற வேலையை விடவும்
High value, not urgent	முக்கிய roadmap feature	திட்டமிட்டு பாதுகாக்கவும்
Low value, urgent	சத்தமான ஆனால் சிறிய கோரிக்கை	பின்னுக்குத் தள்ளவும் அல்லது delegate செய்யவும்
Low value, not urgent	Nice-to-haves	இல்லை என்று சொல்லவும், வெளிப்படையாக வெட்டவும்

நான் பயன்படுத்தும் அளவுகோல்கள்

ஒரு எளிய framework

நான் அதை எப்படி இயக்குகிறேன்

தவறுகள்

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்