क्यों सिर्फ अपनी कोडिंग को अपग्रेड करने से आप एक बेहतर डेवलपर नहीं बन जायेंगे?

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

एक अच्छे डेवलपर के बारे में मिथक यह है कि वह:

1. साफ़ कोड लिखता है
2. बहुत सारी तकनीकों को जानता है
3. कोडिंग कार्य तेजी से
4. एल्गोरिदम और डिज़ाइन पैटर्न का एक समूह जानता है
5. क्लीन कोड का उपयोग करके किसी भी कोड को रिफैक्टर कर सकते हैं
6. गैर-प्रोग्रामिंग कार्यों पर समय बर्बाद नहीं करता
7. अपनी पसंदीदा तकनीक में 100% निपुण

एचआर आदर्श उम्मीदवारों को इसी तरह देखता है, और तदनुसार रिक्तियां भी इसी तरह दिखती हैं।

लेकिन मेरा अनुभव कहता है कि ये बात बिल्कुल सच नहीं है.

सबसे पहले, दो महत्वपूर्ण अस्वीकरण:
1) मेरा अनुभव उत्पाद टीमों का है, अर्थात्। अपने स्वयं के उत्पाद वाली कंपनियां, आउटसोर्सिंग नहीं; आउटसोर्सिंग में सब कुछ बहुत अलग हो सकता है;
2) यदि आप जूनियर हैं, तो सभी सलाह लागू नहीं होंगी, और यदि मैं आपकी जगह होता, तो मैं अभी प्रोग्रामिंग पर ध्यान केंद्रित करता।

अच्छा डेवलपर: वास्तविकता

1: औसत कोड से बेहतर

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

2: समस्याएँ पैदा करने के बजाय उन्हें हल करता है

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

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

3: अधिकतम परिणाम प्राप्त करने के लिए न्यूनतम प्रयास करने का प्रयास करता है, भले ही इसके लिए बैसाखी लिखना पड़े

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

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

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

4. इसकी अपनी व्यवसाय प्रबंधन प्रणाली है और यह किसी भी जटिलता की परियोजनाओं पर काम करने में सक्षम है।

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

5. किसी भी शर्त और परिचय पर सवाल उठाना और उसे स्पष्ट करना

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

6. प्रक्रियाओं और आपके आस-पास के लोगों में सुधार करता है

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

7. दूसरों को प्रबंधित करने में उत्कृष्ट, भले ही प्रबंधक न हों

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

8. अपने ज्ञान को हठधर्मिता के रूप में नहीं मानता, लगातार आलोचना के लिए खुला रहता है

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

आइए एक आदर्श डेवलपर के मेरे विचार की तुलना आम तौर पर स्वीकृत डेवलपर से करें:

यह चित्र दिखाता है कि ऊपर वर्णित कितने बिंदु कोड से संबंधित हैं, और कितने नहीं। किसी उत्पाद कंपनी में विकास केवल एक तिहाई प्रोग्रामिंग है, शेष 2/3 का कोड से कोई लेना-देना नहीं है। और यद्यपि हम बहुत सारे कोड लिखते हैं, हमारी प्रभावशीलता इन "अप्रासंगिक" दो-तिहाई पर बहुत निर्भर करती है।

विशेषज्ञता, सामान्यवाद और 80-20 नियम

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

80-20 नियम हमें बताता है कि 80% परिणाम 20% प्रयास से आता है। 80% राजस्व 20% ग्राहकों से आता है, 80% लाभ 20% कर्मचारियों से आता है, इत्यादि। शिक्षण में, इसका मतलब है कि 80% ज्ञान हम खर्च किए गए समय के पहले 20% में प्राप्त करते हैं।

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

कुल: आप अपना 100% समय किसी कौशल का अध्ययन करने में सीमा तक खर्च कर सकते हैं, या आप एक ही समय पांच क्षेत्रों में बिता सकते हैं, प्रत्येक में 80% तक का स्तर। इस सरल गणित का अनुसरण करके, हम उतने ही समय में चार गुना अधिक कौशल हासिल कर सकते हैं। यह अतिशयोक्ति है, लेकिन यह विचार को स्पष्ट करता है।

संबंधित कौशल को 80% नहीं, बल्कि 30-50% तक प्रशिक्षित किया जा सकता है। 10-20 घंटे बिताने के बाद, आप संबंधित क्षेत्रों में उल्लेखनीय रूप से सुधार करेंगे, उनमें होने वाली प्रक्रियाओं की काफी समझ हासिल करेंगे और अधिक स्वायत्त हो जाएंगे।

आज के आईटी पारिस्थितिकी तंत्र में, जितना संभव हो उतने कौशल रखना बेहतर है और उनमें से किसी में भी विशेषज्ञ नहीं होना चाहिए। क्योंकि, सबसे पहले, ये सभी कौशल जल्दी से फीके पड़ जाते हैं, खासकर जब प्रोग्रामिंग की बात आती है, और दूसरी बात, क्योंकि 99% समय हम न केवल बुनियादी, बल्कि निश्चित रूप से सबसे परिष्कृत कौशल का उपयोग नहीं करते हैं, और यह कोडिंग में भी पर्याप्त है। बढ़िया कंपनियाँ.

और अंत में, प्रशिक्षण एक निवेश है, और निवेश में विविधीकरण महत्वपूर्ण है।

क्या पढ़ाना है

तो क्या पढ़ायें और कैसे? एक मजबूत कंपनी में एक विशिष्ट डेवलपर नियमित रूप से इसका उपयोग करता है:

• संचार
• आत्म संगठन
• आयोजन
• डिज़ाइन (आमतौर पर कोड)
• और कभी-कभी प्रबंधन, नेतृत्व, डेटा विश्लेषण, लेखन, भर्ती, सलाह और कई अन्य कौशल

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

किन क्षेत्रों में विकास करना उचित है?

1. सॉफ्ट स्किल्स वह सब कुछ है जो संपादक में बटन दबाने से संबंधित नहीं है। इस तरह हम संदेश लिखते हैं, हम बैठकों में कैसे व्यवहार करते हैं, हम सहकर्मियों के साथ कैसे संवाद करते हैं। ये सभी स्पष्ट बातें प्रतीत होती हैं, लेकिन अक्सर इन्हें कम करके आंका जाता है।

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

3. सक्रिय, खुले विचारों वाला और योजना बनाने वाला। विषय बहुत सामान्य और महत्वपूर्ण हैं, आईटी के लिए अद्वितीय नहीं हैं, और हर किसी को उन्हें विकसित करना चाहिए। सक्रियता का अर्थ है कार्रवाई करने के लिए सिग्नल की प्रतीक्षा न करना। आप घटनाओं के स्रोत हैं, उन पर प्रतिक्रिया नहीं। खुली मानसिकता किसी भी नई जानकारी को निष्पक्ष रूप से व्यवहार करने, अपने स्वयं के विश्वदृष्टिकोण और पुरानी आदतों से अलग स्थिति का मूल्यांकन करने की क्षमता है। योजना एक स्पष्ट दृष्टिकोण है कि आज का कार्य सप्ताह, महीने, वर्ष के लिए समस्या को कैसे हल करता है। यदि आप किसी विशिष्ट कार्य से परे भविष्य देखते हैं, तो आपको जो चाहिए वह करना बहुत आसान है, और समय के बाद यह महसूस करने से डरें नहीं कि यह बर्बाद हो गया। यह कौशल करियर के लिए विशेष रूप से महत्वपूर्ण है: आप वर्षों तक सफलतापूर्वक परिणाम प्राप्त कर सकते हैं, लेकिन गलत जगह पर, और अंततः सारा संचित सामान खो सकते हैं जब यह स्पष्ट हो जाता है कि आप गलत दिशा में आगे बढ़ रहे थे।

4. सभी संबंधित क्षेत्र बुनियादी स्तर तक। हर किसी के अपने विशिष्ट क्षेत्र होते हैं, लेकिन यह समझना महत्वपूर्ण है कि कुछ "विदेशी" कौशल को विकसित करने पर 10-20 घंटे का समय व्यतीत करके, आप अपने दैनिक कार्य में कई नए अवसरों और संपर्क के बिंदुओं की खोज कर सकते हैं, और ये घंटे हो सकते हैं करियर के अंत तक पर्याप्त रहें।

क्या पढ़ें

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

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

2. स्टीफन आर. कोवे "अत्यधिक प्रभावी लोगों की 7 आदतें". सक्रियता से लेकर सॉफ्ट स्किल तक विभिन्न कौशलों का मिश्रण, जब आपको एक छोटी टीम को एक बड़ी ताकत में बदलने की आवश्यकता होती है तो तालमेल हासिल करने पर जोर दिया जाता है। इसे पढ़ना भी आसान है.

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

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

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

स्रोत: www.habr.com