इंजीनियरिंग का इंतज़ार किए बिना, ऐसा internal tool कैसे बनाएँ जिसे आपकी टीम सच में इस्तेमाल करे

internal business tools बनाने की एक व्यावहारिक गाइड: कैसे पहचानें कि किस process को tool की ज़रूरत है, ज़्यादातर internal tools क्यों छोड़ दिए जाते हैं, एक बिखरे हुए manual workflow से software तक पहुँचने का रास्ता, और कैसे tool का मालिकाना अपने पास रखें, बजाय इसके कि एक और ऐसा tool बना लें जिसे कोई maintain न करे।

यह गाइड किसके लिए है

operations टीमें, office managers, founders, और वे बढ़ती हुई कंपनियाँ जो अपना कोई अहम process manual steps, chat messages और याददाश्त के भरोसे चला रही हैं।

आपको क्या मिलेगा

- यह पहचानने का तरीका कि कौन सा manual process सच में tool माँगता है

- एक बिखरे workflow से ऐसे software तक पहुँचने का रास्ता जिस पर लोग भरोसा करें

- एक ऐसा internal tool जिसका मालिकाना आपके पास हो और जिसे आप बदल सकें, न कि backlog का एक और item

हर बढ़ती हुई कंपनी कुछ ऐसे processes पर चलती है जो कहीं दर्ज नहीं होते: एक approval जो chat पर हो जाती है, एक handoff जो किसी के दिमाग़ में ट्रैक होता है, एक status जिसके बारे में हर कोई पूछता है क्योंकि वह कहीं लिखा ही नहीं होता। internal tools इन्हीं चीज़ों के लिए होते हैं। इतने कम tools बनने की वजह अब लागत नहीं है; वजह यह है कि वे engineering backlog के ऊपर कभी पहुँचे ही नहीं। यह गाइड सही वाले tool को ख़ुद बनाने के बारे में है, ताकि वह सच में बन जाए।

किस process को सच में एक internal tool की ज़रूरत है?

जिस process को tool की ज़रूरत है, वह वही है जिसके बारे में लोग एक-दूसरे से बार-बार पूछते रहते हैं, जहाँ काम किसी handoff के इंतज़ार में अटक जाता है, और जो इस वक़्त chat messages और याददाश्त के सहारे किसी तरह टिका हुआ है। अगर आपकी टीम में बार-बार उठने वाला सवाल किसी न किसी रूप में "X का status क्या है?" या "Y अभी किसके पास है?" जैसा है, तो वही सवाल spec है: tool इसीलिए है ताकि जवाब सबको दिखता रहे और किसी को पूछना ही न पड़े।

internal tools का मक़सद लोगों की जगह लेना नहीं है; इनका मक़सद वह coordination tax हटाना है जो टीम बढ़ने के साथ बढ़ती जाती है। पाँच लोगों की कंपनी अपने दिमाग़ में coordinate कर लेती है। बीस लोगों की कंपनी जो अब भी दिमाग़ में ही coordinate करती है, अपने हर दिन का बढ़ता हुआ हिस्सा status updates देने, approvals के पीछे भागने, और चीज़ें कहाँ तक पहुँचीं यह बार-बार समझाने में लगा देती है। यही अनदेखा बोझ है जिसे एक केंद्रित internal tool हटा देता है, और इसीलिए सही पहला tool उस process को निशाना बनाता है जिसमें सबसे ज़्यादा समय coordination में बह रहा है।

दर्द के आधार पर चुनिए, और ईमानदारी से नापिए। कुछ दिन ध्यान से देखिए कि कौन सा process सबसे ज़्यादा "बस एक छोटा सवाल" पैदा करता है, सबसे ज़्यादा handoffs छूटती हैं, सबसे ज़्यादा "मुझे लगा वह काम आप कर रहे थे" सुनने को मिलता है। जीतने वाला process शायद ही कभी सबसे जटिल होता है; वह सबसे ज़्यादा बार coordinate किया जाने वाला होता है।

ज़्यादातर internal tools आख़िर छोड़ क्यों दिए जाते हैं?

internal tools कुछ तय वजहों से नाकाम होते हैं, और इन वजहों को पहले से जान लेना ही आपके tool को ज़िंदा रखने का सबसे बड़ा हिस्सा है।

• इसने बनाने वाले की सोच वाले process को हल किया, असली को नहीं। असली काम देखे बिना बने tools एक सुथरी कल्पना को अपने अंदर बिठा लेते हैं, और लोग चुपचाप उसी बिखरे तरीके पर लौट जाते हैं जो सच में काम करता है।
• इसे update करना पुराने तरीके से ज़्यादा महँगा पड़ा। अगर tool में कुछ दर्ज करना chat message भेजने से धीमा है, तो chat जीत जाती है। tool को सबसे तेज़ रास्ता होना चाहिए, सिर्फ़ सबसे official नहीं।
• process बदला तो यह बदल नहीं सका। internal processes लगातार बदलते रहते हैं; जिस tool में एक field जोड़ने के लिए engineering ticket लगता हो, वह हक़ीक़त से पिछड़ जाता है और छोड़ दिया जाता है।
• यह एक silo बन गया। जो tool अपनी ज़रूरत का data देख ही नहीं सकता, या अपना data ऐसी जगह रखता है जहाँ और कुछ पहुँच ही नहीं सकता, वह मिलान का काम हटाने के बजाय एक और जोड़ देता है।

अपनाने की कसौटी

एक internal tool तब काम कर रहा है जब उसे इस्तेमाल करना उसे न करने से आसान हो। कोई भी feature जोड़ने से पहले पूछिए कि इससे tool इस्तेमाल करने में तेज़ होगा या धीमा। ज़्यादातर छोड़े गए internal tools अच्छी नीयत से ही मरे: वे fields जो शायद किसी को चाहिए हों, वे steps जो पूरी तरह सोचे-समझे लगते थे, इन सबने रोज़ के रास्ते को तब तक भारी किया जब तक लोग उससे हट नहीं गए।

manual गड़बड़ से software तक पहुँचने का रास्ता क्या है?

लोगों के दिमाग़ में बसे process से एक tool तक पहुँचना एक भरोसेमंद क्रम में होता है। पहला step छोड़ देना ही वह वजह है जिससे इतने सारे tools ग़लत समस्या हल करते हैं।

• 1. असली काम को देखिए | process जैसे सच में होता है वैसे उसे एक हफ़्ते तक पीछा करके देखिए, workarounds और अपवादों समेत | असली workflow, official वाला नहीं
• 2. records और states को नाम दीजिए | यह process किन चीज़ों को ट्रैक करता है, और वे किन states से होकर गुज़रती हैं? | data model और status का बहाव
• 3. पहले सिर्फ़ एक रास्ता बनाइए | शुरू से आख़िर तक मुख्य flow: बनाना, states से गुज़रना, status देखना, handoff करना | आम मामले के लिए एक चलता-फिरता tool
• 4. roles और visibility जोड़िए | कौन क्या करता है, और किसे कुछ किए बिना बस status देखना है | "X का status क्या है?" का अंत
• 5. जो अपवाद आपने देखे उन्हें संभालिए | step 1 के असली edge cases, कल्पना वाले नहीं | एक ऐसा tool जिस पर लोग भरोसा करते हैं क्योंकि वह हक़ीक़त में फ़िट होता है

एक असली internal tool, दायरे में बँधा हुआ

एक logistics टीम का सबसे बुरा process था equipment checkout: कौन सा device किसके पास है, कब से है, और क्या वह देर से लौट रहा है, यह सब एक chat channel और एक शख़्स की याददाश्त में ट्रैक होता था। एक हफ़्ते देखने पर यह चार चीज़ें बन गया: assets, लोग, checkouts, और एक लौटाया गया/देर वाला state। version एक में कोई भी device checkout कर सकता था, पूरी fleet का status एक ही screen पर दिखता था, और देर वाली चीज़ें अपने-आप flag हो जाती थीं। रोज़ का "scanner किसके पास है?" वाला सवाल बस बंद हो गया, क्योंकि screen ने उसका जवाब दे दिया।

इसे एक और मरे हुए tool बनने से कैसे रोकें?

जो internal tool ज़िंदा रहता है और जो मर जाता है, उनके बीच का फ़र्क़ आमतौर पर features नहीं होता; यह होता है कि टीम इसे हक़ीक़त के साथ मिलाकर चला पाती है या नहीं। दो चीज़ें इसकी रक्षा करती हैं।

• आप इसे ख़ुद बदल सकते हैं। जब process बदले, और वह बदलेगा ही, तो एक status या field जोड़ना आपका किया हुआ एक edit है, कोई ticket नहीं जो आप दायर करते हैं। जो tool सिर्फ़ किसी और के हाथों बदल सकता है, वह काम से तालमेल खो देता है और छोड़ दिया जाता है।
• यह अपनी ज़रूरत के data के पास रहता है। जब tool आपके असली records, लोगों, orders, assets को एक ही जगह देख पाता है, तो यह silo जोड़ने के बजाय मिलान का काम हटा देता है। data और tool दोनों का मालिकाना एक साथ अपने पास रखना ही इसे single source of truth बनाए रखता है।

यहीं पर process को बताकर उसके इर्द-गिर्द tool बनवाना दोनों को मात देता है: एक कड़े template को, और एक ऐसे developer की एक-बार-की script को जो बनाकर आगे निकल जाता है। आपको ऐसा software मिलता है जो आपके असली workflow के आकार में ढला हो, जिसे आप workflow के बदलने के साथ दोबारा ढालते रह सकें, बिना हर बार engineering की कतार में लौटे। tool इसलिए ज़िंदा रहता है क्योंकि जो लोग process चलाते हैं वही इसे सच्चा बनाए रख पाते हैं।

• 1 सवाल: दिन भर दोहराया जाने वाला "X का status क्या है?" ही इस tool का spec है
• 1 हफ़्ता: असली काम को देखना ग़लत process बना लेने से रोकता है
• सबसे तेज़ रास्ता: tool को chat message से तेज़ होना ही होगा, वरना chat जीत जाती है

छोटा वाला निचोड़

• जिस process को tool की ज़रूरत है, वह वही है जिसके बारे में लोग एक-दूसरे से बार-बार पूछते हैं; बार-बार उठने वाला "X का status क्या है?" सवाल ही spec है।
• internal tools तब छोड़ दिए जाते हैं जब वे एक कल्पित process को हल करते हैं, पुराने तरीके से ज़्यादा महँगे पड़ते हैं, बदल नहीं सकते, या एक silo बन जाते हैं।
• पहले असली काम देखकर बनाइए, फिर records और states, फिर एक मुख्य रास्ता, और फिर roles और वे असली अपवाद जो आपने देखे।
• इसे अपने मालिकाना से ज़िंदा रखिए: process बदलने के साथ इसे ख़ुद बदलिए, और इसे अपनी ज़रूरत के data के पास रखिए ताकि यह single source of truth बना रहे।

अक्सर पूछे जाने वाले सवाल

मुझे कैसे पता चले कि सबसे पहले कौन सा internal tool बनाना है?

उस process को निशाना बनाइए जिसके बारे में लोग एक-दूसरे से बार-बार पूछते हैं और जहाँ काम handoffs पर अटकता है। कुछ दिन ध्यान दीजिए कि कौन सा process सबसे ज़्यादा "बस एक छोटा सवाल" और छूटी हुई handoffs पैदा करता है; सबसे ज़्यादा बार coordinate किया जाने वाला process, न कि सबसे जटिल, वहीं tool सबसे ज़्यादा बर्बाद होता समय हटाता है।

internal tools इतनी बार क्यों छोड़ दिए जाते हैं?

क्योंकि वे असली process के बजाय उसका एक सुथरा version हल करते हैं, क्योंकि उन्हें update करना उस chat message से धीमा है जिसकी जगह उन्होंने ली थी, क्योंकि process बदलने पर वे बदल नहीं सकते, या क्योंकि वे एक data silo बन जाते हैं। इलाज यह है कि पहले असली काम देखिए, tool को सबसे तेज़ रास्ता बनाइए, और उसे ख़ुद बदल पाइए।

एक internal tool के version एक में क्या होना चाहिए?

सिर्फ़ मुख्य रास्ता: record बनाना, उसे उसके असली states से गुज़ारना, उसका status देखना, और उसे handoff करना, साथ ही वे roles जो तय करते हैं कि कौन क्या करता है और किसे सिर्फ़ देखना है। वे अपवाद जोड़िए जो आपने सच में देखे, कल्पना वाले नहीं, और बाक़ी सब कुछ लोगों के इस्तेमाल शुरू करने के बाद के लिए छोड़ दीजिए।

क्या internal tool बनाने के लिए मुझे किसी developer की ज़रूरत है?

अब नहीं, और इसे ख़ुद बनाने का एक असली फ़ायदा है: internal processes लगातार बदलते हैं, इसलिए जिस tool को आप process बदलने के साथ edit कर सकें वह उपयोगी बना रहता है, जबकि जिसमें हर बदलाव के लिए engineering ticket लगता हो वह तालमेल खोकर छोड़ दिया जाता है। workflow को बताइए और उसे बदलने की क्षमता अपने पास रखिए।