एक सॉफ्टवेयर इंजीनियर के रूप में लंबे समय तक काम करना, अनुभव और ज्ञान के अलावा, मैंने विशेष रूप से कार्य प्रक्रिया और बॉस पर असंतोष और टिप्पणियां एकत्र कीं। हर बार जब मैं एक समस्या में आया, तो मैंने सोचा कि मैं इसे कैसे हल कर सकता हूं और इस स्थिति में मैं क्या कर सकता हूं। कुछ करना संभव था, लेकिन प्रक्रिया और शासी तंत्र के बारे में कुछ टूट गया था। और हर बार समस्या और इसके समाधानों को मेरे द्वारा हटा दिया गया, इस बोध के साथ कि यदि मेरे पास आवश्यक लाभ था, तो मैं इसे बदल सकता था और इसे सही तरीके से कर सकता था। मैंने एक मानसिक प्रणाली भी बनाई थी, जो कि कागज पर औपचारिक रूप देने के लिए बहुत आलसी थी। मेरे चारों ओर व्याप्त अन्याय मेरे लिए था, यद्यपि छिपा हुआ था, लेकिन मेरे गले में एक गांठ, मेरी आत्मा पर एक पत्थर में बदल रहा था। मैं एक मौका और सब कुछ महसूस करने और सही करने की उम्मीद कर रहा था जो संचित हो गया था, और एक बार अवसर बदल गया।
अपनी इच्छाओं में सावधान रहें - वे सच हो जाते हैं!
और ऐसा हुआ कि मुझे अप्रत्याशित रूप से एक नेतृत्व की स्थिति की पेशकश की गई जिसने मेरी प्रतिभा और कौशल की सराहना की और मुझे अपनी महत्वाकांक्षाओं को महसूस करने की अनुमति दी। प्रबंधक के साथ बातचीत सबसे अच्छी परंपरा में समाप्त हुई "
आप अब मालिक हैं - प्रबंधन करें ।" और अब मुझे न्याय के दीप्तिमान और क्रिस्टल-स्पष्ट प्रकाश को मूर्त रूप देना था और लोगों को खुश करना था, शब्द और बाइट लोगों तक ले जाना था। हालाँकि, लगभग तुरंत ही यह पता चला कि यह पहले की तुलना में थोड़ा अधिक जटिल था, कि ऊपर और नीचे की समस्याओं पर देखने का कोण थोड़ा अलग है, और देशी कोड समस्याओं और चिंताओं की भारी संख्या की तुलना में अधिक प्रशंसनीय निकला। इसलिए अब मैंने आखिरकार कलाकार की ओर से और मालिक के चश्मे से अपने हठधर्मिता को कागज पर उतारने का फैसला किया। मैं कुछ भी नया कहने की संभावना नहीं हूँ, इसके अलावा जो कुछ भी मेरे सामने अच्छी किताबों में लिखा गया है, व्यावहारिक उदाहरणों और चुटकुलों के साथ चुटकुलों के अपवाद के साथ, इसलिए या तो तुरंत स्क्रॉल करें या कैट का स्वागत करें
सबसे पहले, मैं कुछ करने और कुछ हासिल करने से शुरू करता हूं, आपको जानने, चाहने और करने की जरूरत है। यह भाग्य या पीटर के सिद्धांत को खारिज करने के लिए पर्याप्त नहीं है: "
एक पदानुक्रमित प्रणाली में, कोई भी कर्मचारी अपनी अक्षमता के स्तर तक बढ़ जाता है ।" हालांकि यह प्राकृतिक प्रोग्रामर न्याय की तुलना में अधिक बार होता है। आपको यह जानने की जरूरत है कि सिद्धांत की आवश्यकता से अधिक क्या है, कागज के एक टुकड़े के कब्जे से, डिप्लोमा देता है, उस दृष्टिकोण से भागीदारी की तुलना में जो आपके दृष्टिकोण से दिखाई देता है। एक साधारण कर्मचारी के रूप में, मेरी दिलचस्पी थी कि आईटी आर्किटेक्ट और प्रोजेक्ट मैनेजर आईटी कैसे करते हैं, कैसे सब कुछ जुड़ा हुआ है और यह कैसे काम करता है, और नरक मैं कोड क्यों लिख रहा हूं। नहीं, निश्चित रूप से मैं समझ गया था कि मेरा सॉफ़्टवेयर नियंत्रक की मेमोरी में लिखा जाएगा, और ग्राहक नियंत्रक को पैसे देगा। लेकिन मेरे कोड के अलावा अभी भी बहुत कुछ बाकी था, अक्सर, यह मुझे लगता था, अनावश्यक (और कभी-कभी यह था), और मेरे लिए उस मिशन के सार और उद्देश्य को समझना महत्वपूर्ण था, जो न्याय मैं चंद्रमा के नाम पर ले जाता हूं।
प्रोग्रामर, डेवलपर्स के पास न्याय की ऊँची भावना है । यदि वह नहीं है, तो यह विशेषज्ञ खराब है। उसके साथ व्यवहार न करें और उस पर भरोसा न करें। अच्छे प्रोग्रामर तब तक समझौता नहीं करते जब तक वे समाधान मेला नहीं लगा लेते। इसलिए, सबसे महत्वपूर्ण प्रेरणाओं में से एक पवित्र लक्ष्य, लक्ष्य प्रबंधन है। एक अच्छा उदाहरण कर्मचारियों की स्वतंत्रता के साथ अपने शांतिवाद या Google के साथ Apple का उदाहरण है। एक अच्छा उदाहरण अन्य कंपनियों के चेहरे में "बुराई" के खिलाफ प्रदर्शन है। एक लक्ष्य होने, वर्कफ़्लो में और कंपनी के स्तर पर, यह निर्धारित करना आसान है कि ठेकेदार अपने कार्यों के लिए क्षमताओं और संसाधनों का उपयोग करेगा, वह अंततः समझ जाएगा कि वह क्यों और क्या काम कर रहा है, और यह कि उसका पकड़ा हुआ बग अब और नहीं उड़ जाएगा हवा में, कहीं एक हवाई जहाज नियंत्रण नियंत्रक में बैठा हुआ है, जिसके बारे में सौ लोगों ने सोचा है, क्योंकि उसकी कंपनी, चलो कहते हैं, लोगों के जीवन को उच्चतम लक्ष्य के रूप में सेट करें। डेवलपर, अपने स्वयं के आदर्शों और न्याय का एक उपाय होने पर, कभी भी ऐसी कंपनी में नहीं जाएगा जो फर सील को मारती है या बजट को पैचिंग गड्ढों में काट देती है यदि यह उनके आदर्शों के विपरीत है। कोड की शैली उसके लिए महत्वपूर्ण होगी (नहीं, केवल भारतीय कोड नहीं!), कुकीज़ की संख्या (किसी को भी नहीं मिलती!), खिड़की से दृश्य (बॉस से नदी तक, और प्रोग्रामर से ईंट की दीवार तक) और शोर। कार्यालय (प्रबंधक हमेशा काम के बजाय बात करते हैं)। प्रक्रिया में अन्य प्रतिभागियों के दृष्टिकोण से, डेवलपर हमेशा सही नहीं हो सकता है, लेकिन उसके पास अपने स्वयं के पवित्र लक्ष्य हैं, हठधर्मिता, इसका उल्लंघन, उदाहरण के लिए, पारिश्रमिक की तुलना में बहुत खराब है।
यह एक बहुत ही महत्वपूर्ण बिंदु है, डेवलपर का पारिश्रमिक ऐसा होना चाहिए कि वह अपनी चिंताओं के बारे में न सोचें और पैसा बनाने के लिए स्नैपशॉट न देखें। और उनकी सफलताओं को पुरस्कार के रूप में पुष्टि की आवश्यकता नहीं है। वह एक उद्देश्य के लिए काम करता है, अपने न्याय के लिए, लेकिन प्रोत्साहन के लिए नहीं। डेवलपर को हाथ से खाना खिलाना, आप एक उत्कृष्ट विशेषज्ञ को नष्ट करने का जोखिम उठाते हैं, जो अपने विचारों के साथ पूरे वर्कफ़्लो को रोशन कर सकता है। हालांकि, अगर डेवलपर सबसे आगे पैसा लगाता है, और नियमित रूप से बॉस से बोनस मांगने जाता है, तो यह एक समस्या का संकेत है। किसी व्यक्ति या प्रक्रिया के साथ। एक गलती की गई थी, जिसमें से कोई वापसी नहीं है, लेकिन, प्रक्रिया और प्रबंधन के दृष्टिकोण से, अन्य कर्मचारियों के लिए भविष्य में इसी तरह की समस्या से बचना संभव है।
मुझे हमेशा उतना भुगतान नहीं किया गया था जितना मैं चाहूंगा और मुझे इसकी आवश्यकता होगी, और कभी-कभी मैं एक ही समय में फ्रीलांस साइटों पर चढ़ गया, लेकिन काम पर मैंने पहल की, अपने काम को समय से पहले करने में, संकोच करने वाले कर्मचारियों की मदद करना, सामान्य तौर पर, मैंने मैंने लगन से काम किया, हालाँकि जाम के साथ, लेकिन मैंने काम करने की कोशिश की, पुरस्कार के लिए नहीं, बल्कि सफलता के लिए: "हम एक ही दोहन में हैं"। मैं खुद के साथ ईमानदार था, लेकिन भीतर के न्याय की भावना ने छलांग लगाई: मैं परिणाम के लिए काम करता हूं, और मेरा सहयोगी घंटों काम करता है। मैं एक ही निकास के साथ आठ के बजाय दो घंटे काम कर सकता था, मुझे ट्रैफ़िक जाम में अतिरिक्त घंटों नहीं खड़ा होना पड़ेगा। मुझे बोनस का भुगतान नहीं किया जा सकता था (यदि यह प्रदान किया गया था), लेकिन परिणाम से, उस कर्मचारी-आलसी व्यक्ति के बजट से। न्याय को विभिन्न तरीकों से बहाल किया जा सकता है। लेकिन किसी ने नहीं किया। यह एक प्रबंधन त्रुटि थी, जिसके परिणामस्वरूप प्रेरणा में गिरावट आई और एक कुर्सी पर बैठ गया। कभी भी, किसी भी परिस्थिति में, डेवलपर्स को किसी और के काम करने के लिए एक अवसर दें, यहां तक कि अपनी पहल पर भी। योजनाओं को बदलें, लापरवाही को बाहर निकालें, जटिल कार्यों को सक्रिय दें, लेकिन डेवलपर को श्रम के अनुचित विभाजन को महसूस करने की अनुमति न दें। डेवलपर की ओर से, किसी को अपने काम के माप के माध्यम से दूर नहीं जाना चाहिए, बल्कि अपने समय की योजना बनाएं और अपने संसाधनों को एक अलग दिशा में जाने दें: सीखने, संवाद करने, प्रक्रिया में सुधार करने के लिए।
शायद, पाठक के दृष्टिकोण से, आप कह सकते हैं कि यह मेरी अपनी गलती है, कि मैंने खुद इसे पूरा नहीं किया है? मैंने "उस आदमी" पर हल क्यों चलाया? अगर कई लोग कार्यस्थल पर बैशगोर पढ़ सकते हैं और काम की उपस्थिति बनाए रख सकते हैं, तो यह मेरे लिए कठिन था, मैनुअल के माध्यम से छोड़ना और कोडांतरक स्थिति के लिए क्यूटी कोड लिखना (उदाहरण के लिए), फिर से न्याय की ऊँची भावना के कारण - अधिकारियों को धोखा देने के लिए? हां, और काम के दौरान कुछ और करना कहीं भी स्वागत योग्य नहीं है, और इससे भी ज्यादा है साइड-प्रोजेक्ट्स। यह प्रबंधन की गलतियों में से एक है - कर्मचारियों को प्रशिक्षित करने के लिए नहीं।
एक डेवलपर की दूसरी महत्वपूर्ण गुणवत्ता सीखने की क्षमता है । हम, आईटी से संबंधित लोग, सीखने और सुधार की एक स्थायी स्थिति में हैं। हमारे लिए अपने कौशल को सुधारने के लिए यह पर्याप्त नहीं है, और ब्रेनफक पर हैलो वर्ल्ड, हैस्केल पर टेट्रिस और बहुत सी ऐसी चीजें लिखना दिलचस्प है जो हमसे नहीं पूछे जाते हैं। हम नई चीजें सीखने में रुचि रखते हैं। और जब मैंने प्रबंधन से पूछा "क्या आपके पास प्रशिक्षण, सेमिनार हैं?" - उन्होंने मुझे नकारात्मक उत्तर दिया। वे हमेशा काम से संबंधित नहीं हो सकते हैं, जो नियोक्ता की ओर से संसाधनों का जोखिम और नुकसान ला सकता है, लेकिन ज्ञान और प्रभाव के मेरे क्षेत्र का विस्तार, अन्य प्रोग्रामर के साथ अनुभव का आदान-प्रदान, और मेरे क्षेत्र में नए उत्पादों का ज्ञान सकारात्मक होगा। और इसमें आश्चर्यचकित होने की कोई बात नहीं है कि अक्सर हमारे लिए एक अपठनीय कोड लिखने में मज़ा आता था, या तो सुंदर, या सुपरफास्ट और निम्न स्तर, जहां लड़ाई हर बिट के लिए हुई थी, न कि थोड़ा सा, लेकिन प्रत्येक घड़ी चक्र के लिए। जो, अंत में, हालांकि यह आंतरिक मानकों के विपरीत नहीं था, लेकिन नेतृत्व के असंतोष का कारण बना: कोड मानव-निर्भर बन गया। हमारे लिए अन्याय की जरूरत है।
यह Google कर्मचारी को अपनी परियोजनाओं पर अपने समय का 20% खर्च करने का अधिकार है, यदि संभव हो तो, उन्हें भविष्य में लागू करें, अर्थात। पहल करें। व्यवहार में, यह लगभग हमेशा नहीं होता है। इसके अलावा, दिनचर्या आमतौर पर दिलचस्प कार्यों पर हावी रहती है, और साइड प्रोजेक्ट्स की कमी भी डेवलपर्स के माहौल और प्रेरणा के लिए हानिकारक है। फिर भी, डेवलपर की प्रेरणा और उसके विचारों और आंदोलनों को जल्द या बाद में नेतृत्व तक पहुंचाना बहुत मुश्किल है। उनमें से सभी उपयोगी नहीं हैं, निश्चित रूप से, लेकिन उनमें से कोई भी, एक नियम के रूप में, हानिकारक है (जब तक कि निश्चित रूप से, विशेषज्ञ ने पूरे निर्माण को एक असाधारण और अनुचित सुविधा के साथ अंतिम प्रतिबद्ध के साथ नीचे लाया है)। हालांकि, उसके लिए एक गंभीर झटका कचरे में परिणाम फेंक देगा। उदाहरण के लिए, किसी भी तरह से पूरे वास्तुकला और बाद के पुनरावृत्तियों / परीक्षण की चिंता नहीं करनी चाहिए। एक उदाहरण के रूप में, मैं कोड की एक विशुद्ध रूप से सौंदर्य की चाट, टैब, टिप्पणियों में टाइपोस (नए लिखित फ़ंक्शन के अलावा), या यूनिट-परीक्षणों के अलावा MC \ DC का हवाला दे सकता हूं। यह काफी स्पष्ट है कि कार्यात्मक रूप से इस तरह के बदलावों से कुछ भी नहीं बदलेगा, वे बस इस तथ्य को जन्म देंगे कि दूसरों को कोड के एक खंड के बजाय अपडेट में मिल जाएगा, और सामान्य रूप से बदलाव अपेक्षा से अधिक होंगे। समस्या: पहल के परिणाम को कचरे में फेंक दिया जाएगा। इस तथ्य के बावजूद कि यह वर्कफ़्लो में उल्लंघन या जाम नहीं है। या रिवर्स साइड - नवाचार (सुविधा, वर्कफ़्लो, टूल) को विचार के लेखक के तहत नहीं, बल्कि किसी अन्य कर्मचारी या मध्यवर्ती बॉस के नाम के तहत स्वीकार किया जाएगा। एक तरफ, इसे फ्लैगेंट चोरी के रूप में माना जा सकता है, और दूसरी ओर, कर्मचारी के अविश्वास के संकेत के रूप में, जो अपने स्वयं के आकलन को बहुत प्रभावित करेगा।
अन्य बातों के अलावा, विकास टीम का संरक्षण और सामंजस्य भी महत्वपूर्ण है। संरक्षक का मतलब निम्नलिखित तथ्य है कि ऊपर से डेवलपर पर सब कुछ डालना - लेखा रिपोर्ट, रैलियां, एससीआरयूएम स्प्रिंट (यदि प्रक्रिया स्थापित नहीं है), इन्वेंट्री, तकनीकी उपकरण, कंपनी के जीवन में भाग लेने का अवसर, प्रबंधकों और प्रबंधन के व्यक्ति में एक बफर द्वारा फ़िल्टर किया जाना चाहिए। डेवलपर्स के पास जीवन का एक विशेष प्रतिमान है, एक विशेष पारिस्थितिकी तंत्र जिसमें कुछ समझ से बाहर होने के लिए बहुत जोखिम भरा है। वे, एक विशाल मॉडल को ध्यान में रखते हुए, प्रोजेक्ट और कोड के रिश्ते को "ट्रिफ़ल्स" द्वारा विचलित नहीं किया जा सकता है, अन्यथा सब कुछ ताश के पत्तों की तरह उखड़ना शुरू हो जाता है, और कार्य प्रक्रिया को फिर से शुरू करने की उम्मीद गड़बड़ हो जाती है, चैटिंग होती है, जिसके परिणामस्वरूप, पूरे कंपनी के सभी कर्मचारियों द्वारा एकत्र करने की आवश्यकता होगी। । लेकिन इसके साथ ही, यह ध्यान रखना महत्वपूर्ण है कि कंपनी के जीवन में भागीदारी न केवल एक उज्ज्वल लक्ष्य देखने का एक तरीका है, बल्कि आपके महत्व को महसूस करना भी है। सबसे आम समस्या संदेश है "आप पैसा नहीं बनाते हैं।" आईटी लोग कुछ भी उत्पादन नहीं करते हुए पैसा खर्च करते हैं। और बिक्री विभाग पैसा बनाता है। बेचता है। समर्थन ग्राहकों के साथ काम करता है। यह कथन एक विशाल प्रणालीगत समस्या का एक बीकन है, जब एक वितरित चिंता में भी आईटी कर्मियों की भूमिका "लाभहीन" होती है, हालांकि, एक नियम के रूप में, एक विकास टीम के स्वचालन और परियोजनाएं बिक्री के लिए हजारों और लाखों यूनिट सामान ला सकती हैं। आईटी इन्फ्रास्ट्रक्चर विभागों के साथ स्थिति खराब है, खासकर यदि वे अच्छी तरह से काम करते हैं (और लगातार केबल नहीं खींचते हैं) और परीक्षण के साथ (कोड लिखा है!)। हालांकि यह रवैया एक रक्षात्मक प्रतिक्रिया "बेवकूफ भ्रष्ट महिलाओं" को जन्म देता है, लेकिन सबसे महत्वपूर्ण बात यह है कि यह अक्सर कोग-डेवलपर की उपेक्षा की ओर जाता है, जिस पर संपूर्ण चिंता (और अंत में अंतिम लाभ) टिकी हुई है: घरेलू योजना में - दूसरी श्रेणी की कुर्सियों में, बचाने के अवसर में। (वे लोगों से शिकायत नहीं करते हैं; वे लोगों के साथ काम नहीं करते हैं), कुकीज़ या मोबाइल संचार के लिए बजट में कटौती करें, खाने के लिए काले जंगल में भेड़ियों को छोड़ दें, अगर दुर्भाग्यपूर्ण प्रोग्रामर अंधेरे जंगलों की वस्तु पर एक व्यापार यात्रा पर जाने के लिए पर्याप्त भाग्यशाली था।
डेवलपर्स बहुत धैर्यवान लोग हैं, क्योंकि वे आमतौर पर जानते हैं कि, सबसे पहले, वे मूर्खों पर अपराध नहीं करते हैं, और दूसरी बात, वे उन लोगों पर पानी ढोते हैं जो नाराज हैं। लेकिन अगर कर्मचारी शुरू में उस कंपनी में आया था जहां मुफ्त कुकीज़ थे, और खिड़की से दृश्य एक स्क्रब था, और समय की चूक के बाद वह इस से वंचित था, परेशानी का इंतजार करें। विश्वास है कि वित्तीय विभाग और उबलते पानी का भुगतान करने की संभावना नहीं है। यह बेहतर था - यह खराब हो गया, और इसके अलावा, अब पालतू कब्रिस्तान की खिड़की से एक दृश्य है। यह इस तथ्य के कारण है कि डेवलपर एक प्रगतिशील प्राणी है, और अगर वह एक प्रतिगमन देखता है जिसके साथ वह नियंत्रित नहीं कर सकता है, जिससे कोई सुरक्षा नहीं है - यह भी उसे demotivates।
टीम सामंजस्य एक बहुत ही महत्वपूर्ण चीज है, और किसी तरह इसे प्रबंधन रूप में रखना बहुत मुश्किल है। सामंजस्य एक टीम की एक ही टीम में जाने और एक दूसरे के पूरक होने की क्षमता है, सामान्य हित हैं, "सबसे खराब और सर्वश्रेष्ठ" को उजागर नहीं करते हैं। मैंने पहले ही ऊपर कहा है कि लक्ष्य और उद्देश्य ओवरलैप नहीं होने चाहिए, लोगों के बीच प्रतिस्पर्धा और प्रतिद्वंद्विता नहीं होनी चाहिए। रेटिंग, पदोन्नति, गाजर और कुकीज़, विशेष रूप से अभिजात वर्ग के लिए कुकीज़, बुराई के अंधेरे पक्ष हैं। और कोई भी बुराई सामूहिक नहीं है। डेवलपर को समझने और स्वीकार किए जाने की इच्छा के साथ अपने काम पर आता है। और आम जमीन महत्वपूर्ण है। अक्सर सामान्य बिंदु उपसमूह, रुचि समूह बनाते हैं। किसी भी समाज में, यह सामान्य है, लेकिन काम की प्रक्रिया में अस्वीकार्य है। मैं वास्तव में क्या बुरा हूं, कि मैं पोकर प्रशंसकों के इस समूह से संबंधित नहीं हूं? समस्या तब होती है जब समूह का मूल व्यक्ति के मूल से अलग हो जाता है। उदाहरण के लिए, समाचार पोर्टलों की दैनिक चर्चा या एक अप्रकाशित खेल असंतोष का कारण होगा। सिर्फ इसलिए कि एक व्यक्ति पीली खबर नहीं पढ़ता है और बाईं छोटी उंगली के साथ कोर की आकर्षक किकिंग नहीं देखता है। इसके अलावा, इस तरह के समुदायों में एकीकरण से आंतरिक सुरक्षा और संरक्षण होगा, एक के ऊपर एक का प्रचार। एक सामान्य समाज में, ये संचार समस्याएं हैं, लेकिन एक तकनीकी समाज में, आईटी वातावरण में, क्योंकि उनके पास खराब संचार कौशल हैं, ऐसी समस्या प्रकृति में टर्मिनल हो सकती है। इसके अलावा, यह सोचने का एक अवसर है कि क्या कर्मचारियों में से एक मैनुअल अध्ययन कर रहा है, विषयगत संसाधनों को पढ़ रहा है, और "मुझे यहां ऐसा ढांचा मिला है" साझा करने की इच्छा के साथ सहयोगियों से संपर्क करना "वह जवाब में सुनता है" यह कुछ भी नहीं है, यह हमारे लिए दिलचस्प नहीं है। यह डेवलपर के लिए सोचने का एक अवसर है - क्या वह वहां आया था? और कर्मचारियों के प्रबंधन के बारे में सोचने का एक कारण: क्या वे व्यस्त हैं और क्या वे सही लोग हैं? पेशेवर हित के बिना समस्याओं और कार्यों को हल करने की क्षमता प्रक्रिया और टीम के क्षय का संकेत है।
इसलिए, ब्याज डेवलपर की तीसरी महत्वपूर्ण गुणवत्ता है ।
इन सभी समस्याओं के परिणामस्वरूप अन्याय और गलत की भावना पैदा होती है। प्रक्रिया, लोग, सब कुछ जो एक व्यक्ति को घेरता है। और यह इन कारकों के साथ था कि मैं, नेता के रूप में, पिछली गलतियों को नहीं लड़ना और दोहराना था।
ऐसा करने के लिए, आप उन सभी चीजों की अंतिम सूची बना सकते हैं जो मैंने ऊपर सूचीबद्ध की हैं:
- उचित हो और डेवलपर के दृष्टिकोण को देखें;
- प्रतिक्रिया के लिए खुला होना;
- उस व्यक्ति का अधिकार है जो इस विषय को जानता है;
- लोगों को इस डर के बिना विकसित करने के लिए कि वे छोड़ देंगे;
- ट्रस्ट और प्रतिनिधि प्रबंधन;
- ऐसे वादे न करें जिन्हें रखा नहीं जा सकता;
- टीम और लोगों के चयन का प्रबंधन;
- एक लक्ष्य और मूल्यों को विकसित करने के लिए;
- एक खुली और स्पष्ट प्रक्रिया है;
- पहले स्थान पर टीम के हितों की रक्षा करना।
उत्तरार्द्ध के बारे में, मैं ध्यान दे सकता हूं कि प्रबंधन के लिए यह महत्वपूर्ण बिंदुओं में से एक है। एक टीम नेता का समर्थन है, और टीम मजबूत होती है, जितना अधिक डेवलपर संतुष्ट होता है, उतने अधिक अवसर उसे परियोजना को समय पर पूरा करने के लिए होते हैं, इसे ग्राहक तक पहुंचाते हैं और इसे आदर्श बनाते हैं।
हम अगली बार अन्य समस्याओं, अनुभव और विवरण के बारे में बात करेंगे।