మీరు వేగంగా వెళ్లమని అడిగారు కానీ ఎక్కువ మంది వ్యక్తులు ఇవ్వలేదు అన్నప్పుడు మీరు ఏమి చేస్తారు?

Question

Accepted Answer

వ్యక్తులను జోడించడం short term లో ఎలాగైనా అరుదుగా team ను వేగంగా చేస్తుంది, కాబట్టి నిజమైన ప్రశ్న: team యొక్క *సమయం నిజంగా ఎక్కడికి వెళ్తోంది*, మరియు దాని గురించి నేను ఏమి మార్చగలను? నేను "వేగంగా వెళ్లు" ను ఎక్కువ గంటలు పనిచేయమనే ఒక డిమాండ్ గా కాకుండా, leverage ను కనుగొనమనే ఒక prompt గా treat చేస్తాను.

## నేను వేగం కోసం ఎక్కడ చూస్తాను

- **corners కాదు, scope ను కత్తిరించండి.** వేగంగా ship చేయడానికి వేగవంతమైన మార్గం తక్కువ నిర్మించడం. ruthlessly prioritize చేయడానికి మరియు విలువను అందించే అతిచిన్న version ను కనుగొనడానికి నేను PM తో పనిచేస్తాను. చాలా features 20% పనిలో 80% విలువ.
- **friction మరియు wait time ను తొలగించండి.** తరచుగా bottleneck coding వేగం కాదు — ఇది slow CI, flaky tests, painful deploys, slow reviews, లేదా approvals కోసం వేచి ఉండటం. ఒక 30-నిమిషాల build లేదా ఒక రెండు రోజుల review turnaround ను సరిచేయడం ఉచితంగా నిజమైన velocity ను కొంటుంది.
- **work-in-progress ను తగ్గించండి.** పది విషయాలను juggle చేసే teams ఏదీ పూర్తి చేయవు. సమాంతరంగా తక్కువ items పై దృష్టి పెట్టడం విషయాలను త్వరగా ship చేస్తుంది.
- **పునరావృతమైన దాన్ని automate చేయండి.** Manual testing, manual releases, manual environment setup — ఒకసారి పెట్టుబడి పెట్టండి, ఎప్పటికీ ఆదా చేయండి.
- **మిమ్మల్ని చురుకుగా నెమ్మదిస్తున్న debt ను చెల్లించండి.** అదంతా కాదు; team రోజూ తడబడే భాగం మాత్రమే.
- **focus time ను రక్షించండి.** తక్కువ meetings మరియు interruptions ఏ tool కంటే పెద్ద విజయం కావచ్చు.

## నేను ask కు ఎలా స్పందిస్తాను

నేను కేవలం "అసాధ్యం" అని చెప్పను లేదా నిశ్శబ్దంగా అంగీకరించను. నేను ఒక **trade-off** తో స్పందిస్తాను: "మనం features A మరియు B ను కత్తిరిస్తే, లేదా testing పై ఎక్కువ risk ను అంగీకరిస్తే ఆ తేదీని తాకగలము. ఇదిగో నేను సిఫార్సు చేసేది." ఇది వేగాన్ని ఒక నిశ్శబ్ద నాణ్యత జూదం కాకుండా ఒక shared, conscious నిర్ణయంగా చేస్తుంది.

## నివారించాల్సిన లోపాలు

- **Overtime ను తప్పనిసరి చేయడం.** ఇది ఒక చిన్న sprint ను కొంటుంది మరియు దాన్ని burnout, bugs, మరియు attrition తో తిరిగి చెల్లిస్తుంది.
- **tests మరియు reviews ను నిశ్శబ్దంగా skip చేయడం.** ఈరోజు వేగం, వచ్చే నెల ఒక outage.
- **ఏమీ మార్చకుండా తేదీకి yes అనడం** — అది కేవలం ఆశించడం, మరియు ఆశ deadlines ను కోల్పోతుంది.

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

Sustainable వేగం వ్యక్తులను పిండడం నుండి కాదు, వ్యర్థాన్ని తొలగించడం నుండి వస్తుంది. ఒత్తిడికి స్పష్టమైన trade-offs మరియు process improvements తో స్పందించే Tech Lead నిజంగా వేగవంతమైన మరియు మన్నికైన team ను నిర్మిస్తాడు — sprint చేసి, crash అయి, దాని ఉత్తమ engineers ను కోల్పోయే team కు బదులుగా.