इंजीनियरिंग टीम फोकस की कला: कम करें, ज़्यादा हासिल करें

• इंजीनियरिंग टीमों पर अक्सर "ज़्यादा फीचर्स को तेज़ी से ship करने" का दबाव होता है
• लेकिन एक साथ बहुत सारा काम चलाने से उल्टा productivity घट जाती है
• "ज़्यादा ship करने का राज़ है, दरअसल कम करना" - Less is More

मुख्य सिद्धांत

• सभी काम को दृश्य बनाएं
• काम को छोटी इकाइयों में परिभाषित करें
• चल रहे काम को सीमित करें
• क्षमता के अनुसार resources allocate करें
• बोनस: अनिश्चित स्थितियों के लिए बफ़र स्पेस रखें

---

# सभी काम को दृश्य बनाएं

• काम को दृश्य बनाने से वास्तविक स्थिति साफ़ दिखाई देती है
• जब सारा काम एक नज़र में दिखता है, तो ये फायदे मिलते हैं
  • priorities स्पष्ट रूप से तय की जा सकती हैं
  • गैर-ज़रूरी काम को रोका या pause किया जा सकता है
  • टीम शुरू किए गए काम को पूरा करने पर फोकस कर सकती है
• लक्ष्य हर काम को हमेशा ट्रैक करना नहीं है → बल्कि वास्तविक स्थिति को स्पष्ट समझकर बेहतर फ़ैसले लेना है

# काम को छोटी इकाइयों में परिभाषित करें

• जब काम बहुत बड़ा होता है, तो टीम की ऊर्जा ख़त्म होती है और progress स्पष्ट नहीं दिखती
• काम की इकाइयों को 1~2 हफ्तों तक सीमित रखें
  • डेवलपर्स short-term उपलब्धियों से motivated रहते हैं
  • जल्दी feedback लेकर सुधार किया जा सकता है
• छोटी काम-इकाइयों के फायदे
  • code review आसान हो जाता है
  • knowledge sharing स्वाभाविक रूप से होती है
  • टीम सदस्यों के बीच collaboration मज़बूत होता है
  • deployment risk कम होता है
• काम की इकाइयाँ छोटी करने से गति बढ़ती है → जटिल फीचर्स से दबे बिना momentum बनाए रखा जा सकता है

# चल रहे काम को सीमित करें

• कई फीचर्स को एक साथ संभालने से productivity उल्टा घटती है
• context switching cost होती है → नए काम में ढलने में अधिकतम 23 मिनट लग सकते हैं
• जैसे-जैसे चल रहे काम बढ़ते हैं, ये समस्याएँ सामने आती हैं
  • quality में गिरावट
  • bugs बढ़ना
  • टीम morale में कमी
• टीम-स्तर पर overload के संकेत
  • प्रति डेवलपर 4 से ज़्यादा काम
  • पूरा होने में अनुमान से ज़्यादा समय लगना
  • पूरे हुए फीचर्स से ज़्यादा in-progress फीचर्स होना
• व्यक्तिगत स्तर पर overload के संकेत
  • फोकस में कमी
  • code review response time बढ़ना
  • status meetings में priorities समझाना मुश्किल होना

# क्षमता के अनुसार resources allocate करें

• "एक डेवलपर, एक फीचर" वाला approach अप्रभावी है
• टीम के resources को सबसे महत्वपूर्ण काम पर केंद्रित करें
  • collaboration बेहतर होती है → problem-solving तेज़ होती है
  • code quality सुधरती है → real-time peer review सक्रिय होता है
  • काम पूरा होने की गति बढ़ती है
• collaboration के ज़रिए डेवलपर्स काम को और गहराई से समझ पाते हैं
• टीम-स्तर की उपलब्धियों को बढ़ावा देना चाहिए → व्यक्तिगत प्रदर्शन से ज़्यादा टीम प्रदर्शन पर ज़ोर

# बफ़र स्पेस रखें

• 100% capacity पर काम करने से उल्टा performance गिरता है
• अप्रत्याशित काम आना तय है → बस यह पता नहीं होता कि कब आएगा
• बफ़र स्पेस न होने पर ये समस्याएँ होती हैं
  • टीम reactive तरीके से काम करने लगती है
  • quality गिरती है
  • innovation कम होता है
  • technical debt बढ़ता है
• बफ़र स्पेस होने पर ये फायदे मिलते हैं
  • अप्रत्याशित समस्याओं पर लचीलेपन से प्रतिक्रिया दी जा सकती है
  • creative problem-solving संभव होती है
  • high quality बनाए रखी जा सकती है
  • sustainable work pace बनाए रखा जा सकता है
• उचित बफ़र स्पेस लगभग 20% → टीम की प्रकृति के अनुसार इसे समायोजित किया जा सकता है

मुख्य रणनीति का सार

• काम को दृश्य बनाएं → वास्तविक स्थिति साफ़ दिखे
• काम को छोटी इकाइयों में परिभाषित करें → momentum बनाए रखें
• चल रहे काम को सीमित करें → फोकस बढ़ाएँ
• क्षमता के अनुसार resources allocate करें → priorities के हिसाब से ध्यान केंद्रित करें
• बफ़र स्पेस रखें → flexibility सुनिश्चित करें

निष्कर्ष

• ज़्यादा काम करने के लिए कम करने की रणनीति ज़रूरी है
• टीम की सफलता इस बात से नहीं मापी जाती कि उसने एक साथ कितने फीचर्स संभाले, बल्कि इससे कि उसने ग्राहकों तक कितनी प्रभावी तरह से मूल्य पहुँचाया
• लीडर की भूमिका टीम पर और काम डालना नहीं, बल्कि गैर-ज़रूरी काम हटाना है

[laeyoung]

GeekNews में कई बार उल्लेख की गई किताब <Phoenix Project> में भी ऐसी ही बात आती है। जैसे-जैसे क्षमता 100% के करीब पहुँचती है, response time घातांकीय रूप से लंबा हो जाता है।

[roxie]

ओह। वह बात Goal नाम की किताब में भी आती है!

[kallare]

क्योंकि <Phoenix Project> खुद <The Goal> के IT version के रूप में लिखी गई किताब है।

[roxie]

अरे........ धन्यवाद!!

[kipsong133]

हम 80% काम और 20% खाली स्पेस रखने की कोशिश तो करते हैं, लेकिन इसका मानदंड क्या हो, इसे लेकर हर बार सोचना पड़ता है। कभी-कभी लगता है कि शायद इसे सिर्फ समय के आधार पर तय करना चाहिए।

[zihado]

इसलिए मैं शुक्रवार दोपहर को पूरी तरह से व्यक्तिगत development time के लिए अलग रखता हूँ!

[ceruns]

जब काम को इतने छोटे tasks में बाँट दिया जाता है, तो बड़ी तस्वीर देखने वाला leader बहुत अधिक अधिकार अपने हाथ में ले लेता है। साथ काम कर रहे engineers उल्टा demotivated हो जाते हैं और सोचते हैं, "हम आखिर जा कहाँ रहे हैं?" यह sprint-based agile की सबसे प्रतिनिधि कमियों में से एक है.
यह लेख शायद title की तरह ही बहुत ज़्यादा leader के नज़रिए से लिखा गया लगता है.

engineer का momentum इस बात से भी बहुत प्रभावित होता है कि leader झंडा किस दिशा में उठा रहा है। customer को कौन-सी value देनी है, और हर sprint में output तथा delivery outcome क्या है, इसे प्रस्तुत करने के तरीकों पर भी थोड़ा और विचार करने की ज़रूरत लगती है। बेशक यह एक कठिन soft skill है, इसलिए इसे सही ढंग से करने वाले leaders भी कम दिखते हैं और इस पर अच्छे लेख भी बहुत कम हैं.

[kuthia]

मैं इस टिप्पणी से ज़ोरदार सहमति रखता हूँ। तकनीकी हिस्सों पर micromanaging होने का खतरा रहा है। यह सच में आसान नहीं है।

[mmiroro]

क्या बड़ी तस्वीर साझा करके, और यह सुनिश्चित करके कि सभी लोग समझ रहे हों, काम को छोटे-छोटे tasks में बाँटना ही सही तरीका नहीं होगा??

[ceruns]

अगर इसे 1-2 हफ्तों में बांटा जाए, तो स्वाभाविक रूप से ऐसा लगता है कि किसी एक फीचर की पूरी तस्वीर सिर्फ सीमित लोग ही जान पाएंगे। कुछ वैसा ही जैसे process और thread के बीच का अंतर। क्योंकि फोकस को सीमित करके productivity बढ़ाई जा रही है.

भले ही पूरी तस्वीर साझा की जाए, यह मानकर चलना होगा कि लोग उस तस्वीर पर सवाल उठाएंगे। लेकिन मुझे लगता है कि मैंने स्वाभाविक रूप से यह भी मान लिया था कि हर sprint planning में थोड़ा-थोड़ा बदलती दिशा के साथ लोग इस बड़ी तस्वीर को कैसे ट्रैक कर रहे हैं, इसे वे ठीक से मिला नहीं पाएंगे.

[castedice]

मैं इस लेख में रखी गई बातों से पूरी तरह सहमत हूँ, और आपने जो समस्या बताई है उससे भी सहमत हूँ.
असल में यह वही बिंदु है जिस पर मैं भी सोच रहा हूँ.
यह हर squad में अलग था, लेकिन sprint planning में टीम के सदस्यों को सक्रिय रूप से शामिल करने पर आपने जो समस्या बताई, वह वास्तव में नहीं हुई. प्रोजेक्ट का context साझा करते हुए और हर sprint में बदलती परिस्थितियों को साझा करते हुए, ताकि बदलते कामों को वे पर्याप्त रूप से समझ सकें, हमने यह भी कहा कि कामों को बहुत बारीकी से बाँटकर देखा जाए.
जैसा आपने कहा, management के दृष्टिकोण से progress status, work speed measurement, अप्रत्याशित स्थितियों से निपटना, और जब काम इच्छित तरीके से न हो तो उसके opportunity cost को देखें, तो अंततः कामों को छोटे हिस्सों में बाँटना ही बेहतर प्रगति में मदद करता है.

[kallare]

ऐसी मिलती-जुलती बातें बार-बार लिखी जाती हैं, लेकिन इंसानी लालच की कोई सीमा नहीं होती और हम वही गलतियाँ दोहराते रहते हैं

• बेहतरीन प्रदर्शन करने वाली टीम बनानी है, तो उनसे सिर्फ 85% मेहनत की अपेक्षा करें
• प्रोडक्ट डेवलपमेंट को बर्बाद करने वाली 6 गलत धारणाएँ

कंप्यूटर में CPU load का 100% सामान्य नहीं माना जाता,
लेकिन इंसानों के काम का load 100% हो तो निष्कर्ष निकलता है कि और ज़्यादा मेहनत करनी चाहिए..