तकनीकी काम का विफल वस्तुकरण

 (ludic.mataroa.blog)
2 पॉइंट द्वारा GN⁺ 2023-11-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें

तकनीकी काम का विफल वस्तुकरण

  • डेटा इंजीनियरिंग क्षेत्र में बेहद उत्कृष्ट प्रतिभा और पहले मैनेजर रहे एक व्यक्ति का खाना पकाने के प्रति जुनून।
  • खाना पकाने के प्रति इतना गहरा जुनून कि वह ओवन में चिकन की heat distribution के विश्लेषण जैसी बातें साझा करता है।
  • खाना पकाने की जटिलता और McDonald's संचालन की जटिलता के प्रति सम्मान व्यक्त करता है।

C-level अधिकारियों की सोच पर संक्षिप्त अंतर्दृष्टि

  • तकनीकी उद्योग की वर्तमान स्थिति को समझने के लिए 'The Phoenix Project' नाम की किताब पढ़ी जाती है।
  • किताब बताती है कि IT operations, manufacturing factory के काम की तरह है, और इससे संगठन के भीतर workflow management पर संकेत मिलते हैं।
  • 'The Unicorn Project', 'Investments Unlimited' जैसी इसी विषय की कई किताबें हैं, और ये किताबें संगठनों को अधिक कुशलता से चलाने पर सलाह देती हैं।

McData

  • तकनीकी उत्पाद बेचने वाली कंपनियाँ, उत्पाद के तकनीकी विवरणों से ज़्यादा, एकसमान काम को दोहराकर करने की क्षमता पर ज़ोर देकर उत्पाद बेचती हैं।
  • उत्पाद यह वादा करते हैं कि वे तकनीकी समस्याएँ हल करते समय किसी खास engineer की क्षमता पर निर्भर हुए बिना भी पर्याप्त अच्छे परिणाम दे सकते हैं।
  • कई कंपनियाँ तकनीकी बारीकियों को नज़रअंदाज़ कर, सिर्फ़ नया system खरीदकर समस्या हल करना चाहती हैं।

It's Fucking Raw

  • बहुत सा तकनीकी काम अब भी वस्तुकरण नहीं हो पाया है, और यह एक महत्वपूर्ण समस्या है।
  • तकनीकी काम का वस्तुकरण अक्सर विफल हो जाता है, जिससे कंपनियाँ ऐसे products बेचती और खरीदती हैं जो ठीक से काम नहीं करते।
  • तकनीकी काम का वस्तुकरण अब भी व्यक्तिगत रचनात्मकता से जुड़ा हुआ है, और यह संगठनों के भीतर मानवीय तत्व से भी जुड़ा है।

GN⁺ की राय

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

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-26
Hacker News राय
  • मेरा मानना है कि लेखक इस बात को नज़रअंदाज़ कर रहा है कि तकनीकी काम का एक बड़ा हिस्सा अब commoditized हो चुका है। जो चीज़ें पहले तकनीकी काम थीं, वे अब सरल कामों में बदल गई हैं। उदाहरण के लिए, mail merge या double-entry accounting अब साधारण barcode scan और tap-to-pay से बदल दिए गए हैं। तकनीकी काम की तुलना में requirements इकट्ठा करना अधिक कठिन हिस्सा है।
  • मैं सहमत हूँ कि तकनीकी काम का पूर्ण commoditization एक बुरा विचार है, और यह आगे भी विफल होता रहेगा। लेकिन मुझे नहीं लगता कि 'Phoenix Project' इसका समर्थन करता है। 'Phoenix Project' का मुख्य बिंदु यह है कि दोहराए जाने वाले काम को प्रबंधित और automate करने के लिए एक स्पष्ट system हो, काम के प्रगति समय को न्यूनतम किया जाए, जानकारी को व्यापक रूप से साझा किया जाए, वही काम किया जाए जिसकी business को वास्तव में ज़रूरत है, और unplanned work तथा शोर को कम किया जाए ताकि कर्मचारी अधिक मूल्यवान काम कर सकें।
  • यह बताया गया है कि 'commodification' और 'commercialization' जैसे शब्दों में भ्रम हो रहा है। 'Commodification' का अर्थ है कि जो चीज़ें पहले proprietary थीं वे सामान्य बन जाएँ, जबकि 'commercialization' का अर्थ है कि जो चीज़ें बिकती नहीं थीं वे बिक्री योग्य बन जाएँ।
  • डेवलपर्स McDonald's के किशोर कर्मचारियों जैसे नहीं हैं, बल्कि उस मशीन को डिज़ाइन करने वाले engineers के अधिक समान हैं। Programming खुद काम करना नहीं है, बल्कि meta-work है: एक बार instructions की सूची लिख दी जाए, तो computer वही काम अनंत बार कर सकता है।
  • एक गलत धारणा है कि software development पहले ही commoditized हो चुका है और अब code लिखने की ज़रूरत नहीं रही। वास्तव में, नई समस्याओं को हल करने के लिए system बनाना आसान नहीं है, और इसके लिए logical rules और flow को दर्शाने वाला text, version control, rollback आदि की आवश्यकता होती है, इसलिए programmers की अब भी ज़रूरत है।
  • मानव तत्व को फलने-फूलने दिए बिना कोई मूल्यवान self-help book नहीं बनाई जा सकती। लेकिन फिर भी किताबें छाप सकने वाली factory की ज़रूरत होती है, और सुंदर binding तभी निकलती है जब उसे ऐसे लोग चलाएँ जिनका काम से जुड़ाव हो।
  • tech industry लंबे समय से developers को commoditize करने की कोशिश करती रही है। उच्च-स्तरीय frameworks और देखने में सरल requirements के बावजूद, बहुत-सा software अब भी ठीक से काम नहीं करता। जैसा लेखक ने बताया, असली समाधान ऐसे सक्षम developers हैं जिन्हें वास्तव में परवाह हो।
  • business intelligence/analytics roles में SQL लिखने वाले लोगों को Tableau जैसे tools इस्तेमाल करने वालों से बदलने की कोशिश होती रही है। लेकिन इसमें कुछ समस्याएँ हैं: अधिक (और कम वेतन वाले) लोगों को रखना पड़ता है, business logic UI में छिपकर अधिक जटिल हो जाती है, और अब समाधान Tableau workbook में संग्रहित होता है जिसे किसी और चीज़ के input के रूप में इस्तेमाल नहीं किया जा सकता।
  • software की तुलना urban planning से करना अधिक उपयुक्त लगता है, और इसमें विभिन्न विशेषज्ञताएँ उभर रही हैं। जैसे-जैसे standards विकसित होंगे, किसी विशेष क्षेत्र में काम करने के लिए विशिष्ट certifications की आवश्यकता पड़ सकती है। कई मामलों में software अंतिम परिणाम नहीं, बल्कि स्वयं एक enabling capability होता है।
  • मैंने ऐसी company में काम किया है जिसने 'Phoenix Project' के विचारों को लागू करके developers को factory की machine parts की तरह treat किया, लेकिन अंततः उस company को अपनी प्रमुख subsidiaries बंद करनी पड़ीं और अधिकांश कर्मचारियों को निकालना पड़ा।