← वापस WordPress विकास को आउटसोर्स करना: एजेंसियां क्या गलत करती हैं -- लाइन-आर्ट इलस्ट्रेशन

WordPress Dev को आउटसोर्स करना: एजेंसियां क्या गलत करती हैं

WordPress

2018 में मैंने एक WooCommerce project, करीब £22,000 की कीमत का काम, एक development partner को दिया जिसे मैंने Zoom call पर तकरीबन चालीस मिनट तक verify किया था। Portfolio अच्छा दिख रहा था। वह बातें अच्छे से करता था। तीन महीने बाद मैं क्लाइंट को refund दे रहा था और site को खुद एक brutal दो-हफ़्ते के sprint में rebuild कर रहा था। उस experience ने मुझे पैसे, नींद, और एक client relationship खर्च की, जिसके बारे में अभी भी बुरा लगता है।

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

तो हाँ। WordPress development को आउटसोर्स करने के बारे में मेरी राय है।

Seahawk के माध्यम से 5,000+ साइटें बनाने और उससे पहले Hackney के एक फ्लैट से फ्रीलांसर के रूप में काम करने के बाद, मैंने खराब तरीके से आउटसोर्स किया है और शानदार तरीके से भी। अंतर आमतौर पर उन निर्णयों तक सीमित होता है जो कोड की एक भी लाइन लिखने से पहले लिए जाते हैं।

---

एजेंसियां पहली जगह में WordPress काम को आउटसोर्स क्यों करती हैं

ईमानदारी से जवाब दें? मांग क्षमता से अधिक है। बस इतना ही।

2025 तक WordPress सभी वेबसाइटों के 43% से ज़्यादा को चलाता है। WordPress डेवलपमेंट का बाज़ार सिकुड़ नहीं रहा है। अगर आप किसी भी तरह की डिजिटल एजेंसी चला रहे हैं, छोटी ही सही, अकेले आदमी की ही सही, तो देर-सवेर आप ऐसी दीवार से टकराएँगे जहाँ क्लाइंट जो चाहता है, वह उतनी गुणवत्ता से जितनी वह डिज़र्व करता है, और तय समयसीमा में, आप खुद नहीं बना सकते।

आउटसोर्सिंग वह तरीका है जिससे आप हर बार जब कोई बड़ा प्रोजेक्ट आता है तो भर्ती का दौर शुरू किए बिना उस अंतराल को पाट सकते हैं।

लागत का तर्क भी है। लंदन में एक सीनियर WordPress डेवलपर को फ़ुल-टाइम स्टाफ़ पर रखने में आसानी से £50,000-£75,000 सालाना लगते हैं, और इसमें employer NI, बेनिफ़िट, बीमारी की छुट्टियाँ और वे महीने शामिल नहीं हैं जब पाइपलाइन पतली होती है और आप उन्हें अपनी डेस्क सजाने के पैसे दे रहे होते हैं।प्रोजेक्ट-आधारित या रिटेनर आउटसोर्सिंग में तीन महीने का काम £12,000-£36,000 में हो सकता है, जो उस फ़ुल-टाइम स्टाफ़ की सालाना लागत से काफ़ी कम है जिसकी आपको साल भर ज़रूरत शायद न हो।

लेकिन, और यह वह जगह है जहाँ ज्यादातर agency owners एक step skip करते हैं, सस्ता तभी मायने रखता है जब काम अच्छा हो। और काम तभी अच्छा होता है जब आप outsource करने से पहले groundwork कर चुके हों।

---

आपको क्या आउटसोर्स करना चाहिए (और क्या नहीं)

सब कुछ बाहरी भागीदार के हाथों में नहीं होता। मैंने यह धीरे-धीरे सीखा, ज्यादातर गलत तरीके से।

यहां वह है जो वास्तव में आउटसोर्स करने के लिए समझ में आता है:

  • E-commerce builds, WooCommerce, खासकर custom payment flows या complex product catalogues
  • Plugin development, custom functionality जिसे deep PHP knowledge की जरूरत हो
  • Migrations, 500-page sites को Drupal या old WordPress installs से move करना tedious और time-consuming होता है; इसे outsource करें
  • परफॉर्मेंस ऑप्टिमाइजेशन, Core Web Vitals का काम, सर्वर-लेवल कैशिंग, इमेज पाइपलाइन का सामान
  • Third-party integrations, CRMs, ERPs, booking systems, कुछ भी जिसमें API wrangling शामिल हो

मैं आउटसोर्सिंग के बारे में अधिक सावधान रहूंगा:

  • क्लाइंट-फेसिंग डिस्कवरी और strategy (वह आपका रिश्ता है, इसकी रक्षा करें)
  • कोई भी अस्पष्ट brief और कठिन deadline के साथ (यह संयोजन घातक है)
  • चल रहे support retainers जहां आपको वास्तव में क्या किया जा रहा है इसकी दृश्यमानता नहीं है

WP Umbrella की टीम ने सही कहा है: छोटे, कम जोखिम वाले, दोहराए जा सकने वाले कामों से शुरू करें। प्लगइन अपडेट, इमेज ऑप्टिमाइज़ेशन, मेटा विवरण। किसी बड़े प्रोजेक्ट की चाबी सौंपने से पहले पार्टनर को भरोसेमंद साबित करने दें।

यह वास्तव में अच्छी सलाह है और मैं चाहता हूं कि किसी ने मुझे 2018 में बताया होता।

---

एक WordPress विकास भागीदार की जांच करना

यह वह जगह है जहां अधिकांश एजेंसियां लापरवाही करती हैं, मेरी भी शुरुआती दिनों में।

बिक्री डेक नहीं, वास्तविक कार्य देखें

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

एक तैयार किए गए संदर्भ नहीं, अतीत के क्लाइंट से बात करें

संदर्भ (References) बेकार होते हैं। बिल्कुल, उनके पास दो लोग हैं जो अच्छी बातें कहेंगे। इसकी बजाय, कोई क्लाइंट खुद से ढूंढिए, LinkedIn के माध्यम से, उनके case studies के माध्यम से, जल्दी सर्च करके, और सीधे संपर्क करें। किसी अनचाहे पुराने क्लाइंट के साथ एक ईमानदार पाँच मिनट की बातचीत आपको एक घंटे की बिक्रय कॉल्स से कहीं ज़्यादा बताती है।

केवल उनके आउटपुट नहीं, उनकी प्रक्रिया की जांच करें

Rivulet IQ की खरीदार गाइड सुझाती है कि सीधे सवाल पूछें: वे QA कैसे संभालते हैं, हैंडऑफ़ कैसे तय करते हैं, और क्या वे version control का लगातार इस्तेमाल करते हैं। ये दिलचस्प सवाल नहीं हैं। पर यही मायने रखते हैं। जो पार्टनर अपनी QA प्रक्रिया सरल भाषा में नहीं समझा सकता, उसके पास कोई प्रक्रिया है ही नहीं।

"छोटा भुगतान परीक्षण" नियम

Seahawk ने इसे सालों से इस्तेमाल किया। एक बड़ा प्रोजेक्ट एक नए आउटसोर्सिंग पार्टनर के लिए करने से पहले, हमने उन्हें एक छोटे निर्धारित-दायरे वाली परीक्षा दी: एक विशिष्ट घटक का पुनर्निर्माण, एक कस्टम Gutenberg ब्लॉक लिखें, गति के लिए एक पृष्ठ का अनुकूलन करें। £300-£500। असली पैसे, असली डिलीवरेबल, असली समय सीमा। आप उस एक अभ्यास से सबकुछ जानने के लिए जरूरी होंगे।

---

Engagement को स्ट्रक्चर करना ताकि यह वास्तव में काम करे

एक खराब आउटसोर्सिंग रिश्ता आमतौर पर असफल नहीं होता क्योंकि developer अक्षम है। यह असफल होता है क्योंकि brief अस्पष्ट था, communication async और infrequent था, और किसी ने यह परिभाषित नहीं किया कि "done" का मतलब क्या है।

यहाँ है मैं अब engagements को कैसे structure करता हूँ:

  1. एक ठीक-ठाक स्कोप दस्तावेज़ लिखें। विशेषणों से भरी PDF नहीं। असली फ़ीचर सूची, पेजों की संख्या, इंटीग्रेशन, थर्ड-पार्टी सेवाएँ, ब्राउज़र सपोर्ट की ज़रूरतें। अगर आप इसे लिख नहीं सकते, तो आपको पता ही नहीं कि आप चाहते क्या हैं।
  2. Acceptance criteria को आगे से ही define करें। "Checkout को 4G connection पर 3 seconds में एक test transaction complete करना चाहिए", ये एक criterion है। "Site fast होना चाहिए" नहीं है।
  3. साप्ताहिक सिंक्स, कोई अपवाद नहीं। इसलिए नहीं कि आप उन पर भरोसा नहीं करते, बल्कि क्योंकि संदर्भ बदलता रहता है। हर हफ्ते तीस मिनट तीन सप्ताह का भटकाव रोकते हैं।
  4. डिलीवरेबल्स से जुड़ी चरणबद्ध भुगतान व्यवस्था। कभी भी 50% अग्रिम और 50% पूरा होने पर न दें। इसे कम से कम तीन माइलस्टोन्स में बाँटें। अगर छठे हफ्ते में कुछ गलत हो जाए, तो आपके पास लीवरेज होना चाहिए।
  5. Code आपका है, हमेशा। कुछ भी शुरू करने से पहले इसे writing में रखवा लें। Repository access, documentation, सब कुछ।

संचार विशेष रूप से महत्वपूर्ण है। मेरे पास 2021 में एक Seahawk fintech project था जहां हम दो सप्ताह तक अपने आउटसोर्स किए गए dev के साथ ठीक से चेक-इन नहीं कर सके क्योंकि सभी व्यस्त थे। जब हमने अंत में sync किया, तो उन्होंने account dashboard को गलत spec version के विरुद्ध बनाया था। पूरी तरह से ठीक करने योग्य था, लेकिन इसमें हमें चार दिन का rework खर्च हुआ। प्रति सप्ताह तीस मिनट इसे तीसरे दिन पकड़ लेता।

---

White Label बनाम Named Outsourcing

यह स्पष्ट करना महत्वपूर्ण है क्योंकि agencies इसे लेकर confuse हो जाती हैं।

White label outsourcing का मतलब है कि बाहरी पार्टनर आपके ब्रैंड के नीचे काम करता है। आपका क्लाइंट कभी नहीं जानता कि वह मौजूद है। कोड, संचार, deliverables, सब कुछ आपके ब्रैंड के तौर पर। यह तब अच्छी तरह काम करता है जब आपके पास मजबूत क्लाइंट रिश्ते हों और उन्हें सुरक्षित रखना चाहते हों।

Named outsourcing (या referred outsourcing) का मतलब है आप client के साथ transparent हैं: "हम इस तरह के development के लिए एक specialist team के साथ partner करते हैं।" कुछ clients को ये honesty अच्छी लगती है। कुछ को नहीं। अपने client को जानकर decide करें।

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

---

Cost Maths (अपने साथ ईमानदार रहें)

बहुत से agency owners outsourcing शुरू करते हैं क्योंकि सोचते हैं कि यह सस्ता होगा। कभी-कभी होता है। कभी-कभी नहीं। पूरी तरह से इस बात पर निर्भर करता है कि आप किससे तुलना कर रहे हैं।

इसे समझने का एक सामान्य तरीका यह है:

  • Outsourced project rate (अच्छा partner, UK या Eastern Europe): £800-£1,500/day equivalent
  • इन-हाउस mid-level डेवलपर (लंदन): £55,000-£65,000/साल ऑल-इन
  • Breakeven: लगभग 50-70 billed days per year in-house को justify करने के लिए

अगर आप साल में 70 दिन से ज़्यादा development काम consistently outsource कर रहे हैं, तो आपको शायद किसी को नियुक्त करना चाहिए। अगर यह project-by-project है और असंगत है, Q3 में बड़ी भीड़, Q1 में शांति, तो outsourcing ज़्यादा financial sense बनाता है।

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

---

चेतावनी के संकेत जहां से दूर चले जाएं

मैंने ये पैटर्न बार-बार देखे हैं। पैटर्न पर विश्वास करें।

  • वे आपको सीधा जवाब नहीं दे सकते कि वास्तव में काम कौन करेगा
  • उनकी timeline संदेहास्पद रूप से छोटी है (दो हफ्ते में एक जटिल WooCommerce बिल्ड, नहीं)।
  • उनकी प्रक्रिया में कहीं भी version control का उल्लेख नहीं है
  • वे तीन दिन से अधिक समय तक बिना किसी व्याख्या के चुप रहते हैं
  • वे staged payments या milestone-based contracts पर जोरदार आपत्ति करते हैं
  • पोर्टफोलियो सुंदर डिजाइन दिखाता है लेकिन कोई तकनीकी case study नहीं है

और ईमानदारी से? अगर आपका अंतर्ज्ञान पहली कॉल पर कुछ गलत कहता है, तो उसे सुनें। मैंने यह भावना दो बार नजरअंदाज की है। दोनों बार महंगी गलतियां थीं।

---

FAQ

क्या WordPress development को outsource करना वास्तव में in-house hiring से सस्ता है?

आमतौर पर हाँ, लेकिन यह बहुत अधिक निर्भर करता है कि आपके पास कितना काम है। inconsistent project volumes वाली agencies के लिए, outsourcing salary, employer NI, और benefits के fixed overhead से बचाता है। steady, high-volume development needs वाली agencies के लिए, outsourcing का per-day cost साल भर के समतुल्य in-house cost से ज़्यादा हो सकता है। अपनी specific situation के लिए मैथ करें, बजाय यह मान लें कि एक model हमेशा सस्ता हो।

फ्रीलांसर बनाम एजेंसी को आउटसोर्स करने में क्या अंतर है?

Freelancers आमतौर पर सस्ते और ज़्यादा flexible होते हैं, लेकिन आप एक व्यक्ति की उपलब्धता और क्षमता पर निर्भर होते हैं। Agencies एक टीम, processes, और redundancy लाती हैं, अगर कोई छुट्टी पर जाए या बीमार पड़े, काम चलता रहता है। छोटे, सीमित कामों के लिए, एक freelancer अक्सर बेहतर विकल्प है। लंबे engagements या कुछ भी mission-critical के लिए, एक छोटी specialist agency कम risk है।

आउटसोर्सिंग करते समय मैं क्लाइंट गोपनीयता को कैसे संभालूं?

बाहरी पार्टनर के साथ कोई भी क्लाइंट जानकारी साझा करने से पहले हमेशा NDA रखें। यह specify करें कि क्या शामिल है: क्लाइंट नाम, briefs, design assets, business data। अधिकांश professional outsourcing पार्टनर के पास एक standard NDA तैयार होगा, लेकिन पढ़ें, उनका बस sign न करें। अगर project value यह warrant करे तो अपने solicitor को देखने दें।

कौन से प्रकार की WordPress परियोजनाएं आउटसोर्सिंग के लिए सबसे उपयुक्त हैं?

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

जब मैं खुद विकास नहीं कर रहा हूं तो मैं गुणवत्ता नियंत्रण को कैसे बनाए रखूं?

brief में acceptance criteria define करें। हर milestone पर code review करें, सिर्फ अंत में नहीं। Staging environments का उपयोग करें और sign-off से पहले thoroughly test करें। अगर आपके पास code directly review करने की technical chops नहीं हैं, तो एक freelance QA consultant को एक दिन के लिए नियुक्त करें, यह लागत के लायक है। और हमेशा, हमेशा एक proper handover रखें: documentation, repository access, deployment notes। आपको engagement खत्म होने के बाद साइट को maintain करने में सक्षम होना चाहिए।

---

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

उन्हें गलत समझो और तुम्हें क्लाइंट्स को रिफंड करना होगा और सप्ताहांत की नींद उड़ाकर साइट्स को फिर से बनाना होगा। मुझसे पूछो कि मुझे कैसे पता है।

संबंधित पढ़ाई: Drupal से WordPress माइग्रेशन: 5,000 साइटों का SEO प्लेबुक, WordPress सपोर्ट, और साइट माइग्रेशन।

← वापस