किसी developer के प्रदर्शन का मूल्यांकन करने के लिए आप किन मानदंडों का उपयोग करते हैं?

Question

Accepted Answer

मैं developers का मूल्यांकन उनके द्वारा उत्पन्न **परिणामों और टीम पर पड़ने वाले प्रभाव** पर करता हूँ, न कि कच्चे output मेट्रिक्स जैसे lines of code, commits, या story points पर। अच्छा मूल्यांकन एक ही sprint नहीं, बल्कि एक सार्थक समय अवधि में कई संकेतों का त्रिकोणीकरण करता है।

## मैं वास्तव में क्या देखता हूँ

- **प्रभाव और ownership।** क्या वे ऐसा काम ship करते हैं जो product को आगे बढ़ाता है या दूसरों को unblock करता है? क्या वे किसी समस्या को end to end मालिक बनाते हैं, जिसमें rollout, monitoring, और फ़ॉलो-अप बग्स जैसे गड़बड़ हिस्से शामिल हैं?
- **गुणवत्ता और विश्वसनीयता।** क्या उनका कोड production में टिकता है? क्या वे codebase को बेहतर छोड़ रहे हैं या **tech debt** जमा कर रहे हैं जिसे दूसरों को चुकाना पड़ता है?
- **सही स्तर पर स्वायत्तता।** एक mid-level इंजीनियर जिसे नियमित कार्यों पर hand-holding चाहिए, वह एक senior से अलग है जो एक अस्पष्ट समस्या ले सकता है और एक योजना लौटा सकता है।
- **सहयोग गुणक।** Code review गुणवत्ता, mentoring, design इनपुट, documentation। सबसे अच्छे इंजीनियर अपने आसपास के लोगों को ऊपर उठाते हैं।
- **विकास प्रक्षेपवक्र।** क्या वे छह महीने पहले से बेहतर हैं? क्या वे feedback पर प्रतिक्रिया दे रहे हैं?

## मैं इसे निष्पक्ष कैसे बनाता हूँ

- उनके स्तर की **अपेक्षाओं** के विरुद्ध calibrate करें, लिखित रूप में, ताकि feedback मनमाना न हो।
- review समय पर पुनर्निर्माण करने के बजाय लगातार ठोस सबूत इकट्ठा करें। मैं हर व्यक्ति के लिए नोट्स रखता हूँ।
- **प्रदर्शन** (परिणाम) को **क्षमता** (अगले स्तर की योग्यता) से अलग करें। इन्हें मिलाने से बुरे promotion और PIP निर्णय होते हैं।

| संकेत | अच्छा स्रोत | भ्रामक स्रोत |
|---|---|---|
| उत्पादकता | Ship किए गए परिणाम | Lines of code, commit count |
| गुणवत्ता | Incident/defect रुझान | व्यक्तिपरक अनुमान |
| सहयोग | Peer feedback, PR history | meetings की मात्रा |

## गलतियाँ

- **Recency bias** — पूरी अवधि नहीं, बल्कि पिछले दो हफ़्तों को आँकना।
- **Visibility bias** — शोरगुल वाले काम को पुरस्कृत करना और on-call और reviews जैसे शांत glue work को चूकना।
- मेट्रिक्स को लक्ष्य मानना; जिस क्षण एक मेट्रिक लक्ष्य बन जाता है, लोग इसे gem करने लगते हैं।

## यह क्यों महत्वपूर्ण है

निष्पक्ष, सबूत-आधारित मूल्यांकन भरोसा, retention, और सही विकास निवेश को संचालित करता है। इसे गलत करें और आप गलत लोगों को promote करते हैं, अपने सबसे मज़बूत योगदानकर्ताओं को हतोत्साहित करते हैं, और टीम को सिखाते हैं कि दिखावटी काम असली प्रभाव को मात देता है।

संकेत	अच्छा स्रोत	भ्रामक स्रोत
उत्पादकता	Ship किए गए परिणाम	Lines of code, commit count
गुणवत्ता	Incident/defect रुझान	व्यक्तिपरक अनुमान
सहयोग	Peer feedback, PR history	meetings की मात्रा