- अक्सर बदलते शुरुआती बिज़नेस माहौल में सबसे आसान समाधान से समस्या को जल्दी सुलझाना, और सीमाएँ दिखने पर ज़रूरतों का दोबारा मूल्यांकन करके उसे बदलना या मजबूत करना समझदारी है
- Google Sheets तेज़ी से बदलते माहौल में समस्या सुलझाने का एक प्रभावी तरीका है; जटिल टूल बनाने की तुलना में यह वास्तविक उपयोगिता और waste कम करने के लिहाज़ से बेहतर हो सकता है
- लेखक याद करता है कि उसने काम के दौरान सामान्य-उपयोग वाले टूल की जगह जल्दी-जल्दी विशेष सिस्टम बना दिए और scope की अनिश्चितता को नज़रअंदाज़ कर समय बर्बाद किया
- मुख्य तरीका है सबसे छोटे और आसान समाधान से शुरू करना → असली काम के जरिए scope समझना → ज़रूरत हो तो धीरे-धीरे सुधार करना; यानी छोटे से शुरू करो, बार-बार सुधार करो रणनीति
- लेकिन हर समस्या को spreadsheet से हल नहीं किया जा सकता; scope साफ़ होने तक इसे अस्थायी रूप से इस्तेमाल करना ठीक है, और संगठन के संदर्भ के अनुसार समझदारी से चुनाव करना ज़रूरी है
समस्या-समाधान के लिए सबसे आसान विकल्प
- किसी भी समस्या में पहले सबसे आसानी से लागू होने वाला समाधान चुनना महत्वपूर्ण है
- जब वह तरीका बिज़नेस के लिए उपयुक्त न रहे, तब नई ज़रूरतों के हिसाब से मौजूदा समाधान को सुधारना या विकल्प ढूँढना चाहिए
- लेखक के अनुभव में, ज़्यादातर मामलों में एक नया Google Sheet बनाना सबसे अच्छा तरीका था
तेज़ी से बदलता startup माहौल और टूल्स की उपयोगिता
- लगभग 9 महीने पहले नौकरी जॉइन करने के बाद, छोटी और शुरुआती-stage कंपनी के लिए नए टूल और सेवाएँ बनाने का उत्साह धीरे-धीरे खत्म हो गया
- हर 2 महीने में बिज़नेस दिशा बदलने वाले माहौल में कई प्रोजेक्ट शुरू हुए और फिर छोड़ दिए गए
- कई मामलों में, जहाँ Google Sheet से आसानी से काम हो सकता था, वहाँ अनावश्यक रूप से जटिल प्रोजेक्ट्स पर समय और मेहनत लगाई गई
समय बर्बाद होने के उदाहरण
-
cargo management admin panel
- बिज़नेस के लिए आने वाले cargo को manage और track करने वाला admin panel डिज़ाइन और बनाने में 2 महीने लगे
- इसका उद्देश्य packages और customer data को वर्गीकृत करना और बेहतर ढंग से manage करने में मदद करना था
- यह admin panel दो बार इस्तेमाल हुआ और फिर कभी नहीं हुआ
- इसे आसानी से Google Sheet से बदला जा सकता था, और अभी यही काम उसी से हो रहा है
-
customs auto-calculation MVP
- खास products के order पर customs duty और tax अपने-आप calculate करने वाला quotation system MVP बनाने में 3 हफ्ते लगे
- ज़िम्बाब्वे के tax और customs बहुत जटिल हैं; अगर ग्राहकों को सही payable amount पता हो, तो बेहतर customer journey मिल सकती है और third-party customs processing कंपनी से हर customer query के जवाब का इंतज़ार नहीं करना पड़ता, जिससे process तेज़ होता है
- आखिर में प्रतियोगी की tax और customs classification table देखकर उसे Google Sheet में कॉपी करके इस्तेमाल किया गया
-
CRM चुनने की प्रक्रिया
- बिज़नेस में उपयोग के लिए अच्छा CRM ढूँढने में research, meetings (1 घंटे से ज़्यादा), और search पर 2 महीने लगे
- अलग-अलग CRM के features और pricing की तुलना करके लंबा विश्लेषण किया गया
- अंत में Oddo के free version का उपयोग करने का फैसला हुआ, लेकिन बिज़नेस में उसका ज़्यादा इस्तेमाल नहीं हुआ
- हैरानी की बात यह थी कि कुछ हफ्ते पहले पता चला कि Google Sheets में CRM template पहले से built-in है
Google Sheets approach के सिद्धांत
- Google Sheet बनाना हर समस्या का सबसे अच्छा समाधान नहीं है, लेकिन लेखक की स्थिति में यह अक्सर सही रहा
- अक्सर ऐसी स्थिति आती है जहाँ असली काम शुरू करने से पहले समस्या का पूरा दायरा कभी पता ही नहीं चलता
- इसका मतलब यह नहीं कि प्रोजेक्ट की planning नहीं करनी चाहिए
- टीम को workflow और ज़रूरी जानकारी पर चर्चा करनी चाहिए, लेकिन असली काम शुरू होने से पहले समस्या का पूरा दायरा पता नहीं चलता
- जब समस्या का पूरा दायरा समझ में आ जाए, तब मौजूदा समाधान को बनाना या सुधारना शुरू किया जा सकता है
- यह तरीका best case में गैर-ज़रूरी features जोड़ने के अतिरिक्त बोझ से बचाता है, और worst case में ऐसे प्रोजेक्ट पर समय खर्च होने से रोकता है जो असफल होने वाला हो
- समस्या का पूरा दायरा समझने के लिए सबसे छोटा, सबसे आसान, बुनियादी समाधान अपनाना और ज़रूरत पड़ने पर उसके बाद iterate करना अब तक सबसे अच्छा तरीका रहा है
सीमाएँ और सावधानियाँ
- इस तरीके की कमियाँ भी हैं; उदाहरण के लिए कुछ संगठन हजारों rows वाली spreadsheet में सारे transactions और जानकारी रिकॉर्ड करते हैं
- Google Sheets सिर्फ समस्या का पूरा दायरा समझ आने से पहले तक उपयोगी है
- यह समझ और अनुभव होना चाहिए कि कौन-सी समस्या Google Sheet से हल की जा सकती है
- समय बर्बाद किए बिना ऐसे टूल बनाने पर ज़ोर होना चाहिए जिन्हें वास्तव में उपयोग किया जा सके
- लेकिन यह हर किसी पर लागू होने वाली सलाह नहीं है, इसलिए अपनी परिस्थिति के अनुसार सावधानी से निर्णय लेना ज़रूरी है
निष्कर्ष
- सबसे कम मेहनत और सबसे सरल समाधान से शुरू करना, और सिर्फ ज़रूरत पड़ने पर ही उसे बढ़ाना या उन्नत करना, startup या तेज़ी से बदलते माहौल के लिए बहुत उपयुक्त रणनीति है
- व्यक्तिगत development experiments अलग से किए जा सकते हैं, लेकिन बिज़नेस में सिर्फ वही बनाना महत्वपूर्ण है जो वास्तव में ज़रूरी हो, और गैर-ज़रूरी कामों पर समय व ऊर्जा बर्बाद न की जाए
3 टिप्पणियां
मैं भी मूल रूप से सहमत हूँ, लेकिन Google Sheets की तुलना में अब मैं शुरुआती baseline के लिए Notion Database का इस्तेमाल करना पसंद करता हूँ। दोनों काफ़ी मिलते-जुलते हैं, लेकिन वैसे भी template setting एक ही व्यक्ति करता है। अगर बाकी लोग उसी आधार पर data manage करें, तो अव्यवस्थित स्थिति से बचा जा सकता है। यह App Script जितना सक्षम तो नहीं है, लेकिन automation को थोड़ा ज़्यादा आसानी से लागू किया जा सकता है। शुरुआती setting की कठिनाई अगर थोड़ी-सी ज़्यादा है भी, तो बहुत बड़ी नहीं है, और flexibility वगैरह भी लगभग समान लगती है। ऊपर से, हाल ही में row-स्तर की permission management भी हो गई है, so good.
मुझे लगता है कि Notion अच्छा है क्योंकि इसकी learning curve कम है।
Hacker News राय
यह बात अक्सर नज़रअंदाज़ हो जाती है। स्प्रेडशीट एक ही जगह पर database, तेज़ और आसानी से customize होने वाला UI, और दोहराने योग्य तथा debug करना आसान data processing environment को साथ लाती है। यह ऐसा टूल है जिसे दुनिया भर के दफ़्तरों में लोग पहले से समझते और इस्तेमाल करते हैं, और यह बनाने वाले को अपनी ज़रूरत के मुताबिक़ कुछ भी लागू करने की आज़ादी भी देता है। इसकी portability भी शानदार है। मुझे पूरा यक़ीन है कि coding न जानने वाले लोगों के लिए यह ख़ास तौर पर रचनात्मक और शक्तिशाली टूल है। बेशक इस आज़ादी के कुछ नुकसान भी हैं, लेकिन online होना चाहिए या नहीं, या कौन-सा vendor बेहतर है जैसी बहसों के बावजूद, spreadsheets के प्रति मेरा गहरा लगाव ज़रा भी कम नहीं हुआ है। मुझे लगता है कि यह हमारे बनाए सबसे बेहतरीन authoring tools में से एक है। spreadsheets से मिलता-जुलता मॉडल अगर किसी का है, तो वह HyperCard है। वह एक लचीला workbench था जिसमें अलग-अलग apps, data, UX वगैरह को जोड़ा जा सकता था। काश HyperCard को हमेशा याद रखा जाए
सही बात है, spreadsheets में entry barrier सचमुच बहुत कम है। मैं तो खेत के बीचोंबीच फ़ोन से Google Sheets में फ़सल की बढ़त का रिकॉर्ड भरता हूँ। सिग्नल कमज़ोर हो तो भी offline mode में दर्ज कर लेता हूँ और घर पहुँचकर sync हो जाता है। रिकॉर्ड बिखरा हुआ हो तो भी, कुछ न होने से तो बहुत बेहतर है। खेती में data की बहुत ज़रूरत होती है, लेकिन हैरानी की बात है कि यह data की कमी वाला माहौल है। learning cycle एक-एक साल लंबा होता है, और हर साल अलग निकलता है
जो लोग coding कर सकते हैं, उनके लिए Appscript spreadsheets को लगभग superpower बना देता है। जिन्हें पता न हो, उनके लिए कहूँ तो Google Sheets के built-in web IDE में सिर्फ़ JS लिखना ही ज़रूरी नहीं है—हालाँकि वह भी काफ़ी काम का है। अगर आप clasp इस्तेमाल करें, तो local IDE में Typescript से development कर सकते हैं, build process में उसे JS में compile करके सीधे spreadsheet में deploy भी कर सकते हैं। अगर toolchain सेट कर लें, तो developer experience (DX) भी काफ़ी अच्छा हो जाता है
ज़ोरदार सहमति। database+UX+logic को एक workbench में जोड़ देने का मूल्य उन apps के केंद्र में है जिन्हें हम बार-बार बनाते रहते हैं। यही वजह है कि Visual Basic आज भी इस्तेमाल होता है। बेशक दिशा एकदम साफ़ हो जाने के बाद यह हमेशा सबसे अच्छा तरीका नहीं होता, लेकिन तेज़ी से iterate करते हुए असली requirements समझने के लिए इससे बेहतर कुछ नहीं
मेरा मानना है कि spreadsheets को database backend की तरह इस्तेमाल करने का कोई बेहतर तरीका होना चाहिए। लोग spreadsheets में जो बहुत-सा काम करते हैं, उसका बड़ा हिस्सा database में बेहतर तरीके से संभाला जा सकता है। लेकिन databases के लिए ज़्यादा training चाहिए, और training कम हो तो नतीजा spreadsheets से भी बदतर हो सकता है
मैं हमेशा सोचता रहा हूँ कि spreadsheet से custom UI वाले पूर्ण database तक क्रमिक रूप से जाने का कोई व्यावहारिक transition path क्यों नहीं है। spreadsheet उस भूमिका से बस एक क़दम पहले है, और कुछ ज़रूरी features—जैसे structured data, native SQL, custom UI elements, IDE integration वगैरह—मिल जाएँ तो यह पूरी तरह संभव लगती है
मुझे "Ask HN: Is the world run by badly updated Excel sheets?" याद आ गया। spreadsheets की सीमाएँ सच में समझने के लिए उनका अनुभव होना ज़रूरी है। इनमें version control नहीं होता, testing नहीं होती। जो काम नहीं बदलता और कम समय के लिए है, उसके लिए यह अच्छी है, लेकिन अगर उसे लगातार evolve होना है तो समस्या बनती है। https://news.ycombinator.com/item?id=33611431 देखें। उस thread में एक टिप्पणी थी: आख़िरकार कंपनी के अंदर सब लोग Excel के मालिक के तरीक़े के हिसाब से खुद को ढाल लेते हैं। अगर पसंद न हो, तो अपनी नई Excel बनाकर copy-paste कर लो, इसलिए हर कोई अपनी तरफ़ से संभालता है। एक project manager को जानता हूँ जिसके रोज़मर्रा के काम का हिस्सा अलग-अलग लेखकों द्वारा बनाई गई spreadsheet versions को लगातार मिलाना-जुलाना था
जब मैंने 2000 के दशक के अमेरिका में coder के रूप में शुरुआत की थी, तो मुझे लगता था कि मेरा काम windows network drive पर पड़ी उन spreadsheets को web apps में बदलना है जिन्हें हमेशा किसी न किसी को बहुत संभालकर चलाना पड़ता था। लेकिन आज भी बहुत-सी कंपनियाँ spreadsheet-based व्यवस्था पर ठीक-ठाक चल रही हैं। आख़िरकार scalability की समस्या आती ही है, और तब app में जाना पड़ता है, लेकिन हर चीज़ को परफ़ेक्ट बनाने के चक्कर में कुछ भी न कर पाने से बेहतर है कि पहले काम पूरा किया जाए
आपने कहा कि "version control नहीं होता", लेकिन सच तो यह है कि Excel में version control जैसा feature मौजूद है। 'Track Changes' का इस्तेमाल करके आप दूसरों के बदलाव approve या reject कर सकते हैं। हालाँकि जो लोग Rube Goldberg-शैली की spreadsheet automation से काम चलाते हैं, वे इस feature का लगभग कभी इस्तेमाल नहीं करते। लेकिन ज़रूरत हो तो यह मौजूद है
मैंने अक्सर समस्याएँ तब देखी हैं जब जानकारी कई spreadsheets में बिखरी होती है। शामिल लोग अक्सर नहीं जानते कि कौन-सी जानकारी किस spreadsheet में है, और authoritative कौन-सी है। इसलिए अक्सर ऐसा टकराव होता है कि किसी को पता ही नहीं चलता कि कोई सिर्फ़ A फ़ाइल अपडेट कर रहा है, जबकि कोई दूसरा सिर्फ़ B को छेड़ रहा है। समस्या असल program या data से ज़्यादा इस बात में थी कि project के भीतर files को कैसे manage किया जा रहा था। जटिल shared folders, network पर कहीं छूटी हुई files—सब मिलकर management की भूलभुलैया बन जाते थे
मैं इस सलाह से सहमत हूँ: "समस्या हल करने के लिए हमेशा सबसे आसान तरीका अपनाओ, और जब वह तरीका business के लिए उपयुक्त न रहे, तब नई requirements के अनुसार उसे बेहतर बनाओ या कोई वैकल्पिक solution ढूँढो।" ध्यान अभी की समस्या हल करने पर होना चाहिए; भविष्य में कभी आने वाली या सिर्फ़ कल्पित समस्या के लिए पहले से सोचना अक्सर सही नहीं बैठता। मौजूदा solution भविष्य में अनुपयुक्त हो सकता है, लेकिन वह किस तरह अनुपयुक्त होगा, यह अनुमान लगाना मुश्किल है
भविष्य में solution किस दिशा में अनुपयुक्त होगा, यह अनुमान लगाना मुश्किल है, लेकिन फिर भी हम मौजूदा solution इस तरह चुन सकते हैं कि वह भविष्य के solution को रोके या बाधित न करे। विकल्प खुले रखना और vendor lock-in से बचना बेहतर है
अनुपयुक्त हो जाने का एक साफ़-साफ़ अनुमान लगाने योग्य उदाहरण यह है कि आप किसी एक vendor पर पूरी तरह निर्भर हो जाएँ, और फिर या तो service से बाहर कर दिए जाएँ या लगातार बढ़ती फ़ीस चुकानी पड़े। यह काफ़ी हद तक अनुमान लगाने योग्य समस्या है
अगर आप बिना ज़्यादा अतिरिक्त काम किए समस्या-क्षेत्र को व्यापक रूप से कवर करने वाले तरीक़े से समाधान बनाते हैं, तो थोड़े-बहुत बदलाव के साथ बदलती requirements को समाहित किया जा सकता है, जिससे solution की मज़बूती बढ़ती है। ऐसा करने पर स्वाभाविक रूप से भविष्य की समस्याएँ भी कुछ हद तक cover हो जाती हैं
मैं अमेरिका की एक मशहूर बड़ी कंपनी में काम करता हूँ। हमारा विभाग दो spreadsheets पर बहुत अधिक निर्भर है। ये मेरे प्लांट से जुड़ी तीन acquisitions के बाद भी बची रही हैं। जब मैं 7 साल पहले शामिल हुआ था, तब भी ये पहले से पुराना format थीं। 2 साल पहले एक नए manager ने इसे company-wide system में migrate करने की कोशिश की, लेकिन असफल रहे, और जल्द ही वह system भी एक नए system से बदल दिया जाएगा। फिर भी मुझे लगता है कि 2027 में भी हम spreadsheet ही इस्तेमाल कर रहे होंगे
मैं Google का पूर्व कर्मचारी हूँ। 5 साल तक मैंने Sheets (जिसे अंदरूनी तौर पर Trix कहा जाता था) से ही project management, CRM, quarterly planning, reporting, interviews, finance—सब कुछ संभाला। यह सिर्फ़ इसलिए नहीं था कि वह Google product था—हम प्रतिस्पर्धी products भी पर्याप्त इस्तेमाल करते थे। spreadsheets की सबसे बड़ी सुविधा यह थी कि इन्हें लक्ष्य हासिल करने लायक़ उपयोगी रूप में बहुत तेज़ी से बनाया जा सकता था, इसलिए काम की असली प्रकृति पर ध्यान देना आसान था
किसी के "नौकरी में 9 महीने" वाले विचार पर, सही हो या ग़लत, एक साल से भी कम अनुभव के साथ इतनी ठोस राय देना काफ़ी दुस्साहसिक लगता है। OP जिस बात को चूक गया, वह यह सच्चाई है कि "अस्थायी जुगाड़ से ज़्यादा स्थायी कुछ नहीं होता।" अभी के लिए तेज़ और ad hoc solution चुनना तभी ठीक है जब आप उसके lifecycle को पूरी तरह नियंत्रित करते हों। अगर किसी ने आपसे कुछ जल्दी बनवाया, आपने जल्दी दे भी दिया, और फिर वे उसी के ऊपर लगातार नए use cases जोड़ते चले जाएँ... तब मैं थोड़ी अधिक upfront cost वाले tool पर ज़ोर दूँगा
उस समस्या वाले "हर कुछ महीनों में एक बार..." वाक्य पर तो मुझे लगभग हँसी आ गई थी। लेखक ने यह ठीक पकड़ा कि सरल tools से काम करना मूल सिद्धांत होना चाहिए। अगर मौजूदा tools वैसे ही इस्तेमाल किए जा सकते हों और ज़रूरत को ठीक-ठाक पूरा कर दें, तो वही सबसे अच्छा है। असल दुनिया में business requirements हर कुछ महीनों में नई हो जाती हैं, इसलिए यह भी संभव है कि "अस्थायी जुगाड़ स्थायी जुगाड़ बन गया" वाली स्थिति से बचा जाए। लेकिन ज़्यादातर लोगों के लिए सालों बाद भी cleanup करना पड़ता है, और "ज़रूरत पड़ी तो फिर से लिख लेंगे" वाला परिदृश्य लगभग कभी काम नहीं करता। और लेखक ने अभी 1 साल बाद, या उससे आगे का अनुभव ख़ुद नहीं किया है
मुझे ख़ास तौर पर वह "हर कुछ महीनों में..." वाला हिस्सा बहुत चुभा। सोचता हूँ कि क्या यह बात कम से कम 4 बार झेलने के बाद कही गई थी
बड़े spreadsheets से परेशान लोगों के लिए MS Access काफ़ी काम का समाधान हुआ करता था। यह spreadsheets में structure और maintainability जोड़ देता था, जबकि accessibility और development difficulty को बहुत नहीं बढ़ाता था। ज़्यादा coding knowledge के बिना भी शानदार UI बनाए जा सकते थे। 20 साल बाद भी, Access की जगह लेने वाला solution क्या है, यह मुझे भी ठीक से नहीं पता
मैं OP की बात से पूरी तरह सहमत हूँ। बस एक बात जोड़ना चाहूँगा: जब requirements Google Sheets के लिए बहुत जटिल हो जाएँ, तो Google Colab (या Jupyter notebook) अगला स्तर बन जाता है। किसी proper app को बनाने से पहले मैं हमेशा खुद से पूछता हूँ: 1. क्या यह सिर्फ़ spreadsheet से हो सकता है? 2. अगर नहीं, तो क्या Jupyter notebook से हो सकता है? और वैसे, Sheets और Colab के बीच integration भी शानदार है
मेरी राय में jupyter notebook, साधारण python script लिखने की तुलना में काफ़ी ज़्यादा जटिल कदम है। python script में भी comments लिखे जा सकते हैं, इसलिए "local webserver चलाकर comments देखने के लिए code block दर code block चलाना" मुझे बहुत पसंद नहीं
मैं सोच रहा हूँ कि मौजूदा google sheet वाली चीज़ को colab notebook में upgrade कैसे किया जाए। gspread python package से sheet का raw data पढ़ा जा सकता है, लेकिन मौजूदा charts या interactive elements को सीधे jupyter notebook में लाना मुश्किल लगता है। शायद आख़िर में उन्हें फिर से बनाना ही पड़ेगा
Google Apps Script भी अच्छा विकल्प है। data import जैसे साधारण scripts से भी बहुत कुछ किया जा सकता है
business automation की सबसे बड़ी समस्याओं में से एक वह खाई है जो तथाकथित 'shadow' IT, low-code platforms, और पूरी तरह 'formal' projects के बीच मौजूद है। "google form से किसी तरह बना लो" और "react app के साथ CI/CD, testing, CDN सब लगा दो" के बीच एक उचित migration path ग़ायब है। दोनों तरफ़ बस ऐसे walled garden विकल्प हैं जो एक-दूसरे से compatible नहीं हैं
मैं अपना पूरा finance management Google Sheets से करता हूँ। मैंने अपना Expense Tracker UI भी ख़ुद बनाया है और कई सालों में 5,000 से ज़्यादा expense entries जमा की हैं। हाल ही में vibe coding से Google Service Account का इस्तेमाल करने वाला एक web UI tool भी बनाया, और उसे PWA बना दिया ताकि फ़ोन पर भी इस्तेमाल कर सकूँ। सरल उपयोग के मामलों में—ख़ास तौर पर single-user applications के लिए—DB की जगह Google Sheets काफ़ी है