1.0 भाग 1 का परिचय: लोग
सॉफ़्टवेयर लोगों द्वारा बनाया जाता है, और लोग संस्कृति, संरचना, और प्रक्रिया द्वारा संगठित होते हैं। इसलिए कोड, आर्किटेक्चर, या टूलिंग की बात करने से पहले, यह भाग उस मानवीय प्रणाली को देखता है जो यह सब उत्पन्न करती है: वे साझा मूल्य जिनके अनुसार एक टीम जीती है, जिस तरह वह स्वयं को टीमों में विभाजित करती है, वह करियर को कैसे बढ़ाती है, वह दिन-प्रतिदिन कैसे समन्वय करती है, और वह निर्णय कैसे लेती और याद रखती है। पुस्तक में बाकी सब कुछ इन्हीं नींवों पर टिका है। एक शानदार आर्किटेक्चर जिसे एक भयभीत, खंडित, या भुलक्कड़ संगठन ने बनाया हो, वास्तविकता के संपर्क में आने पर टिक नहीं पाएगा।
बड़ी टीमों के लिए, ये नींवें सहज (intuitive) होना बंद कर देती हैं और संरचनात्मक बन जाती हैं। एक कमरे में आठ लोगों के बीच सोख (osmosis) से फैलने वाली प्रथाएँ पूरी दुनिया में फैले आठ सौ लोगों के बीच बिखर जाती हैं। इसलिए आपको संस्कृति को स्पष्ट बनाना होगा, टीम की सीमाओं को जानबूझकर डिज़ाइन करना होगा, वृद्धि की अपेक्षाओं को लिखित रूप में रखना होगा, समन्वय को गलियारे की बातचीत से टिकाऊ दस्तावेज़ों की ओर ले जाना होगा, और निर्णयों को इस तरह दर्ज करना होगा कि उनका तर्क उन्हें बनाने वाले लोगों से भी अधिक समय तक जीवित रहे।
एंटरप्राइज़ और सरकारी संगठन इन दबावों में से हरेक को पूरी ताकत से महसूस करते हैं। वे स्केल पर, ऑडिट और निगरानी के तहत, लंबी समयरेखाओं में, और स्थायी स्टाफ़, ठेकेदारों (contractors), और विक्रेताओं के मिश्रण के साथ काम करते हैं। आज आपके द्वारा बनाई गई प्रणाली एक दशक तक चल सकती है, जिसे ऐसे लोग बनाए रखेंगे जो कभी आपसे मिले ही नहीं। इन परिवेशों में इस भाग की नींवें कोई सॉफ़्ट स्किल या “होने से अच्छा” चीज़ें नहीं हैं। वे संस्थागत स्मृति, जवाबदेही, और जोखिम प्रबंधन की मशीनरी हैं।
इस भाग के अध्याय
1.1 सॉफ़्टवेयर इंजीनियरिंग मूल्य: वे साझा विश्वास और रोज़मर्रा के व्यवहार जो वास्तव में यह नियंत्रित करते हैं कि सॉफ़्टवेयर कैसे बनता है, जो मनोवैज्ञानिक सुरक्षा, दोषरहित सीख, स्पष्ट स्वामित्व, एक लेखन संस्कृति, और टिकाऊ गति के इर्द-गिर्द केंद्रित हैं।
1.2 टीम टोपोलॉजी और संगठनात्मक डिज़ाइन: लोगों को टीमों में विभाजित करना उस सॉफ़्टवेयर को कैसे आकार देता है जिसे वे बना सकते हैं (कॉनवे का नियम: संगठन ऐसी प्रणालियाँ उत्पन्न करते हैं जो उनकी अपनी संचार संरचनाओं को प्रतिबिंबित करती हैं), कॉग्निटिव लोड को न्यूनतम करने और क्रॉस-टीम निर्भरता को कम करने के लिए स्ट्रीम-अलाइंड, प्लेटफ़ॉर्म, एनेबलिंग, और कॉम्प्लिकेटेड-सबसिस्टम टीमों का उपयोग करते हुए।
1.3 भूमिकाएँ, करियर लैडर, और वृद्धि: समानांतर इंडिविजुअल-कंट्रीब्यूटर और प्रबंधन ट्रैक के साथ स्पष्ट, कैलिब्रेटेड करियर फ्रेमवर्क बनाना, ताकि लेवलिंग, प्रमोशन, हायरिंग, और वेतन स्केल पर निष्पक्ष, सुसंगत, और बचाव-योग्य हों।
1.4 काम करने के तरीके: टीमें दिन-प्रतिदिन कैसे समन्वय करती हैं, योजना बनाती हैं, और डिलीवर करती हैं, कर्मकांडों (rituals) की तुलना में सिद्धांतों को प्राथमिकता देते हुए और असिंक्रोनस, डॉक्स-फ़र्स्ट, परिणाम-केंद्रित प्रथाओं को डिफ़ॉल्ट मानते हुए जो समय क्षेत्रों और मिश्रित कार्यबलों में स्केल करती हैं।
1.5 निर्णय-निर्माण और गवर्नेंस: पक्की सड़कों (paved roads), सही आकार की समीक्षा, उलटने-योग्य-बनाम-अपरिवर्तनीय सोच, और तकनीकी ऋण को एक पोर्टफ़ोलियो के रूप में प्रबंधित करने के माध्यम से टीम की स्वायत्तता को संगठनात्मक संरेखण के विरुद्ध संतुलित करना।
1.6 निर्णय रिकॉर्ड: निर्णय रिकॉर्ड ( सबसे सामान्यतः आर्किटेक्चर डिसीज़न रिकॉर्ड (ADR) ) कैसे लिखें, संग्रहीत करें, और बनाए रखें, ताकि किसी विकल्प के पीछे का तर्क स्टाफ़ टर्नओवर से बचा रहे और ऑडिट को संतुष्ट करे, और निर्णयों को खोजने-योग्य और यहाँ तक कि परीक्षण-योग्य भी कैसे बनाया जाए।
1.7 इंजीनियरिंग मानक और अपवाद: एक संगठन अपने इंजीनियरिंग मानकों को कैसे लिखता, प्रकाशित, लागू, और विकसित करता है, और वह एक गवर्न किए गए, दस्तावेज़ीकृत अपवाद (छूट) प्रक्रिया के माध्यम से विचलनों को कैसे संभालता है ताकि मानक कठोर बने बिना विश्वसनीय बने रहें।
1.8 हायरिंग, साक्षात्कार, और ऑनबोर्डिंग: समावेशी सोर्सिंग, पूर्वाग्रह को कम करने वाले संरचित और कैलिब्रेटेड साक्षात्कारों, और एक वास्तविक ऑनबोर्डिंग योजना के माध्यम से जानबूझकर टीम बनाना, जो नए इंजीनियरों को डूबने-तैरने देने के बजाय जल्दी उत्पादक बनाती है और अपनेपन का एहसास कराती है।
1.9 वितरित और दूरस्थ कार्य: असिंक्रोनस, लिखित, डॉक्यूमेंटेशन-फ़र्स्ट सहयोग को डिफ़ॉल्ट मानकर, जानबूझकर ओवरलैप और हैंडऑफ़ डिज़ाइन करके, और घंटों या दृश्यता के बजाय परिणामों पर लोगों का मूल्यांकन करके स्थानों और समय क्षेत्रों में संचालन करना।
1.10 इंजीनियरिंग प्रभावशीलता और डेवलपर उत्पादकता: एकल, खेली-जा-सकने वाली संख्याओं के बजाय बहुआयामी फ्रेमवर्क (SPACE और डेवलपर अनुभव) का उपयोग करके यह मापना और बेहतर बनाना कि इंजीनियर कितने प्रभावी ढंग से अपना सर्वश्रेष्ठ काम कर सकते हैं, और उस घर्षण व थकाऊ मेहनत को हटाना जो टीमों को धीमा करती है।
1.11 इंजीनियरिंग प्रबंधन: करियर लैडर के बजाय इंजीनियरों को प्रबंधित करने का शिल्प: वन-ऑन-वन, फ़ीडबैक, और कोचिंग लूप, प्रत्यायोजन (delegation), मानवीय परफ़ॉर्मेंस प्रबंधन, और अपने खुद के आउटपुट के बजाय टीम के गुणक (multiplier) के रूप में मापा जाना।
1.12 विविधता, समानता, समावेशन, और अपनेपन की भावना: एक ऐसी टीम बनाना जहाँ अंतर मौजूद हो, उसे निष्पक्ष रूप से माना जाए, सक्रिय रूप से शामिल किया जाए, और उसे अपनेपन का एहसास कराया जाए, क्योंकि समावेशी टीमें बेहतर सॉफ़्टवेयर बनाती हैं और क्योंकि यह सही है, ईमानदार मापन और बिना किसी दिखावे (tokenism) के साथ।
1.13 मार्गदर्शन, कोचिंग, और ज्ञान साझाकरण: मार्गदर्शन (mentoring), कोचिंग, और प्रायोजन (sponsorship), प्रैक्टिस समुदायों, आंतरिक टॉक, पेयरिंग, और शिक्षण-के-रूप-में-दस्तावेज़ीकरण के माध्यम से जानबूझकर लोगों को बढ़ाना और विशेषज्ञता फैलाना, ताकि ज्ञान किसी भी व्यक्ति से अधिक समय तक जीवित रहे और बस-फ़ैक्टर जोखिम कम बना रहे।
ये अध्याय एक-दूसरे से कैसे जुड़े हैं
ये अध्याय एक एकल सूत्र (throughline) बनाते हैं। मूल्य यह परिभाषित करते हैं कि एक संगठन किस बात की परवाह करता है। संरचना और भूमिकाएँ यह तय करती हैं कि काम कौन करता है और वे कैसे बढ़ते हैं। काम करने के तरीके यह नियंत्रित करते हैं कि लोग कैसे समन्वय करते हैं। गवर्नेंस और निर्णय रिकॉर्ड उनके विकल्पों के पीछे के तर्क को संरक्षित करते हैं। निर्भरताएँ इसी क्रम में चलती हैं। अध्याय 1.1 की लेखन संस्कृति और मनोवैज्ञानिक सुरक्षा अध्याय 1.3 में ईमानदार कैलिब्रेशन, अध्याय 1.4 में डॉक्स-फ़र्स्ट सहयोग, और अध्याय 1.6 में टिकाऊ निर्णय रिकॉर्ड के लिए पूर्वशर्तें हैं। अध्याय 1.2 में डिज़ाइन की गई टीम की सीमाएँ अध्याय 1.4 में समन्वय को स्केल करने के लिए आपका मुख्य लीवर हैं, जो खुलकर भारी फ्रेमवर्क जोड़ने की तुलना में समन्वय की आवश्यकता को कम करने को प्राथमिकता देता है। अध्याय 1.5 और 1.6 एक जानबूझकर बनाई गई जोड़ी हैं: पहला गवर्नेंस दर्शन तय करता है, दूसरा उसे एक निरंतर प्रथा में बदल देता है।
इस भाग की पहुँच पूरी पुस्तक में फैली हुई है। अध्याय 1.2 की टीम टोपोलॉजी अध्याय 8.4 की प्लेटफ़ॉर्म इंजीनियरिंग और अध्याय 9.1 के विश्वसनीयता स्वामित्व को आकार देती है। यहाँ पेश किए गए निर्णय रिकॉर्ड वहाँ हर जगह दोहराए जाते हैं जहाँ महत्वपूर्ण विकल्प बनाए जाते हैं, अध्याय 3.1 में आर्किटेक्चर फाउंडेशन से लेकर अध्याय 10.3 में बिल्ड-बनाम-खरीद और खरीद (procurement) तक, और उनका फ़िटनेस-फ़ंक्शन आश्वासन अध्याय 8.1 की डिलीवरी पाइपलाइनों से जुड़ता है। अध्याय 1.1 की दोषरहित सीख अध्याय 9.3 के घटना प्रबंधन को आधार देती है, और इस पूरे भाग में स्थापित बचाव-योग्य, दस्तावेज़ीकृत निर्णय-निर्माण ठीक वही है जिस पर अध्याय 10.2 का जोखिम, ऑडिट, और आश्वासन कार्य निर्भर करता है। नींवों को सही रखें, और पुस्तक का बाकी हिस्सा लागू करना कहीं आसान हो जाता है।