उपयोगकर्ता, सुविधाएँ और नृत्य भालू

किसी कारण से, यह बहुत दर्दनाक और अपमानजनक है जब आप जिस परियोजना पर एक साल से अधिक समय से काम कर रहे हैं वह अचानक अनावश्यक कार्यों के एक समूह में बढ़ने लगती है - सिर्फ इसलिए कि एक काल्पनिक ग्राहक को इसकी आवश्यकता होती है। लेकिन शुरू में उत्पाद को एक सार्वजनिक सेवा के रूप में योजनाबद्ध किया गया था। यह देखने के लिए दर्दनाक है कि कैसे एक पतला इमारत सचमुच गिर रही है, क्षणिक कार्यों के ल्यूरिड ऐड-ऑन के साथ फट।



मैं समझता हूं: बाजार, प्रतियोगिता, समय, ग्राहक। लेकिन उपयोगकर्ताओं को मैनुअल देने और उनकी सनक का आँख बंद करके पालन करने से बुरा कुछ नहीं है। कार्यक्षमता के लिए दौड़ एक झूठी दौड़ है, इसे जीतने पर ग्राहक को छोड़कर, शायद, कोई पुरस्कार नहीं मिलेगा। उत्पाद का आकर्षण कार्यों की बहुतायत में नहीं है, लेकिन उनके उचित फिट, संतुलन, सुविधा में है।

इस स्थिति में एकमात्र तरीका उत्पाद को ब्रंच करना है: एक अलग उपयोगकर्ता शाखा बनाएं, और यदि यह विकास नीति है, तो इसमें आवश्यक फ़ंक्शन जोड़ें। साफ और समझ रखने के लिए एक सार्वजनिक शाखा। केवल यह दृष्टिकोण उपयोगकर्ताओं या डेवलपर्स के लिए खुशी नहीं लाएगा, क्योंकि दोनों शाखाएं धीरे-धीरे कार्यात्मक राक्षसों में बदल रही हैं, "डांसिंग भालू"।

ग्राहक की प्रेरणा स्पष्ट है - वह एक एकल उत्पाद प्राप्त करना चाहता है और उसका उपयोग करना चाहता है (हालाँकि उसकी कार्यक्षमता की आवश्यकता अन्य उत्पादों के साथ एकीकरण के माध्यम से प्राप्त की जा सकती है): मैं एक ही बार में और एक ही पैसे के लिए सब कुछ चाहता हूँ। अब केवल परिणाम ही नहीं है, जैसे कि एक अलग दादी की कंबल सैकड़ों कतरनों से बुना हुआ है, लेकिन गर्म और सुंदर है - लेकिन एक ही टुकड़े का एक फर्श चीर, जिस पर हर कोई अपने पैरों को पोंछता है और उन्हें बदलने के लिए नए कतरनों को सिलाई करता है। वैसे भी उपयोग करना संभव होगा - केवल यह मुश्किल और असुविधाजनक है। और उस गुण में नहीं।

समस्या का स्रोत है, ठीक है, उनमें से कम से कम दो हैं: एक उच्च-स्तरीय वैचारिक डिजाइन की कमी (जिसे इंटरैक्शन डिज़ाइन कहा जाता है - सिस्टम आर्किटेक्चर के साथ भ्रमित नहीं होना) और फिलहाल एक काल्पनिक ग्राहक को खुश करने की इच्छा। इन दो चीजों की अनुपस्थिति में, आप केवल फ़ंक्शन को यथासंभव सटीक रूप से भरकर उत्पाद की संकीर्णता को कम कर सकते हैं (हाँ - प्रयोज्य - परीक्षण, रीडिज़ाइनिंग)।

नैतिक: लेकिन उसकी नहीं। अधिक सटीक रूप से, यह स्पष्ट है - एक सामान्य सत्य, इसलिए बोलने के लिए। सिस्टम आर्किटेक्चर के साथ (और इससे पहले भी) वहाँ होना चाहिए (एक होना चाहिए!) एक स्पष्टीकरण चरण, हम क्या कर रहे हैं और हमारे उत्पाद की मदद से कौन से कार्य हल किए जा सकते हैं। लेकिन सबसे महत्वपूर्ण बात यह है कि इसे ग्राहकों तक पहुँचाया जाए। ताकि माइक्रोस्कोप के साथ नाखूनों को हथौड़ा करने की आवश्यकता न हो। खैर, एक विशिष्ट ग्राहक के लिए सेवाओं के साथ सार्वजनिक सेवाओं का मिश्रण न करें।