आपके इंजीनियर समस्या नहीं हैं। समस्या वह काम है जो आप उन्हें दे रहे हैं।
आखिरी स्प्रिंट को ईमानदारी से देखें। इसमें से कितना कुछ नया निर्माण कर रहा था, और इसका कितना हिस्सा पहले से ही तैनात किए गए कार्यों की देखरेख कर रहा था?
ऑन-कॉल शिफ्ट. ट्राइएज घुमाव. ऐसी जांचें जो शून्य जांच के गायब होने के साथ समाप्त होती हैं। एक ही वर्ष में तीन बार एक ही प्रतिगमन के लिए पोस्टमार्टम। एक प्लेटफ़ॉर्म टीम जो तकनीकी रूप से एक प्लेटफ़ॉर्म टीम है, लेकिन व्यवहार में रोशनी चालू रखने के लिए मौजूद है। एक स्लैक चैनल को बुलाया गया #अग्निशमन जिसे कोई भी म्यूट नहीं करना चाहता क्योंकि म्यूट करना गैर-जिम्मेदाराना लगता है।
हमने खुद को आश्वस्त किया है कि यह इंजीनियरिंग है।
यह नहीं है. यह पर्यवेक्षण है.
महँगा काम हमेशा प्रभावशाली काम नहीं होता
उत्पादन रखरखाव बाहर से गंभीर लग सकता है। डैशबोर्ड खुले हैं. धागे घूम रहे हैं. लॉग स्क्रॉल कर रहे हैं. इंजीनियर दबाव में निर्णय ले रहे हैं।
उसमें से कुछ काम जरूरी है. इसमें से अधिकांश केवल वह संगठन है जो मनुष्यों से अपूर्ण स्वचालन के लिए बैकअप सिस्टम बनने के लिए कह रहा है।
आपकी टीम के सर्वश्रेष्ठ इंजीनियर घटना चैनलों को ताज़ा करने, एक ही तैनाती विंडो की दो बार तुलना करने, या किसी पाइपलाइन की देखभाल करने के लिए तब तक शामिल नहीं हुए जब तक कि कुछ लाल न हो जाए। वे उत्पाद बनाने, वास्तुकला में सुधार करने, बाधाओं को दूर करने और उत्तोलन बनाने के लिए शामिल हुए।
जब उनके सप्ताह का एक तिहाई हिस्सा उत्पादन पर्यवेक्षण में चला जाता है, तो कंपनी सिर्फ घंटों का नुकसान नहीं करती है। यह वरिष्ठ इंजीनियरों के भविष्य के बारे में सोचने के मिश्रित प्रभाव को खो देता है।
पैटर्न दोहराता है क्योंकि लूप मैनुअल है
अधिकांश आवर्ती उत्पादन कार्य एक परिचित पथ का अनुसरण करते हैं:
- कुछ विफल रहता है.
- एक अलर्ट इंसान तक पहुंचता है.
- मानव निशान, लॉग, परिनियोजन इतिहास और हाल की प्रतिबद्धताओं को खोलता है।
- कोई पूछता है कि सेवा का स्वामी कौन है?
- टीम इस बात पर बहस करती है कि क्या यह बग है, ख़राब तैनाती है, अपस्ट्रीम समस्या है या डेटा एज का मामला है।
- वास्तविक सुधार छोटा निकला।
समाधान हमेशा कठिन नहीं होता. समस्या को ठीक करने से ही दोपहर में परेशानी होती है।
वह अंतर वह है जहां टीमें उत्पाद की गति खो देती हैं। यह वह जगह भी है जहां एआई एजेंट इंजीनियरों से नियंत्रण छीने बिना मदद कर सकते हैं।
2026 में, यह एक समाधान योग्य समस्या है
सेल्फ-हीलिंग सॉफ़्टवेयर का मतलब यह नहीं है कि कोई मॉडल चुपचाप उत्पादन बदल देता है। गंभीर इंजीनियरिंग टीमें यही नहीं चाहतीं।
बेहतर मॉडल संकीर्ण और अधिक उपयोगी है:
- ट्रेस पढ़ें
- विफलता का सारांश प्रस्तुत करें
- तैनाती की तुलना करें
- संभावित प्रतिगमन का पता लगाएं
- मालिक की पहचान करें
- पुल अनुरोध का मसौदा तैयार करें
- सबूत दिखाओ
- अनुमोदन की प्रतीक्षा करें
इससे इंजीनियरिंग निर्णय को हटाए बिना इंजीनियरों को समय वापस मिल जाता है। मानव अभी भी निदान की समीक्षा करता है, पैच को संपादित करता है, परीक्षणों की जांच करता है, और निर्णय लेता है कि विलय करना है या नहीं।
एजेंट पर्यवेक्षण का कार्य संभालता है। इंजीनियर निर्णय संभालता है।
सीटीओ प्रश्न बदल रहा है
इस तिमाही में प्रत्येक सीटीओ के लिए सवाल केवल यही नहीं है, "क्या हमारे पास पर्याप्त इंजीनियर हैं?"
यह भी है, "हमारे इंजीनियर वह काम क्यों कर रहे हैं जिसे एक एजेंट 90 सेकंड में तैयार कर सकता है जबकि फिक्स भेजने के लिए मानव अनुमोदन की प्रतीक्षा कर रहा है?"
यदि उत्तर अनुपालन, स्वामित्व, या सुरक्षा है, तो यह मान्य है। वे बाधाएँ मायने रखती हैं। लेकिन उन्हें मैन्युअल बने रहने के लिए समीक्षा से पहले हर कदम की आवश्यकता नहीं है।
टीमें नियंत्रण रख सकती हैं और फिर भी उत्पादन सिग्नल से समीक्षा किए गए पुल अनुरोध तक दोहराए जाने वाले पथ को स्वचालित कर सकती हैं।
इंजीनियरों को उत्पाद का समय वापस दें
आपके सबसे मजबूत इंजीनियरों को उत्पाद कार्य से गायब नहीं रहना चाहिए क्योंकि वे लॉग आउटपुट की 40,127 लाइनें पढ़ रहे हैं।
उन्हें सीआई/सीडी के लिए अतिरेक परत नहीं होना चाहिए।
उन्हें मंगलवार की दोपहर फिर से यह साबित करने में नहीं बितानी चाहिए कि प्रतिगमन का वही वर्ग वापस आ गया है।
उन्हें उस चीज़ का निर्माण करना चाहिए जिसे बनाने के लिए कंपनी ने वास्तव में धन जुटाया था।
लक्ष्य परिचालन जिम्मेदारी को खत्म करना नहीं है। लक्ष्य मानव ध्यान को सिस्टम में सबसे सस्ता निगरानी आदिम मानना बंद करना है।
आपके इंजीनियरों को निर्माण करना चाहिए, बच्चों की देखभाल नहीं। उन्हें निर्माण के लिए समय वापस दें।
