फ्रीलांसर स्कोप क्रीप समस्या को कैसे ठीक करें

फ्रीलांसर स्कोप क्रीप समस्या को कैसे ठीक करें

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

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

1. प्रारंभिक चेतावनी संकेतों को पहचानें

बार-बार “छोटे” अतिरिक्त की तलाश करें। एक अतिरिक्त बैनर सामान्य है। तीन अतिरिक्त बैनर, सोशल मीडिया के लिए एक नया संस्करण, और ईमेल के लिए एक अलग प्रारूप एक ही काम नहीं हैं। यह पहला संकेत है।

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

लोगों द्वारा उपयोग किए जाने वाले शब्दों पर ध्यान दें। “जब आप वहाँ हैं,” “क्या हम बस जोड़ सकते हैं,” और “यह आसान होना चाहिए” क्लासिक संकेत हैं। ये हानिरहित लगते हैं। जब ये हर थ्रेड में प्रकट होते हैं तो ये हानिरहित नहीं होते।

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

यहाँ एक सरल परीक्षण है: यदि अनुरोध समय, उपकरण, या डिलीवरबल्स को बदलता है, तो इसे एक स्कोप परिवर्तन के रूप में मानें। यदि यह केवल मूल कार्य के बारे में भ्रम को स्पष्ट करता है, तो यह अभी भी काम के अंदर हो सकता है। उस रेखा को स्पष्ट रखें।

2. मूल समझौते को फिर से पढ़ें

पहले हस्ताक्षरित ब्रीफ खोलें। फिर संदेश इतिहास खोलें। फिर डिलीवरबल्स सूची खोलें। ये तीन दस्तावेज आमतौर पर दिखाते हैं कि प्रोजेक्ट कहाँ से भटका, और यह स्मृति से बेहतर करते हैं।

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

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

मूड्स नहीं, डिलीवरबल्स की जांच करें। एक क्लाइंट महसूस कर सकता है कि प्रोजेक्ट “लगभग पूरा” है, लेकिन हस्ताक्षरित सूची में अभी भी दो गायब आइटम हो सकते हैं। यह अंतर महत्वपूर्ण है। भावनाएँ प्रोजेक्ट को बंद नहीं करतीं; पूर्ण डिलीवरबल्स करती हैं।

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

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

3. अतिरिक्त क्या है और क्या अभी भी शामिल है, इसे वर्गीकृत करें

हर नए अनुरोध को तीन बकेट में डालें। पहला: पहले से सहमति वाला कार्य। दूसरा: उचित स्पष्टीकरण। तीसरा: वास्तविक दायरे से बाहर के ऐड-ऑन। यह बातचीत को विशिष्ट रखता है।

पहले से सहमति वाला कार्य आसान है। यदि संक्षिप्त में "दो संपादन के दौर" शामिल हैं, तो दूसरा दौर शामिल है। यदि ग्राहक दूसरे दौर के लिए पूछता है, तो कोई समस्या नहीं। यह दायरे का विस्तार नहीं है।

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

वास्तविक दायरे से बाहर के ऐड-ऑन अलग होते हैं। एक ब्रोशर डिज़ाइन परियोजना जिसे अब ब्रांड रणनीति, कॉपीराइटिंग, और प्रिंट विक्रेता समन्वय की आवश्यकता है, अब केवल डिज़ाइन का काम नहीं है। इसे ठीक से लिखें। शब्द महत्वपूर्ण हैं।

एक छोटा टेबल कमरे को शांत रखने में मदद कर सकता है:

भाषा को सरल रखें। जब आप कहना चाहते हैं “यह एक कठिन अनुरोध है” तो ऐसा न कहें, बल्कि कहें “यह एक नया कार्य है।” भावनात्मक शब्दावली बहस को आमंत्रित करती है। स्पष्ट श्रेणियाँ निर्णय लेने को आमंत्रित करती हैं।

4. परियोजना को लिखित में रीसेट करें

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

इस संरचना का प्रयास करें: “हमने X, Y, और Z पर सहमति दी। मैं अगली बार उन वस्तुओं को पूरा करूंगा। A के लिए नया अनुरोध वर्तमान दायरे के बाहर है और इसे अलग से उद्धृत किया जा सकता है।” इस तरह का नोट भ्रम को कम करता है बिना नाटकीय लगे।

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

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

यदि परियोजना पहले से ही कई दिनों से अव्यवस्थित है, तो बताएं कि क्या अभी भी सक्रिय है और क्या रुका हुआ है। “हम स्वीकृत होमपेज और दो संशोधनों के साथ आगे बढ़ रहे हैं। अतिरिक्त चेकआउट प्रवाह अनुरोध तब तक रुका हुआ है जब तक हम दायरे पर सहमत नहीं होते।” वह एक पैराग्राफ एक और सप्ताह के भ्रम को रोक सकता है।

उन टीमों के लिए जो सीमाओं को बार-बार पार कर रही हैं, 24freelance.pro साइट के नियम। फ्रीलांस भी एक उपयोगी अनुस्मारक हो सकता है कि स्पष्ट शर्तें कोई विलासिता नहीं हैं। वे कार्यस्थल हैं।

5. समय, लागत, और समय सीमा के प्रभाव का पुनः अनुमान लगाएं

जब एक नया अनुरोध वास्तविक हो जाए, तो इसे समय, लागत, और समय सीमा के प्रभाव में अनुवादित करें। ग्राहक शिकायतों की तुलना में व्यापार के समझौते को तेजी से समझते हैं। यदि कुछ 6 घंटे जोड़ता है, तो 6 घंटे कहें। यदि यह डिलीवरी को 2 दिन पीछे धकेलता है, तो 2 दिन कहें।

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

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

एक स्पष्ट पुनः अनुमान भी ग्राहक की रक्षा करता है। वे गति, लागत, और अतिरिक्त दायरे के बीच चयन कर सकते हैं। वे बिना किसी व्यापार के समझौते के तीनों rarely प्राप्त करते हैं। कोई भी परियोजना ऐसा नहीं करती।

कभी-कभी सबसे अच्छा उत्तर काम को विभाजित करना होता है। मौजूदा कार्य को अब पूरा करें। अतिरिक्त अनुरोध को एक बाद के चरण के लिए उद्धृत करें। इससे वर्तमान समय सीमा बरकरार रहती है और नया अनुरोध मौजूदा काम को हाइजैक करने से रोकता है।

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

6. आगे बढ़ने के लिए एक परिवर्तन-अनुरोध प्रक्रिया का उपयोग करें

इस बिंदु से, एक सरल नियम का पालन करें: नया अनुरोध, प्रभाव समीक्षा, लिखित स्वीकृति, निष्पादन। चार चरण। कोई शॉर्टकट नहीं। यह प्रक्रिया अनौपचारिक बातचीत के दौरान दायरे में बदलाव को रोकती है।

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

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

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

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

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

7. अगले प्रोजेक्ट को समस्या को दोहराने से बचाएं

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

मील का पत्थर चेकपॉइंट शामिल करें। हर 1 या 2 चरणों में एक चेकपॉइंट दोनों पक्षों को दिशा की पुष्टि करने का स्थान देता है इससे पहले कि काम बढ़ने लगे। बिना चेकपॉइंट के, स्कोप क्रीप प्रोजेक्ट के आधे रास्ते में यात्रा कर सकता है इससे पहले कि कोई इसे नोटिस करे।

कार्य समझौते में “क्या शामिल नहीं है” अनुभाग जोड़ें। यह एक अनुभाग समय बचाता है क्योंकि यह सवालों के जवाब देता है इससे पहले कि वे तर्क बन जाएं। एक ब्रोशर पैकेज प्रिंट प्रबंधन को बाहर कर सकता है। एक सामग्री प्रोजेक्ट CMS अपलोड को बाहर कर सकता है। एक विकास कार्य कॉपीराइटिंग को बाहर कर सकता है। इसे स्पष्ट करें।

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

संशोधन सीमाओं के बारे में एक लाइन लिखना, प्रतिक्रिया समय के बारे में एक लाइन लिखना, और अंतिम काम को कौन मंजूरी देता है इसके बारे में एक लाइन लिखना भी मदद करता है। छोटे विवरण बाद में बड़े सिरदर्द को रोकते हैं। यह सिद्धांत नहीं है। यह इस तरह है कि प्रोजेक्ट प्रबंधनीय रहते हैं जब सभी व्यस्त हो जाते हैं।

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

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