रीडिज़ाइन की कहानी-1 (200 हफ्तों पुराने legacy प्रोजेक्ट को ठीक करना)

यह एक निजी पुनरावलोकन है, लेकिन लगा कि शायद दूसरे डेवलपर्स की भी ऐसी ही चिंताएँ हों, इसलिए साझा कर रहा हूँ।

रीडिज़ाइन की कहानी-1

[क्यों Front से फिर से सोचा?]

Select Admin ने एक भी हफ्ता रुके बिना लगभग 200 हफ्तों तक लगातार क्रमिक सुधार जारी रखे

• Select Admin की मौजूदा सेवा 2021 की शरद ऋतु से संचालित हो रही है
• 2022 में paid होने के बाद बहुत से सुधार हुए
• 2023 में admin से आगे बढ़कर dashboard और partner center तक विस्तार हुआ
• 2024 में बड़े enterprises और mid-sized companies की आवश्यकताओं को पूरा करते हुए और उन्नत बनाया गया

Select Admin का विस्तार हुआ है, लेकिन मुझे लगता है कि इसका मूल उपयोग-तरीका वहीं का वहीं रह गया

• editing environment में बदलाव 2022 के preview के बाद से वैसा ही बना हुआ है
• YAML spec लगातार जोड़े गए, लेकिन backward compatibility बनाए रखी गई
• deployment और environment फीचर 2023 में जोड़े गए
• self-hosted, CLI, Git के उपयोग-तरीके 2024 में रिन्यू किए गए

शुरुआत में इसे डेवलपर्स के लिए खोला गया था, लेकिन इसमें अलग-अलग user groups और कई तरह की खूबियाँ एक साथ थीं

• database से connect करके तुरंत query करना
• ENV साझा किए बिना API को अंदर wrap करके उपलब्ध कराना
• front-end developer न होते हुए भी screen बनाना
• developer न होते हुए भी पहले से बने menu और screen को संपादित करना

समस्या यह है कि उपयोग-तरीका और कठिन होता गया, और नए users को और भी मुश्किल और जटिल documentation देखनी पड़ी

• server developer के नज़रिए से documentation में JavaScript, CSS code दिखता है
• front-end developer के नज़रिए से documentation में SQL, Cache code दिखता है
• C-Level के नज़रिए से यह एक सरल adoption है, लेकिन उन्हें detailed permissions, organization groups, security policies तक सोचना पड़ता है
• individual और small-scale उपयोग पर भी enterprise pricing plan लागू हो जाता है
  कुल editors की संख्या कम हुई, इसलिए feedback और improvement requests भी कम हुईं
• जटिल admin और partner center बनाने वाले users तो बढ़े, लेकिन simple lookup और edit pages बनाने वाले users घटते गए
• एक startup के रूप में अच्छा product बनाने के लिए users अनिवार्य हैं। internal planning से कहीं अधिक मूल्यवान customer requirements होती हैं
• नए users के influx से feedback की बहुत आवश्यकता है

अच्छे users, अच्छा product, और अच्छी pricing — इन सब पर एक ही स्तर पर विचार किया गया

• हम और अधिक UI और features देना चाहते हैं, लेकिन यदि paid subscribers न हों तो budget सुरक्षित करना कठिन है
• यदि product कठिन है, तो नए users बढ़ने पर भी customer support cost बढ़ जाती है
• जब कोई उत्साही और problem-solving के प्रति गंभीर developer इसका उपयोग शुरू करता है, और Select team पहले से बहुत व्यस्त हो, तो दुर्भाग्य से जल्दी संबंध बनाने का सही समय निकल जाता है
• इस विषय पर सोचा गया कि हम लगातार कैसे मदद कर सकते हैं?
  अंततः हमने सबने मिलकर अधिक गहरी दिशा पर विचार किया
• एक छोटा product बनाते हैं। Select Admin में बहुत ज़्यादा features हैं और 80% users सिर्फ 20% features का उपयोग करते हैं।
• admin की असुविधाओं को और गहराई से समझें। Select Admin सिर्फ निर्माण नहीं, बल्कि planning, design, operation तक का बोझ कम करे
• इसे आसानी से handover किया जा सके और collaboration संभव हो। भले ही ज़िम्मेदार व्यक्ति नौकरी बदल दे, छोड़ दे, या organization transfer हो जाए, handover पाने वाले हर व्यक्ति पर बोझ न पड़े (4 साल में ऐसे अनगिनत cases)

ज़्यादा आसान उपयोग-तरीका, कम कीमत, और एक तर्कसंगत starting point

• मेरा मानना है कि product की appeal शुरुआत से अंत (result) तक के पूरे अनुभव में होती है
• जिन features की provisioning cost अधिक है (security), उन्हें यथासंभव add-on service के रूप में अलग किया जाए, और अधिकांश users के लिए सभी features free plan में दिए जाएँ।
• pricing plan को इस तरह बदला जाए कि केवल संतुष्ट users ही (डेवलपर्स की संख्या के अनुसार) भुगतान करें। 1-person developer भी paid plan पर 500 लोगों की admin service चला सके, ऐसा कर के सीमा को बाधा न बनने दें।

इसे ठोस रूप से कैसे बदला जाएगा, यह अगले भाग में

[moderator]

Show GN के लिए उपयुक्त न होने के कारण इसे समाचार में स्थानांतरित कर दिया गया।