हम अपने ख़ुद के प्रोडक्ट क्यों बनाते हैं

जब हमने KeepFlow शुरू किया, तो हमारे सामने वही चुनाव था जिसका हर तकनीकी टीम शुरुआत में सामना करती है: ग्राहकों के लिए software बनाओ, या ऐसा software बनाओ जिसके हम मालिक हों। एजेंसी वाला रास्ता ज़्यादा सुरक्षित है। ग्राहक डिलीवरी पर भुगतान करते हैं, राजस्व अनुमानित होता है, और जब कोई प्रोजेक्ट ship होता है, तो वह किसी और की समस्या बन जाता है। हमने जानबूझकर कठिन रास्ता चुना। KeepFlow जो भी प्रोडक्ट बनाता है, उसके हम आद्योपांत मालिक हैं — हम उसे बनाते हैं, हम उसे चलाते हैं, और जब तक वह मौजूद है, हम उसके हर फ़ैसले के साथ जीते हैं।

यह कोई branding का बयान नहीं है। यह बदल देता है कि इंजीनियरिंग असल में कैसे काम करती है, और इस तरह कि इसे पूरी तरह समझने में हमें कुछ वक़्त लगा। यह वह है जो मालिकाना, आपके बनाने के तरीक़े के साथ करता है।

जब रिश्ता डिलीवरी पर ख़त्म नहीं होता

ग्राहक-काम की परिभाषक विशेषता यह है कि उसका एक अंत होता है। आप किसी प्रोजेक्ट का दायरा तय करते हैं, उसे बनाते हैं, सौंप देते हैं, और रिश्ता बंद हो जाता है। उस software के साथ बाद में जो कुछ होता है — असल भार के नीचे उभरने वाली bugs, performance की चट्टानें, वह security patch जो कभी लगाया ही नहीं जाता — वह अब किसी और का है। आप अगले कॉन्ट्रैक्ट पर आगे बढ़ चुके हैं।

अपने प्रोडक्ट का मालिक होना उस अंत को हटा देता है। कोई हस्तांतरण नहीं, कोई ऐसा पल नहीं जहाँ कोड आपकी समस्या रहना बंद कर दे। यह एक बोझ जैसा लगता है, और कुछ दिन होता भी है। पर यह software में शॉर्टकट के एकमात्र सबसे बड़े स्रोत को भी हटा देता है: यह जानकारी कि परिणामों से आपको नहीं निपटना होगा। जब कोई निकास न हो, तो कोना काटना समय बचाना नहीं है — यह ख़ुद को ब्याज पर एक समस्या उधार देना है, और चुकाने वाले आप ही हैं।

हर bug आपकी bug है

सबसे तात्कालिक असर जवाबदेही पर है, और यह अमूर्त नहीं है। KeepFlow प्रोडक्ट की हर bug हमारी bug है। हर performance regression हमारे अपने आँकड़ों में दिखता है। हर झुँझलाया हुआ उपयोगकर्ता उस काम पर एक सीधा फ़ैसला है जो हमने किया। ticket थमाने को कोई और नहीं है।

यह उस दीवार को ढहा देता है जिसे बनाए रखने में अधिकांश software संगठन बेहद ऊर्जा लगाते हैं — वह दीवार जो software लिखने वाले लोगों और उसे चलाने वाले लोगों के बीच होती है। KeepFlow में वे एक ही लोग हैं। जिस इंजीनियर ने कोई feature बनाया, वही उसे production में देखता है, तीन बजे रात जब वह page करती है तब जवाब देता है, और पढ़ता है कि उपयोगकर्ता उसके बारे में क्या कहते हैं।

वह व्यवस्था डिज़ाइन से असहज है, और यही मक़सद है। जब कोड ship करने वाला व्यक्ति ही वह व्यक्ति है जिसे उसी कोड से जगाया जाता है, तो गुणवत्ता के इर्द-गिर्द के प्रोत्साहन ऐसी चीज़ बनना बंद कर देते हैं जिसे किसी प्रक्रिया से लागू करना पड़े। रात 3 बजे कोई अपने ही शॉर्टकट को debug नहीं करना चाहता। इसे पहली बार में सही बनाने का दबाव काम के ढाँचे से आता है, किसी नीति दस्तावेज़ से नहीं।

अवधियों के लिए बनाना, समय-सीमाओं के लिए नहीं

ग्राहक प्रोजेक्ट समय-सीमाओं के इर्द-गिर्द संगठित होते हैं। मालिकाना प्रोडक्ट अवधियों के इर्द-गिर्द संगठित होते हैं, और वह फ़र्क़ ऐसे तकनीकी फ़ैसलों तक पहुँचता है जो सतह पर एक जैसे दिखते हैं पर उल्टे निकलते हैं।

जब आप कोई ऐसी चीज़ बना रहे होते हैं जिसे आप बरसों चलाएँगे, तो लगभग हर चुनाव का हिसाब उलट जाता है:

• आप शुरू में ही observability में निवेश करते हैं, क्योंकि रात 2 बजे dashboards को घूरने वाले आप ही होंगे, और जिस सिस्टम के अंदर आप देख नहीं सकते वह ऐसा सिस्टम है जिसे आप चला नहीं सकते।
• आप वे टेस्ट लिखते हैं जिन्हें किसी समय-सीमा के नीचे छोड़ देने का लोभ होता, क्योंकि दो साल बाद इस कोड में बदलाव करने वाले आप ही होंगे, बहुत बाद में जब आप भूल चुके होंगे कि यह काम कैसे करता है।
• आप रोमांचक नए framework के बजाय उबाऊ, आज़माया हुआ तकनीक चुनते हैं, क्योंकि आप इस फ़ैसले को बहुत लंबे समय तक बनाए रखने के लिए हस्ताक्षर कर रहे हैं, और नयापन, hype के आगे बढ़ जाने पर, एक जोखिम में बदल जाने की आदत रखता है।

इनमें से कोई भी चुनाव आपको इस तिमाही तेज़ ship करने में मदद नहीं करता। ये सब स्पष्ट रूप से सही हैं जब आपका समय-क्षितिज हफ़्तों के बजाय बरसों में नापा जाए। ग्राहक-काम इन्हें कम ही पुरस्कृत करता है, क्योंकि निर्णय लेने वाला व्यक्ति वह व्यक्ति नहीं है जिसे लागत विरासत में मिलती है। मालिकाना उन दोनों व्यक्तियों को एक में मिला देता है।

प्रतिक्रिया-चक्र बंद हो जाता है

एक और सूक्ष्म फ़ायदा है जिसे भाँपने में हमें ज़्यादा समय लगा: जब आप प्रोडक्ट के मालिक होते हैं, तो किसी उपयोगकर्ता की समस्या और उसके समाधान के बीच का चक्र नाटकीय रूप से छोटा हो जाता है, क्योंकि उसके बीच में कोई कॉन्ट्रैक्ट नहीं बैठा होता।

एजेंसी काम में, अपने उपयोगकर्ताओं के बारे में कुछ सीखना अक्सर एक मोलभाव की शुरुआत होती है। आप किसी रुकावट को भाँपते हैं, पर उस पर कार्रवाई का मतलब है एक change request, एक दायरा तय करने की बातचीत, एक नया statement of work — और जब तक यह सब सुलझता है, अंतर्दृष्टि बासी हो चुकी होती है। अर्थशास्त्र सक्रिय रूप से हतोत्साहित करता है कि आप जो सीखते हैं उस पर कार्रवाई करें, क्योंकि हर सुधार billable है और इसलिए विवादित।

जब प्रोडक्ट आपका है, तो भाँपना और ठीक करना एक ही गति है। एक इंजीनियर कोई सपोर्ट थ्रेड पढ़ता है, तीन शिकायतों के पीछे का पैटर्न पहचानता है, और उसी दोपहर fix ship कर देता है — कोई मंज़ूरी की कड़ी नहीं, कोई invoice नहीं, यह कोई बहस नहीं कि यह दायरे में है या नहीं। समस्या के सबसे क़रीब बैठे लोगों के पास उसे समझने का संदर्भ और उसे सुलझाने का अधिकार, दोनों होते हैं। महीनों में, छोटे, बेरोक सुधारों का वह चक्रवृद्धि होना ही ज़्यादातर वह चीज़ है जो किसी ऐसे प्रोडक्ट को, जिसे लोग बरदाश्त करते हैं, उस प्रोडक्ट से अलग करती है जिस पर वे भरोसा करते हैं।

यह पहले-पहल भी बदल देता है कि हम क्या बनाते हैं। क्योंकि जो हम बनाते हैं उसे हम ख़ुद चलाते हैं, इसलिए हम अपनी अनुपस्थित features को किसी उपयोगकर्ता के रिपोर्ट करने से पहले ही महसूस कर लेते हैं। हमारे प्रोडक्ट की कई सबसे तीखी चीज़ें एक झुँझलाहट के रूप में शुरू हुईं जो हममें से किसी को उसी टीम में कोई अलग प्रोडक्ट चलाते हुए झेलनी पड़ी। अपना सबसे माँगीला ग्राहक ख़ुद होना एक तरह का शोध है जिसे कोई ग्राहक brief ख़रीद नहीं सकता।

रुझानों के पीछे न भागना

इस उद्योग में एक लोभ है कि सबसे नई चीज़ को सबसे अच्छी चीज़ मान लिया जाए — जो भी framework चढ़ान पर है उसी पर फिर से बनाया जाए, जो भी architecture pattern चर्चा में है उसके पीछे भागा जाए। हम इसका कड़ा प्रतिरोध करने की कोशिश करते हैं, और मालिकाना इसे आसान बनाता है, क्योंकि हम जिस भी रुझान के पीछे भागते हैं उसकी पूरी लागत महसूस करते हैं। कोई rewrite जो इस साल फ़ैशन में है, वह अगले पाँच साल हमारे कंधों पर एक रखरखाव का बोझ है।

इसके बजाय हम जो बना रहे हैं वह वह infrastructure है जिस पर व्यवसाय रोज़ निर्भर करते हैं: ग्राहक सपोर्ट जिसे जवाब देना ही है, fraud detection जिसे सही होना ही है, moderation जिसे तेज़ होना ही है, वे टूल जिन्हें लोग यह सोचे बिना पकड़ लेते हैं कि नीचे क्या है। वैसा software भरोसा धीरे-धीरे कमाता है, उबाऊ गुणों के ज़रिए — विश्वसनीयता, एकरूपता, हाज़िर रहना और काम करना। वे गुण नयेपन से नहीं आते। वे किसी चीज़ की इतनी लंबी परवाह करने से आते हैं कि उसे सही कर लिया जाए, और फिर उसे वैसा बनाए रखने के लिए टिके रहने से।

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