नोकरीतील मजेशीर व्यक्तीमत्वे

Submitted by सामो on 10 October, 2019 - 16:37

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

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

द्वितिय व्यक्तीमत्व - लाडावलेली कार्टी
हे डेव्हलपर्स ज्यांना नवनवीन कोड लिहीण्याची दांडगी हौस असते परंतु तोच् स्वतः लिहीलेला कोड पुढे राखण्याची (मेंटेन) तितकीच नावड असते.हे लोक एकामागे एक निर्मीतीक्षम प्रकल्प (क्रिएटीव्ह असाइनमेन्ट्स) स्वतःपुरते निर्माण करत जातात, शोधत जातात पण नंतर अपेक्षा ही की उरल्या सुरल्या प्रकल्पाची जबाबदारी अन्य कोणीतरी खांद्यावर घ्यावी. आरंभशूर!!! अशा लोकांचे सहकारी या लोकांवर खार खाऊनच असतात कारण यांचे प्रकल्प नंतर बिचारे सहकारीच राखत (मेंटेन) बसलेले असतात. काही काही क्लायंट रिलेशन मॅनेजर्स तर क्लायंटचा पूर्ण विश्वास संपादून बसलेले असतात आणि मग ना त्यांना काढता येते. उलट त्यांचे नखरे सर्वाना सहन करता बसावे लागते. अशाना कसे हॅण्डल करायचे ब्वॉ?

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

विषय: 
Group content visibility: 
Use group defaults

माझ्या अल्प मतीला हे सुचले.

Inhouse Developmet :-
Rotation of Job , breaking the programme in various modules and developing these modules through different programmers, Finally integrating it and testing. So that no single developer will know the entire progeamme and will not be able blackmail.

And last but not least
Outsourcing the project at bit higher cost and get source code .
Train inhouse teams to debug and maitain.
खूप छोटा प्रोग्राम असेल तर दोनचार प्रोग्रामरना त्या software चे जनरल ट्रेनिंग द्यावे.

साळुंके मस्त कल्पना आहे. अनेकांकडून मॉड्युल्स डेव्हलप करुन घ्यायची आणि शेवटी इन्टिग्रेट करायची. माझ्या पहील्या प्रॉजेक्टवरती हे केलेले होते पण त्यामध्ये इतके ब्रेनस्टॉर्मिंग होते, की एकमेकांची मॉड्युल्स व्यवस्थित कळून आली. प्रॉजेक्ट मॅनेजर एकच होता आणि मुख्य आम्ही अगदी जवळजवळ बसत असू.
शेवटचा पर्याय तुम्ही कॉट्स चा म्हणताय बहुतेक. ( कमर्शिअल ऑफमिळवुन),पण सोर्स कोड मिळवुन,

आम्ही क्ष कडून एक गुंतागुंतीचा Oracle , D2k programme घेतला आहे सोर्स कोड सह . नंतर आमच्या सिलेक्टेड लोकांना क्ष ने train केले. या team ला Oracle , D2k training sql plus ने दिले. आता संपूर्ण प्रोजेक्ट inhouse team maitain करते. नियम बदलले की change management invoke होते. ते यशस्वीरीत्या ते करतात. आता तर frontend देखील VB केले. मला वाटत job rotation असल्यावर blackmailing होणार नाही.

छानच की. धन्यवाद साळुंके.
_________________
बरं झालं संपादित केलत. कंपनी आदि नावेदेखील "क्ष्क्ष्क्ष्क्ष्क्ष" घातलीत तरी चालेल Happy