पुस्तक “बुद्धिजीवियों का प्रबंधन कैसे करें। मैं, नर्ड और गीक्स "

परियोजना प्रबंधकों को समर्पित (और जो लोग मालिक बनने का सपना देखते हैं)।

टन का कोड लिखना मुश्किल है, और लोगों को प्रबंधित करना और भी मुश्किल है! तो आपको बस इस पुस्तक की आवश्यकता है कि दोनों कैसे करें।

क्या शांत कहानियों और गंभीर पाठों को संयोजित करना संभव है? माइकल लोप (जिसे रैंड्स के रूप में संकीर्ण क्षेत्रों में भी जाना जाता है) सफल रहे। अविश्वसनीय रूप से उपयोगी (यद्यपि काल्पनिक) अनुभव वाले काल्पनिक लोगों के बारे में काल्पनिक कहानियाँ आपकी प्रतीक्षा करती हैं। इस तरह से रैंडी ने अपने विविध, कभी-कभी अजीब अनुभव बड़े आईटी निगमों में काम के वर्षों में प्राप्त किए हैं: Apple, Pinterest, Palantir, Netscape, Symantec, आदि।

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

यह पुस्तक प्रबंधन या नेतृत्व पर किसी भी पांडुलिपि की तरह नहीं है। माइकल लोप्प कुछ भी नहीं छुपाता है, वह बस सब कुछ बताता है जैसा वह है (शायद सभी कहानियों को सार्वजनिक नहीं किया जाना चाहिए: आर)। लेकिन केवल इस तरह से आप समझ पाएंगे कि आप ऐसे बॉस के साथ कैसे रह सकते हैं, geeks और nerds को कैसे प्रबंधित कर सकते हैं और "उस कमबख्त परियोजना" को कैसे सुखद अंत तक ला सकते हैं!

अंश। इंजीनियरिंग की मानसिकता

विषय पर विचार: क्या आपको कोड लिखना जारी रखने की आवश्यकता है

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

लचीले बने रहें!

यह विचार करने के लिए कि आप पहले से ही सब कुछ जानते हैं एक बहुत बुरा विचार है। ऐसी स्थिति में जहां एकमात्र अपरिवर्तनीय तथ्य यह है कि दुनिया में लगातार परिवर्तन हो रहे हैं, लचीलापन ही सही स्थिति बन जाती है।

विरोधाभासी रूप से, सूची में दूसरा आइटम आश्चर्यजनक रूप से अनम्य है। हालांकि, यह आइटम मेरा व्यक्तिगत पसंदीदा है, क्योंकि मेरा मानना ​​है कि यह प्रबंधकीय विकास की नींव बनाने में मदद करता है। यह पैराग्राफ पढ़ता है:

कोड लिखना बंद करो!

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

जब मैं देखता हूं कि कोड लिखने से पहले एक नव-मंथन नेता "गिर" जाता है, तो मैं उससे कहता हूं: "हम जानते हैं कि आप कोड लिख सकते हैं। सवाल अलग है: क्या आप जानते हैं कि कैसे नेतृत्व करना है? अब आप अकेले अपने लिए जिम्मेदार नहीं हैं, आप पूरी टीम के लिए जिम्मेदार हैं; और मुझे यकीन है कि आप अपनी टीम को अपने दम पर समस्याओं को हल करने के लिए प्राप्त कर सकते हैं, बिना खुद को कोड लिखे। अपने काम के लिए कैसे अपने आप को समझाना है। मैं चाहता हूं कि आप केवल एक ही न हों, मैं आपके जैसे कई लोगों को चाहता हूं। ”

अच्छी सलाह, सही? स्केल। प्रबंधन। जिम्मेदारी। इस तरह के आम buzzwords। यह एक दया है कि सलाह गलत है।

गलत?

हाँ। सलाह गलत है! ऐसा नहीं है कि यह पूरी तरह से गलत है, लेकिन इतना गलत है कि मुझे कुछ पूर्व सहयोगियों को फोन करना पड़ा और माफी मांगनी पड़ी: “मेरा वह पसंदीदा कथन याद रखें जो आपको कोड लिखना बंद करना चाहिए? यह गलत है! हां ... फिर से प्रोग्रामिंग शुरू करें। शुरुआत पायथन और रूबी से करें। हां, मैं गंभीर हूं! आपका करियर इस पर निर्भर करता है! ”

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

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

पिछले 20 वर्षों से डेवलपर्स क्या कर रहे हैं? इस समय के दौरान, हमने बकवास कोड का एक गुच्छा लिखा। कोड का सागर! हमने इतना कोड लिखा था कि हमने तय किया: सब कुछ सरल करना और ओपन सोर्स कोड पर स्विच करना अच्छा होगा।

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

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

तर्क करने की यह पंक्ति निराशाजनक लगती है, लेकिन विचार यह है कि हम सभी एकीकरण मशीनों का एक समूह हैं जो एक ही चीज़ के थोड़ा अलग संस्करण बनाने के लिए मौजूदा चीजों के विभिन्न टुकड़ों को एक साथ जोड़ने के लिए डक्ट टेप का उपयोग करते हैं। यह शीर्ष प्रबंधन के लिए विचार की एक क्लासिक पंक्ति है जो आउटसोर्सिंग से प्यार करता है। “यह किसी के द्वारा भी किया जा सकता है जो Google का उपयोग करना जानता है और जिसके पास चिपकने वाला टेप है! तो फिर हम अपनी वेंडिंग मशीनों से एक टन पैसा क्यों दे रहे हैं? ”

हम इस प्रकार के अधिकारियों को वास्तव में बड़ा पैसा देते हैं, और वे इस तरह की बकवास सोचते हैं। एक बार फिर: मेरा मुख्य विचार यह है कि हमारे ग्रह पर कई शानदार और बहुत मेहनती डेवलपर्स हैं; वे वास्तव में शानदार और उत्साही हैं, हालांकि उन्होंने मान्यता प्राप्त विश्वविद्यालयों में बैठकर एक मिनट भी नहीं बिताया है। अरे हाँ, अब उनमें से अधिक हैं!

मेरा सुझाव नहीं है कि आप अपनी जगह के बारे में चिंता करना शुरू कर दें क्योंकि कुछ शानदार कॉमरेड उसके बारे में सोचते हैं। मेरा सुझाव है कि आप उसके बारे में चिंता करना शुरू कर दें, क्योंकि सॉफ्टवेयर विकास का विकास आपसे अधिक तेजी से हो सकता है। आप दस साल से काम कर रहे हैं, जिनमें से पांच साल एक नेता के रूप में, और आप सोचते हैं: "मुझे पहले से ही पता है कि सॉफ्टवेयर कैसे विकसित होता है।" हाँ आप जानते हैं बाय ...

कोड लिखना बंद करें, लेकिन ...

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

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

आपको आपत्ति है। मैं समझ गया। आइए सुनते हैं।

"रैंडी, मैं निर्देशक की कुर्सी पर जा रहा हूं!" अगर मैं कोड लिखना जारी रखता हूं, तो कोई भी विश्वास नहीं करेगा कि मैं विकसित होने में सक्षम हूं। ”

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

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

“उह, रैंडी! लेकिन किसी को एक मध्यस्थ होना चाहिए! किसी को बड़ी तस्वीर देखनी चाहिए। अगर मैं कोड लिखता हूं, तो मैं संभावना की दृष्टि खो दूंगा। "

आपको अभी भी मध्यस्थ बनना है, आपको अभी भी निर्णय प्रसारित करना है, और आपको अभी भी हर सोमवार सुबह चार बार इमारत में घूमना पड़ता है, अपने एक इंजीनियर के साथ 30 मिनट के लिए अपने साप्ताहिक छेड़छाड़ को सुनने के लिए: “हम सभी बर्बाद हैं ! " लेकिन इन सबके अलावा, आपको इंजीनियरिंग के तरीके को अपने अंदर रखना होगा, और इसके लिए आपको पूर्णकालिक प्रोग्रामर होने की आवश्यकता नहीं है।

एक इंजीनियरिंग मानसिकता को बनाए रखने पर मेरी सलाह:

1. विकास के माहौल का उपयोग करें। इसका मतलब है कि आपको अपनी टीम के उपकरणों से परिचित होना चाहिए, जिसमें एक कोड बिल्डिंग सिस्टम, संस्करण नियंत्रण और एक प्रोग्रामिंग भाषा शामिल है। इसके परिणामस्वरूप, आप उस भाषा में धाराप्रवाह होंगे जो आपकी टीम उस समय उपयोग करती है जब वह उत्पाद विकास के बारे में बात करती है। यह आपको अपने पसंदीदा पाठ संपादक का उपयोग करना जारी रखने की अनुमति देगा जो महान काम करता है।
2. आपको एक विस्तृत वास्तु चित्र बनाने में सक्षम होना चाहिए जो किसी भी समय और किसी भी समय आपके उत्पाद का वर्णन करता है। अब मेरा मतलब एक सरलीकृत संस्करण नहीं है जिसमें तीन सेल और दो तीर हैं। आपको विस्तृत उत्पाद आरेख पता होना चाहिए। सबसे कठिन। सिर्फ कोई सुंदर स्कीम नहीं, बल्कि ऐसी स्कीम जो समझाना मुश्किल हो। यह उत्पाद की पूरी समझ के लिए उपयुक्त कार्ड होना चाहिए। यह लगातार बदल रहा है, और आपको हमेशा पता होना चाहिए कि ये या अन्य परिवर्तन क्यों हुए हैं।
3. कार्यों में से एक के कार्यान्वयन पर ले लो। जब मैं इसे लिखता हूं तो मैं सचमुच कांप जाता हूं, क्योंकि यह बिंदु कई छिपे हुए खतरों से भरा होता है, लेकिन मुझे यकीन नहीं है कि आप पैराग्राफ 1 और पैराग्राफ 2 को कम से कम एक फ़ंक्शन के बिना पूरा कर सकते हैं । किसी एक फ़ंक्शन के स्वतंत्र कार्यान्वयन के लिए धन्यवाद, आप न केवल सक्रिय रूप से विकास की प्रक्रिया में भाग लेंगे, यह आपको समय-समय पर "सब कुछ के लिए जिम्मेदार प्रबंधक" की भूमिका से "एक कार्य के कार्यान्वयन के लिए जिम्मेदार व्यक्ति" की भूमिका में स्विच करने की अनुमति देगा। यह मामूली और स्पष्ट स्थिति आपको छोटे निर्णयों के महत्व को याद दिलाएगी।
4. मैं अभी भी कांप रहा हूं। ऐसा लगता है कि कोई पहले से ही मुझ पर चिल्ला रहा है: "जिस नेता ने समारोह के कार्यान्वयन को संभाला है!" (और मैं उससे सहमत हूँ!) हाँ, आप अभी भी एक नेता बने हुए हैं, जिसका अर्थ है कि यह कुछ छोटा कार्य होना चाहिए, ठीक है? हां, आपको अभी भी बहुत कुछ करना है। यदि आप किसी भी तरह से फ़ंक्शन को लागू नहीं कर सकते हैं, तो मेरे पास आपके लिए एक अतिरिक्त टिप है: कुछ बग से निपटें। इस मामले में, आप सृजन की खुशियों को महसूस नहीं करेंगे, लेकिन आपको इस बात की समझ होगी कि उत्पाद कैसे बनाया जाता है, जिसका अर्थ है कि आप कभी भी काम से बाहर नहीं रहेंगे।
5. इकाई परीक्षण लिखें। मैं अभी भी उत्पादन चक्र के बाद के चरणों में ऐसा करता हूं, जब लोग पागल होने लगते हैं। इसे अपने उत्पाद के लिए स्वास्थ्य जांच सूची के रूप में सोचें। अक्सर करते हैं।

एक बार फिर आपत्ति?

“रैंड, अगर मैं कोड लिखता हूं, तो मैं अपनी टीम को भ्रमित करूंगा। वे नहीं जान पाएंगे कि मैं कौन हूं, नेता या डेवलपर। ”

सब ठीक है।

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

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

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

विकास करना बंद न करें

मेरी एक बोरलैंड सहकर्मी ने एक बार मौखिक रूप से मुझे "कोडर" कहने के लिए हमला किया था।

"रैंड, एनकोडर एक बुद्धिहीन मशीन है! बंदर! एक एनकोडर बेकार कोड की बोरिंग लाइनों के अलावा कुछ नहीं करता है। मैं कोडर नहीं हूं, मैं एक सॉफ्टवेयर डेवलपर हूं

वह सही थी, वह नए नेताओं से मेरी शुरुआती सलाह से नफरत करेगी: "कोड लिखना बंद करो!" इसलिए नहीं कि इसके द्वारा मुझे लगता है कि वे कोडर हैं, बल्कि इसलिए भी कि मैं लगातार सुझाव देता हूं कि वे अपने काम के सबसे महत्वपूर्ण हिस्सों में से एक को अनदेखा करना शुरू कर दें - सॉफ्टवेयर विकास।

इसलिए, मैंने अपनी सलाह को अंतिम रूप दिया। यदि आप एक अच्छे नेता बनना चाहते हैं, तो आप कोड लिखना बंद कर सकते हैं, लेकिन ...

लचीले बनो। याद रखें कि एक इंजीनियर होने का क्या मतलब है, और सॉफ्टवेयर विकसित करना बंद न करें।

लेखक के बारे में

माइकल लोप एक सॉफ्टवेयर डेवलपमेंट दिग्गज हैं, जिन्होंने अभी भी सिलिकॉन वैली नहीं छोड़ी है। पिछले 20 वर्षों में, माइकल Apple, Netscape, Symantec, Borland, Palantir, Pinterest सहित कई नवीन कंपनियों में काम करने में सफल रहे, साथ ही साथ एक स्टार्टअप में भाग लेते हैं जो धीरे-धीरे गुमनामी में बह गया।

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

माइकल कैलिफोर्निया के रेडवुड में अपने परिवार के साथ रहते हैं। उन्हें हमेशा एक पहाड़ी बाइक की सवारी करने, हॉकी खेलने और रेड वाइन पीने का समय मिलता है, क्योंकि स्वस्थ रहना व्यस्त से अधिक महत्वपूर्ण है।

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

फेरीवालों के लिए 20% कूपन बंद - मानव प्रबंधन

पुस्तक के पेपर संस्करण के भुगतान पर, पुस्तक का एक इलेक्ट्रॉनिक संस्करण ई-मेल द्वारा भेजा जाता है।

पुनश्च: पुस्तक की लागत का 7% नई कंप्यूटर पुस्तकों के अनुवाद में जाएगा, छपाई घर को सौंपी गई पुस्तकों की सूची यहां है ।