- independent developer या creator के लिए सबसे कठिन चुनौती यह तय करना है कि नियमित salary बंद होने के बाद पैसे कैसे लिए जाएँ, कितना charge किया जाए, और उसके अनुरूप value कैसे बनाई जाए
- Fixed-price contract ग्राहक को और ज्यादा deliverables मांगने के लिए, और consultant को सिर्फ approval पाने लायक minimum काम करने के लिए incentivize करता है
- Hourly billing, realistic estimated hours के आधार पर ग्राहक को cost control देता है, और अगर शुरुआत में value न दिखे तो जल्दी काम खत्म करने देता है
- Price हर acceptance के बाद थोड़ा-थोड़ा बढ़ाकर वह बिंदु खोजें जहाँ acceptance rate लगभग 50% तक गिर जाए; discounts से अतिरिक्त दबाव बढ़ सकता है, इसलिए उनसे बचना बेहतर है
- अक्सर ग्राहक सस्ते विकल्पों या अनसुनी सलाह की कीमत चुकाने के बाद ही consultant की value समझते हैं, इसलिए जितनी ज्यादा पैसों की जल्दी हो, उतना ही unsuitable काम को मना करना चाहिए
Independent काम में पैसे कब मुश्किल बन जाते हैं
- नौकरी छोड़कर independent होने पर freedom मिलती है, लेकिन नियमित आती salary भी साथ ही खत्म हो जाती है
- नए independent developer या creator के लिए पैसा तुरंत एक practical समस्या बन जाता है
- लोगों से पैसे कैसे लिए जाएँ
- कितना charge किया जाए
- charge की गई रकम के अनुरूप value कैसे दी जाए
- Fixed-price contract में पहले हुई failures के अनुभव के आधार पर, independent consulting में pricing और customer selection को मुख्य विषय के रूप में देखा गया है
Fixed-price contract जो खराब incentives बनाता है
- Fixed-price contract ग्राहक और consultant दोनों के लिए खराब structure की तरह काम करता है
- ग्राहक के पास संभवतः सबसे कम price पर सहमति बनाने के बाद, उसी रकम में जितना हो सके उतना ज्यादा काम मांगने का incentive होता है
- इसके उलट consultant को customer approval पाने के लिए जरूरी सबसे तेज और सस्ता काम करने की ओर धकेला जाता है
- approval के बाद आने वाली problems ठीक करने की motivation भी लगभग खत्म हो जाती है
- बेहतर तरीका है fair hourly rate पर काम करना, और requested deliverables के लिए आवश्यक समय का careful और realistic estimate लगाना
- ग्राहक पूरी रकम तुरंत fix किए बिना भी cost control रख सकता है
- consultant के पास शुरुआत से ही ग्राहक को value देने का मजबूत incentive होता है
- अगर ग्राहक एक-दो दिन बाद तय करे कि यह fit नहीं है, तो वह तब तक का खर्च देकर relationship खत्म कर सकता है
- काम खत्म होने के बाद अगर additional changes या improvements चाहिए हों, तो free में खिंचते न जाएँ; अलग estimate और cost decision के जरिए “just one more thing” वाली situation रोकनी चाहिए
Repeat business बनाने वाला consultant लंबे समय तक टिकता है
- कुछ कंपनियों को चिंता होती है कि hourly billing consultant को कामचोरी की ओर ले जाएगी
- बेईमान consultant समस्याएँ और delays पैदा करके समय बढ़ा सकता है
- ऐसे में ग्राहक को इसे पहचानकर relationship खत्म करना चाहिए
- long term में यह successful strategy नहीं है
- Consultants को poacher और farmer में बाँटकर देखा जा सकता है
- poacher वह है जो जल्दी profit निकालकर चला जाता है
- farmer long-term relationship की देखभाल करता है और ग्राहकों को बनाए रखता है ताकि अगले साल भी फिर revenue मिल सके
- नए customers लगातार ढूँढना कठिन और महँगा है, और meetings, proposals, estimates पर समय लगाने के बावजूद लगभग आधे cases close नहीं हो सकते
- Existing customers को न खोना बेहतर है, और reputation आखिरकार फैलती ही है
- Repeat business सबसे अच्छा business इसलिए बनता है क्योंकि marketing मुश्किल है
- समय के साथ services की सक्रिय marketing किए बिना भी लोग आने लगते हैं
- उस point को यह संकेत माना जा सकता है कि आप सही तरीके से काम कर रहे हैं
Price कम से शुरू करने के बजाय ऊँचा validate करना चाहिए
- Pricing पर सबसे अच्छी सलाह है: “एक number सोचें और उसे double कर दें”
- Rate बताते समय अगर आपको थोड़ा संकोच नहीं हो रहा है, तो संभव है कि आप बहुत कम बोल रहे हों
- अगर हमेशा acceptance मिल रही है, तो price निश्चित रूप से बहुत कम है
- Independent काम की शुरुआत में विनम्रता और काम जीतने की इच्छा के कारण खुद को underprice करना आसान है
- कंपनियाँ महंगे consultants को पैसा देना अक्सर सकारात्मक रूप से देखती हैं
- इसे Chivas Regal effect के रूप में देखा जा सकता है
- यह analogy है कि सस्ती whisky खराब लगेगी, और 60 डॉलर वाली whisky अच्छी quality की लगेगी
- Manager ऐसी problem के लिए consultant hire करता है जिसे वह solve नहीं कर पा रहा, और problem जितनी महंगी हो, department उतना ज्यादा महत्वपूर्ण दिख सकता है
- High price ग्राहक को यह reassurance देता है कि “हमने top-tier expert को काम सौंपा है”
- हालांकि, यह structure तभी बना रहता है जब आप सच में अच्छा काम करें
- महंगा charge करने पर customer सलाह को ज्यादा valuable मानने और उसे बेहतर तरीके से सुनने की संभावना बढ़ती है
- Jerry Weinberg की Secrets of Consulting में सलाह है: “उन्हें इतना पैसा देने दें कि वे आपकी कही बात करें”
Discount न दें, और ऐसे customer का इंतजार करें जो सलाह सुनने के लिए तैयार हो
- सही price खोजने का तरीका है: जब भी customer price accept करे, अगली बार थोड़ा और बढ़ाएँ
- जब लोग complain या reject करना शुरू करें, तो आप उचित range के करीब पहुँच रहे होते हैं
- Acceptance rate लगभग 50% तक गिर जाए, तो आमतौर पर level सही होता है
- जितने ज्यादा customers के साथ consultant काम करता है, उतना ही ज्यादा सीखता है, बेहतर consultant बनता है, और ज्यादा charge कर सकता है
- Price समय के साथ लगातार बढ़ना चाहिए, लेकिन हमेशा दी जा रही value से मेल खाना चाहिए
- Negotiation दूसरी शर्तों पर हो सकती है, लेकिन price negotiation न करना बेहतर है
- Discount request को यह signal माना जा सकता है कि “मुझे नहीं लगता आप जितनी मांग रहे हैं उतनी value रखते हैं”
- Discount देने पर additional demands, short deadlines, office hours के बाहर support जैसे दूसरे दबाव भी आ सकते हैं
- Jerry Weinberg की सलाह की तरह, “अगर आपको पैसों की जरूरत है, तो वह काम न लें” core principle है
- Customer आपकी expertise वाला domain नहीं जानता, इसलिए fair price भी नहीं जानता हो सकता
- अगर वह high rate सुनकर deal छोड़ता है, तो आपने ऐसे customer से बचाव कर लिया जिसे value की समझ नहीं है
- एक customer ने कहा कि लेखक का rate उनकी expectation से बहुत ज्यादा है और Eastern Europe का कोई दूसरा व्यक्ति उसी काम को उस price के 20% में कर देगा; लेखक ने जवाब दिया कि उन्हें उसी व्यक्ति को hire करना चाहिए
- कुछ महीनों बाद customer ने वापस संपर्क किया और कहा कि अब वह समझता है कि वह विकल्प सस्ता क्यों था
- इसके बाद original quoted rate पर लंबा और rewarding contract बना
- Customer consultant की सलाह सुनकर भी पैसे, politics या अन्य कारणों से अलग decision ले सकता है
- कभी-कभी customer सलाह स्वीकार करने के लिए तैयार नहीं होता
- Bitfield के consulting के पहले नियम “ग्राहक को सलाह न मानने का दर्द महसूस करना पड़ता है, तभी वह सलाह स्वीकार करने के लिए तैयार होता है” पर यही बात लागू होती है
1 टिप्पणियां
Hacker News की रायें
hiring करने वाले के नज़रिए से, भले ही किसी के नई technology सीखने का खर्च उठाना पड़े, वे हमेशा full-time team बनाने को तरजीह देते हैं
consultants जिस बात को अक्सर नहीं बताते, वह यह है कि आखिर उन्हें भी हमारे code और company को सीखने में समय लगता है, और उसका भी खर्च होता है। कोई भी ऐसा नहीं होता जिसे तुरंत लगा दें और वह फौरन value देने लगे, इसलिए onboarding time, internal employees द्वारा consultants को train करने का समय वगैरह सबका भुगतान करना पड़ता है
engineer के नज़रिए से भी सबसे दिलचस्प projects और companies आम तौर पर full-time कर्मचारियों के इर्द-गिर्द चलती हैं, इसलिए अगर दिलचस्प काम करना हो तो full-time काम करना चाहूंगा
उदाहरण के लिए, SOC2 compliance में मदद करने वाले कई consultants का काम अक्सर recommendations से भरे बड़े document को copy-paste करना और team interviews के हिसाब से paragraphs को थोड़ा इधर-उधर करना भर होता है
यह estate planning या will में मदद करने वाले सामान्य lawyer से बहुत अलग नहीं है। व्यवहार में कई कामों के लिए सबसे सस्ता lawyer लेना ही सही होता है, और अगर project सरल और दोहराव वाला है तो ज्यादा पैसे देना उन लोगों का काम है जिन्हें ठीक से समझ नहीं है। murder trial हो तो महंगा lawyer रखेंगे, लेकिन छोटे काम के लिए इसकी जरूरत नहीं, इसलिए वह analogy समझ में नहीं आती
आखिर में, consulting समय के मुकाबले cash flow के लिए अच्छी हो सकती है, लेकिन यह अस्पष्ट है कि क्या यह income के दूसरे forms की तुलना में आपको ज्यादा अमीर बनाती है। अमीर employees या founders तो देखे हैं, लेकिन अमीर independent consultants बहुत कम देखे
फिर भी कुछ संक्षिप्त examples दूं तो, एक executive machine learning इस्तेमाल करना चाहता था, लेकिन full-time team बनाने के लिए political capital भी कम था और candidates का interview लेने का knowledge भी नहीं था। निजी भरोसे के network से मिली एक छोटी consulting company ने MVP बनाया, और उसके परिणामस्वरूप full-time team बनी। code खराब था, लेकिन उसने virtuous cycle शुरू कर दिया, और कुछ साल बाद सबको लगा कि return on investment अच्छा रहा
एक और बड़ी company में एक छोटी team थी जो ऐसी technology इस्तेमाल कर रही थी जो FAANG में standard मानी जाती, लेकिन support या training बिल्कुल नहीं थी, इसलिए लगभग एक साल तक कोई progress नहीं हुई। इतना important नहीं था कि बहुत पैसा लगाया जाए, लेकिन core product का bottleneck बन गया तो consultant कुछ हफ्तों के educator के तौर पर आया। team आखिरकार speed नहीं पकड़ पाई, consultant के code examples धीरे-धीरे सीधे bug fixes बन गए, और कोई भी खुश नहीं था, लेकिन crisis हल हो गया
product को आखिरकार product-market fit मिलने के बाद, management ने तभी hiring करने का फैसला किया जब team technical debt से दब चुकी थी, और तब भी वह full-time junior ही होना था। इसमें कई महीने लगे और फिर training की जरूरत पड़ी, और जब तक नया hire net value देने लगा, technical debt मूल crisis level का दोगुना हो चुका था। अजीब तरह से, वह ठीक 2 साल बाद चला गया
कई consultants के सामने branding problem होती है। उनकी सबसे बड़ी जीत अक्सर ऐसे disaster को ठीक करना होती है जिसके बारे में client company public में बात नहीं करना चाहती। अगर उसी client से दोबारा काम पाना है, तो उसे billboard पर डालना मुश्किल है
इसके अलावा contractor के रूप में काम करने से internal politics से कुछ दूरी बनी रहती है। आम तौर पर internal employees business को अच्छी तरह समझते थे, लेकिन इस्तेमाल हो रही technology में कमजोर थे, और जितनी भी training दी जाए, यह बहुत नहीं सुधरता था
एकमात्र नुकसान travel था, इसलिए कामों के बीच के gap का इस्तेमाल करके मैंने अपना product develop करने की दिशा में pivot कर लिया
consulting बताए गए कारणों और दूसरे कारणों से बहुत कठिन है, लेकिन कुछ regions में employee के रूप में काम करने की तुलना में इसका ceiling बहुत ज्यादा होता है
कई कामों में मैंने निश्चित रूप से पहले दिन से contribute किया है
“अमीर employees या founders देखे हैं, लेकिन independent consultants बहुत कम देखे” यह भी market और ‘अमीर’ के मतलब पर निर्भर कर सकता है। consultants को stock मिलना दुर्लभ है, लेकिन वे अक्सर employees से कहीं बेहतर outcomes पा लेते हैं। ‘अमीर’ के करीब पहुंचे employees मैंने बहुत कम देखे हैं, लेकिन उदाहरण के लिए London के consultants काफी संपन्न हो सकते हैं
नतीजा यह हुआ कि internal DevOps/SRE team को पता ही नहीं था कि infrastructure के कुछ हिस्से कैसे काम करते हैं, और जब change की जरूरत होती थी तो शुरुआत इस लंबे phase से करनी पड़ती थी कि consultant ने क्या और कैसे बनाया था। बेशक manager extra time cost नहीं देना चाहता था
जब developers के साथ problem solve करनी होती थी, तो DevOps/SRE को messenger बनना पड़ता था, और जो काम 2 घंटे से 2 दिन में खत्म हो सकता था, वह अधिकतम 2 हफ्ते तक लग जाता था
यह बहुत frustrate करने वाला था और आखिरकार मेरे सहित कुछ लोग company छोड़कर चले गए
जरूरत पड़ने पर जरूरी knowledge लाने वाले व्यक्ति के रूप में consultant की value मुझे अब भी दिखती है। लेकिन अगर उन्हें कोई ऐसी चीज सौंपी जा रही है जो लंबे समय तक चलनी है, तो manager को consultant के काम करने के दौरान और end point पर सही knowledge transfer enforce करना चाहिए
लगभग 10 साल तक consultant के तौर पर काम किया, और जब भी कभी मौका बना, मैंने fixed-price contract को कहीं ज़्यादा पसंद किया
hourly fee लेने पर आप customer की सनक के हिसाब से काम करने लगते हैं, और अक्सर employee जैसा, या उससे भी बुरा, व्यवहार झेलना पड़ता है। असल में आप किराए पर उपलब्ध शरीर जैसे बन जाते हैं
fixed price में पूरी autonomy बनी रहती है। तय समय और budget के भीतर deliver कर दूँ तो schedule मैं तय करता हूँ। customer मेरी सहमति के बिना scope नहीं बदल सकता, और खुद को सचमुच इंसान जैसा महसूस होता है
अगर scope साफ हो और customer ऐसा न लगे कि बार-बार, बिना बताए बदलाव मांगेगा, तो fixed price पसंद करता था
उल्टा, अगर scope अस्पष्ट हो या बहुत सारी change requests आने की संभावना हो, तो hourly पर जाता था
hourly bill करने पर customer कोई काम मुझसे करवाने से पहले बहुत सोच-समझकर फैसला करता है
पागलपन वाली deadline पूरी करने के लिए 12 घंटे की shifts भी, अगर हर घंटे के पैसे देने पड़ें, तो काफी जल्दी गायब हो जाती हैं। अब मैं fixed-price contract बिल्कुल नहीं लेता
customer के लिए फायदा यह था कि company के पास काम के घंटे बढ़ा-चढ़ाकर दिखाने की वजह नहीं थी, और company के लिए फायदा यह था कि ongoing work के लिए long-term contracts को बढ़ावा मिलता था। उस environment में यह दोनों पक्षों के लिए win-win जैसा दिखता था
individual consultant से थोड़ा अलग है, लेकिन दोनों models की तुलना करने के लिए दिलचस्प case था
फिर भी लगता है कि consultant और customer अगर नियमित gate stages पर सहमत हों तो दोनों के लिए बेहतर होगा। जैसे 10 work units के लिए 100,000 dollars पर सहमति हो, लेकिन हर milestone pass करने पर 10,000 dollars की किस्त मिले, तो गलतफहमियाँ जल्दी पकड़ी जा सकती हैं
customer 3 महीने इंतजार करके ऐसा waterfall-style delivery पाने से बच सकता है जो specification के हिसाब से तो सही हो लेकिन वास्तविक जरूरत से अलग हो, और consultant 3 महीने काम करके customer के संतुष्ट होने तक एक पैसा भी न मिलने की स्थिति से बच सकता है
लेकिन कभी-कभी यह आपके पक्ष में भी काम करता है। एक pharmaceutical company के project में संयोग से मेरे पास उस knowledge के कुछ हिस्से थे जिनकी उन्हें जरूरत थी, और वे solution का इंतजार करते हुए बहुत पैसा खो रहे थे। जैसे ही मैं दरवाजे से अंदर गया, उन्होंने कहा, “बहुत अच्छा हुआ आप आ गए, हम लंबे समय से solution ढूंढ रहे थे और हर दिन बहुत पैसा गंवा रहे हैं।” 8 दिन के काम से मैं एक साल निकाल सकता था
“जितना ज़्यादा खर्च करोगे, upper management में उतनी ज़्यादा मान्यता मिलेगी और अगले साल budget भी उतना बड़ा होगा। आखिर company में सबसे महंगी problem वाला department ही सबसे महत्वपूर्ण department होगा” — यह बात मैंने government के बारे में सच सुनी थी, और इसे इस उदाहरण की तरह पेश किया गया था कि government के incentives गलत हैं और private companies कहीं बेहतर हैं
मतलब private companies में efficient तरीके से पैसा बचाने पर bonus मिलता है, लेकिन government में सजा मिलती है और department छोटा कर दिया जाता है। इसलिए यह सुनकर हैरानी हुई कि ऐसा large enterprises में भी होता है। हालांकि मैंने सिर्फ बहुत छोटी companies के साथ ही काम किया है
कई common beliefs की तरह, यह विचार कि companies efficient होती हैं, खासकर government से ज़्यादा efficient, एक myth है
company में manager promotion इसलिए नहीं पाता कि उसने numbers छोटे रखे, बल्कि इसलिए पाता है कि उसके नीचे काम करने वाले लोग ज़्यादा हो जाएँ
अगले साल उतना ही budget मिलता था जितना खर्च किया गया हो, इसलिए अगर 1,000 dollars बच जाते तो अगले साल का budget 1,000 dollars कम हो जाता। इसलिए हर साल वे team के एक member को भेजते कि customers के साथ अक्सर जाने वाले restaurants के ढेर सारे gift cards खरीद लाए, और एक ही दिन में पूरा budget खर्च कर देते
“उस काम को किसी और की problem बना देना” ज्यादातर economic activity पर लागू होता है
gardener को full-time रखना है, कुछ हफ्तों में एक बार बुलाना है, या खुद करना है—यह काम के scale और frequency, मेरी skills, मेरे time की value, उम्र आदि पर निर्भर करता है
धरती पर लगभग हर economic transaction ऐसा ही है। दूसरों से करवाना हमेशा महंगा होता है। IT contracts अलग क्यों होंगे? कभी-कभी खुद करना या full-time employee को देना समझदारी नहीं होती
पता नहीं क्यों, लेकिन मुझे लगा कि author ने
schemeकी जगहconceptलिखा होता तो बेहतर होतासाथ में, मेरा मतलब यह नहीं कि word choice गलत थी। बस आंख में अटक गई
fixed price बनाने वाले पर बड़ा risk डालता है, लेकिन hourly price में risk नहीं होता
व्यक्तिगत तौर पर मुझे अच्छा balance यह लगता है कि कुछ fixed-price कामों में cap और termination clause हों, और maintenance व additional development hourly पर हो
missing piece retainer contract है। consultants के लिए यह लगभग cheat code जैसा मानता हूँ, क्योंकि कई retainers stack किए जा सकते हैं और यह ज़्यादा stable होता है
“available on standby” होने की भी कीमत होती है, लेकिन बहुत सारे consultants वह cost charge नहीं करते
मुझे यह ऐसा सुनाई दिया कि “वे पैसे आपकी confidence के लिए देते हैं”
यानी यह भरोसा कि आप आकर customer पर बड़ा burden डाले बिना काम खत्म कर सकते हैं। consultant के तौर पर मुझे मिली सलाहों में यह शायद सबसे अच्छी थी
यह सलाह भी अच्छी है कि आप अपनी rate जितनी सोचते हैं, उसका double बोलें। जब हमारी company ने ऐसा करना शुरू किया, तो हमने customers नहीं खोए; बल्कि हम higher-end market में चले गए और कहीं बेहतर customers व कहीं ज़्यादा interesting projects करने लगे
मेरे हिसाब से दोनों सलाह एक ही context में हैं। ऐसा behave करें जैसे आप वह expert हैं जिसे उसके success rate के मुताबिक pay किया जाता है। बेशक उसे सच में support भी करना होगा, लेकिन वह तो implementation detail है, है न?
कंसल्टेंट की तरफ़ से यह सब आकर्षक लगता है, लेकिन buyer की तरफ़ से उतना convincing नहीं होता
hourly rate में कंसल्टेंट को जल्दी हटाया जा सकता है—यह तर्क medium-to-large budgets वाले लोगों पर चल सकता है, लेकिन fixed price में कम-से-कम यह गारंटी होती है कि अंत में X मिलेगा या पैसे नहीं देने पड़ेंगे
छोटे budget वाले लोगों के पास अक्सर बिना deliverable के कंसल्टेंट को test करने में जलाने के लिए भी पैसा नहीं होता
अगर वे कुछ रकम या शुरुआती कुछ घंटों की cost भी नहीं दे सकते, तो actual project cost कैसे देंगे? जब पैसा कमाना शुरू करेंगे तब? अगर ऐसा है, तो बेहतर है कि equity के बदले काम करने वाला “co-founder engineer” ढूंढें
procurement department जैसे कुछ लोगों का काम ही vendors से बेहतर price निकलवाना होता है। वे company को मिलने वाली value से अलग, price कम करने की कोशिश कर सकते हैं
हालांकि अगर उन्होंने आपको किसी दूसरे vendor से मिल सकने वाली commodity के रूप में नहीं देखा है, तो बहुत ज़्यादा दबाव बनाना मुश्किल होता है
independent technical consultant के रूप में मेरे अनुभव में, आपकी value को कुछ हद तक समझने वाला executive या manager आपको hire करना चाहता हो, तब भी उसे दूसरों को यह समझाना पड़ सकता है कि आपका rate क्यों value रखता है। हो सकता है sticker price देखकर झटका लगा हो, या government contract में justification देना पड़ रहा हो
इसलिए वे हल्के से या सीधे-सीधे उस आधार को बनाने में आपकी मदद मांग सकते हैं। जैसे bio लिखना, credentials व्यवस्थित करना, या यह पता लगाने के लिए regulation-based सवालों के जवाब देना कि आप किसी खास grade या exemption में आते हैं या नहीं। मेरे अनुभव में यह negotiation tactic नहीं था, और हर बार बिना discount के काम तक पहुंचा
यह सिर्फ़ एक anecdote है और मैं consulting business expert होने का दावा नहीं करता। मैंने ऐसी high value दी जिसे replace करना मुश्किल था, इसलिए कुछ clients को बहुत अच्छी deal मिली, और मैंने ऐसे कई मौके reject किए जहां clients अपनी जरूरतों को commodity की तरह सोच रहे थे
इसे solve करने के लिए मैं consulting firm बढ़ाकर “associates” hire कर सकता था और खुद “partner” के रूप में supervision/mentoring कर सकता था, लेकिन दूर से value लगाना मुश्किल billable hours बेचने के बजाय, founder के तौर पर product और पूरे business को integrated तरीके से बनाना और success पर बड़ा reward पाना मुझे ज्यादा पसंद है
ऊपर की image की वजह से मुझे लगा था कि यह article somehow Golang से जुड़ा होगा
फिर भी पढ़ने में मज़ा आया; यह informative और अच्छी तरह लिखा हुआ article था