👨🏼‍🎨 🛰️ 👩🏾‍🍳 नियोक्ता को बुरी सलाह। डेवलपर के साथ "ठीक से" बातचीत कैसे करें 👩‍🚒 🧑🏽‍🤝‍🧑🏻 🥅

मैं हाल ही में भाग्यशाली रहा हूं - मैं उन कंपनियों के लिए काम करता हूं जहां डेवलपर्स वास्तव में सम्मानित हैं। लेकिन यह हमेशा ऐसा नहीं था; मुझे बातचीत के विभिन्न तरीकों से निपटना पड़ा। मैं यह कहना चाहूंगा कि "जंगली नैतिकता" अतीत की बात है, लेकिन मेरे सहकर्मियों की कहानियों में उनके पिछले कामों के बारे में और मेरे बाजार के बयान इस कथन को खारिज करते हैं।

ठीक है, चलो कैसे "ठीक से" डेवलपर के साथ बातचीत करते हैं, उदाहरण के लिए, व्यक्तिगत रूप से मेरे साथ ...

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

जब आप मेरे कार्यक्रम की योजना ...

... याद रखें कि सबसे अच्छा मैं आपातकालीन मोड में काम करता हूं, कल के 40 घंटे के कोडिंग सत्र के 3 घंटे बाद सो रहा हूं। यह इस समय है कि 2 मॉनिटर नेत्रहीन रूप से 4 में बदल जाते हैं, और कोड सिर में एक तंबुरिन की समान ध्वनि के लिए मूल अमेरिकी नृत्य करना शुरू करता है। केवल इस तरह से आप मुझे गैर-मानक से प्राप्त करेंगे, एक कह सकता है, शानदार विचार। इस आपातकालीन स्थिति में, कोड लंबे नूडल्स की तरह दिखाई देने लगता है। यदि कोई मौजूद होता है तो उसके पास 'केवल लेखन' की एक फ़ाइल विशेषता होगी। आप इस तरह के कोड को केवल उसी आपात स्थिति में डुबाकर पढ़ सकते हैं, जिसमें मैंने इसे लिखा था।

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

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

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

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

यह मत भूलो कि मुझे योजना के दौरान काम के सभी चरणों में अच्छे आकार में रखने की आवश्यकता है। यदि मैं चार घंटे के काम पर कार्य का मूल्यांकन करता हूं, तो ग्राहक को दो कॉल करने के लिए स्वतंत्र महसूस करें। यह स्पष्ट है कि मैंने आलस्य के लिए समय की एक शर्त रखी है।

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

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

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

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

यदि आप मुझे प्रेरित करने के लिए नहीं जानते हैं ...

... परीक्षण के दौरान पाए जाने वाले हर बग का बहाना बनाते हैं।

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

लेकिन यहां मुख्य बात बहुत दूर नहीं जाना है। यदि आपको संदेह है कि मैं वास्तव में गड़बड़ कर रहा हूं, तो इसके विपरीत चुप रहने का प्रयास करें। अन्यथा, मुझे सभी चीजों की धोखाधड़ी (अपने काम की निरर्थकता सहित) की भावना कैसे मिलेगी?

हां, और मंत्र को भूल जाओ "सभी परियोजना कोड आम है", यह सच्चे लेखकों को नाराज करता है और निजी संपत्ति के अधिकार का उल्लंघन करता है।

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

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

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

सभी कर्मचारियों को शॉर्टकट सौंपें। आपके पास पेटीएम है, जो "हमेशा धीरे-धीरे काम करता है", और वास्या, जो "हमेशा प्रतिज्ञा करता है"। और मैक्सिम भी होना चाहिए जिसने यह "मॉड्यूल XXX" किया, और केवल वह वहां परिवर्तन कर सकता है। अन्यथा, नए कर्मचारी टीम को कैसे नेविगेट करेंगे?

अधिक बार आपको याद दिलाता है कि पेट्या धीमा है, सार्वजनिक रूप से पेट्या को डांटता है, ताकि हर कोई स्पष्ट रूप से समझे कि क्यों। याद रखें: कर्मचारी बदलते नहीं हैं और विकसित नहीं होते हैं - यह जांचने का कोई मतलब नहीं है कि क्या कंपनी में एक साल के काम के बाद उसी पेटी को ठीक किया जाता है या नहीं। यदि अचानक पेटीएम जल्दी से कार्य करता है, तो उसे ttete-à-tête की प्रशंसा करना बेहतर है। और फिर अचानक सहकर्मी भूल जाते हैं कि पेट्या अभी भी धीमी है? ठीक है, सामान्य तौर पर, सार्वजनिक रूप से डांट और पीएम में प्रशंसा।

टीम में एक पालतू जानवर ढूंढें और उसकी गरिमा की अधिक प्रशंसा करें, भले ही वह उसे सौंपे गए कार्यों में से आधे को भी पूरा न करे। उसे सबसे दिलचस्प कार्य करने दें। ऐसा "दाहिना हाथ" हर बॉस में होना चाहिए। लेकिन आप बिना समर्थन के नेतृत्व के पद पर कैसे रह सकते हैं?

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

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

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

यदि आप मुझे एक कार्य देना चाहते हैं ...

... TK को यथासंभव छोटा बनाएं। याद रखें: संक्षिप्तता प्रतिभा की बहन है, क्योंकि मैं आखिरी नींद से बचे हुए तीन लीटर कॉफी के आधार पर सभी विवरणों का अनुमान लगा सकता हूं। आदर्श शब्द: "सब कुछ ठीक होना चाहिए!"

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

टीके में, किसी भी स्थिति में ब्राउज़र या ऑपरेटिंग सिस्टम के सटीक संस्करण के बारे में जानकारी नहीं होनी चाहिए, उन दस्तावेज़ों के लिए कोई लिंक नहीं जिनमें कोई त्रुटि हुई।

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

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

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

मेरे लिए कोई भी कार्य अधिकतम नौकरशाही के साथ होना चाहिए। मुझे और कैसे यकीन होगा कि यह वास्तव में महत्वपूर्ण है?

निष्पादित कार्य पर रिपोर्टिंग यथासंभव विस्तृत होनी चाहिए। यदि मुझे कुछ समय के ट्रैकिंग सिस्टम (टीम और कॉर्पोरेट, उदाहरण के लिए) पर ध्यान नहीं देना है, तो मुझे लगेगा कि कोई भी मेरे प्रयासों की सराहना नहीं करता है। केवल जानकारी का दोहराव ही इसकी सुरक्षा के उचित स्तर को सुनिश्चित करेगा! यह वांछनीय है कि रिपोर्टिंग फॉर्म अलग है।

यह मानने योग्य है कि प्रति सप्ताह किए गए कार्यों की अवधि 40 घंटे से कम नहीं होनी चाहिए। हर चीज पर विचार करना सुनिश्चित करें, यहां तक कि 2 मिनट का ब्रेक भी। अगर इस समय कर्मचारी ने ट्रैकर को रोक नहीं दिया - अनुशासनात्मक कार्रवाई!

सप्ताह में कम से कम एक बार समय रिपोर्ट की जाँच करें, प्रत्येक पंक्ति का विश्लेषण करने के लिए एक सामान्य कॉल की व्यवस्था करें। और अंत में, एन्कोडर की औसत गति की गणना करें - हर कोई जानता है कि कार्य की अवधि कोड की पंक्तियों की संख्या के सीधे आनुपातिक है!

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

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

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

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

यदि आप एक रिलीज की योजना बना रहे हैं ...

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

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

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

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

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

यदि आप गलती से एक वरिष्ठ स्तर के विशेष ...

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

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

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

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

यदि आप प्रौद्योगिकी स्टैक को अपग्रेड करना चाहते हैं ...

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

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

यदि कोई डेवलपर आपके बैक के पीछे नई तकनीकों के बारे में कुछ सीखने की कोशिश कर रहा है, तो पालतू प्रोजेक्ट्स को विकसित करते हुए, अपने मुख्य कार्य को कठिन रूप से लोड करने का प्रयास करें। मैं तकनीकी दिशा में विकास कर रहा हूं ताकि आप बहुत सारे पैसे (और तेज) से दूर हो सकें।

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

यदि आप मुझे कार्यालय ले गए ...

... फर्नीचर पर अतिरिक्त पैसा खर्च न करें। मैं 500 रूबल के लिए एक कुर्सी पर बैठ सकता हूं। VHI है - फिर हम अपनी पीठ पीछे करेंगे।

और किसी भी क्षैतिज पट्टियों और ट्रेडमिल को कार्यालय में न रखें। और फिर डेवलपर्स उत्पादक धूम्रपान के बजाय धावक बन जाएंगे। क्या सही कोड है जब वे दिनों के लिए खत्म हो गया है?

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

यदि आपने मुझे दूरस्थ रूप से काम पर रखा है ...

... जितना संभव हो उतना कम मेरे साथ संपर्क करने की कोशिश करें! अन्य होमो सेपियन्स के साथ बात न करने के लिए दूरस्थ कार्य बनाया गया था।

वैसे, मैं उस टीम के उस हिस्से के साथ संवाद न करने के क्रम में udalenka के पास गया जो कार्यालय में बनी हुई थी। उन्हें धूम्रपान कक्ष में अपने डिजाइन निर्णय लेने दें और अधिमानतः मेरे बिना। मुझे इसमें क्यों भाग लेना चाहिए?

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

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

लेख लेखक: यूजीन वेटज़ेल ( @imater )

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

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

PPS हम अपने लेख कई Runet साइटों पर प्रकाशित करते हैं। वीके , एफबी , इंस्टाग्राम या टेलीग्राम चैनल पर हमारे सभी प्रकाशनों और अन्य मैक्सिलैक्ट समाचारों के बारे में जानने के लिए हमारे पेज की सदस्यता लें ।

नियोक्ता को बुरी सलाह। डेवलपर के साथ "ठीक से" बातचीत कैसे करें