एडम स्मिथ बनाम फुलस्टैक डेवलपर्स

12

एडम स्मिथ द्वारा, श्रम विभाजन आपको 240 गुना अधिक प्रभावी बना सकता है (18 चरणों में पिन बनाने वाले पिन कारखाने के उदाहरण पर)।

फिर बहु-कुशल भूमिकाएं इतनी मांग में क्यों हैं अगर यह वास्तव में उत्पादकता को कम करता है - या स्मिथ सिर्फ गलत था, तो क्यों?

Google पर "फुलस्टैक डेवलपर" की खोज अभी भी चल रही है, हालांकि स्पष्ट रूप से दो साल पहले की तुलना में धीमी है:

=====

योग करने के लिए, एक पूर्ण स्टैक डेवलपर लगभग सभी मूल्य श्रृंखला में सक्षम होगा (मुझे गलत होने पर सही करें):

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

UPD - " हमें विशेषज्ञता की उत्पादकता की आवश्यकता है, लेकिन हम" श्रम के चरम विभाजन "(DevOps Guys, " DevOps, एडम स्मिथ और जनरलिस्ट की किंवदंती "के इंसुलर विश्वदृष्टि नहीं चाहते हैं , 2013-2016)

culture project-management

— पीटर मुर्सकिन
स्रोत

1

सभी ट्रेडों का एक जैक किसी का भी स्वामी नहीं है (ठीक है शायद कुछ)।

— पेतह

12

दो प्रकार के कार्य हैं:

शोषण - अच्छी तरह से परिभाषित कार्य जिसे आसानी से अच्छी तरह से परिभाषित चरणों में विभाजित किया जा सकता है, जहां प्रत्येक चरण को सीखा जा सकता है और अपने दम पर महारत हासिल की जाती है और चरणों के बीच सौंपने के लिए संचार की आवश्यकता नहीं होती है।
अन्वेषण - अनिर्धारित कार्य, जिसके लिए प्रत्येक चरण को पूरा करने के लिए सीखने और प्रयोग करने की आवश्यकता होती है और चरणों के बीच सौंपने के लिए सभी सीखने और परियोजना की स्थिति के लिए भारी मात्रा में संचार की आवश्यकता होती है।

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

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

— जिरी क्लौडा
स्रोत

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

— पीटर मुर्सकिन

6

एडम स्मिथ को एक चरण से दूसरे चरण में जानकारी पारित करने पर विचार करने की आवश्यकता नहीं थी। यह किसी भी महत्वपूर्ण आईटी परियोजना का एक महत्वपूर्ण हिस्सा है। इसलिए एक फुलस्टैक डेवलपर के महत्वपूर्ण लाभ हैं:

उन्हें किसी अन्य विभाग में किसी से बात करने की ज़रूरत नहीं है
उन्हें इसके इर्द-गिर्द आने के लिए उन अन्य लोगों की प्रतीक्षा करने की आवश्यकता नहीं है
बहुत कम संभावना है कि एक परत और दूसरी के बीच अनुवाद में कुछ खो जाएगा

आईटी परियोजनाओं में पास होने वाली सूचना के महत्व के बारे में अधिक जानने के लिए फ्रेड ब्रूक के पौराणिक मानव माह को देखें ।

— चूजों
स्रोत

ठीक है; लेकिन, मैं एक फुलस्टैक पिन निर्माता के बिना नहीं देखता, तब तक वह खुद पिन नहीं बनाता?

— पीटर मर्सकिन

1

@PeterMuryshkin: पिन निर्माता के साथ फुलस्टैक डेवलपर की तुलना न करें। आप मेकफाइल मेंटेनर की तुलना पिन मेकर से कर सकते हैं। एक फुलस्टैक डेवलपर की तुलना एक शेफ से की जानी चाहिए। एक शेफ के बिना एक रसोई पूरी तरह से ठीक काम कर सकती है, क्योंकि एक देव टीम एक फुलस्टैक डेवलपर के बिना पूरी तरह से ठीक काम कर सकती है। लेकिन एक शेफ रसोई के वर्कफ़्लो को बेहतर ढंग से बेहतर बना सकता है क्योंकि वह सूप से सब कुछ समझता है कि कैसे रसोई को साफ रखना चाहिए। एक फुलस्टैक डेवलपर के रूप में एक ही रास्ता एक देव टीम के वर्कफ़्लो में सुधार कर सकता है

— स्लीबेटमैन 11

1

@PeterMuryshkin अब, क्यों कि एक शेफ रसोई का बॉस है, लेकिन एक फुलस्टैक देव अक्सर एक देव टीम का नेता नहीं होता है, यह एक और दिन के लिए एक सवाल है

— स्लीवेटमैन

1

फिजिकल मैन्युफैक्चरिंग में आपके द्वारा एक चरण में बनाये जाने वाले विजेट अनिवार्य रूप से पूर्ण और अपेक्षाकृत मेटाडेटा से मुक्त होते हैं। सॉफ्टवेयर डेवलपमेंट में मेटाडेटा अधिक स्वैच्छिक और महत्वपूर्ण है।

— चूजों को

4

IMHO जवाब के पैमाने और संसाधन उपलब्धता के साथ बहुत कुछ करना है।

मेरा मानना है कि एडम स्मिथ के सिद्धांत को केवल बड़े पैमाने पर लागू किया जा सकता है - संपूर्ण राष्ट्रों / अर्थव्यवस्थाओं को मूल संदर्भ में, या, एसडब्ल्यू विकास के संदर्भ में - बड़े विकास दल।

एक बड़ी टीम में, वास्तव में, अधिक विशिष्ट मानव संसाधन को रखने के लिए अधिक कुशल है:

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

ओह, और ऐसी टीमें केवल कार्यात्मक हो सकती हैं यदि वे उच्च-गुणवत्ता वाले वास्तुशिल्प संसाधनों से पूरित होती हैं जो उत्पाद को छोटे, विशेष कार्यों में विभाजित करना आवश्यक होता है जिन्हें विशेष संसाधनों के साथ संबोधित किया जा सकता है।

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

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

— डैन कोर्निलेस्कु
स्रोत

3

मैं खुद को जिम्मेदारियों के निम्नलिखित संयोजन के आधार पर एक फुलस्टैक डेवलपर के रूप में मानता हूं:

फ्रंट एंड और बैक एंड प्रोग्रामिंग

मैं कुछ हद तक यूआई परिवर्तन कर सकता हूं: एचटीएमएल, सीएसएस (एक वेब डेवलपर के रूप में) लिखें और दूसरी तरफ कुछ विस्तार में डेटाबेस से यूआई को डेटा प्रदान करें, इसे एक सेवा में प्रदान करें आदि।

मैं परीक्षण, वास्तुकला और उन लोगों को छोड़ देता हूं, ग्राहकों से मिलना काम के विवरण में जोड़ा जा सकता है।

सामने

मेरी बात के विपरीत यूआई लोगों और बैक एंड दोस्तों की सख्त भूमिका होगी।

निष्कर्ष

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

— माइको
स्रोत

1

इसके लिए धन्यवाद, हालांकि यह मेरे सवाल का जवाब नहीं है, लेकिन फुलस्टैक डेवलपर शब्द का अधिक सटीक स्वागत किया जा रहा है

— पीटर मुर्सकिन

3

संक्षेप में, मुझे नहीं लगता कि एडम स्मिथ गलत थे, लेकिन मुझे लगता है कि सॉफ्टवेयर निर्माण में श्रम विभाजन के उनके मॉडल और सिलोस में कुछ गंभीर अंतर हैं।

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

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

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

जहां मुझे लगता है कि स्मिथ का काम सॉफ्टवेयर डेवलपमेंट में सही है, संदर्भ स्विचिंग (या मल्टीटास्किंग ) के क्षेत्र में है ; यदि कोई एकल डेवलपर विकास के सभी क्षेत्रों के लिए ज़िम्मेदार है, तो उसे ज़िम्मेदारी से हटने में समय लगता है। पैमाने पर, एक ही उत्पाद टीम में विभिन्न अनुभवों के साथ टीम के सदस्यों के बीच सहयोग संदर्भ स्विचिंग और जटिल बातचीत को संतुलित कर सकता है।

— स्टुअर्ट आइन्सवर्थ
स्रोत

3

समझने के लिए एक महत्वपूर्ण बिंदु यह है कि श्रम विभाजन का अर्थ हमेशा प्रति चरण एक अलग व्यक्ति नहीं होता है।

मैं एक कार फैक्ट्री में अपना इतिहास ले जाऊंगा, मैं एक सीट असेंबली चेन पर था, एयरबैग, लेदर, हेड रेस्ट आदि के साथ पूरी सीट पाने के लिए चेन को 9 चरणों में विभाजित किया गया था। हम 9 चेन पर काम कर रहे थे। प्रत्येक व्यक्ति एक समय में केवल एक ही चरण कर रहा था, लेकिन हर घंटे हम बहुत अधिक पुनरावृत्ति से बचने के लिए अगले चरण पर जा रहे थे। कार्यदिवस 8h लंबा था इसलिए हम हर दिन प्रत्येक चरण पर नहीं आए।

यह वास्तव में एक श्रम विभाजन है जहां आप एक निश्चित समय में विधानसभा का केवल एक चरण करते हैं, जो आपको पूर्ण विधानसभा करने में सक्षम होने से नहीं रोकता है।

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

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

— Tensibai
स्रोत

अच्छा! मैंने ऐसा कभी नहीं माना, लेकिन आप बिल्कुल सही हैं! श्रम का विभाजन, श्रम को केवल वृद्धिशील चरणों में विभाजित कर रहा है।

— जेरेमी डेविस

एडम स्मिथ बनाम फुलस्टैक डेवलपर्स - और DevOps में उत्पादकता?