जब एक फ्रीलांसर एक मील का पत्थर चूकता है तो क्या करें

क्या यह एक मील का पत्थर समस्या है, या एक दायरा समस्या?

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

एक मील का पत्थर को एक चेकपॉइंट के रूप में सोचें जिसमें एक स्पष्ट समाप्ति रेखा हो। यदि मील का पत्थर था “शुक्रवार तक होमपेज मॉकअप डिलीवर करें,” तो यह विशिष्ट है। यदि यह था “होमपेज को अधिक प्रीमियम महसूस कराएं,” तो यह एक मील का पत्थर नहीं है; यह एक चलती हुई लक्ष्य है। एक मापने योग्य है। दूसरा एक बातचीत है जो होने का इंतजार कर रही है।

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

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

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

आपको प्रतिक्रिया देने से पहले कार्य पैकेज में क्या जांचना चाहिए?

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

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

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

छिपे हुए पूर्वधारणाओं की जांच करें। क्या फ्रीलांसर को 3 ब्राउज़रों में परीक्षण करना था? क्या 2 संशोधनों के दौर शामिल थे, या 5? क्या मील का पत्थर एक खुरदरे मसौदे के लिए था या अंतिम डिलीवरी के लिए? कार्य पैकेज में एक वाक्य पूरे चित्र को बदल सकता है। यदि पैकेज पतला है, तो समस्या केवल चूके हुए मील के पत्थर की नहीं है; यह वह प्रक्रिया है जिसने अस्पष्टता की अनुमति दी।

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

अनुबंध स्वच्छता के लिए, कई टीमें भी नियमों पर नज़र रखती हैं 24freelance.pro साइट के नियम। फ्रीलांस। एक स्पष्ट प्लेटफ़ॉर्म नियम एक लंबे तर्क की तुलना में एक प्रश्न को तेजी से हल कर सकता है, विशेष रूप से जब एक मील का पत्थर एक बड़े डिलीवरबल्स की श्रृंखला के भीतर होता है।

आप बिना परियोजना को संकट में बदले देरी प्रबंधन को कैसे संभालते हैं?

अच्छा देरी प्रबंधन वर्गीकरण से शुरू होता है। क्या देरी छोटी, मध्यम, या परियोजना के लिए खतरा है? एक कम जोखिम वाले कार्य पर 1-दिन की चूक एक लॉन्च निर्भरता पर 1-सप्ताह की देरी के समान नहीं है। यदि सब कुछ तत्काल के रूप में माना जाता है, तो कुछ भी उपयोगी नहीं रहता।

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

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

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

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

जब मील का पत्थर देर से हो लेकिन फ्रीलांसर अभी भी काम कर रहा हो, तो आपको क्या कहना चाहिए?

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

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

यदि आप थोड़ी अधिक संरचना चाहते हैं, तो संख्या वाले प्रश्नों का उपयोग करें। 1) क्या पूरा हुआ? 2) क्या अभी भी लंबित है? 3) पिछले चेक-इन के बाद क्या बदला? 4) आज आप मुझसे क्या चाहते हैं? यह प्रारूप काम करता है क्योंकि यह उत्तर को संकीर्ण करता है। “यह क्यों देर हो रहा है?” जैसी व्यापक शिकायत आमतौर पर एक व्यापक बहाना उत्पन्न करती है।

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

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

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

पुनः-स्कोपिंग कार्य कब सही अगला कदम है?

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

एक विकल्प है कि डिलीवर करने योग्य को संकीर्ण किया जाए। पूर्ण लैंडिंग पृष्ठ की मांग करने के बजाय, पहले हीरो सेक्शन और कॉल टू एक्शन के लिए पूछें। पूर्ण ऐप मॉड्यूल के बजाय, केवल प्राथमिक कार्यप्रवाह के लिए पूछें। यह मानकों को कम करना नहीं है। यह पूर्णता की सही इकाई का चयन करना है।

एक और विकल्प है कि मील का पत्थर छोटे भागों में विभाजित किया जाए। एक कार्य जो 1 आइटम की तरह दिखता है वास्तव में 4 टुकड़े हो सकता है। यदि फ्रीलांसर इस सप्ताह 2 और अगले सप्ताह 2 समाप्त कर सकता है, तो आपको जल्दी उपयोगी प्रगति मिलती है। छोटे टुकड़े समस्याओं को जल्दी उजागर करते हैं, जो अंत में सभी को खोजने से स्वस्थ है।

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

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

आप अगले मील के पत्थर के लिए अपेक्षाओं को कैसे रीसेट करते हैं?

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

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

स्वामी जिम्मेदारियों को स्पष्ट रूप से सौंपें। कौन संपत्तियाँ भेजता है? कौन अनुमोदन करता है? कौन 24 घंटे के भीतर फीडबैक देता है? यदि ये भूमिकाएँ स्पष्ट नहीं हैं, तो अगला मील का पत्थर वही देरी विरासत में लेगा। लोग समय के दबाव में अच्छी तरह से अनुमान नहीं लगाते।

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

यह भी बताने का स्थान है कि अगला मीलस्टोन क्यों महत्वपूर्ण है। यदि फ्रीलांसर जानता है कि एक कार्य समीक्षा, लॉन्च, या किसी अन्य ठेकेदार के काम को अनलॉक करता है, तो अनुक्रम स्पष्ट हो जाता है। यह दृश्यता सभी को बेहतर निर्णय लेने में मदद करती है।

आपको क्या दस्तावेज़ करना चाहिए ताकि परियोजना नियंत्रित रहे?

रिकॉर्ड को संक्षिप्त लेकिन पूर्ण रखें। संशोधित लक्ष्य तिथि, कोई संशोधित दायरा, सहमत अवरोधक, और अद्यतन वितरण आदेश लिखें। ये 4 आइटम परियोजना को नियंत्रित रखने के लिए पर्याप्त हैं बिना इसे प्रशासन में डूबोए।

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

निर्णय को दस्तावेज़ करें, न कि नाटक को। “हीरो सेक्शन को गुरुवार को स्थानांतरित किया गया; प्रशंसापत्र चरण 2 में स्थानांतरित किए गए; ग्राहक से कॉपी लंबित” उपयोगी है। “यह एक गड़बड़ रहा है” नहीं है। पहली पंक्ति टीम की मदद करती है। दूसरी केवल भड़ास निकालती है।

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

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

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