"हिडन आईटी ..." को निषिद्ध या नियंत्रित करना? किसे लिखना चाहिए और तदर्थ सॉफ्टवेयर अनुप्रयोगों को बनाए रखना चाहिए?


61

बड़ी कंपनियों में आमतौर पर यह समस्या होती है, कि कर्मचारियों और पैसे की कमी के कारण सभी कार्यक्रमों को कर्मचारियों को लिखना (समय बचाने के लिए और प्रक्रियाओं को अनुकूलित करने के लिए) संभव नहीं है।

फिर छिपे हुए प्रोग्राम कुछ लोगों द्वारा (कम से कम कुछ) कोडिंग अनुभव (या सस्ते छात्रों / प्रशिक्षुओं ...) द्वारा बनाए जाएंगे। कुछ परिस्थितियों में ये एप्लिकेशन महत्व में बढ़ जाएंगे और एक उपयोगकर्ता से पूरे विभाग में फैल जाएंगे।

फिर महत्वपूर्ण बिंदु है: कौन एप्लिकेशन को बनाए रखेगा, नई सुविधाएँ जोड़ें, ...? और यह ऐप क्रिटिकल है। इसकी जरूरत है। लेकिन इंटर्न ने कंपनी छोड़ दी है। कोई नहीं जानता कि यह कैसे काम करता है। आपके पास केवल स्रोतों का एक गुच्छा और कुछ प्रकार के प्रलेखन हैं।

क्या यह आईटी विभाग के बाहर (एक्सेल मैक्रोज़ जैसे मामूली सामान के अपवाद के साथ) तदर्थ अनुप्रयोग विकास को रोकने और नियंत्रित करने या मना करने का कोई मतलब है?


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

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

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

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

16
'नियमित लोगों' के साथ अपने व्यापार प्रक्रियाओं को स्वचालित करने में क्या गलत है? जब तक यह वास्तव में उन्हें समय बचा रहा है, जो कि शायद यह है, मैं इसे एक अच्छी बात मानता हूं । यदि कोई विशेष 'गड़बड़' 'एड-हॉक' ऑटोमेशन टूल बहुत हद तक निर्भर हो जाता है, तो यह डेवलपर्स के लिए एक रखरखाव योग्य संस्करण लिखने के लायक हो सकता है। सबसे खराब स्थिति यह है कि उन्हें चीजों को मैन्युअल रूप से फिर से शुरू करना पड़ता है जब आवश्यकताएं बदल जाती हैं, लेकिन कम से कम उन्होंने पहले ही बहुत समय बचा लिया!
फिलिप

जवाबों:


79

मैं एक ऐसी कंपनी के लिए काम करता था, जहां हर ऐप जो हमने उन्हें दिया था, उससे यह सवाल उठता है: क्या हम इस डेटा को एक्सेल में निर्यात कर सकते हैं?

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

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

यह एक अनुचित आरोप नहीं था और उन्होंने हमें अपने एक्सेल ऐप्स का समर्थन करने के लिए कभी नहीं कहा, इसलिए किसी ने भी नहीं सोचा था कि यह एक समस्या थी। जब इन एक्सेल डेवलपर्स ने छोड़ दिया, तो वे हमेशा इसे लेने के लिए किसी और को खोजने में कामयाब रहे।

आप तर्क दे सकते हैं कि इसका मतलब है कि हम गलत तरीके से प्राथमिकता दे रहे थे, यह महत्वपूर्ण काम नहीं हो रहा था। लेकिन मैं तर्क दूंगा कि इसने अधिक कठिन काम करने के लिए अधिक-भुगतान वाले डेवलपर्स को मुक्त कर दिया। इससे क्या नुकसान हो सकता है?

अब मैं ऐसे सॉफ्टवेयर को मना करता हूँ जो विकास टीम के बाहर लिखे जा रहे डेटाबेस को अपडेट करता है। और मैं विकास टीम के बाहर लिखे गए ऐप्स का समर्थन करने से इंकार कर दूंगा। लेकिन मैं सभी सॉफ़्टवेयर को व्यवसाय द्वारा स्वयं लिखे जाने से मना करने की कोशिश नहीं करूंगा, और मैं खुशी-खुशी डेटा-निर्यात लिखूंगा ताकि उन्हें ऐसा करने के लिए सशक्त किया जा सके (जब तक कि वे डेटा को उजागर न करें जो उन्हें नहीं देखना चाहिए, जाहिर है )।


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

8
+1 अच्छी तरह से कहा गया। हमारे सॉफ्टवेयर के उपयोगकर्ताओं को सशक्त बनाना हमारी सर्वोच्च प्राथमिकताओं में से एक होना चाहिए।
स्टीवन एवर्स

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

@ स्टीफन: हाँ। और यही कारण है कि उपयोगकर्ताओं को उत्पादन डेटा पर उन्हें देने के बजाय अपनी चीज़ करने के लिए सशक्त बनाना बेहतर है। चाहे वह डेटा की केवल पढ़ने वाली, दैनिक प्रतिलिपि हो, या एक्सेल निर्यात हो, या डीएसएल हो, आपकी सुरक्षा / एसएलए आवश्यकताओं और उनकी डेटा आवश्यकताओं पर बहुत कुछ निर्भर करता है।
पीडीआर

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

50

मुझे लगता है कि लोग यहां सामान्य बिंदु को याद कर रहे हैं:

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

ये ऐप पहली बार क्यों बनाए जा रहे हैं?

मैंने जितने भी मामले देखे हैं, उनमें एक सामान्य कारण है:

व्यावसायिक समूह अपनी जरूरतों को प्राथमिकता देते हैं, उन्हीं आवश्यकताओं की तुलना में पूरी कंपनी के संदर्भ में प्राथमिकता दी जाती है

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

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

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

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

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


2
+1 स्थान पर। मैं यहाँ किसी को यह नहीं बताता कि इन प्रथाओं के साथ एक बहुत बड़ी समस्या है जो मैंने कई कंपनियों में देखी है। अल्पावधि में एक या दो लोगों के लिए क्या काम करता है, तेजी से 30 वर्षों में विकसित होने वाले 30 छोटे ऐप्स के एक विशाल भग्न सॉफ्टवेयर मेस में बदल जाता है, कुछ आधे काम और उन्हें बनाए रखने की लागत दस गुना है अगर आईटी विभाग ने लोगों को काम पर रखा था उन सभी को करो ताकि वे संगत थे और आईटी का एक केंद्रीय स्वामित्व आधार था।
जिमी हॉफ

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

+1 मेरे विचार बिल्कुल, लेकिन ज्यादा बेहतर शब्द।
फिल

16

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

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

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

क्या यह मूर्खतापूर्ण नहीं है?

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

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


2
"मेरे अनुभव में, वे मामले बेहद अक्सर होते हैं।" - तो आपकी कंपनी नॉन प्रोग्रामर जॉब्स में और फिर प्रोग्रामिंग प्रोग्राम्स में खराब प्रोग्रामर को हायर करने का अद्भुत काम करती है? मुझे लगता है कि यह अधिक संभावना है कि कोई व्यक्ति जो प्रथाओं और अंतर्निहित प्रणालियों को नहीं समझता है, उन्हें लगता है कि वे बेहतर सॉफ़्टवेयर लिख रहे हैं। बस मेरे 2 सेंट।
ओमिनस

2
@Ominus: यदि वकील के लिए कोई पद रिक्त है, तो कंपनी वकील की खोज करेगी; यदि उम्मीदवार एक कुशल डेवलपर भी है, तो साक्षात्कारकर्ता को भी यह पता नहीं चल सकता है। तो नहीं, कंपनी "गैर प्रोग्रामर नौकरियों में महान प्रोग्रामर को काम पर रखने" नहीं है: वे नौकरी के लिए एक योग्य व्यक्ति को काम पर रख रहे हैं, विशेष रूप से जागरूक होने के बिना कि यह व्यक्ति एक महान डेवलपर भी है।
आर्सेनी मूरज़ेंको

@Ominus: ध्यान दें कि जब आप के रूप में काम पर रखा जाता है, उदाहरण के लिए, एक क्लर्क, आप साक्षात्कार के दौरान नहीं बताते हैं कि आप एक महान प्रोग्रामर हैं। बिना तकनीकी पृष्ठभूमि वाले बहुत से लोगों के लिए, प्रोग्रामर = हैकर = यार जो अपना समय कंपनी पीसी = बहुत सारी समस्याओं को क्रैक करने में बिताएगा।
आर्सेनी मूरज़ेंको

1
@Ominus - IT लोगों को एक अक्षम आईटी विभाग रखने के लिए कंपनी को बुरा नहीं होना चाहिए। खराब आईटी विभाग हो सकते हैं क्योंकि आईटी को किसी व्यक्ति द्वारा 'ओवरहेड' माना जाता है और जहां तक ​​संभव हो कम हो जाता है। यह उन्हें उनकी वास्तविक क्षमताओं से परे खींचता है और वे एक संगठन के रूप में अक्षम हो जाते हैं - लगातार कार्यों के बीच स्विच करना, निरंतर आतंक मोड, किसी के साथ संवाद नहीं करना, वादों पर पहुंचना नहीं।
माइकल कोहेन

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

6

आप इसे पूरी तरह से नियंत्रित नहीं कर सकते ...

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

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

लेकिन आप एक कोड-अनुकूल वातावरण बना सकते हैं

कई कंपनियां, अक्सर बहुत बड़ी, ऐसा करती हैं। Google का एक अच्छा उदाहरण है, जिसके लिए प्रतिनिधियों ने कहा है कि वे पूरी कंपनी के लिए एक ही SCM का उपयोग करते हैं, हर किसी के लिए निगरानी रखने और दूसरों के कोड को देखने में सक्षम होने के लिए।

मैं आपको निम्नलिखित करने की सलाह दूंगा:

  • अपने SCM के कुछ क्षेत्रों में सार्वजनिक पहुँच दें,
  • निरंतर एकीकरण और निरंतर निरीक्षण सर्वर तक पहुंच का अनुरोध करना आसान बनाते हैं,
  • लोगों को अपने उपकरणों के निर्माण के लिए प्रोत्साहित करें।

समस्या तब प्रौद्योगिकियों का प्रसार है। जाहिर है, कुछ लोग एक्स ओवर वाई का उपयोग करना पसंद करेंगे और ऐसा तब होता है जब उन्हें अपने आर्किटेक्चर में फिट होना कठिन हो जाता है। हालाँकि, यह असंभव नहीं है, और अगर वे चाहते हैं कि उनका कोड बना रहे तो उन्हें अतिरिक्त मील मिल जाएगा अगर, ठीक है, तो यह सिर्फ एक मील है।

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

टीमों को कुछ स्वतंत्रता दें

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

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

आईटी से बात करें, उन्हें शामिल करें

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

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


3

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

आप एक्सेल एकीकरण (या कम से कम आयात / निर्यात) की भारी इच्छा देखेंगे क्योंकि सभी व्यावसायिक स्कूल अब एक्सेल सिखाते हैं और यह कई व्यावसायिक पाठ्यक्रमों में उपयोग किया जाने वाला एक प्रमुख उपकरण है।


3

सरबेंस-ऑक्सले और इसी तरह के कानून, अमेरिका के बाहर, गोपनीयता कानूनों और आंतरिक रूप से स्वयं की गोपनीयता और सुरक्षा प्रक्रिया और नीतियों के साथ संयुक्त "हथौड़ा" है जो अक्सर और छाया-आईटी घटना पर क्लैंप करने के लिए उपयोग किया जाता है।

जैसे ही ग्राहक या कर्मचारी व्यक्तिगत रूप से पहचान योग्य जानकारी (या कोई भी डेटा जिसे आप बाहर नहीं निकालना चाहते हैं) इन स्प्रेडशीट में घूमना शुरू कर देते हैं, आपके पास एक दुर्घटना होने की प्रतीक्षा है।

इसी तरह, जैसे ही इन स्कंकवर्कर्स में से एक आईटी प्रोजेक्ट उस एक्सेल स्प्रेडशीट को लेता है और इसे एक बाहरी रूप से सामने आने वाले वेब ऐप के हैक होने के पीछे के डेटा के रूप में उपयोग करता है, आपके पास आपका CIO और CEO का तूफान होगा, जिसने भी इस ऐप को बनाया होगा। एक सप्ताहांत परिणामों की व्याख्या करने के लिए आ रहा है।

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

यह सब कुछ उन लोगों के लिए मज़ेदार अनुपालन और ऑडिट प्रक्रियाओं को जन्म देता है जो किसी के लिए मज़ेदार नहीं हैं, लेकिन एक उद्यम वातावरण में आईटी के जीवन के कठिन तथ्य हैं।

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


2

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

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

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

जबकि हमें अपने आंतरिक ग्राहकों की जरूरतों को पूरा करने के लिए हर वह चीज करनी चाहिए जो ऐसे समय की जरूरत है जो हम आसानी से नहीं कर सकते। ऐसा होने पर वे अपनी समस्या का समाधान करने के लिए कहीं और देखेंगे।

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

आईटी विभाग संघनित करता है और उनका समर्थन करता है या नहीं और वे कर सकते हैं या नहीं, समर्थन, OLA और SLA प्रतिबद्धताओं के संदर्भ में सीधा प्रभाव पड़ता है, जो किसी भी IT विभाग द्वारा मापा जाता है।


1

वे हमारी कंपनी में इन कारणों से मना कर रहे हैं:

  • पासवर्ड ने एक्सेल मैक्रोज़ की रक्षा की, जहाँ पासवर्ड जानने वाला एकमात्र व्यक्ति कंपनी छोड़ चुका है,
  • अनुभवहीन लोगों द्वारा लिखे गए गलत रिपोर्ट के लिए जिम्मेदार होने के कारण इसे 'आईटी' कहा जाता है।
  • एक रिपोर्ट को संशोधित करने के लिए कहा जा रहा है जिसे हमने पहले कभी नहीं देखा या सुना है।

मैं समझता हूं कि आईटी व्यस्त होने पर यह उपयोगकर्ताओं के लिए निराशाजनक हो सकता है, और वे 'बस स्वयं ऐसा करने' के लिए इच्छुक हो सकते हैं। लेकिन आईटी को उन चीजों के लिए जिम्मेदार नहीं ठहराया जा सकता है जो यह नहीं जानता कि यहां तक ​​कि मौजूद नहीं है, और यदि कोई भी समग्र आईटी के लिए जिम्मेदार नहीं है, तो आगे बड़ी समस्याएं हैं।


5
जो मैं समझता हूं, वह व्यवसाय का समर्थन करने के लिए है; लोगों को उनके काम करने में मदद करने के लिए आईटी विभाग रखने के पीछे उद्देश्य नहीं है? यदि आप उन्हें उन उपकरणों को बनाने से मना कर रहे हैं जिनकी उन्हें आवश्यकता है, तो वे अपना काम कैसे कर सकते हैं? "यह गलत रिपोर्ट के लिए हमें ज़िम्मेदार मत ठहराओ - बिक्री में किसी ने जो बनाया है, उसे गलत नहीं है।"
फिल

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

1
मुझे यह जोड़ना चाहिए कि इन जरूरतों को पूरा करने के लिए आईटी विभाग के विस्तार के लिए उपाय किए गए हैं।
पॉल टी डेविस

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

1

अगर यहां कोई समस्या है तो यह आईटी विभाग के पास है।

विशेषज्ञ व्यवसाय / डोमेन ज्ञान के साथ लोगों को अनुमति देने और वहां स्वयं के डेटा को संसाधित करने की अनुमति देने में कुछ भी गलत नहीं है।

आईटी विभाग को इसे स्वीकार करने और इसका समर्थन करने की आवश्यकता है। पुन: प्रयोज्य इंटरफेस प्रदान करके, EXCEL या एक्सेस DBs जैसे सुविधाजनक प्रारूपों में डेटा पहुंचाना और लचीला टूलिंग प्रदान करना (COGNOS, जैस्पर रिपोर्ट आदि)।

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


1

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


1

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

इसका मतलब यह नहीं है कि विभाग द्वारा वित्त पोषित विकास को मुक्त शासन दिया जाना चाहिए। कुछ आवश्यकताओं को लागू किया जाना चाहिए, जैसे कि निम्नलिखित:

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

सक्षम करने के कई लाभ हैं।

  • आईटी अपने ग्राहकों की जरूरतों को पूरा करने के बारे में अधिक सीखता है। इससे बेहतर प्राथमिकता और साझाकरण होता है।
  • IT को समस्या के बजाय मित्र और लाभ के रूप में देखा जाता है।
  • वास्तविक व्यावसायिक आवश्यकताओं को पूरा किया जाता है।
  • व्यावसायिक डेटा को पर्याप्त रूप से संरक्षित किया जाता है क्योंकि आईटी इसमें शामिल था, जो पीछे के दरवाजे की आवश्यकता को रोकता है।
  • टर्नओवर के कारण डिप्रेशन टूल्स नहीं खोते हैं और जरूरत पड़ने पर इसे आसानी से आईटी में स्थानांतरित किया जा सकता है।

0

मैं मदद नहीं कर सका, लेकिन आप के साथ की पहचान। आपके द्वारा बताई गई समस्या संस्कृतियों, भाषाओं और महाद्वीपों को फैलाती हुई एक सार्वभौमिक प्रतीत होती है।

चीजें जो आप कर सकते हैं:

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

  • केवल आईटी के माध्यम से अनुबंधित होने के लिए आईटी से संबंधित करियर के सभी इंटर्न बनाएं ।

  • OS नीति के माध्यम से प्रतिबंधित करना सॉफ्टवेयर की स्थापना । हर सॉफ्टवेयर इंस्टॉलेशन को IT हेल्प डेस्क के माध्यम से देखा जाना चाहिए, जिसमें पर्यवेक्षक की स्वीकृति आवश्यक है। इस तरह से एमएस एक्सेस, पीएचपी, विजुअल बेसिक, इत्यादि जैसी किसी चीज की स्थापना से किसी का ध्यान नहीं जाएगा।

  • एक नीति जारी करें जिसमें कहा गया है कि समर्थन देने के लिए प्रत्येक नया विकास, जावा, सी #, सी ++ , या किसी भी अन्य भाषा में लिखा जाना चाहिए, जिसमें एक सीखने की अवस्था की आवश्यकता होगी । इस तरह आप "प्रोग्रामिंग का एक निश्चित ज्ञान" वाले लोगों के ब्रह्मांड को कम करने के लिए चारों ओर गड़बड़ करते हैं।

  • आवश्यकताओं लोग, "एक्सेल समाधान" कंपनी के आसपास पर एक नज़र रखना चाहिए क्योंकि एक निगम के आईटी जरूरतों का प्रतिबिंबित है।

  • एक को लागू डेटा गोदाम और एक अंतिम-उपयोगकर्ता के अनुकूल डाटा खनन और रिपोर्टिंग उपकरण । इस तरह से आप कस्टम मेड, इंटर्न लिखित छोटे ऐप की आवश्यकता कम कर देते हैं।

लेकिन: एक बड़ी चीज जो आप नहीं करते हैं वह एक बिग चीफ के एक फोन कॉल को तेज करेगा , आईटी मैनेजर को कॉल करेगा और आपसे उस ऐप का समर्थन करने के लिए कहेगा जो एक इंटर्न ने बनाया था।


बिंदु 1 के बारे में, अकेले ऐप्स को डीबी के बिना भी डेटा को संसाधित करने में एक बड़ी मदद मिल सकती है, बिंदु 4 के बारे में एक कठिन सीखने की अवस्था किसी को सामान लिखने से कभी नहीं रोकती है जब वे इसके आधार पर होते हैं, जिसके परिणाम भी बदतर होंगे समर्थन, या यहाँ तक कि soemone कह "हुंह मैं इस अनुप्रयोग समर्थित की जरूरत नहीं है"
सनकी शाफ़्ट

OS प्रतिबंध के बारे में प्वाइंट 3 काम नहीं करता है। बहुत सी कंपनियां पहले से ही "लाओ-अपना-अपना लैपटॉप" मॉडल पर चली गईं।
सुल्तान

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

0

मेरी कंपनी को इस तरह की स्थितियों में मदद करने का एक तरीका भाषा अज्ञेय नहीं होना है। यदि आप एक ऐप / प्रोग्राम चाहते हैं, तो उसे हमारी पसंद की भाषा (जावा) में होना चाहिए। हम कुछ JQuery या js के लिए नियमों को थोड़ा बढ़ा सकते हैं, लेकिन इसके लिए एक अच्छी तरह से तैयार किया गया एप्लिकेशन होना चाहिए, जिसने एक महत्वपूर्ण आवश्यकता को पूरा किया हो। मत आओ और कहो "मुझे यह PHP ऐप मिला है जो मुझे आपके लिए होस्ट करने की आवश्यकता है" क्योंकि आपको शायद सिर्फ एक पॉलिसी शीट सौंपी जाएगी।

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


0

गीक्स का अहंकार!

कई मामलों में व्यावसायिक उपयोगकर्ता उन चीजों को करने के लिए उपकरणों का उपयोग कर सकते हैं जो आईटी लोग नहीं समझते हैं। ऐसा इसलिए नहीं है क्योंकि वे स्वाभाविक रूप से बुरे हैं, बल्कि इसलिए कि वे व्यवसाय को जानते हैं, यह कैसे काम करता है और वे इसे कैसे काम करना पसंद करेंगे।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.