लगभग सही है, लेकिन मुझे लगता है कि sales या finance वालों के पास भी ऐसी खरीदारी की authority बहुत कम होती है। इसलिए सब लोग कंपनी द्वारा allow किए गए tools या free plans इस्तेमाल करते हैं, और आखिर में boss को ही sell करना पड़ता है
उन्हें यह समझाकर मनाना पड़ता है कि इससे समय बचेगा, project ज्यादा transparent होगा, और freedom कम होगी
Excel के इतने व्यापक इस्तेमाल की वजह भी शायद यही है। कंपनी IT द्वारा allow किया गया सबसे powerful tool भी Excel ही होता है
Sales या finance department में काम करते हुए PC पर WSL install करने की अनुमति लेकर देखिए, समझ आ जाएगा। Web apps popular होने की वजह भी यही है कि कंपनी IT को पता हो तभी वह उन्हें block कर सकती है
Marketing manager अपने card से Basecamp का payment कर सकता है, लेकिन self-hosted tool लाना हो तो “computers हम manage करते हैं, और काम करने का तरीका भी हम तय करते हैं” वाली IT policy से गुजरना पड़ेगा, इसलिए मामला बड़ा हो जाता है
Excel व्यापक रूप से इस्तेमाल होता है क्योंकि सचमुच कोई भी उसे इस्तेमाल कर सकता है। Database के विपरीत, आप जो बनाते हैं वह सीधे दिखने वाले visual form में सामने आता है
यह सभी m365 licenses में शामिल है, और perpetual license भी लंबे समय तक अपेक्षाकृत सस्ता था
Sales team को WSL allow करने की बात सुनकर पूछने का मन करता है कि क्या आपने कभी असली sales लोगों के साथ काम किया है। 99% कंपनियों में tech-savvy sales लोग भी बिना मदद के email attachment भेज पाने भर में मुश्किल से सक्षम होते हैं; WSL से वे क्या करेंगे, समझ नहीं आता
मोटे तौर पर सही है। कंपनी किसी एक individual किताब की खरीद approve नहीं करती, लेकिन learning platform subscription approve कर देती है
ऐसी छोटी-छोटी purchases को approve करना बहुत ज्यादा काम है, और अगर review न किया जाए तो जगह-जगह unused subscriptions जमा हो जाते हैं या कंपनी के लिए ज्यादा useful न होने वाली चीजें बहुत खरीद ली जाती हैं
मेरे अनुभव में sales departments के पास department-level अच्छे tools हो सकते हैं, लेकिन खरीदारी की authority बहुत ज्यादा नहीं होती थी
इसके उलट marketing side के पास खरीदारी की authority काफी ज्यादा दिखती थी, शायद इसलिए कि उनका काम ही तरह-तरह की चीजें खरीदने से जुड़ा होता है
Boss को भी किसी tool की purchase approve करवाने के लिए उससे ऊपर वालों को sell करना पड़ता है, इसलिए यह झंझट हो सकता है। प्रति user $80/month, salary cost की तुलना में practically free है, लेकिन फिर भी हमेशा barrier बनता है
Self-hosted application खरीदना मुश्किल इसलिए है क्योंकि IT को servers, network, storage costs, installation, upgrades, operations, support, AD-based single sign-on, mail, Slack, backup/restore, data export और migration, और cybersecurity तक की responsibility लेनी पड़ती है
सिर्फ एक application भी compromise हो जाए तो पूरी कंपनी का IT risk में पड़ सकता है, और isolation या zero trust लागू करने पर भी attack surface और security cost बढ़ती है
असल में self-hosted application खरीदना आसान हिस्सा है; मुश्किल है उसे business की जरूरत जितने समय तक रोज स्थिरता से चलाना। कुछ मामलों में कानूनन data को लंबे समय तक रखना भी पड़ता है
Business-side IT ने tool request किया हो तो भी वे कुछ technical management कर सकते हैं, लेकिन अक्सर उनके पास समय नहीं होता या वे developers होते हैं, system/network administrators नहीं, इसलिए नहीं कर पाते
आखिरकार कंपनी IT से अलग sandbox इस्तेमाल करना पड़ता है, या backups और AD जैसी convenience features छोड़नी पड़ती हैं, या shadow IT के रूप में खुद implement और maintain करना पड़ता है
इसलिए मुझे लगता है कि SaaS और cloud के बढ़ने की एक वजह इन costs को externalize करना भी है
अगर $50 की किताब खरीदने के लिए लड़ना पड़ रहा है तो शायद आपने गलत कंपनी चुनी है
हालांकि, कुछ developers ने Notion को internally test करने के लिए card से unofficial account बनाया, उसमें important outline documents बनाए और फिर links circulate कर दिए
उन्हें देखने के लिए कंपनी के आधे लोगों ने चुपचाप accounts बना लिए, और अगले महीने CFO के पास $10,000 का bill आ गया
Developers को purchase authority नहीं देनी चाहिए—यह कहानी आम तौर पर कुछ इसी तरह शुरू होती है
यह तो बस predatory pricing model और dark patterns का example है
कई SaaS कंपनियां prepaid payment या fixed cost cap options ठीक से नहीं देतीं, इसकी वजह है। यह scam के करीब है
सिर्फ link click करने से charge लग सकने वाला system किसे अच्छी idea लगा, समझ नहीं आता। अगर card पर reasonable monthly limit भी नहीं थी, तो पूरी setup बेहद absurd थी
इसे “developers के पास purchase authority न रहने की कहानी की शुरुआत” मानना मुश्किल है
Developers हों या कोई और, tools को direct खरीदना अक्सर पूरे organization की कीमत पर local optimization बन सकता है
उदाहरण के लिए tools बिखर जाते हैं, जिससे एक search में information नहीं मिलती, या हर team के अलग tool में अलग login करना पड़ता है
अगर teams company intellectual property वाले tools को अपने-अपने तरीके से manage करें, तो SOC compliance लक्ष्य होने पर यह compliance nightmare बन जाता है
किताबें या learning materials खरीदना मुझे ठीक लगता है
एक ऐसे व्यक्ति के रूप में जिसने प्रति quarter $100 million से ज्यादा engineering hardware, software और services spending पर decisions लिए हैं, अगर आप developer tool बना रहे हैं तो पहले मौजूदा developers को उसे बहुत useful महसूस कराना और उसका जोरदार समर्थन करने लायक बनाना चाहिए
Opaque contracts, lock-in, data security/privacy, single sign-on/authentication integration जैसे veto items को नहीं छेड़ना चाहिए
Pricing भी समझ में आने वाली होनी चाहिए। किसी variable के साथ linear proportion में बढ़ने वाली pricing finance spreadsheet में nonsense लग सकती है। Per-developer monthly billing समझने में आसान है, company-wide floating license बेहतर है, और कुछ मामलों में company-wide unlimited flat fee ज्यादा सही होती है
आखिरी model में भी cloud compute/storage जैसी consumable costs सीधे pass through की जा सकती हैं। अगर customer के cloud account में direct deploy कर सकें तो data security/privacy issues भी solve हो जाते हैं
Billing caps, usage caps, महंगे usage fees trigger करने वाली settings पर limits, और पर्याप्त usage reporting जैसी cost controls देनी चाहिए
ठीक से किया जाए तो committed spend वाले multi-year contracts भी possible हैं। Service reliability बनाए रखें, और बड़े customers के साथ quarterly review करके satisfaction और unmet needs समझें
Dedicated engineers और support जैसी premium professional services भी offer करके charge की जा सकती हैं। यह highly profitable होती हैं, और किसी specific customer को win या retain करने में critical भी हो सकती हैं
Customer company के अंदर product controversial हो सकता है और विरोधी product adoption को fail कर सकते हैं, इसलिए अगर professional services initial integration/implementation संभालें तो IT gatekeepers की involvement कम करके actual users तक पहुंचा जा सकता है
जिन products के बारे में customer strongly मानता है कि वे खुद बना सकते हैं, उन्हें बेचने की कोशिश न करना बेहतर है। भले ही उनका judgment गलत हो, शुरुआत में आप जीत भी जाएं तो आखिर में हारने की संभावना ज्यादा है
Build versus buy का point 7 आम तौर पर इतना black-and-white नहीं होता। सबसे मुश्किल case वह है जब पहले से internal product हो और आप उसे replace करना या उसमें new feature add करना चाहें
सवाल यह है कि build versus buy का ROI कब judge किया जाए
बहुत high integration cost वाला product खरीदना भी असल में बनाने जैसा ही है। Integration में developer time लगता है, और वही time दूसरे कामों या product itself पर लगाया जा सकता था
अच्छा हो कि यह proof-of-concept integration के दौरान सामने आ जाए, लेकिन उस stage पर भी उसे execute करने के लिए developer time चाहिए
यह कंपनी पर निर्भर करता है। पहले जिस कंपनी में काम किया था, उसकी नीति थी: “काम आसान बनाने वाली किताबें, लाइसेंस, यहाँ तक कि hardware भी—जो चाहिए, बस खरीद लो। फैसले में लगने वाली management cost ज़्यादा महंगी है, इसलिए default तुरंत approval है।”
क्या developers ने खरीदारी की बाढ़ ला दी? नहीं; उन्होंने नीति से पहले जितना खरीदते थे, लगभग उतना ही खरीदा। असल में रोज़मर्रा का काम ज़्यादा सुविधाजनक हो गया
किताबों, licenses और hardware को पेन या कागज़ जैसे consumables की तरह देखा गया। IDE जैसे छोटे local software के लिए यह आम तौर पर ठीक हो सकता है
इसके लिए यह धारणा चाहिए कि developer को admin rights देकर भरोसा किया जा सकता है, या company IT installation की अनुमति दे सकता है
सबको छोटा budget दिया जा सकता है, या team/department स्तर पर manage किया जा सकता है, लेकिन जैसे ही company IT integration की ज़रूरत पड़ती है, यह ठीक से काम नहीं करता
मुझे यह तरीका अच्छा लगता है और मैं यह नहीं कह रहा कि यह बिल्कुल नहीं चल सकता, लेकिन अचानक खरीदारी की बाढ़ ही failure का अकेला mode नहीं है
10 या 20 साल छोड़ दें तो तस्वीर बहुत अलग दिख सकती है। धीमी और अदृश्य cost increase जमा हो सकती है, और यह ऐसी culture बन सकती है जहाँ थोड़े कम खर्च करने वालों को भी चीज़ें खरीदनी पड़ें ताकि बाकी लोग फिजूलखर्च न लगें
cost increase को बढ़ावा देने वाले कई subtle mechanisms हैं, इसलिए विपरीत दिशा में धक्का देने वाली व्यवस्था चाहिए। मुझे लगता है यह अभी भी अनसुलझी समस्या है
एक उदार budget limit रखी जा सकती है, लेकिन साफ कहा जाए कि उसे पूरा खर्च करना जरूरी नहीं है; और साल के अंत में बची रकम का कुछ प्रतिशत किसी ऐसी अच्छी जगह donate करने का नियम भी हो सकता है जिसे सभी स्वीकार कर सकें
जैसे, “किताब खरीद सकते हैं। बस याद रखें कि उस किताब की वजह से pony donation 5 डॉलर कम हो जाएगा।” अगर यह manatee के लिए हुआ तो मेरे Chromebook पर काम करने का खतरा है
समस्या यह है कि manager हर फैसले में घुस आते हैं। लोग सोचते हैं manager मदद करने के लिए होते हैं, लेकिन वे जितनी समस्याएँ हल करते हैं उससे ज़्यादा पैदा करते हैं
अक्सर वे ज्यादा से ज्यादा अक्षम ही होते हैं, और कुछ managers कम करके उनकी salary को discretionary budget में लगाना बेहतर है। दोनों पक्षों का फायदा है
मेरी मौजूदा कंपनी में ऐसे purchases संभालने के लिए HR-जैसी भूमिका वाले कुछ लोग हैं। जिस hardware या software की जरूरत हो उसका link email कर दो, वे घर तक deliver करा देते हैं
मुझे कंपनी की ordering और shipping process जानने की जरूरत नहीं पड़ती, इसलिए अब तक देखे तरीकों में यह सबसे अच्छा लगा
ऐसा ही अनुभव रहा है। सबको corporate card दिया गया और इस्तेमाल करने के लिए encourage किया गया
कर्मचारी रहते हुए इस समस्या से एक बार सामना हुआ था। मुझे ThinkPad चाहिए था, लेकिन management खराब Dell पर अड़ा था, और आखिरकार मुझे ThinkPad मिल गया
इसके अलावा किताबें या tools माँगता तो बस मिल जाते थे, महंगा split keyboard भी मिल सकता था
अब self-employed होने के बाद जो चाहिए होता है, बस खरीद लेता हूँ। असल में बहुत ज्यादा जरूरत नहीं पड़ती
पैसे खर्च करने लायक उपयोगी “developer tools” बहुत ज्यादा नहीं हैं, और मेरे workflow में integrate करने लायक value रखने वाली चीज़ें तो और भी कम हैं। समय के साथ यह आखिरी बात और महत्वपूर्ण हो गई है
corporate life ऐसी ही होती है
खराब Dell मिला, खराब हुआ, फिर खराब Dell मिला, फिर खराब हुआ, फिर Dell मिला
कहते हैं “हमारा contract सिर्फ Dell के साथ है”; जब आप पूछते हैं कि शुरुआत में Dell से contract करना ही क्यों चाहिए था, तो सन्नाटा छा जाता है और तब जाकर दिमाग चलना शुरू होता है
समझ आता है कि Dell के खराब होने का समय जीवन के सबसे अच्छे पलों में से है। नया equipment भेजने में purchase order और ordering politics की परतों से गुजरते हुए 5 दिन लगते हैं, और उन 5 दिनों में कंपनी की कठोर security policy के कारण आप कुछ नहीं कर सकते
इसलिए 5 दिन सोते हो, दोस्तों से बात करते हो, फिर से इंसान बनते हो
Dell से प्यार है। ThinkPad नहीं चाहिए
personal use के लिए MacBook इस्तेमाल करता हूँ
अगर पूछना पड़ रहा है, तो आपके पास authority नहीं है
पहले एक engineering company की sales-focused subsidiary में काम किया था
शुरुआती दिनों में 100 डॉलर का lunch आराम से treat कर सकता था, लेकिन अपने computer के लिए 30 डॉलर का card नहीं खरीद सकता था
इसके उलट parent company में 5,000 डॉलर का test equipment आसानी से खरीदा जा सकता था, लेकिन किसी को fast-food जगह ले जाना हो तो तीन forms भरने पड़ते थे
मेरे कार्यकाल के अंत तक दोनों जगहों पर उन forms के बिना असल में कुछ भी नहीं किया जा सकता था
कई सफल developer tools companies ने developers को नहीं, बल्कि bosses को marketing करके पैसा कमाया। यह सिर्फ technology में नहीं, कई क्षेत्रों में सच है
पूरी तरह सहमत हूँ। एक बड़ी tech company में किसी काम के लिए hard disk चाहिए थी, और एक HDD पर 200 डॉलर expense करने की तुलना में 5,000 डॉलर की drive array खरीदकर उसमें से drive निकालना आसान था
अपने domain से बाहर की चीज़ खरीदने की कोशिश करो तो यह बेतुका रूप से complicated हो जाता था
हाल में कंपनी ने कहा “corporate card है, इस्तेमाल करो,” और event-related खर्च EVP approve कर देते थे। यह सामान्य नहीं था, लेकिन यह देखकर अच्छा लगा कि वे जानते हैं कि कभी-कभी bureaucratic process काटनी पड़ती है
अगली बार कोई साधारण expense submit करूँगा तो शायद 20 डॉलर की taxi receipt में departure और destination न होने के कारण accounting team से लड़ना पड़ेगा
software license सीधे खरीदता हूँ और tax में claim करता हूँ। झूठी savings से बचने का यही तरीका है
सही और सस्ता tool ढूँढकर खुद खरीदने की वजह से मुझे office में award भी मिला, किसी खास project में मैं irreplaceable बन गया, salary raise भी मिला, और मनचाहा काम चुनने की स्थिति मिली
मेरी Jetbrains license इसका प्रमुख उदाहरण है। उसके बिना code refactoring करना सोचना भी मुश्किल है
जब कंपनी की cost-cutting रुकेगी, तो workplace में competitors और बढ़ जाएँगे
सिद्धांततः UK tax system में भी यह संभव है। Self Assessment form में employer द्वारा reimburse न किए गए work-related expenses claim करने का section होता है
पहले employer कम mileage rate देता था, इसलिए अंतर को tax return में claim करता था
software के मामले में यह allowable expense है या नहीं, इसका criteria कैसे लागू होगा, इसे लेकर मुझे पक्का नहीं पता
मैं भी कई सालों से यही तरीका अपनाता आया हूँ
क्योंकि ज्यादातर companies काम के लिए सही software नहीं खरीदतीं, मैं भी team में सबसे effective काम करने वाला व्यक्ति बन गया। दूसरों के विपरीत, मैं काम जल्दी और efficient तरीके से कर सकता हूँ
कई companies में ऐसा करते पकड़े गए तो बड़ी मुसीबत में पड़ सकते हैं
अमेरिका में W2 exempt employee “tax में claim” कैसे करता है, यह जानने की उत्सुकता है
दूसरे उदाहरण क्या हो सकते हैं, यह जानना चाहता हूँ
अगर Azure, AWS, Google Cloud पर deploy किया जा सकता हो, तो बात बदल जाती है
आप बिना approval एक पेंसिल भी नहीं खरीद सकते, लेकिन कंपनी के cloud में बिना पूछे हजारों डॉलर खर्च कर सकते हैं
यहीं Amazon Marketplace का जादू है। आप ऐसी services भी खरीद सकते हैं जो AWS की नहीं हैं, फिर भी वे AWS bill में आती हैं और कंपनी के spend commitment में भी योगदान देती हैं
सही है। हमने एक developer से एक FTP server सेटअप करने को कहा था। वह अच्छा Linux admin था और 10 पाउंड वाले VPS पर यह काम कई बार कर चुका था
लेकिन इस बार उसने महीने के 1,000 पाउंड से ज्यादा वाली AWS service चुन ली। Card bill आने पर यह बड़ा सिरदर्द बन गया, और अगले महीने का खर्च भी तब तक काफी आगे बढ़ चुका था
उसके बाद हमें control और सख्त करने पड़े
मेरे साथ भी कुछ ऐसा ही है। सही लोगों से localstack evaluate करवाना एक बड़ी और कठिन लड़ाई लगता है
लेकिन enterprise license खरीदने पर सिर्फ savings से ही लागत तुरंत recover हो सकती है, इसलिए भले यह मेरा main काम नहीं है, फिर भी इसे try करने का दबाव महसूस होता है
निष्पक्ष रूप से कहें तो, अभी तक किसी ने terraform apply को SAP approval flow के साथ integrate करने का तरीका नहीं निकाला है
ऐसा business model पूरी तरह संभव है जिसमें engineer decision-maker हो। बस यह उन tools तक सीमित है जिनसे engineer बाहरी दायरे पर direct impact डाले बिना local optimization कर सकता है
IDE इसका सबसे अच्छा उदाहरण है। अगर कंपनी के engineers को अपनी productivity बढ़ाने के लिए व्यक्तिगत IDE decisions लेने की अनुमति दी जाए, तो उन सभी decisions का कुल global impact ठीक-ठाक हो सकता है। Jetbrains ने यह दिखाया है
लेकिन हर tool ऐसा नहीं होता। मूल पोस्ट Redis, Terraform, AWS जैसे दूसरी category के examples की बात करती है
IDE के उलट, database, infrastructure management और cloud infrastructure में व्यक्तिगत decisions फैलने लगें तो समस्या बनती है। कंपनी को heterogeneous stack maintain करना पड़ता है, और कोई vendor सिर्फ इसलिए meaningful enterprise contract नहीं बना सकता कि किसी team ने Redis चुना
इसलिए कुछ हद तक standardization जरूरी हो जाती है। उस point पर choice का impact और licensing scale बड़े हो जाते हैं, इसलिए सिर्फ engineering lead ही नहीं, finance भी अपनी बात रखना चाहता है। और इसकी वजह वाजिब है
और जैसे ही finance शामिल होता है, ज्यादातर engineers को ऐसी भाषा में अपने choice को justify करना पड़ता है जो उनके लिए कठिन होती है
मेरी purchase authority कुछ ऐसी है। मैं अपने manager से कहता हूं, “यह developer tool खरीदने से developer time के X घंटे बच सकते हैं”
यहां X tool की कीमत के मुकाबले पर्याप्त बड़ा होना चाहिए। यह तरीका काफी अच्छा काम करता है, इसलिए बार-बार इस्तेमाल करने लगा हूं, और अब manager भी इसे संदेह से देखने लगा है
संदेह करना सही है। चाहे tool हो या redesign, benefits को overestimate करना उतना ही आम है जितना effort estimates को underestimate करना, और दोनों शायद काफी closely related हैं
इसका मतलब यह नहीं कि valuable tools नहीं होते। होते हैं, लेकिन बहुत दुर्लभ होते हैं
सोचता हूं, manager को यह कहने में कितना समय लगेगा: “पिछले 3 महीनों में जिन tools की तुमने बात की, उन्हें जोड़कर तुमने कहा था कि वे एक developer-year बचाएंगे, तो मैं team से 1 developer कम कर दूंगा और काम व schedule वही रखूंगा”
जवाब ऐसा भी आ सकता है: “Developer time कोई KPI नहीं है, और महीने में 160 घंटे काम करो या 180 या 200 घंटे, salary समान ही रहती है”
1 टिप्पणियां
Hacker News की राय
लगभग सही है, लेकिन मुझे लगता है कि sales या finance वालों के पास भी ऐसी खरीदारी की authority बहुत कम होती है। इसलिए सब लोग कंपनी द्वारा allow किए गए tools या free plans इस्तेमाल करते हैं, और आखिर में boss को ही sell करना पड़ता है
उन्हें यह समझाकर मनाना पड़ता है कि इससे समय बचेगा, project ज्यादा transparent होगा, और freedom कम होगी
Excel के इतने व्यापक इस्तेमाल की वजह भी शायद यही है। कंपनी IT द्वारा allow किया गया सबसे powerful tool भी Excel ही होता है
Sales या finance department में काम करते हुए PC पर WSL install करने की अनुमति लेकर देखिए, समझ आ जाएगा। Web apps popular होने की वजह भी यही है कि कंपनी IT को पता हो तभी वह उन्हें block कर सकती है
Marketing manager अपने card से Basecamp का payment कर सकता है, लेकिन self-hosted tool लाना हो तो “computers हम manage करते हैं, और काम करने का तरीका भी हम तय करते हैं” वाली IT policy से गुजरना पड़ेगा, इसलिए मामला बड़ा हो जाता है
यह सभी m365 licenses में शामिल है, और perpetual license भी लंबे समय तक अपेक्षाकृत सस्ता था
Sales team को WSL allow करने की बात सुनकर पूछने का मन करता है कि क्या आपने कभी असली sales लोगों के साथ काम किया है। 99% कंपनियों में tech-savvy sales लोग भी बिना मदद के email attachment भेज पाने भर में मुश्किल से सक्षम होते हैं; WSL से वे क्या करेंगे, समझ नहीं आता
ऐसी छोटी-छोटी purchases को approve करना बहुत ज्यादा काम है, और अगर review न किया जाए तो जगह-जगह unused subscriptions जमा हो जाते हैं या कंपनी के लिए ज्यादा useful न होने वाली चीजें बहुत खरीद ली जाती हैं
इसके उलट marketing side के पास खरीदारी की authority काफी ज्यादा दिखती थी, शायद इसलिए कि उनका काम ही तरह-तरह की चीजें खरीदने से जुड़ा होता है
सिर्फ एक application भी compromise हो जाए तो पूरी कंपनी का IT risk में पड़ सकता है, और isolation या zero trust लागू करने पर भी attack surface और security cost बढ़ती है
असल में self-hosted application खरीदना आसान हिस्सा है; मुश्किल है उसे business की जरूरत जितने समय तक रोज स्थिरता से चलाना। कुछ मामलों में कानूनन data को लंबे समय तक रखना भी पड़ता है
Business-side IT ने tool request किया हो तो भी वे कुछ technical management कर सकते हैं, लेकिन अक्सर उनके पास समय नहीं होता या वे developers होते हैं, system/network administrators नहीं, इसलिए नहीं कर पाते
आखिरकार कंपनी IT से अलग sandbox इस्तेमाल करना पड़ता है, या backups और AD जैसी convenience features छोड़नी पड़ती हैं, या shadow IT के रूप में खुद implement और maintain करना पड़ता है
इसलिए मुझे लगता है कि SaaS और cloud के बढ़ने की एक वजह इन costs को externalize करना भी है
अगर $50 की किताब खरीदने के लिए लड़ना पड़ रहा है तो शायद आपने गलत कंपनी चुनी है
हालांकि, कुछ developers ने Notion को internally test करने के लिए card से unofficial account बनाया, उसमें important outline documents बनाए और फिर links circulate कर दिए
उन्हें देखने के लिए कंपनी के आधे लोगों ने चुपचाप accounts बना लिए, और अगले महीने CFO के पास $10,000 का bill आ गया
Developers को purchase authority नहीं देनी चाहिए—यह कहानी आम तौर पर कुछ इसी तरह शुरू होती है
कई SaaS कंपनियां prepaid payment या fixed cost cap options ठीक से नहीं देतीं, इसकी वजह है। यह scam के करीब है
इसे “developers के पास purchase authority न रहने की कहानी की शुरुआत” मानना मुश्किल है
उदाहरण के लिए tools बिखर जाते हैं, जिससे एक search में information नहीं मिलती, या हर team के अलग tool में अलग login करना पड़ता है
अगर teams company intellectual property वाले tools को अपने-अपने तरीके से manage करें, तो SOC compliance लक्ष्य होने पर यह compliance nightmare बन जाता है
किताबें या learning materials खरीदना मुझे ठीक लगता है
एक ऐसे व्यक्ति के रूप में जिसने प्रति quarter $100 million से ज्यादा engineering hardware, software और services spending पर decisions लिए हैं, अगर आप developer tool बना रहे हैं तो पहले मौजूदा developers को उसे बहुत useful महसूस कराना और उसका जोरदार समर्थन करने लायक बनाना चाहिए
Opaque contracts, lock-in, data security/privacy, single sign-on/authentication integration जैसे veto items को नहीं छेड़ना चाहिए
Pricing भी समझ में आने वाली होनी चाहिए। किसी variable के साथ linear proportion में बढ़ने वाली pricing finance spreadsheet में nonsense लग सकती है। Per-developer monthly billing समझने में आसान है, company-wide floating license बेहतर है, और कुछ मामलों में company-wide unlimited flat fee ज्यादा सही होती है
आखिरी model में भी cloud compute/storage जैसी consumable costs सीधे pass through की जा सकती हैं। अगर customer के cloud account में direct deploy कर सकें तो data security/privacy issues भी solve हो जाते हैं
Billing caps, usage caps, महंगे usage fees trigger करने वाली settings पर limits, और पर्याप्त usage reporting जैसी cost controls देनी चाहिए
ठीक से किया जाए तो committed spend वाले multi-year contracts भी possible हैं। Service reliability बनाए रखें, और बड़े customers के साथ quarterly review करके satisfaction और unmet needs समझें
Dedicated engineers और support जैसी premium professional services भी offer करके charge की जा सकती हैं। यह highly profitable होती हैं, और किसी specific customer को win या retain करने में critical भी हो सकती हैं
Customer company के अंदर product controversial हो सकता है और विरोधी product adoption को fail कर सकते हैं, इसलिए अगर professional services initial integration/implementation संभालें तो IT gatekeepers की involvement कम करके actual users तक पहुंचा जा सकता है
जिन products के बारे में customer strongly मानता है कि वे खुद बना सकते हैं, उन्हें बेचने की कोशिश न करना बेहतर है। भले ही उनका judgment गलत हो, शुरुआत में आप जीत भी जाएं तो आखिर में हारने की संभावना ज्यादा है
सवाल यह है कि build versus buy का ROI कब judge किया जाए
बहुत high integration cost वाला product खरीदना भी असल में बनाने जैसा ही है। Integration में developer time लगता है, और वही time दूसरे कामों या product itself पर लगाया जा सकता था
अच्छा हो कि यह proof-of-concept integration के दौरान सामने आ जाए, लेकिन उस stage पर भी उसे execute करने के लिए developer time चाहिए
यह कंपनी पर निर्भर करता है। पहले जिस कंपनी में काम किया था, उसकी नीति थी: “काम आसान बनाने वाली किताबें, लाइसेंस, यहाँ तक कि hardware भी—जो चाहिए, बस खरीद लो। फैसले में लगने वाली management cost ज़्यादा महंगी है, इसलिए default तुरंत approval है।”
क्या developers ने खरीदारी की बाढ़ ला दी? नहीं; उन्होंने नीति से पहले जितना खरीदते थे, लगभग उतना ही खरीदा। असल में रोज़मर्रा का काम ज़्यादा सुविधाजनक हो गया
इसके लिए यह धारणा चाहिए कि developer को admin rights देकर भरोसा किया जा सकता है, या company IT installation की अनुमति दे सकता है
सबको छोटा budget दिया जा सकता है, या team/department स्तर पर manage किया जा सकता है, लेकिन जैसे ही company IT integration की ज़रूरत पड़ती है, यह ठीक से काम नहीं करता
10 या 20 साल छोड़ दें तो तस्वीर बहुत अलग दिख सकती है। धीमी और अदृश्य cost increase जमा हो सकती है, और यह ऐसी culture बन सकती है जहाँ थोड़े कम खर्च करने वालों को भी चीज़ें खरीदनी पड़ें ताकि बाकी लोग फिजूलखर्च न लगें
cost increase को बढ़ावा देने वाले कई subtle mechanisms हैं, इसलिए विपरीत दिशा में धक्का देने वाली व्यवस्था चाहिए। मुझे लगता है यह अभी भी अनसुलझी समस्या है
एक उदार budget limit रखी जा सकती है, लेकिन साफ कहा जाए कि उसे पूरा खर्च करना जरूरी नहीं है; और साल के अंत में बची रकम का कुछ प्रतिशत किसी ऐसी अच्छी जगह donate करने का नियम भी हो सकता है जिसे सभी स्वीकार कर सकें
जैसे, “किताब खरीद सकते हैं। बस याद रखें कि उस किताब की वजह से pony donation 5 डॉलर कम हो जाएगा।” अगर यह manatee के लिए हुआ तो मेरे Chromebook पर काम करने का खतरा है
अक्सर वे ज्यादा से ज्यादा अक्षम ही होते हैं, और कुछ managers कम करके उनकी salary को discretionary budget में लगाना बेहतर है। दोनों पक्षों का फायदा है
मुझे कंपनी की ordering और shipping process जानने की जरूरत नहीं पड़ती, इसलिए अब तक देखे तरीकों में यह सबसे अच्छा लगा
कर्मचारी रहते हुए इस समस्या से एक बार सामना हुआ था। मुझे ThinkPad चाहिए था, लेकिन management खराब Dell पर अड़ा था, और आखिरकार मुझे ThinkPad मिल गया
इसके अलावा किताबें या tools माँगता तो बस मिल जाते थे, महंगा split keyboard भी मिल सकता था
अब self-employed होने के बाद जो चाहिए होता है, बस खरीद लेता हूँ। असल में बहुत ज्यादा जरूरत नहीं पड़ती
पैसे खर्च करने लायक उपयोगी “developer tools” बहुत ज्यादा नहीं हैं, और मेरे workflow में integrate करने लायक value रखने वाली चीज़ें तो और भी कम हैं। समय के साथ यह आखिरी बात और महत्वपूर्ण हो गई है
खराब Dell मिला, खराब हुआ, फिर खराब Dell मिला, फिर खराब हुआ, फिर Dell मिला
कहते हैं “हमारा contract सिर्फ Dell के साथ है”; जब आप पूछते हैं कि शुरुआत में Dell से contract करना ही क्यों चाहिए था, तो सन्नाटा छा जाता है और तब जाकर दिमाग चलना शुरू होता है
समझ आता है कि Dell के खराब होने का समय जीवन के सबसे अच्छे पलों में से है। नया equipment भेजने में purchase order और ordering politics की परतों से गुजरते हुए 5 दिन लगते हैं, और उन 5 दिनों में कंपनी की कठोर security policy के कारण आप कुछ नहीं कर सकते
इसलिए 5 दिन सोते हो, दोस्तों से बात करते हो, फिर से इंसान बनते हो
Dell से प्यार है। ThinkPad नहीं चाहिए
personal use के लिए MacBook इस्तेमाल करता हूँ
पहले एक engineering company की sales-focused subsidiary में काम किया था
शुरुआती दिनों में 100 डॉलर का lunch आराम से treat कर सकता था, लेकिन अपने computer के लिए 30 डॉलर का card नहीं खरीद सकता था
इसके उलट parent company में 5,000 डॉलर का test equipment आसानी से खरीदा जा सकता था, लेकिन किसी को fast-food जगह ले जाना हो तो तीन forms भरने पड़ते थे
मेरे कार्यकाल के अंत तक दोनों जगहों पर उन forms के बिना असल में कुछ भी नहीं किया जा सकता था
कई सफल developer tools companies ने developers को नहीं, बल्कि bosses को marketing करके पैसा कमाया। यह सिर्फ technology में नहीं, कई क्षेत्रों में सच है
अपने domain से बाहर की चीज़ खरीदने की कोशिश करो तो यह बेतुका रूप से complicated हो जाता था
हाल में कंपनी ने कहा “corporate card है, इस्तेमाल करो,” और event-related खर्च EVP approve कर देते थे। यह सामान्य नहीं था, लेकिन यह देखकर अच्छा लगा कि वे जानते हैं कि कभी-कभी bureaucratic process काटनी पड़ती है
अगली बार कोई साधारण expense submit करूँगा तो शायद 20 डॉलर की taxi receipt में departure और destination न होने के कारण accounting team से लड़ना पड़ेगा
software license सीधे खरीदता हूँ और tax में claim करता हूँ। झूठी savings से बचने का यही तरीका है
सही और सस्ता tool ढूँढकर खुद खरीदने की वजह से मुझे office में award भी मिला, किसी खास project में मैं irreplaceable बन गया, salary raise भी मिला, और मनचाहा काम चुनने की स्थिति मिली
मेरी Jetbrains license इसका प्रमुख उदाहरण है। उसके बिना code refactoring करना सोचना भी मुश्किल है
जब कंपनी की cost-cutting रुकेगी, तो workplace में competitors और बढ़ जाएँगे
पहले employer कम mileage rate देता था, इसलिए अंतर को tax return में claim करता था
software के मामले में यह allowable expense है या नहीं, इसका criteria कैसे लागू होगा, इसे लेकर मुझे पक्का नहीं पता
क्योंकि ज्यादातर companies काम के लिए सही software नहीं खरीदतीं, मैं भी team में सबसे effective काम करने वाला व्यक्ति बन गया। दूसरों के विपरीत, मैं काम जल्दी और efficient तरीके से कर सकता हूँ
अगर Azure, AWS, Google Cloud पर deploy किया जा सकता हो, तो बात बदल जाती है
आप बिना approval एक पेंसिल भी नहीं खरीद सकते, लेकिन कंपनी के cloud में बिना पूछे हजारों डॉलर खर्च कर सकते हैं
लेकिन इस बार उसने महीने के 1,000 पाउंड से ज्यादा वाली AWS service चुन ली। Card bill आने पर यह बड़ा सिरदर्द बन गया, और अगले महीने का खर्च भी तब तक काफी आगे बढ़ चुका था
उसके बाद हमें control और सख्त करने पड़े
लेकिन enterprise license खरीदने पर सिर्फ savings से ही लागत तुरंत recover हो सकती है, इसलिए भले यह मेरा main काम नहीं है, फिर भी इसे try करने का दबाव महसूस होता है
terraform applyको SAP approval flow के साथ integrate करने का तरीका नहीं निकाला हैऐसा business model पूरी तरह संभव है जिसमें engineer decision-maker हो। बस यह उन tools तक सीमित है जिनसे engineer बाहरी दायरे पर direct impact डाले बिना local optimization कर सकता है
IDE इसका सबसे अच्छा उदाहरण है। अगर कंपनी के engineers को अपनी productivity बढ़ाने के लिए व्यक्तिगत IDE decisions लेने की अनुमति दी जाए, तो उन सभी decisions का कुल global impact ठीक-ठाक हो सकता है। Jetbrains ने यह दिखाया है
लेकिन हर tool ऐसा नहीं होता। मूल पोस्ट Redis, Terraform, AWS जैसे दूसरी category के examples की बात करती है
IDE के उलट, database, infrastructure management और cloud infrastructure में व्यक्तिगत decisions फैलने लगें तो समस्या बनती है। कंपनी को heterogeneous stack maintain करना पड़ता है, और कोई vendor सिर्फ इसलिए meaningful enterprise contract नहीं बना सकता कि किसी team ने Redis चुना
इसलिए कुछ हद तक standardization जरूरी हो जाती है। उस point पर choice का impact और licensing scale बड़े हो जाते हैं, इसलिए सिर्फ engineering lead ही नहीं, finance भी अपनी बात रखना चाहता है। और इसकी वजह वाजिब है
और जैसे ही finance शामिल होता है, ज्यादातर engineers को ऐसी भाषा में अपने choice को justify करना पड़ता है जो उनके लिए कठिन होती है
मेरी purchase authority कुछ ऐसी है। मैं अपने manager से कहता हूं, “यह developer tool खरीदने से developer time के X घंटे बच सकते हैं”
यहां X tool की कीमत के मुकाबले पर्याप्त बड़ा होना चाहिए। यह तरीका काफी अच्छा काम करता है, इसलिए बार-बार इस्तेमाल करने लगा हूं, और अब manager भी इसे संदेह से देखने लगा है
इसका मतलब यह नहीं कि valuable tools नहीं होते। होते हैं, लेकिन बहुत दुर्लभ होते हैं