- software की मूलभूत भूमिका यह है कि वह साफ़ तौर पर जाने कि उसे कौन-सी समस्या हल करनी है, और अपनी सीमाओं को पहचाने
- अच्छा software हर feature को समेटने की कोशिश नहीं करता, बल्कि केवल वहीं काम करता है जहाँ सुधार की ज़रूरत हो, और अपने उद्देश्य से भटकता नहीं
ls command को AI feature से बदल देने के एक काल्पनिक उदाहरण के ज़रिए, मौजूदा tools के बेवजह फैलते जाने की प्रवृत्ति पर व्यंग्य किया गया है- 37Signals की ‘Getting Real’ और ‘Rework’ में दिए गए सिद्धांतों का हवाला देते हुए, यह ज़ोर दिया गया है कि constraints को ताकत बनाना चाहिए और गैर-ज़रूरी feature requests को ठुकराना चाहिए
- AI उछाल के बीच भी यह याद दिलाया गया है कि मौजूदा standards की स्थिरता और समस्या की स्पष्ट परिभाषा किसी नए trend से अधिक मूल्य रखती है
software की भूमिका और सीमाएँ
- लेख की शुरुआत एक काल्पनिक दृश्य से होती है, जिसमें Linux distribution update करने के बाद
ls command AI-आधारित directory intelligence में बदल जाती है
- नया
als command user की मंशा का अनुमान लगाता है, files को rank करता है, और यह संदेश दिखाता है कि मौजूदा ls का support 30 दिनों में बंद हो जाएगा
- यह दृश्य feature overload और गैर-ज़रूरी innovation पर एक व्यंग्यात्मक उदाहरण है
- “खुशकिस्मती से ऐसा वास्तव में नहीं होता” कहते हुए, यह रेखांकित किया गया है कि अच्छा software जानता है कि उसे कब रुकना चाहिए
अच्छे software के मुख्य सिद्धांत
- अच्छा software जानता है कि उसका उद्देश्य क्या है, वह सब कुछ करने की कोशिश नहीं करता, और यह अलग कर पाता है कि कब रुकना है और क्या सुधारना है
- इंसानी ‘maximalist mindset’ हर चीज़ को बड़ा, अधिक जटिल और अधिक भरा हुआ बनाने की प्रवृत्ति रखता है
- लेकिन software को अपने role और स्थान को स्पष्ट रूप से परिभाषित करना चाहिए, और अगर कोई नया विचार मौजूदा vision से मेल नहीं खाता, तो उसे अलग project के रूप में अलग कर देना चाहिए
37Signals की product philosophy
- Basecamp के संस्थापकों की लिखी ‘Rework’ और ‘Getting Real’ product design के लिए महत्वपूर्ण सीख देती हैं
- constraints फायदे हैं (Constraints are advantages): छोटी team, सीमित budget और सीमित scope बेहतर निर्णय लेने में मदद करते हैं
- feature requests को नज़रअंदाज़ करना (Ignore feature requests): users की माँगी हर feature को सीधे implement करने के बजाय, मूल समस्या को समझने वाला दृष्टिकोण ज़रूरी है
- जल्दी ship करो, बार-बार ship करो (Ship early, ship often): पूरी तरह perfect लेकिन launch न हुआ product, अपूर्ण लेकिन सचमुच काम करने वाले product से कम मूल्यवान है
- core-केंद्रित design (Epicenter design): navigation या आसपास के elements से पहले core interface और interaction को design करना चाहिए
- default रूप से ‘न’ कहना (Say no by default): हर नए feature के साथ complexity, maintenance cost और exception handling जैसी छिपी हुई लागतें आती हैं
- जो खुद चाहिए वही बनाना (Scratch your own itch): वही product जो आपकी अपनी वास्तविक समस्या हल करता है, बेहतर निर्णय लेने में मदद करता है
बदलाव से अधिक निरंतरता का मूल्य
- हाल में कई products में AI को केंद्र में रखकर नाम और features को फिर से गढ़ने का रुझान देखा जा रहा है
- MinIO → AIStor
- Oracle Database → Oracle AI Database
- हर चीज़ का नाटकीय रूप से बदलना ज़रूरी नहीं है
- किसी खास problem domain में de facto standard बन जाना उससे भी बड़ा मूल्य रखता है
अभी कोई टिप्पणी नहीं है.