क्यों सर्वरहित प्रौद्योगिकी उत्पाद प्रबंधन में एक क्रांति है

सर्वर रहित आर्किटेक्चर मूल रूप से उत्पाद विकास को सीमित करने वाले कारकों को प्रभावित करते हैं।

संगठन में उत्पाद प्रबंधक विभिन्न प्रकार की भूमिकाओं में कार्य करते हैं। कभी-कभी उन्हें "ग्राहक आवाज़" कहा जाता है, कभी-कभी वे "कॉर्पोरेट बिल्ली-खतरा" की भूमिका निभाते हैं। वे मोटी-चमड़ी वाले भाई हैं, जो लोग किसी भी नैतिकता या बहाने के बावजूद आपको उत्पाद देने के लिए मजबूर करते हैं। एक अच्छा उत्पाद प्रबंधक शायद ही कभी किसी और की मूर्ति बन जाता है, लेकिन यह ऐसे लोगों के काम के लिए धन्यवाद है जो आपके द्वारा उपयोग किए गए अधिकांश तकनीकी समाधान सन्निहित हैं।

पीएम हमेशा समस्या को हल करने के लिए उच्चतम गुणवत्ता वाले उपकरणों की तलाश में हैं। हम जानते हैं कि प्रतियोगी अपनी ऊँची एड़ी के जूते पर लगातार आगे बढ़ रहे हैं, ग्राहक इंतजार करते-करते थक गए हैं, इसलिए हमें लगातार स्मार्ट, तेज और अधिक कुशलता से कार्य करना होगा। सर्वर रहित प्रौद्योगिकियों के आगमन के साथ, यह तुरंत स्पष्ट नहीं था कि वे उत्पाद प्रबंधन इच्छा सूची में कैसे फिट होंगे। हालांकि, एक साल तक इन तकनीकों के साथ काम करने के बाद, मैं देखता हूं कि वे सॉफ्टवेयर विकास की कुछ समस्याओं को हल करते हैं जो हमें हमेशा के लिए लगती थीं।

विरोधाभास: टीम का आकार और प्रदर्शन

उत्पाद प्रबंधन का पहला नियम कहता है: प्रदर्शन किए जाने वाले काम की मात्रा लगातार बढ़ रही है। बैकलॉग में सूजन जारी है, और यह केवल एक मामले में शून्य तक गिर जाता है: जब उत्पाद समाप्त हो जाता है। प्रसव के लिए तैयार उत्पाद में अपने बैकलॉग के सबसे महत्वपूर्ण तत्वों को चालू करना सबसे मुश्किल काम है। अन्य सभी चीजें समान हैं, यह माना जाता है कि निम्नलिखित संबंध देखा जाना चाहिए:


यदि एक खुदाई करने वाला प्रति दिन 1 टन मिट्टी को रीसायकल कर सकता है - तो यह माना जाता है कि 10 खुदाई करने वाले 10 टन को रीसायकल कर सकते हैं। एक नियम के रूप में, कंपनियों में संसाधन प्रबंधन इस सिद्धांत पर बनाया गया है: यदि आप बिक्री बढ़ाना चाहते हैं - अधिक बिक्री वाले लोगों को किराए पर लें। सॉफ्टवेयर विकसित करते समय, जब बैकलॉग बढ़ता है, तो प्रलोभन बस टीम को बढ़ाने के लिए होता है। हालांकि, जटिल उत्पादों और सेवाओं के मामलों में, लगभग निम्नलिखित अनुसूची आमतौर पर समय के साथ कम हो जाती है:


यह देखना दुर्लभ है कि स्टैखानोव गति में एक विशाल टीम कैसे काम करती है; लेकिन अक्सर ऐसा होता है कि एन्विबल कॉन्स्टेंसी वाली एक छोटी टीम छलांग और सीमा से आगे बढ़ती है।

कई स्टार्टअप में इस तरह की गलती होती है: जैसे ही उत्पाद सफल हो जाता है, कर्मचारियों में अधिक नए डेवलपर्स और प्रबंधकों को जोड़ दिया जाता है। जल्द ही यह अचानक पता चलता है कि गति गिरने लगती है। मामला क्या है? कि पहले डेवलपर्स अधिक प्रतिभाशाली थे, कि कंपनी में नौकरशाही बढ़ी और वास्तुकला की योजना कैसे बनाई गई?

मुझे लगता है कि ये सब सिर्फ लक्षण हैं, समस्या की जड़ नहीं। समस्या स्वयं तीन महत्वपूर्ण कारकों की बातचीत के लिए नीचे आती है, जिनमें से केवल दो को सीधे नियंत्रित किया जा सकता है:

• नाजुकता नए परिवर्तनों का प्रभाव है। यदि एक नई सुविधा मशीन के केवल एक हिस्से को प्रभावित करती है, तो परीक्षण करना और लागू करना आसान है। यदि यह मशीन के सभी तत्वों को प्रभावित करता है, तो परीक्षण अधिक कठिन हो जाता है और एक ही समय में अधिक महत्वपूर्ण होता है, और कार्यान्वयन के लिए अधिक समय के परिमाण के आदेश की आवश्यकता होती है।
• काम की मात्रा एक टीम द्वारा किया जा सकता है और उत्पादन में एक उत्पादक सुविधा देता है कि काम का सबसे छोटा टुकड़ा है। उदाहरण के लिए, परिणाम "एलेक्सा के साथ भुगतान करें" के बजाय "एक साथ मिलता है और चर्चा करें कि एलेक्सा के साथ भुगतान कैसे करें"।
• जटिलता - एक विशेषता को लागू करने के लिए कितना ज्ञान आवश्यक है। क्या एक डेवलपर जो जानता है कि संगठन के भीतर एक ही काम करने में सक्षम फीचर को कैसे लिखना है? प्रगति के क्रम में धीरे-धीरे धीमा होने के लिए अतिरिक्त परिवर्तन क्या होने चाहिए, और उत्पाद उन विशेषताओं के साथ बढ़ना बंद हो जाता है जो क्लाइंट के दृष्टिकोण से मूल्यवान हैं?

मुझे विशेष रूप से दिलचस्पी है कि क्यों, अस्तित्व के भोर में, इन सभी कारकों को संतुलित रूप से संतुलित किया जाता है: कुछ भी नाजुक नहीं है, काम की मात्रा विशेष रूप से बड़ी नहीं है (और आप आमतौर पर ग्राहक से सहमत हो सकते हैं), और जटिलता व्यावहारिक रूप से अनुपस्थित है। इसलिए, यदि किसी टीम को जीडीपीआर-अनुपालन साइट बनाने की आवश्यकता होती है, तो उनके पास इस समस्या पर शोध करने का समय होगा, एक निर्णय जल्दी से किया जाएगा, और टीम यह सुनिश्चित करेगी कि साइट बिल्कुल नियोजित रूप से काम करती है।

बड़ी कंपनियों में, इन कारकों को संयोजित किया जाता है, जिसके परिणामस्वरूप टीम का आकार बढ़ता है, और प्रदर्शन किए गए कार्य की मात्रा कम हो जाती है। ऐसी कंपनी में जीडीपीआर-संगत वेबसाइट बनाने के लिए, आपको एक वकील के हस्ताक्षर, बाज़ारियों की स्वीकृति, निदेशक मंडल के स्तर पर परियोजना की मंजूरी, कम से कम विघटनकारी कार्यान्वयन का ए / बी परीक्षण, प्रवेश की टीम के साथ विकास रुकावट का समन्वय, अन्य टीमों द्वारा अपनाई गई तैनाती योजनाओं के साथ समन्वय की आवश्यकता होगी। - सूची जारी होती है। इस नियंत्रण की मात्रा और प्रक्रियाओं की संख्या के साथ भी, टीम बहुत कम आश्वस्त है कि यह पूरी प्रणाली की नाजुकता और पारिस्थितिकी तंत्र में कई अज्ञातताओं के कारण सफल होगा।

इस उदाहरण को एक वास्तविक परियोजना के आकार में विस्तारित करना, जिसमें दर्जनों विशेषताएं और सैकड़ों परिवर्तन हो सकते हैं, यह समझना आसान है कि इन कारकों की बातचीत के कारण, अनुपात "टीम के आकार / कार्य की मात्रा" का ग्राफ पहले से दूसरे में बदल जाता है। जैसे-जैसे टीम बढ़ती है, आप समय की प्रति यूनिट कम काम करने के लिए बर्बाद हो जाते हैं, चाहे आप संगठनात्मक कॉलॉज़ को आउट करने की कोशिश करें। या यह सिर्फ ऐसा लगता है - लेकिन फिर, क्या किया जाना है?

तीनों कारकों को कैसे हैक किया जाए

यह समस्या मुझे कई वर्षों से सता रही है, जिसने मुझे इसके संभावित कारणों का अध्ययन करने के लिए प्रेरित किया। क्या स्टार्टअप के लिए तेजी से प्रगति करना संभव है? कुछ समय के लिए, मैंने सिर्फ इतना सोचा, बड़े संगठनों में उत्पाद प्रबंधन की कठिनाइयों का सामना किया। हालांकि, तब मैंने तीनों कारकों को अधिक बारीकी से देखा।

नाजुकता हमेशा आपके विरोध में होती है - यह किसी भी आकार के किसी भी प्रोजेक्ट में बढ़ते तकनीकी ऋण को उकसाती है। स्थिति "विपरीत पर आधा जीवन" की याद दिलाती है: कार्यक्रम का कोई भी तत्व समय के साथ बढ़ता है और इस वजह से (विकास के दौरान) यह अधिक नाजुक हो जाता है, और यह सब कोड की प्रत्येक नई पंक्ति के साथ जटिल होता है।

काम की मात्रा उत्पाद की एक विशिष्ट विशेषता ("एलेक्सा के साथ भुगतान") से संबंधित नहीं है, लेकिन अगर हम "पहले" और "बाद" राज्यों की तुलना करते हैं तो बुनियादी ढांचे की रूपरेखा में अंतर है। जितना मुश्किल "बाद" बन जाता है, उतना ही अधिक काम करने की मात्रा कम हो जाती है। इसीलिए कई कंपनियों में, जब कार्य की योजना होती है, तो ग्राहक की जरूरतों ("एलेक्सा के साथ भुगतान") से संगठन की जरूरतों पर जोर दिया जाता है ("मिलिए और एलेक्सा के साथ भुगतान करें" सुविधा के कार्यान्वयन में शामिल होना चाहिए।

जटिलता सामाजिक, संगठनात्मक और तकनीकी कारकों का एक संयोजन है जो सीधे एक उपयुक्त डेवलपर के लिए खोज की अवधि को प्रभावित करता है, प्रोग्रामर को बहु-काम करने वाले लोगों के रूप में व्यवहार करने की क्षमता जो किसी भी काम को सौंपा जा सकता है। इसके अलावा, यह जटिलता है - बहुत ही पहलू जो अदृश्य, अनिर्दिष्ट और गलत समझा जाता है। एक डेवलपर घर पर एक रिएक्ट एप्लिकेशन लिख सकता है और इसे स्वयं जारी कर सकता है, लेकिन संगठन में उसे एक दर्जन अतिरिक्त कदम उठाने होंगे जो कि अपना समय लेगा, और उपयोगकर्ता के लिए दिलचस्प विशेषताएं बिल्कुल नहीं बदलेगी। प्रोग्रामर उन पर दिन का अधिकांश समय बिताएगा।

साथ में, ये तीन कारक एक दुष्चक्र बनाते हैं, ताकि प्रदर्शन किए गए कार्य की मात्रा कम हो जाती है, नाजुकता बढ़ जाती है, डेवलपर कम और कम सुविधाओं को पूरा करने का प्रबंधन करता है, और आपका उत्पाद एक अदृश्य कीचड़ के रूप में जटिलता के साथ उग आता है। नतीजतन, टीम की वृद्धि में मदद नहीं करता है, और गति केवल संख्याओं और संकेतकों के साथ चालाक द्वारा सचेत रूप से बढ़ाई जा सकती है। एक क्लासिक लक्षण: "बैठक आयोजित" स्थिति स्प्रिंट रिपोर्टों में दिखाई देती है।

बड़ी कंपनियों में, मुझे इस चक्र को तोड़ने के लिए डिज़ाइन किए गए कुछ त्रुटिपूर्ण दृष्टिकोणों का अवलोकन करना था। पहली "बड़े पैमाने पर फुर्तीली" है, जिसके परिणामस्वरूप विशाल बैठकें होती हैं जिसमें किसी विशेष सुविधा के विकास में बिल्कुल भाग लेते हैं और काम को समन्वित करने का प्रयास किया जाता है। इसलिए काम का समन्वय करने और जटिलता को समझने की कोशिश करें। ऐसा दृष्टिकोण खाद्य वितरण कंपनियों के लिए अच्छा है जो मंत्रमुग्ध कर देती हैं, लेकिन हमारे मामले में यह काम नहीं करता है। तथ्य यह है कि जैसे-जैसे प्राथमिकता परियोजनाओं के समूह का आकार बढ़ता है, यह अधिक से अधिक होता जाता है, और वे खुद ही कम हो जाते हैं। इसलिए, नाजुकता और जटिलता की समस्याओं को मौलिक रूप से हल करना संभव नहीं है। समय के साथ, बड़े पैमाने पर एजाइल कार्यों की एक सामरिक सूची देता है जो खरीदारी की सूची से मिलता-जुलता है, और एक विचारशील सुविधा से दूसरे तक समग्र पथ की तरह कम और कम है।

दूसरे, इंट्रा-कॉरपोरेट "इनोवेशन ग्रुप्स" अक्सर परिधीय परिवर्तनों को धकेलने की कोशिश करते हैं, इस उम्मीद में कि यह काम एक नाजुक मशीन में जड़ लेगा, और बेहतर के लिए पूरी संरचना बदल जाएगी। यह दृष्टिकोण एक विचित्र पक्ष प्रभाव देता है: विश्वास को समेकित किया जाता है कि इस तरह के "इनोवेटर्स के समूह" को प्रक्रिया में बदलाव करने का अधिकार है। इसलिए, एक समान विधि संगठनात्मक जटिलता के साथ समस्याओं को हल नहीं करती है।

कई वर्षों की विभिन्न विफलताओं को देखने के बाद, मैं इस नतीजे पर पहुंचा कि सभी तीन कारकों को हैक करना आवश्यक है ताकि काम पर उनके संयुक्त प्रभाव को रोका जा सके और जड़ता का सामना किया जा सके:

• भविष्य के संस्करणों में या उत्पाद की उम्र के रूप में नाजुकता नहीं बढ़नी चाहिए।
• कार्य का टुकड़ा उपयोगकर्ता के दृष्टिकोण से महत्वपूर्ण विशेषता बनाने के लिए आवश्यक से कम नहीं होना चाहिए।
• जटिलता किसी एकल डेवलपर के काम को प्रभावित नहीं करना चाहिए।
  यदि आप इन विचारों को अपनाने में सफल होते हैं, तो आपको चट्टान से बचाया जाएगा, जो मानव जाति के इतिहास में सभी सॉफ्टवेयर उत्पादों का पीछा करता है। यह बहुत अच्छा लगता है, लेकिन यह कैसे प्राप्त किया जा सकता है?

यदि आप इन विचारों को अपनाने में सफल होते हैं, तो आपको चट्टान से बचाया जाएगा, जो मानव जाति के इतिहास में सभी सॉफ्टवेयर उत्पादों का पीछा करता है। यह बहुत अच्छा लगता है, लेकिन यह कैसे प्राप्त किया जा सकता है?

सर्वर रहित प्रौद्योगिकियाँ सीमाएँ तोड़ती हैं

क्लाउड तकनीक के आगमन के लिए धन्यवाद, महत्वपूर्ण ट्रेल्स को एक नए "हैक" राज्य में देना संभव था। सामान्य तौर पर, बादलों के आगमन के साथ, एक सॉफ्टवेयर उत्पाद देने की प्रक्रिया अधिक कॉम्पैक्ट हो गई, क्योंकि एक प्रदाता ने आपके लिए बहुत सी नियमित चीजें करना शुरू कर दिया। बादलों के दिखाई देने से पहले, यदि आपको एक नई उपयोगकर्ता सुविधा लागू करने की आवश्यकता है, तो आपको एक सर्वर ऑर्डर करना होगा, रैक पर उपकरण स्थापित करना होगा, एक डेटा सेंटर में नेटवर्क बिछाने पर सहमत होना होगा, और फिर इस उपकरण को बनाए रखना होगा, जो समय के साथ खराब हो जाता है। क्लाउड में, यह सब किराए पर लिया जा सकता है, इस प्रकार दर्जनों संगठनात्मक वस्तुओं से छुटकारा पाने और पूरे महीने की बचत होती है।

इसके अलावा, डेटा सेंटर में उपकरणों को अपग्रेड करने और मांग पर हार्डवेयर तक पहुंच प्रदान करने की आवश्यकता को समाप्त करके, हम नाजुकता और जटिलता दोनों को कम करते हैं। पुराने दिनों की तुलना में कार्यक्रमों का उपयोग करना बहुत आसान है। हालांकि, समय के साथ, एक व्यापक आभासी बुनियादी ढांचे के प्रशासन का बोझ काफी बढ़ गया है, और कई पुरानी डिलीवरी विधियां अपरिवर्तित बनी हुई हैं। बादलों का उपयोग करते हुए, काम को धीमा करने से पहले टीम को काफी बढ़ाया जा सकता है - हालांकि, यह धीमा करना शुरू कर देता है, एक तरह से या किसी अन्य।

सर्वर रहित प्रौद्योगिकियां इस गतिशील को मौलिक रूप से बदल देती हैं। सर्वर रहित एप्लिकेशन में आपकी टीम (तथाकथित "गोंद") और कार्यात्मक "ब्लैक बॉक्स" द्वारा लिखे गए कोड के छोटे टुकड़े होते हैं जो क्लाउड प्रदाता द्वारा प्रबंधित होते हैं। ब्लैक बॉक्स केवल एक कॉन्फ़िगरेशन को स्वीकार करता है और परिवर्तनों पर प्रतिक्रिया करता है। उच्च गुणवत्ता वाली वास्तुकला के साथ एक आवेदन में, ऑपरेशन के संचालन से जुड़े संचालन का एक मानक हिस्सा मानक ब्लैक बॉक्स पर पड़ता है। एप्लिकेशन स्वयं अब एक अखंड फ़ंक्शन नहीं है, लेकिन फ़ंक्शंस और ब्लैक बॉक्स की एक संघीय संरचना है।

व्यवहार में, यह नाटकीय रूप से उन तीन कारकों को प्रभावित करता है, जिनका मैंने ऊपर उल्लेख किया है:

• शून्य अवसंरचना प्रबंधन लागत और कमजोर बंधन के कारण नाजुकता कम हो जाती है। हमारी अपनी परियोजनाओं में, यह देखा गया कि ऐसे परिवर्तनों के परिणामस्वरूप कोड आधार कभी-कभी दस गुना कम हो सकता है।
• "काम का टुकड़ा" का आकार आमतौर पर एक नई सुविधा बनाने की लागत के बराबर होता है, क्योंकि यह कार्यों के नए संस्करणों या पूरी तरह से नए कार्यों को बनाने के लिए तुच्छ हो जाता है जिनकी पहले आवश्यकता नहीं थी।
• जटिलता डेवलपर को प्रभावित नहीं करती है - यदि वह एक फ़ंक्शन लिख सकता है जो क्रेडिट कार्ड भुगतान की प्रक्रिया करता है, तो सर्वरलेस एप्लिकेशन में इस कोड के अलावा व्यावहारिक रूप से कुछ भी नहीं है, कोई संगठनात्मक आवरण और पारिस्थितिक तंत्र का कोई विचार नहीं है, जिसके कारण काम धीमा हो सकता है।

बहुत बड़े सर्वर रहित अनुप्रयोगों का प्रबंधन करते समय, उत्पाद प्रबंधक के लिए उन बहुत कम तत्वों पर करीब से नज़र डालना आसान होता है जो किए गए परिवर्तनों से प्रभावित थे। इसके अलावा, सुविधाओं के झंडे लगाकर प्रतिस्पर्धी रूप से दो संस्करण लॉन्च करना आसान है। इसके अलावा, आमतौर पर कोड के पुराने संस्करणों को ध्वस्त करना भी आवश्यक नहीं है।

सर्वर रहित अनुप्रयोगों में, बुनियादी ढांचे को हमेशा परिधि पर बनाया जाता है, और आप केवल आवश्यक न्यूनतम कोड लिखते हैं जो पूरी तरह से प्रबंधित सेवाओं को जोड़ती है। आपको परिचालन के दृष्टिकोण से उनके बारे में कभी नहीं सोचना चाहिए। हम मोनोलिथ को नियंत्रित करने की कोशिश नहीं कर रहे हैं, पुराने कोड को साफ करते हैं, या पूरे सिस्टम को एक पक्षी की नजर से देखते हैं।

यह बेहद महत्वपूर्ण क्यों है

जैसे-जैसे परिवर्तन की गति बढ़ती है, यह भविष्यवाणी करना मुश्किल हो जाता है कि भविष्य में आपका कार्यक्रम कैसा दिखेगा या उपयोगकर्ता आपसे क्या चाहते हैं। इसलिए, कोड को "सदियों से" लिखने का प्रयास किया जाता है, ताकि भविष्य में यह किसी भी बदलाव के बावजूद काम करना पड़े। हमने देखा है कि अधिकांश कंपनियों में कोड का पुन: उपयोग कितना बुरा है, और अप्रचलित प्लेटफॉर्मों का पालन कैसे प्रगति को धीमा कर देता है।

अब सब कुछ व्यवस्थित किया जाता है ताकि पुरानी प्रणाली को यथासंभव लंबे समय तक विकसित और बनाए रखा जाए, जब तक कि इसका समर्थन लगभग हर समय प्रोग्रामर से दूर रखना शुरू न करे। उसके बाद, कंपनी फिर से नई प्रणाली के साथ शुरू होती है, पूरी तरह से पुराने में की गई गलतियों को नहीं दोहराने का वादा करती है। जब तीन कारक जल्दी या बाद में नई प्रणाली का गला घोंटते हैं, तो एक तकनीकी "वन फायर" है, जिसके बाद फिर से आपको फिर से शुरू करना होगा।

हम जटिलता के लक्षणों के खिलाफ लड़ाई में बदल जाते हैं, यही कारण है कि इतने सारे प्रतिमान आते हैं और चले जाते हैं, उत्पाद प्रबंधन के इतिहास में कोई महत्वपूर्ण निशान नहीं है। सर्वर रहित विकास, बदले में, टीम को जटिलता में वृद्धि को कम करने और मूल्यवान उत्पाद को एक समान गति से वितरित करने की अनुमति देता है, बिना क्लासिक ट्रैप में गिरते हुए कि दशकों से किसी भी सॉफ्टवेयर विकास का संकट बना हुआ है।

सर्वर रहित प्रतिमान अभी विकसित होना शुरू हुआ है, लेकिन यह पहले से ही बेहद आशाजनक है। ऐसे समय में जब क्लाइंट को आपके पास पहले जैसी नई सुविधाएँ होने की आवश्यकता होती है, उत्पाद प्रबंधक अंततः एक प्लेटफ़ॉर्म प्राप्त कर सकते हैं जो आपको नई सुविधाओं की तैयारी के आधार पर सटीक सोचने की अनुमति देता है। संगठनात्मक जटिलता बढ़ने से यह प्रक्रिया बाधित नहीं होती है, और अत्यधिक नाजुकता के कारण भी नहीं रुकती है।