दोषारोप आयटी सिंड्रोम टाळण्यासाठी 4 टिपा

लेखक: Robert Simon
निर्मितीची तारीख: 22 जून 2021
अद्यतन तारीख: 24 जून 2024
Anonim
या हायस्कूलर्सना त्यांच्या शिक्षकांकडून मिरपूड फवारताना पहा
व्हिडिओ: या हायस्कूलर्सना त्यांच्या शिक्षकांकडून मिरपूड फवारताना पहा

सामग्री


टेकवे:

बर्‍याच आयटी विभागांना भेडसावणारा सर्वात मोठा प्रश्न तांत्रिक नाही - त्याचा वैयक्तिक.

बर्‍याच कॉर्पोरेट आयटी विभागांवर परिणाम करणारी सर्वात मोठी गैर-तांत्रिक समस्या म्हणजे व्यवस्थापन करणे देखील सोपे आहे. जेव्हा शेवटच्या वापरकर्त्यांशी वागण्याचा विचार केला जातो तेव्हा प्रत्येकाला समान पृष्ठावर असणे आवश्यक आहे आणि काय केले जाऊ शकते - आणि केव्हा माहित असणे आवश्यक आहे. आणि तेथे की आहे: वापरकर्त्यांच्या अपेक्षांचे व्यवस्थापन करणे. हे सोपे वाटत आहे, परंतु दररोज आधारावर अनुप्रयोगांचा सेट वापरणार्‍या लोकांशी व्यवहार करताना हे सहसा गोष्टी सुलभ करण्याच्या दिशेने बरेच पुढे जाऊ शकते.

आयटी विभाग जे या एका गोष्टीवर अयशस्वी ठरतात त्यांना खरोखर त्रास होऊ शकतो, कारण त्या विभागाकडे असंतोष वाढत आहे. हे प्रत्येकासाठी प्रकल्प अधिक कठीण करते. (समर्थनाबद्दल अधिक सल्ल्यासाठी, अधिक चांगले आयटी समर्थन प्रदान करण्यासाठी 10 टिपा पहा.)

अपेक्षा सेट करा

आपण थोड्या काळासाठी आयटीमध्ये काम केले असेल तर आपण कदाचित प्रकल्प, तिकिटे आणि रोल-आउटचा विचार करू शकता जिथे आयटी विभागाला एकतर प्रकल्प, तिकीट किंवा रोल-आउट उशीर झाल्याबद्दल दोषी ठरवले जाते, सुरुवातीला विनंती केलेली नाही किंवा फक्त साधा पुरेसा चांगला नाही. जेव्हा एंड-यूजर समुदायाच्या अपेक्षा (ईयूसी) वास्तविकतेच्या संकल्पनेशी जुळत नसतात - किंवा अगदी थोड्या प्रमाणात पडतात तेव्हा - त्यांची टीका एक अप्रिय विचलित होऊ शकते.


नवीन वापरकर्त्याच्या खात्यासारख्या सोप्या गोष्टी देखील विभागांमधील मतभेद निर्माण करतात - किंवा अगदी आंतर-कार्यालयीन संघर्ष. हे टाळण्याचा उत्तम मार्ग म्हणजे वास्तववादी अपेक्षा निर्माण करणे आणि प्रत्येक वेळी त्यांना भेटणे. याचा अर्थ आयटीला कर्मचार्‍यांना सांगणे आवश्यक आहे की प्रकल्प किती वेळ घेईल आणि जेव्हा ते संपेल तेव्हा काय अपेक्षा करावी. पाच-व्यक्ती कार्यालय असो वा बहुराष्ट्रीय समूह असो, जे माहिती तंत्रज्ञान विभाग वापरु शकतात त्यांना माहिती द्या की आयटी विभाग काय करू शकतो व काय करू शकत नाही. बहुतेक प्रकरणांमध्ये, आयटी जे साध्य करते त्यावरून अडचणी येत नाहीत, परंतु इतर कर्मचार्‍यांच्या मते ते करण्यास सक्षम असावे. अशा प्रकारचे डिस्कनेक्ट टाळू शकणारी विभाग "बॉल्ट आयटी" सिंड्रोम टाळण्यासाठी बराच पुढे जाईल.

अपेक्षा व्यवस्थापित करणे

एंड-यूजर समुदायाच्या अपेक्षांचे व्यवस्थापन करणे सुरू करण्याचा एक उत्तम मार्ग म्हणजे सर्व सेवांसाठी सेवा-स्तरीय करार (एसएलए) देण्याचे धोरण राबविणे होय. तांत्रिक क्षेत्रातील बरेच लोक एसएलएला बाह्य विक्रेत्यांशी संबद्ध करतात, परंतु तीच मानसिकता अंतर्गत ग्राहकांसाठी देखील वापरली जाऊ शकते - आणि ती असावी. हे शेवटच्या वापरकर्त्यांना सेवांची विनंती करताना काय अपेक्षा करावी याची एक चौकट प्रदान करेल आणि प्रत्येकजणाला समान पृष्ठावर नसल्यास किमान त्याच अध्यायात ठेवेल.


बर्‍याच अडचणी-तिकिट सॉफ्टवेअर पॅकेजेसमध्ये एसएलए स्थापित करण्यासाठी मॉड्यूल असतात. तुमच्या अंतर्गत ग्राहकांसाठी तुमच्याकडे आधीपासूनच एसएलएज झाल्या असतील तर अभिनंदन, तुमचा विभाग आधीच योग्य मार्गावर आहे.

संप्रेषण बूस्ट

आता आपण पाया घातला आहे, आपण संप्रेषण करणे आवश्यक आहे. दीर्घकालीन प्रकल्प आणि छोट्या प्रकल्पांसाठी, सर्व पक्षांना प्रगती आणि अडचणी या दोहोंच्या पळवाट ठेवणे अत्यावश्यक आहे. अपेक्षा हृदयाच्या ठोक्यातून एकतर जाऊ शकते आणि आपण प्रोजेक्टच्या प्रारंभाच्या वेळी आनंदी होऊ शकता, आपण ठरवलेली टाइमलाइन गमावल्यास, गोष्टी लवकर बिघडू शकतात. चुकीच्या नियमांपेक्षा वेगवान साध्य करण्यासाठी आयटीने कार्य केले आहे आणि मुदती सोडल्या आहेत अशा चांगल्या गोष्टींना बर्‍याच गोष्टी नष्ट करतील.

अरे, आणि जर आपणास मुदत चुकली असेल तर, आपण उशीरासाठी वेगवान आणि वाजवी कारणासंदर्भात स्पष्टपणे बोलू शकता. संवादाचे मार्ग उघडे ठेवणे, पंख गोंधळ घालण्यास टाळण्यास मदत करेल आणि प्रकल्प कसा येत आहे याबद्दल प्रत्येकाला चांगले वाटते हे सुनिश्चित करा. जर आपले अंतिम वापरकर्त्यांनी आपल्याकडे लक्ष न दिले तर ते गृहित धरू शकतात की सर्व काही कंटाळवाणा आहे. जर असे झाले नाही तर आपण त्यांच्या अपेक्षांची पूर्तता करण्यात अपयशी ठरल्यास मोठ्या प्रमाणात त्यांना अयशस्वी कराल.

कोणतीही दोष नाही, तणाव नाही - आपले जीवन नष्ट न करता जीवन-बदलणारे सॉफ्टवेअर तयार करण्यासाठी चरण चरण बाय चरण

जेव्हा कोणालाही सॉफ्टवेअर गुणवत्तेची काळजी नसते तेव्हा आपण आपली प्रोग्रामिंग कौशल्ये सुधारू शकत नाही.

प्रतिकूल परिस्थितीला तोंड देणे

एकदा आपण आपल्या अंतिम वापरकर्त्याच्या समुदायाशी सुसंवाद साधला आणि प्रत्येकजण एकत्र काम करत असेल तर आपण कदाचित कार्यस्थळावरील निर्वाण प्राप्त केले असा विचार करू शकता. खूप वेगाने नको. अचानक सर्व्हर किंवा (येथे संबंधित आऊटपुट घाला) एखाद्या प्रकारची आपत्तीजनक अपयशी ठरते आणि आपल्याकडे एक मिशन गंभीर यंत्रणा आहे. त्वरित आणि अतिरिक्त समस्यांशिवाय आउटेजचे निराकरण करण्यात मदत करण्यासाठी विचलित कमी करण्यासाठी आपल्या शेवटच्या वापरकर्त्यांच्या अपेक्षा व्यवस्थापित करण्याची ही आणखी एक संधी आहे.

आपण हे करण्यात अयशस्वी झाल्यास, आपण आउटेज अहवाल आणि अपरिहार्य "हे किती काळ खाली असेल?" प्रश्न. हे केवळ निराशेच्या ज्वालांना चमकविण्यात यशस्वी होईल.

काय करावे हेसः जेव्हा एखादे आऊटेज येते तेव्हा आपल्याकडे शब्द बाहेर काढण्याची एकापेक्षा जास्त पद्धती असणे आवश्यक आहे. ते देखील सुसंगत आणि प्रामाणिक असले पाहिजे. तर, आपण असे म्हटले की आउटेजचे निराकरण दोन तासात केले जाईल, तर आपले अंतिम वापरकर्ते त्या वेळेत पूर्ण होण्याची अपेक्षा करतील. याचा अर्थ असा की लोकांना आनंदी करण्यासाठी आपण आशावादी अंदाज बांधणे टाळावे. शिवाय, जर समस्या आता आपल्या अंतिम वापरकर्त्यांना त्रास देत असेल तर त्यास प्राधान्य देण्याला प्राधान्य द्या. जेव्हा त्या आउटेजचे वेळेवर निराकरण केले जाते तेव्हा आपण आणि आपला कार्यसंघ आपल्या नियमितपणे नियोजित प्रोग्रामिंगमध्ये परत येऊ शकता.

गुळगुळीत प्रकल्प व्यवस्थापनाची गुरुकिल्ली

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