जेएच वर्षा जल "बिल्लियों को कैसे चरना है" (भाग दो): वह सब जो तकनीकी में महारत रखता है

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

प्राथमिकता

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

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

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

सभी अनुरोधों और सूचनाओं को अधिक सफलतापूर्वक व्यवस्थित करने के लिए, लेखक उन्हें संसाधित करने के लिए निम्नलिखित मैट्रिक्स का उपयोग करने का सुझाव देता है:

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

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

परियोजनाओं का विस्तार

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

कोई भी प्रक्रिया आपकी अपेक्षा से अधिक समय तक चलेगी। कुछ हमेशा ऐसा प्रतीत होता है कि आपने सोचा नहीं था।

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

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

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

उदाहरण के लिए, यदि आप इस तरह के दस्तावेज से लैस किसी परियोजना को अपनाते हैं, तो आपके सामने कई प्राकृतिक आपदाएँ और बाधाएँ आएंगी:



यदि रोडमैप नीचे के नमूने के समान है, तो सुखद परिणाम की संभावना काफी बढ़ जाती है:



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

• परियोजना के उद्देश्यों की अपर्याप्त विशिष्टता
• इस कंपनी के लिए नई तकनीक का अनुप्रयोग
• वार्षिक / गुम परियोजना प्रबंधन पद्धति
• समूह के प्रमुख विशेषज्ञों की कमी
• हार्डवेयर / सॉफ्टवेयर निर्माताओं द्वारा समझौतों का विघटन

आम भाषा खोज

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

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

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

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

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

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

झुंड उठाकर

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

लेखक साक्षात्कार के लिए निम्नलिखित सिफारिशें प्रदान करता है:

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

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

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

कर्मचारियों के काम का संगठन

आरामदायक रहने का माहौल

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

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

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

काम के घंटे

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

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

कार्य वितरण और पर्यवेक्षण

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

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

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

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

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

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

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

प्रेरणा और प्रोत्साहन

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

पारिश्रमिक के संदर्भ में, जो प्रबंधक विकास छोड़ चुके हैं, वे भी बहुत जल्दी नहीं होते हैं, लेकिन अक्सर विपरीत परिस्थितियों में गिर जाते हैं और कर्मचारियों की अपेक्षाओं को कम कर देते हैं। दरों पर निर्णय लेते समय, निम्नलिखित कारकों को ध्यान में रखें: उत्पादकता, अनुभव, प्रभावशीलता, कार्यों की समयबद्धता, वर्तमान औसत दर, बाजार की स्थिति और कॉर्पोरेट मानक। एक सामान्य गलती अग्रिम में वेतन बढ़ाना है, उम्मीद है कि यह श्रमिकों को अपना सब कुछ देने के लिए प्रोत्साहित करता है। , – , .

, , , . , , .

– . , , , (, , «»). . – , . , , , .

, . – , -, , , , . : , . « » , . ( – ) – .