💆🏾 😧 🎌 डेवलपर को बुरी सलाह: प्रबंधन को "कृपया" करने के लिए क्या करना चाहिए 🖖🏿 📏 🙇🏾

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

(ग्रिगोरी ओस्टर)

आइए इस बारे में बात करते हैं कि कौन से डेवलपर्स के सपने देखते हैं। इस बार मैं एक अमूर्त प्रबंधक के रूप में काम करूंगा ...

किसी भी प्रोजेक्ट की शुरुआत में ...

क्या आप जानते हैं कि एक प्रबंधक का उच्चतम कौशल न्यूनतम प्रारंभिक जानकारी के साथ निर्णय लेना है। हमें, नेताओं को, इस कौशल को प्रशिक्षित करने से मत रोकिए। इन युक्तियों का पालन करें:

धूमिल तारीखों को नाम दें, बल्कि उनके बारे में बिल्कुल भी बात न करें।
जब हम पूछते हैं कि क्या प्रस्तावित सुधार मौजूदा मॉड्यूल को नहीं तोड़ेंगे, तो चुटकी में चुप हो जाएं, एक रहस्यमय चेहरे की अभिव्यक्ति करें!
परियोजना की आगामी समस्याओं के बारे में बात करते हुए, कभी भी अपने समाधान की पेशकश न करें, याद रखें, हमें लोगों-प्रश्नों की आवश्यकता है, न कि लोगों के विकल्प-समाधानों की।
— , , ? 48- , 10 , .
— , .

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

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

परियोजना के भीतर कौन से विशिष्ट कार्य हल किए जाएंगे, हमें कभी नहीं बताएं। केवल समाधान के तरीकों के बारे में बात करें। और यह सभी विवरणों में वांछनीय है - आज रात को सीटीओ शांति से कैसे सोएगा?

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

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

बिल्कुल सही कोड ...

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

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

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

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

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

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

परियोजना में आदेश ...

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

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

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

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

समस्या को सुलझाना ...

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

किसी समस्या को हल करते समय क्रियाओं का सही क्रम:

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

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

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

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

और कार्य के छोटे हिस्से पर किसी भी परिकल्पना का परीक्षण न करें, अन्यथा आपके सहकर्मियों को लगेगा कि आप संदेह में हैं!

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

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

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

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

परियोजना पर संचार ...

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

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

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

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

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

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

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

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

परियोजना के अंत की ओर ...

जब हम आपसे ग्राहक को प्रोजेक्ट दिखाने के लिए कहते हैं, तो किसी भी स्थिति में पहले से प्रदर्शन के लिए तैयार न हों। यह सभी के लिए स्पष्ट है: यदि प्रोजेक्ट आपके लैपटॉप पर शुरू हुआ है, तो इसका मतलब है कि यह 100% काम कर रहा है और कहीं भी शुरू होगा। हम सब भाग्यशाली हैं!

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

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

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

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

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

समस्या के एक पक्ष के बारे में सभी को बताएं। अपने "कारनामों" के बारे में चुप रहें, हमें बताएं कि कौन से प्रबंधक अनुचित हैं। हमें समझने की कोशिश मत करो, बाहरी लोगों को बताओ। NDA कायरों के साथ आया!

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

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

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

लेख लेखक: यूजीन वेत्सेल (imater)

पीएस पिछली बार की तरह , मेरी कहानी में वास्तविकता के साथ केवल भूतिया संयोग है। और नैतिक यह है: चलो टीम में रिश्तों के निर्माण, इस सारे व्यंग्य को ध्यान में रखते हैं।

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