पहले सवाल का जवाब मत दो

 (lalitm.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • performance debugging tools में किसी अजीब अनुरोध का तुरंत जवाब देने के बजाय उसका संदर्भ पूछना चाहिए, ताकि उपयोगकर्ता की असली समस्या और टूल की कमियाँ सामने आ सकें
  • यह सिर्फ XY problem से निपटने से आगे की बात है; गलत सवाल पैदा करने वाली उलझन को ही शुरुआती बिंदु बनाकर उपयोगकर्ता और प्रोडक्ट, दोनों की समझ बेहतर होती है
  • Perfetto में हर metric की गणना के लिए trace का इस्तेमाल करना संभव तो है, लेकिन अप्रभावी है; dedicated metric collection system ज़्यादा उपयुक्त हो सकता है
  • trace को बाँटने जैसे अनुरोधों में, जहाँ ऊपर से दिखने वाला जवाब और असली ज़रूरत अलग हो सकती है, वहाँ periodic trace snapshots जैसी मौजूदा सुविधा बेहतर रास्ता हो सकती है
  • प्रोडक्ट बदलाव तब करना बेहतर होता है जब बार-बार उभरने वाली ज़रूरत पर्याप्त रूप से स्पष्ट हो जाए; जल्दबाज़ी में feature जोड़ना बड़े technical debt में बदल सकता है

पहले सवाल का तुरंत जवाब न देने की वजह

  • Perfetto जैसे performance debugging tools में अगर उपयोगकर्ता पूछे, “Perfetto trace को कई फ़ाइलों में कैसे बाँटें?”, और सवाल अजीब लगे, तो सीधे तरीका बताने के बजाय पहले यह पूछना चाहिए, “आपको इतना बड़ा trace collect करने की ज़रूरत क्यों पड़ी?”
  • यह तरीका सिर्फ XY problem हल करने से एक कदम आगे जाता है
    • यह सिर्फ उपयोगकर्ता के सवाल को “असल इरादे” में बदलकर जवाब देकर खत्म नहीं करता, बल्कि गलत सवाल पैदा करने वाली उलझन को ही बातचीत की शुरुआत बनाता है
    • उपयोगकर्ता को टूल के बारे में बेहतर mental model मिलता है, और टूल बनाने वालों को यह ज़्यादा साफ़ दिखता है कि प्रोडक्ट कहाँ भ्रम पैदा कर रहा है
    • कभी-कभी बातचीत का अंत इस नतीजे पर भी पहुँचता है कि प्रोडक्ट को ही बदलना चाहिए
  • यह तरीका खास तौर पर engineering tools बनाने वालों पर सीधे लागू होता है
    • consumer products या B2B services में इसे उतनी सीधाई से लागू करना मुश्किल हो सकता है, लेकिन मूल दृष्टिकोण फिर भी उपयोगी रह सकता है

अनुरोध को समझने का तरीका

  • हर सवाल के लिए गहरी बातचीत ज़रूरी नहीं होती
    • कुछ आसान और बार-बार आने वाले सवाल सिर्फ documentation दिखाकर सुलझाए जा सकते हैं; वे यहाँ चर्चा का विषय नहीं हैं
    • दिलचस्प मामला वह है जहाँ पहले अनुरोध से संदर्भ पूरा नहीं मिलता, और सवाल खुद सामान्य से अलग दिखता है
  • अजीब सवाल में यह देखा जाता है कि असंगति कहाँ है
    • क्या यह ऐसा सवाल है जो पहले कभी देखा गया है; अगर नहीं, तो इसे दुर्लभ अनुरोध मानकर थोड़ा धीमे चलना चाहिए
    • क्या दूसरे सवालों की तुलना में यह तर्कसंगत लगता है; अगर नहीं, तो उसके नीचे छिपे किसी और सामान्य सवाल को खोजा जाना चाहिए
    • क्या यह अनुरोध टूल की संरचना से मेल खाता है, या उपयोगकर्ता अनजाने में architecture के खिलाफ़ जा रहा है
  • असंगति मिल जाने पर ऐसे सवाल पूछे जाते हैं जिनसे छूटा हुआ संदर्भ सामने आए
    • जैसे, सीधा जवाब X है, लेकिन कारण Y की वजह से यह काफ़ी असामान्य अनुरोध लगता है, इसलिए पहले थोड़ा बड़ा problem space समझना चाहूँगा
    • इसके बाद बातचीत की रफ़्तार इस पर निर्भर करती है कि उपयोगकर्ता अपनी बात कितनी स्पष्टता से समझा पाता है
  • आम तौर पर बातचीत तीन नतीजों में से किसी एक तक पहुँचती है
    • उपयोगकर्ता टूल की philosophy को मिस कर रहा है
    • सही रास्ता प्रोडक्ट में मौजूद है, लेकिन साफ़ दिखाई नहीं देता
    • या फिर प्रोडक्ट को ही बदलना चाहिए

जब टूल की philosophy समझ में न आए

  • अक्सर उपयोगकर्ता किसी टूल तक इस हालत में पहुँचते हैं कि उन्हें ठीक-ठीक यह भी नहीं पता होता कि वे क्या चाहते हैं या कौन-सी समस्या हल करना चाहते हैं
    • इसका मतलब यह नहीं कि उपयोगकर्ता की आलोचना की जा रही है
    • टीमें सीमित समय और संसाधनों में समस्या सुलझाते हुए जब आगे नहीं बढ़ पातीं, तब नया debugging tool ढूँढती हैं
    • भले ही टूल उनकी ज़रूरी functionality का बड़ा हिस्सा देता हो, अगर वह उनके इस mental model से मेल नहीं खाता कि “यह ऐसे काम करना चाहिए”, तो वे feature request करने लगते हैं
  • Perfetto में इसका आम उदाहरण है trace को हर metric निकालने का सर्व-उपयोगी समाधान मान लेना
    • Perfetto trace किसी निश्चित समयावधि में डिवाइस ने क्या किया, उसका बहुत विस्तृत रिकॉर्ड रखता है
    • trace से metrics निकाले जा सकते हैं, इसलिए उपयोगकर्ता frame rate, app memory usage जैसे मान भी trace से ही निकालना चाहते हैं
    • सिद्धांततः trace से किसी भी metric की गणना की जा सकती है
  • लेकिन हर metric के लिए trace का इस्तेमाल अप्रभावी है
    • trace collect और process करना महँगा पड़ता है
    • सिर्फ एक संख्या चाहिए हो तब भी पूरे सिस्टम का data collect करना पड़ता है
    • dedicated metric collection system वही काम कहीं ज़्यादा कुशलता से कर सकता है
  • हर टूल की अपनी design philosophy होती है, और उपयोगकर्ता तात्कालिक समस्या पर ध्यान देते हुए उसे आसानी से नज़रअंदाज़ कर सकते हैं
    • सिर्फ Perfetto चलाने का तरीका बताना काफी नहीं है; performance engineering के बारे में सोचना कैसे है, यह सिखाना भी ज़रूरी है
    • startup time, frame drops, memory, power जैसे विषयों को कैसे समझना और handle करना है, यह बताना चाहिए
    • यह समझ बनानी चाहिए कि सामान्य स्थिति और समस्या की स्थिति, दोनों में कौन-सा टूल कैसे इस्तेमाल करना है

जब सही रास्ता छिपा हुआ हो

  • कभी-कभी उपयोगकर्ता समस्या को समझता है, लेकिन यह नहीं जानता कि मौजूदा tools को साथ मिलाकर कैसे इस्तेमाल किया जाए
    • टूल को जानबूझकर बहुत शक्तिशाली बनाया गया होता है, और यह मान लेना ठीक नहीं कि दूसरी टीम हर capability की पूरी सीमा समझती होगी
    • जब असली ज़रूरत स्पष्ट होती है, तो अक्सर पता चलता है कि किसी और उद्देश्य के लिए बना feature ही उपयोगकर्ता की ज़रूरत पूरी कर सकता है
  • trace splitting का अनुरोध इसका अच्छा उदाहरण है
    • उपयोगकर्ता कहता है कि लंबी trace में एक दिलचस्प हिस्सा है और वह उसे काटकर अलग करना चाहता है
    • वजह यह है कि इससे performance analysis और visualization आसान हो जाएँगे
    • लेकिन इस स्थिति में शुरू से लंबी trace collect ही न करना ज़्यादा सही तरीका हो सकता है
  • Perfetto में पहले से periodic trace snapshots मौजूद हैं
    • यह एक लंबी रिकॉर्डिंग की जगह छोटी रिकॉर्डिंग्स को बार-बार सेव करने की सुविधा है
    • इससे लंबी trace collect करने के बाद उसे बाँटने की ज़रूरत ही खत्म हो सकती है
  • उपयोगकर्ता ने जो जवाब माँगा है, वह और जो जवाब वास्तव में चाहिए, वे अलग हो सकते हैं
    • “बस, मुझे यही चाहिए था” जैसी प्रतिक्रिया इस बात का संकेत है कि आपने उसके सोचे हुए अनुरोध का नहीं, बल्कि उसकी असली ज़रूरत का पता लगाया

जब प्रोडक्ट को बदलना चाहिए

  • कुछ प्रतिक्रियाएँ ऐसी नई ज़रूरत दिखाती हैं जो प्रोडक्ट में बड़े बदलाव की ओर ले जा सकती हैं
    • ऐसे मामले मुश्किल होते हैं
    • अनुरोध नया हो सकता है, लेकिन अनुरोध करने वाला खुद भी यह साफ़-साफ़ नहीं बता पाता कि उसे वास्तव में क्या चाहिए
  • foundational software में गलत फ़ैसले की कीमत बहुत ज़्यादा होती है
    • इसलिए बेहतर यह है कि जो चीज़ नहीं है, उसे तब तक न बनाया जाए जब तक उसकी कमी सच में दर्द न देने लगे
    • जब कई टीमें एक जैसी ज़रूरत जताने लगती हैं, तब अक्सर उसका असली core स्पष्ट होने लगता है, जिसे बनाना वाकई सार्थक है
    • सिर्फ एक अनुरोध से उस core को पकड़ना बहुत कठिन होता है, इसलिए इंतज़ार करना शक्तिशाली रणनीति है
  • Perfetto का ad-hoc UI customization गलत फ़ैसले का उदाहरण है
    • लोग अपने workflow के हिसाब से UI को hack करना चाहते थे और इस बात की लगातार शिकायत करते थे कि यह मुश्किल है
    • जैसे ही इसे अनुमति दी गई, बहुत बड़ा technical debt पैदा हो गया
    • हर नया feature बाकी सभी मौजूदा features के साथ interact करने लगा, और पूरी संरचना तेज़ी से non-scalable बन गई
    • इस स्थिति से बाहर निकलने के लिए एक सही plugin API डिज़ाइन करने में लगभग 1 साल लग गया
  • असली ज़रूरत यह थी: “हर उपयोगकर्ता को प्रभावित किए बिना, टीम या use case के हिसाब से UI को personalize करने का तरीका”
    • यह ज़रूरत शुरुआत से साफ़ शब्दों में सामने नहीं आई थी
    • अनुरोधों की इस धारा में इसे जल्दी पहचानने की ज़िम्मेदारी प्रोडक्ट बनाने वालों की थी
  • Perfetto trace को “merge” करने की सुविधा एक अच्छे फ़ैसले का उदाहरण है
    • लोग इसे बार-बार माँगते रहे, लेकिन इसे तुरंत नहीं बनाया गया
    • workaround बताए गए और स्थिति को देखते रहने का रवैया रखा गया
    • यह पहले से समझा गया था कि इसे सही तरह बनाना कठिन और गलत तरह बनाना आसान है
    • problem space को पर्याप्त रूप से समझ लेने के बाद, पिछले साल इसे maintainable तरीके से implement किया गया

मुख्य सीख

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

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय

  • लेखक कहता है कि यह लेख XY problem से कहीं आगे जाता है, लेकिन मुझे यह उल्टा XY problem को रोचक insights के साथ विस्तार से समझाने वाला लेख ज़्यादा लगा

    • मुझे नहीं लगता कि यह असल में XY problem पर लेख है। यह XY problem से कहीं अधिक व्यापक रूप से लागू होता है, और जवाब देने वाले के लिए इसे “यह XY problem है” मान लेने जितना ख़तरनाक भी नहीं है
      सवाल को XY problem के फ़्रेम में डालने पर, XY problem जैसा दिखने वाले सवालों का जवाब देते समय लोग जिन उल्टे असर वाले heuristics का इस्तेमाल करते हैं, उन्हीं पर वापस लौटने की संभावना बढ़ जाती है
      सलाह लेने की कोशिश करते हुए मुझे अनगिनत बार यह झेलना पड़ा है कि आसपास के लोग तय मान लेते हैं कि मैं XY problem से जूझ रहा हूँ, और तब तक मुझे लगातार सफ़ाई देनी पड़ती है जब तक मैं ऐसे किसी व्यक्ति तक न पहुँच जाऊँ जो मैंने लिखा है उसे सच में ध्यान से पढ़े। प्रोग्रामिंग संस्कृति में XY problem से निपटने का तरीका मुझे गलत तरह से overcorrected लगता है, और यह लेख उस ग़लत overcorrection के ख़िलाफ़ एक जवाब जैसा पढ़ा जाता है
      भले ही लगे कि प्रश्न पूछने वाला मुझसे बहुत कम जानता है, फिर भी गति धीमी रखना और pattern matching न करना महत्वपूर्ण है। शुरू से ही यह मान लेने का कोई भारी कारण नहीं कि यह XY problem ही होगा, और अगर हो भी, तब भी कई बार उसे वैसा न मानकर संभालना बेहतर हो सकता है

  • लेख अच्छा था। इससे उसी सिक्के का दूसरा पहलू याद आया: सावधान रहना चाहिए कि पूछे गए सवाल को किसी अधिक सरल सवाल में बदलकर उसी का जवाब न दे बैठें
    जैसे, “Amsterdam और San Francisco के बीच की दूरी कितनी है?” के जवाब में “फ़्लाइट से 12 घंटे लगते हैं” कहना
    सवाल दूरी के बारे में था, लेकिन दूरी बताना मुश्किल है और उड़ान का समय ज़्यादा आसानी से दिमाग़ में आता है, इसलिए जवाब देने वाला आसान सवाल में बदलकर उसका जवाब दे देता है
    ऐसा काफ़ी बार दिखता है, और ख़ासतौर पर तब ज़्यादा होता है जब सवाल पूछने वाले और जवाब देने वाले के बीच power distance हो

  • कई कारणों से system modernization के दौरान मैंने ingress router में 404 page जोड़ा, और उससे समस्या पैदा हो गई। एक developer ने कहा कि पुराना 404 behavior वापस चाहिए, क्योंकि पुराने page में navigation bar और menu थे
    और गहराई से पूछने पर पता चला कि कुछ customer configurations में login करते समय हमेशा 404 आता है, और ग्राहक पुराने 404 page के ज़रिए वास्तव में जहाँ जाना चाहिए था वहाँ पहुँच रहे थे
    ऐसे ही पलों के लिए lolcry का आविष्कार हुआ था 🤣😭

    • > GET /hyrums-law HTTP/1.1  
> Host: ingress.customer.doctor_eval.work  
>  
< HTTP/1.1 404 Not Found  
< Content-Type: text/plain  
<  
< API उपयोगकर्ताओं की संख्या काफ़ी अधिक हो जाने पर,  
< कॉन्ट्रैक्ट में क्या वादा किया गया है, इससे फ़र्क नहीं पड़ता:  
< सिस्टम के हर observable behavior पर  
< कोई न कोई निर्भर हो जाएगा।  
<

  • @lalitm, यह समस्या इंटरनेट से भी पुरानी है और इसका नाम पहले से है: requirements analysis
    Ed Yourdon आदि ने उपयोगकर्ता जो परिणाम पाना चाहता है, उस process और उस परिणाम तक पहुँचने के तरीक़े यानी procedure में फ़र्क किया था। उदाहरण के लिए, ग्राहक को यह बताना कि उसका ऑर्डर भेज दिया गया है एक process है, जबकि वह जानकारी email से भेजना एक procedure है
    सिस्टम के उपयोगकर्ता अक्सर समाधान को सिस्टम की functionality की तरह सोचते हैं। प्रोग्रामर भी इससे अलग नहीं हैं, इसलिए “X में Y solve करना” जैसे रूप बहुत दिखते हैं। analyst का काम किसी विशेष implementation form से requirements निकालना है, और engineer के रूप में उसके बाद समाधान implement किया जा सकता है
    हाल ही में मैं एक चर्चा में था जहाँ कहा गया कि syslog(3) backlog में दब जाता है और events log से गायब हो जाते हैं, इसलिए logging को और तेज़ बनाना चाहिए। लेकिन असली समस्या तेज़ logging नहीं थी। उपयोगकर्ता तेज़ logging नहीं चाहते; वे अपनी समस्या हल करना चाहते हैं। ज़रूरी जानकारी देना process है, और सब कुछ log में लिखना उसका सिर्फ़ एक तरीका है
    Yourdon, CASE tools के समर्थकों में से एक थे। अगर management quality और productivity को माप पाता, तो शायद वह सफल होता, लेकिन वह किसी और दिन की शिकायत है

  • कहा जाता है, “ग़लत सवाल पैदा करने वाली उलझन ख़ुद एक अवसर है,” लेकिन अगर आप उस क्षेत्र के सबसे बड़े expert नहीं हैं, तो शुरुआत में ही यह तय कर लेना काफ़ी मुश्किल है कि कौन-सा सवाल ग़लत है

    • सही बात। और कई बार यह समझने में समय लगाना कि किसी संगठन की कौन-सी अजीब परिस्थितियाँ ऐसे “ग़लत” सवाल तक ले आईं, किसी के भी काम का नहीं होता

  • दरअसल जवाब देना चाहिए
    अगर आप अपनी कीमती मानसिक ऊर्जा के gatekeeper नहीं हैं, तो improvisation की strategy की तरह “हाँ, और…” वाला तरीका अपनाना चाहिए। हाँ, साथ में यह भी जोड़ सकते हैं कि मनचाहा परिणाम पाने के और भी तरीके हो सकते हैं
    अटकी हुई स्थिति को खोलने के लिए एक ही strategy पर निर्भर रहने के बजाय, जितनी संभव हों उतनी strategies इस्तेमाल करना बेहतर है

    • यह अभिव्यक्ति मुझे बहुत पसंद आई। संदेश के उलझ जाने के रास्ते अनगिनत हैं, और समस्या की जड़ तक पहुँचने में मदद करने के लिए कई approaches चाहिए होती हैं। और यह भी ज़ाहिर है कि उलझन में हमेशा सामने वाला ही हो, ऐसा नहीं है