GitHub की Engineering System Success Playbook

• इंजीनियरिंग सफलता के लिए गुणवत्ता (Quality), गति (Velocity), डेवलपर संतुष्टि (Happiness) — इन तीन क्षेत्रों के बीच संतुलन होना महत्वपूर्ण है
• ESSP (Engineering System Success Playbook) इन्हें एकीकृत रूप से बेहतर बनाकर व्यावसायिक परिणामों को अधिकतम करने के लिए 3-स्टेप फ्रेमवर्क प्रदान करता है
• SPACE, DevEx, DX Core 4, DORA जैसे कई फ्रेमवर्क पर आधारित 12 मुख्य metrics के ज़रिए संगठन अपनी वर्तमान स्थिति समझ सकता है, सुधार लक्ष्यों के अनुसार प्राथमिकताएँ तय कर सकता है, और क्रमिक रूप से बदलाव लागू व समायोजित कर सकता है
  • ये 12 metrics इस तरह बनाए गए हैं कि हर क्षेत्र को मात्रात्मक रूप से ट्रैक किया जा सके, और इन्हें हर संगठन अपनी स्थिति के अनुसार कस्टमाइज़ भी कर सकता है
• सभी सुधार टीम-स्तर की sustainability और systemic thinking पर आधारित होते हैं, और leading indicators तथा lagging indicators — दोनों को साथ लेकर चलने वाले संतुलित दृष्टिकोण पर ज़ोर देते हैं
• तेज़ सुधार के बजाय टिकाऊ, दीर्घकालिक बदलाव को लक्ष्य बनाया जाता है
• ESSP को बिना किसी अपने measurement tool के भी शुरू किया जा सकता है, और survey जैसी qualitative methods से की गई शुरुआती जाँच भी उपयोगी होती है
• GitHub अपने उदाहरण के ज़रिए इस बात पर ज़ोर देता है कि गुणवत्ता-केंद्रित सुधार अंततः गति और डेवलपर संतुष्टि पर भी सकारात्मक प्रभाव डालते हैं

GitHub के इंजीनियरिंग सफलता metrics

• Quality
  • Change failure rate: बदलाव विफलता दर
    → वे बदलावों का अनुपात जिनसे outage या समस्या हुई
    • गणना विधि: (विफल deployments की संख्या / कुल deployments की संख्या) × 100
    • टिप: टीम के भीतर स्पष्ट सहमति बनाएं कि किस आधार पर किसी deployment को विफल माना जाएगा (उदाहरण: rollback, monitoring alert आदि)
  • Failed deployment recovery time: विफल deployment recovery time
    → विफल deployment को rollback करने या सामान्य स्थिति में वापस लाने में लगा समय
    • गणना विधि: हर विफल deployment के recovery complete time − विफलता होने का समय का median
    • टिप: alert system या logs से इसे अपने आप निकालने का तरीका सुझाया जाता है। average की बजाय median का उपयोग बेहतर है (extreme values के प्रभाव से बचने के लिए)
  • Code security and maintainability: कोड की सुरक्षा और maintainability
    • गणना विधि: static analysis tools, GitHub Advanced Security, CodeQL आदि के माध्यम से vulnerabilities की संख्या, complexity, coverage आदि का समग्र मूल्यांकन
    • टिप: नियमित automated scans सेट करें। refactoring या security policy में बदलाव के असर को मापने में उपयोगी
• Velocity
  • Lead time: lead time
    → कोड बदलाव के production में पहुँचने तक लगने वाला समय
    • गणना विधि: PR बनाए जाने के समय से merge होने के बाद deployment तक का समय
    • टिप: average नहीं बल्कि median इस्तेमाल करने से distortion कम होता है। अगर lead time लंबा हो, तो PR waiting time या review delay को अलग से मापें
  • Deployment frequency: deployment frequency
    → production deployment कितनी बार हो रहे हैं
    • गणना विधि: किसी निश्चित अवधि में deployments की संख्या (दैनिक/साप्ताहिक)
    • टिप: यह स्पष्ट होना चाहिए कि automated deployments को शामिल किया जाएगा या नहीं, और छोटे teams के लिए साप्ताहिक मानदंड अधिक उपयुक्त हो सकता है
  • PRs merged per developer: प्रति डेवलपर merge किए गए PRs
    • गणना विधि: कुल merged PRs / योगदान देने वाले डेवलपर्स की संख्या
    • टिप: इसे तुलना के साधन के रूप में नहीं, बल्कि team workflow efficiency मापने के लिए उपयोग करें। PR के size या complexity के साथ मिलाकर समझना ज़रूरी है
• Developer Happiness
  • Flow state experience: flow state का अनुभव
    • गणना विधि: डेवलपर survey के माध्यम से “हाल में flow experience की frequency/duration” का मूल्यांकन
    • टिप: महीने में कम-से-कम एक बार नियमित survey की सिफारिश की जाती है। open-ended responses शामिल करने पर qualitative insights भी मिल सकते हैं
  • Engineering tooling satisfaction: इंजीनियरिंग tools से संतुष्टि
    • गणना विधि: डेवलपर survey के माध्यम से tools के उपयोग से संतुष्टि और सुधार की अपेक्षाएँ इकट्ठा करना
    • टिप: अगर tool-wise detailed items (IDE, CI, issue tracking आदि) में बाँटा जाए, तो व्यावहारिक सुधार बिंदु निकाले जा सकते हैं
  • Copilot satisfaction: Copilot उपयोग संतुष्टि
    • गणना विधि: Copilot license holders पर satisfaction survey (NPS या score)
    • टिप: तुरंत अपनाने के बाद और 3 महीने बाद जैसे अलग-अलग समय बिंदुओं पर तुलना की सिफारिश की जाती है। feedback के ज़रिए training/usage cases बेहतर किए जा सकते हैं
• Business Outcomes
  • AI leverage: AI उपयोग स्तर
    • गणना विधि: Copilot commits का अनुपात, AI code suggestions adoption rate, usage time आदि
    • टिप: GitHub के Copilot Telemetry API या internal instrumentation का उपयोग किया जा सकता है। qualitative feedback के साथ विश्लेषण करने पर यह और प्रभावी होता है
  • Engineering expenses to revenue: revenue के मुकाबले engineering खर्च का अनुपात
    • गणना विधि: इंजीनियरिंग से संबंधित खर्च / कुल revenue
    • टिप: internal accounting standards को व्यवस्थित करना ज़रूरी है। तुलना के लिए monthly या quarterly trend analysis की सिफारिश की जाती है
  • Feature engineering expenses to total engineering expenses: कुल engineering खर्च में feature development खर्च का अनुपात
    • गणना विधि: (feature development से संबंधित खर्च / कुल engineering खर्च)
    • टिप: maintenance, infrastructure, testing जैसे feature के बाहर के खर्चों के classification criteria को पहले से स्पष्ट करना होगा, तभी सटीक माप संभव है

[इंजीनियरिंग सफलता के लिए 3 चरण]

Step 1: सफलता में मौजूदा बाधाओं की पहचान करें

• वर्तमान development process की समस्याओं और engineering success में बाधा डालने वाले अवरोधों की पहचान करना मुख्य है
• यह आगे के सुधार की दिशा और प्राथमिकताएँ तय करने के लिए baseline की भूमिका निभाता है
• दृष्टिकोण
  • पूरे SDLC(Software Development Life Cycle) flow का विश्लेषण करके bottleneck points की पहचान की जाती है
  • GitHub में विश्लेषण 12 standard metrics के आधार पर किया जाता है, लेकिन संगठन की विशेषताओं के अनुसार इनमें से कुछ का ही उपयोग किया जा सकता है
• टीम की भागीदारी
  • किसी एक leader के बजाय पूरी टीम को मिलकर improvement process परिभाषित करना चाहिए
  • केवल कुछ metrics के साथ भी meaningful conversation शुरू करना पर्याप्त है
• कार्यप्रणाली

  • 1. बुनियादी flow को समझना

    • पूरे engineering flow को इस तरह विभाजित करके देखा जाता है:
      • योजना (Plan) → विकास (Develop) → समीक्षा (Review) → बिल्ड (Build) → टेस्ट (Test) → रिलीज़ (Release) → ऑपरेशन (Operate)

  • 2. मात्रात्मक signals एकत्र करना

    • नीचे दिए गए जैसे quantitative data का विश्लेषण किया जाता है:
      • deployment cycle: deployment कितनी बार होता है
      • lead time: code लिखे जाने के समय से deployment तक लगने वाला समय
      • change failure rate: deployment के बाद error होने की दर
      • MTTR (औसत recovery time): समस्या आने के बाद recovery तक लगने वाला समय

  • 3. गुणात्मक signals एकत्र करना

    • developers और टीम से अनुभव-आधारित feedback एकत्र किया जाता है:
      • टीम के सदस्य कब inefficiency महसूस करते हैं
      • कौन से tools या procedures बार-बार समस्या पैदा करते हैं
      • कौन सी गतिविधियाँ सबसे अधिक मानसिक दबाव देती हैं
    • तरीके:
      • survey, retrospective, 1:1 interview आदि का उपयोग
      • पहले से परिभाषित ESSP question list का भी उपयोग किया जा सकता है

  • 4. मुख्य समस्या को परिभाषित करना

    • एकत्र किए गए data के आधार पर barrier को परिभाषित किया जाता है
    • उदाहरण:
      • "lead time लंबा होने से नए features का development देर से होता है"
      • "build failures बार-बार होने से deployment reliability कम है"
      • "developers को अक्सर context switching का सामना करना पड़ता है"
    • समस्या को ठोस और observable रूप में बताया जाना चाहिए

  • 5. metrics की प्राथमिकता तय करना

    • सभी metrics को एक साथ सुधारने के बजाय, सबसे अधिक प्रभाव वाले एक या दो metrics पर ध्यान केंद्रित करें
    • यही प्राथमिकता आगे Step 2 और Step 3 में improvement attempts और performance measurement criteria का आधार बनती है
• Step 1 को सफलतापूर्वक पूरा करने के लिए टिप्स
  • 1. सतही रूप नहीं, मूल कारण पर ध्यान दें
    • केवल surface symptoms देखकर निर्णय न लें; समस्या की जड़ तक गहराई से जाना चाहिए
      • उदाहरण: गति धीमी होने का कारण 'manual testing' लगता हो, लेकिन असली कारण automated testing पर भरोसे की कमी हो सकता है
    • इसके लिए software engineering में आम तौर पर दिखने वाले antipatterns को देखना उपयोगी है
  • 2. antipatterns का संदर्भ लें
    • antipattern का मतलब है ऐसा अक्सर इस्तेमाल होने वाला समाधान जो वास्तविक समस्या हल नहीं करता, बल्कि उलटे side effects पैदा कर सकता है
    • GitHub टीम के भीतर मौजूद हो सकने वाले antipatterns के उदाहरण अलग resource के रूप में देता है, इसलिए इसे self-review tool की तरह इस्तेमाल किया जा सकता है
  • 3. उचित लोगों को शामिल करें
    • Step 1 के Task 1 में विभिन्न भूमिकाओं वाले सदस्यों से input लेना महत्वपूर्ण है
      • उदाहरण: developer, tester, operations, security, product manager आदि
    • इससे पूरे workflow को बहुआयामी तरीके से समझना संभव होता है और किसी खास दृष्टिकोण के छूटने की संभावना कम होती है
  • 4. quantitative data और qualitative data का संतुलित उपयोग करें
    • केवल metrics से पूरे context को समझा नहीं जा सकता
    • quantitative analysis के साथ टीम सदस्यों से मनोवैज्ञानिक, सांस्कृतिक और collaboration से जुड़ी qualitative feedback भी लेनी चाहिए
    • उदाहरण: टीम morale में गिरावट, communication की कमी, retrospective में असंतोष जैसी बातें numbers में नहीं दिखतीं
  • 5. बहुत ज़्यादा barriers न चुनें
    • सभी समस्याओं को एक साथ हल करने की कोशिश न करें; सबसे प्रभावशाली और सबसे तात्कालिक barriers पर ध्यान दें
    • शुरुआत में बहुत ज़्यादा improvement tasks लेने पर execution power और momentum खोने का जोखिम रहता है
  • 6. psychological safety सुनिश्चित करें
    • ऐसा माहौल बनाना चाहिए जहाँ टीम के सदस्य नुकसान या retaliation के डर के बिना ईमानदारी से अपनी बात कह सकें
    • यह वास्तविक समस्याओं को सामने लाने की एक अहम शर्त है और improvement activities की reliability और effectiveness बढ़ाता है
  • 7. तुलना सीखने के लिए है, मूल्यांकन के लिए नहीं
    • टीमों के बीच metrics comparison या workflow differences का उपयोग quantitative performance evaluation के बजाय insights निकालने के लिए किया जाना चाहिए
    • हर टीम की स्थिति, लक्ष्य, tech stack और constraints अलग होते हैं, इसलिए सरल तुलना गलतफहमी पैदा कर सकती है
    • इसके बजाय, क्या अच्छा काम कर रहा है उसे साझा करने और उससे सीख निकालने वाली learning culture को बढ़ावा देना चाहिए

Step 2: अपने लक्ष्य तक पहुँचने के लिए क्या करना होगा, इसका मूल्यांकन करें

• उद्देश्य
  • Step 1 में परिभाषित मुख्य समस्या (Barrier) को हल करने के लिए किन परिवर्तनों को लागू करना है, इसका विश्लेषण करने का चरण
  • सिर्फ फीचर जोड़ने या टूल बदलने से आगे बढ़कर, संगठनात्मक, तकनीकी और सांस्कृतिक स्तर पर मूल कारणों और समाधान की पहचान करना

• 1. मौजूदा स्थिति के मूल कारणों का विश्लेषण

  • सिर्फ "गति धीमी है" या "संतुष्टि कम है" जैसे नतीजों तक सीमित न रहें,
    • क्यों धीमी है,
    • इसके पीछे कौन-से संरचनात्मक और संगठनात्मक कारण हैं,
    • और क्या बदला जा सकता है और क्या नहीं, यह अलग करना चाहिए
  • उपयोगी टूल:
    • 5 Whys तकनीक
    • Fishbone (cause-and-effect) diagram
    • टीम retrospective में मिले qualitative feedback का विश्लेषण

• 2. संभावित समाधान निकालना

  • समस्या के लिए तकनीकी, सांस्कृतिक और process-संबंधित समाधानों पर brainstorming करें
  • उदाहरण:
    • तकनीकी: test speed में सुधार, CI/CD pipeline में सुधार
    • सांस्कृतिक: code review practices को व्यवस्थित करना, onboarding में सुधार
    • process: PR size limit करना, merge criteria बदलना
  • GitHub की सुझाई गई तकनीक:
    • observation-आधारित solutions और people-centric improvements को मिलाकर निकालना

• 3. प्रभाव और जोखिम का मूल्यांकन

  • हर समाधान के लिए इन बिंदुओं का मूल्यांकन करें:
    • अपेक्षित प्रभाव: यह किन improvement metrics को प्रभावित कर सकता है
    • व्यवहार्यता: टीम resources और वास्तविक execution क्षमता
    • संगठनात्मक स्वीकृति: बदलाव के प्रति resistance का स्तर
    • अल्पकालिक/दीर्घकालिक प्रभाव का अंतर: क्या परिणाम जल्दी आएगा या यह टिकाऊ बदलाव है
  • इसके लिए Pilot (प्रायोगिक संचालन) की सिफारिश की जाती है
    • पहले छोटी टीम पर आज़माकर feedback लें, फिर विस्तार करना है या नहीं, यह तय करें

• 4. प्राथमिकता तय करना और communication

  • कई समाधानों में से इन मानकों के आधार पर प्राथमिकता तय करें:
    • जो सबसे बड़ा impact दे सके
    • जो सबसे अधिक लागू करने योग्य हो
    • जो सबसे तत्काल pain point को हल करे
  • यह निर्णय टीम के साथ साझा किया जाना चाहिए और सहमति बनाई जानी चाहिए, और
    • इसे OKR या improvement goal के रूप में स्पष्ट रूप से लिखना बेहतर है
• Step 2 को सफलतापूर्वक पूरा करने के लिए टिप्स
  • 1. दीर्घकालिक स्थिरता को ज़रूर ध्यान में रखें
    • अगर केवल short-term results पर ध्यान दिया जाए, तो इससे दीर्घकालिक समस्याएँ पैदा हो सकती हैं
      • उदाहरण: नया टूल लाकर गति तुरंत बढ़ाई जा सकती है, लेकिन अगर training, support और change management साथ न हो, तो इससे उलटे गलतियाँ और भ्रम बढ़ सकते हैं
    • इसलिए कोई भी सुधार प्रयास maintenance और scale-out की संभावना को ध्यान में रखकर बनाई गई रणनीति होना चाहिए
  • 2. हर zone के बीच के trade-offs पर विचार करें
    • किसी एक क्षेत्र (जैसे speed) को बेहतर करने वाला बदलाव दूसरे क्षेत्र (जैसे developer satisfaction, quality) की क़ीमत पर न हो, इसका ध्यान रखें
      • उदाहरण: review criteria को ढीला करने से speed बढ़ सकती है, लेकिन code quality या developer fatigue खराब हो सकती है
    • हमेशा यह मानकर चलें कि प्रभाव कई क्षेत्रों में फैलेगा, इसलिए संतुलित approach ज़रूरी है
  • 3. शुरुआत से ही टीम को शामिल करें
    • जिन बदलावों में टीम सीधे शामिल होती है और जिन्हें मिलकर बनाया जाता है, उनके सफल होने की संभावना अधिक होती है
    • सदस्यों की राय लेकर बदलाव को bottom-up तरीके से आगे बढ़ने दें
    • एकतरफ़ा निर्देशात्मक top-down बदलाव विरोध और उदासीनता पैदा कर सकते हैं
  • 4. success metrics को स्पष्ट रूप से परिभाषित करें
    • बदलाव लागू करने से पहले यह तय होना चाहिए कि सफलता किसे माना जाएगा
    • उदाहरण: अगर लक्ष्य “deployment time कम करना” है,
      • lagging metric: वास्तविक deployment time में कमी
      • leading metric: PR waiting time में कमी, developer survey में 'PR speed में सुधार महसूस हुआ' जैसे जवाबों में वृद्धि
    • Leading Indicator और Lagging Indicator दोनों को साथ परिभाषित करना आदर्श है
  • 5. परफेक्ट योजना से ज़्यादा तेज़ प्रयोगों को प्राथमिकता दें
    • छोटे बदलाव भी जल्दी आज़माकर feedback लेकर सुधार करने वाला iterative approach अधिक प्रभावी होता है
      • शुरुआत में कोशिश अधूरी हो, तब भी छोटे स्तर पर परीक्षण करें, और असर साबित होने पर विस्तार करें
    • इससे विफलता की संभावना कम होती है, और बदलाव के प्रति टीम की agility और adaptability भी मज़बूत होती है
  • 6. कम मेहनत में बड़ा असर देने वाले बदलाव पहले आज़माएँ
    • जब बदलावों की सूची लंबी और जटिल हो, तो पहले "high-impact, low-cost" क्षेत्र के सुधार चुनें
    • उदाहरण: simple review guide लागू करना, अनावश्यक notifications हटाना — ये जल्दी लागू हो सकते हैं और satisfaction पर बड़ा असर डाल सकते हैं
    • शुरुआती सफलता का अनुभव टीम को आत्मविश्वास देता है और आगे कठिन समस्याओं पर काम करने के लिए गति प्रदान करता है

Step 3: अपने बदलाव लागू करें, परिणामों की निगरानी करें, और ज़रूरत के अनुसार समायोजन करें

• Step 2 में निकाले गए सुधार प्रयासों (Intervention) को संगठन के भीतर वास्तव में लागू करना,
  और उनके परिणामों को मापना, तथा ज़रूरत पड़ने पर समायोजित करना या दोहराकर सुधारना — यही निरंतर engineering success हासिल करने का चरण है

• 1. कार्यान्वयन(Implement the change)

  • लागू करने से पहले निम्न बातों को स्पष्ट करना चाहिए:
    • कौन-सा बदलाव किया जा रहा है?
    • इसकी ज़िम्मेदारी कौन लेगा?
    • किन metrics के आधार पर इसका मूल्यांकन किया जाएगा?
    • मापन कब से कब तक किया जाएगा?
  • लागू करते समय ध्यान देने योग्य बातें:
    • ज़िम्मेदार व्यक्ति नियुक्त करना: ownership स्पष्ट करना
    • टीम onboarding और training: बदलाव क्यों ज़रूरी है और क्या बदलेगा, यह सभी टीम सदस्यों को समझना चाहिए
    • बदलाव का documentation: रिकॉर्ड छोड़ें ताकि भविष्य की retrospective और iteration में संदर्भ के रूप में उपयोग हो सके
  • अपनाने के उदाहरण:
    • CI/CD गति सुधारने के लिए build cache strategy बदलना
    • code review policy बदलना (उदा: 1 दिन के भीतर response rule लागू करना)

• 2. मॉनिटरिंग(Monitor the change)

  • सुधार योजना लागू होने के बाद, पहले से तय metrics के आधार on प्रभाव को ट्रैक और ऑब्ज़र्व करें
    • क्या lead time कम हुआ?
    • क्या failure rate घटा?
    • क्या developer satisfaction बढ़ा?
  • tools:
    • GitHub Insights, Copilot Telemetry, आंतरिक BI system
    • साप्ताहिक/मासिक report dashboard
    • developer survey या retrospective feedback
  • महत्वपूर्ण बिंदु:
    • baseline के साथ तुलना संभव होनी चाहिए
    • एकल संख्या नहीं, बल्कि trend देखना महत्वपूर्ण है

• 3. फ़ीडबैक संग्रह(Collect feedback)

  • मात्रात्मक metrics के अलावा developer के नज़रिए से यह बदलाव वास्तव में मददगार था या नहीं, इसका feedback इकट्ठा करना भी ज़रूरी है
    • retrospective, anonymous survey, 1:1 meeting आदि का उपयोग करें
    • सुधार का "अनुभवजन्य असर" कितना है, और कहीं यह उल्टा थकान पैदा करने वाला बदलाव तो नहीं, यह जाँचें
  • संगठनात्मक सहमति के बिना जल्दबाज़ी में लागू किए गए बदलाव प्रतिरोध और विरोध पैदा कर सकते हैं

• 4. समायोजन या पुनरावृत्ति(Adjust as needed)

  • यदि सुधार प्रयास का परिणाम अपेक्षा से कम हो या उसके side effects हों, तो ऐसे जवाब दें:
    • बदलाव को वापस लें या पूरक सुधार करें
    • केवल कुछ हिस्से बनाए रखें और दायरा कम करें
    • इसे बड़े दायरे में विस्तारित करके लागू करें
  • बदलाव की सफलता/असफलता से अलग, हमेशा यह सीखना चाहिए:
    • कौन-से तत्व प्रभावी थे?
    • कौन-सी बातें बाधा बनीं?
    • अगली बार क्या बदलना चाहिए?
• Step 3 को सफलतापूर्वक करने के लिए टिप्स
  • 1.तुरंत पूर्णता की अपेक्षा न करें
    • हर बदलाव तुरंत स्पष्ट रूप से दिखाई देने वाला सुधार नहीं लाता
      • असर दिखने में समय लग सकता है
      • टीम को भी बदलाव के अनुकूल होने की प्रक्रिया से गुजरना पड़ता है, इसलिए धैर्य और निरंतर अवलोकन महत्वपूर्ण हैं
    • शुरुआती चरण में survey जैसे qualitative feedback tools का उपयोग करके बदलाव के अनुभव को समझना उपयोगी होता है
  • 2.बदलाव को लगातार दोहराएँ और सुधारें
    • एक बार सफलता मिलने का मतलब यह नहीं कि उसे वैसे ही बनाए रखा जाए; बदलाव भी लगातार evolve और adjust होना चाहिए
    • नए मुद्दों या बाहरी माहौल में बदलाव के अनुसार मौजूदा सुधार योजना की फिर से समीक्षा करनी पड़ सकती है
    • टीम को इसे नियमित गतिविधि के रूप में पहचानने और improvement cycle जारी रखने के लिए प्रोत्साहित करना चाहिए
  • 3.अनचाहे side effects से सावधान रहें
    • कुछ बदलाव दूसरे क्षेत्रों में अप्रत्याशित friction पैदा कर सकते हैं
      • उदाहरण: deployment speed बढ़ना अच्छा बदलाव है, लेकिन अगर quality validation कमज़ोर हो तो bugs बढ़ सकते हैं
    • केवल metrics ही नहीं, बल्कि पूरे workflow में flow के बदलाव भी साथ में देखें, और कोई असामान्य संकेत मिले तो तुरंत कार्रवाई करें
  • 4.psychological safety की स्थिति की लगातार जाँच करें
    • बदलाव के बाद भी टीम में समस्याएँ खुलकर उठाई जा सकें, ऐसा माहौल बना रहना चाहिए
    • "न कही गई समस्याएँ" जमा न हों, इसके लिए टीम सदस्यों को ईमानदार feedback देने वाला वातावरण देना ज़रूरी है
    • बदली हुई process को लेकर असंतोष, काम का अत्यधिक बढ़ना, अप्रत्याशित stress आदि
  • 5.दीर्घकालिक प्रभाव का लगातार मूल्यांकन करें
    • केवल short-term performance नहीं, बल्कि सतत परिणाम और टीम morale में सुधार ही मुख्य बात है
    • समय के साथ:
      • क्या बदलाव स्थापित हो गया है
      • क्या कोई नए side effects या समस्याएँ पैदा हुई हैं
      • क्या परिणाम बने हुए हैं या गिरावट आई है, इसकी लगातार जाँच करें
  • 6.feedback को सीखने के अवसर के रूप में इस्तेमाल करें
    • असफल बदलाव भी क़ीमती learning asset होते हैं
    • क्या गलत हुआ, इसका data और feedback के आधार पर विश्लेषण करें, और अगली कोशिश में उसे शामिल करें
    • ऐसी संस्कृति भी महत्वपूर्ण है जो टीम को असफलता को सीखने के अवसर के रूप में देखने के लिए प्रोत्साहित करे

Beyond the steps: Make the playbook work for you

• Tailoring

  • संगठन की विशेषताओं के अनुसार मापे जाने वाले metrics और तरीके (telemetry vs survey) चुनें
  • मापन को ही उद्देश्य न बनाएं, बल्कि उसे वास्तविक सुधार के tool के रूप में उपयोग करें

• Change management

  • ADKAR, Kotter model जैसे change management framework का उपयोग करके संगठन को बदलाव के अनुकूल होने में मदद करना महत्वपूर्ण है

• Growth mindset

  • हर प्रयास को सीखने का अवसर समझें, और असफलता को स्वीकार करने वाला दृष्टिकोण निरंतर सुधार की कुंजी है

• Gamification

  • motivation-आधारित reward design सकारात्मक प्रभाव दे सकता है, लेकिन गलत design होने पर उल्टा quality में गिरावट या असंतुलन पैदा हो सकता है

Alternatives to the GitHub Engineering System Success Playbook

• स्थिति के अनुसार ESSP के बजाय सरल feature-usage आधारित analysis या individual tool-आधारित improvement strategy भी संभव हैं
• महत्वपूर्ण बात है टीम और संगठन के अनुकूल यथार्थवादी approach और निरंतर सुधार का प्रयास