लोगों की बात सुनने के काम से इंजीनियरिंग के जरिए बचने की कोशिश न करें

 (ashley.rolfmore.com)
1 पॉइंट द्वारा GN⁺ 10 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • सॉफ़्टवेयर के कामकाजी माहौल की मुख्य कठिनाई बातचीत की कमी से ज़्यादा सुनने की कमी है, और इसे framework या system जैसे शब्दों में बदलकर हल करने की कोशिश वास्तव में ज़रूरी सुनने से बच निकलती है
  • किसी के अनुरोध को जस का तस पूरा करना, उसकी वास्तविक ज़रूरत समझने से अलग है, और विशेषज्ञता प्रभाव तथा technical/non-technical द्विभाजन सामने वाले के ज्ञान और संदर्भ को नज़रअंदाज़ कर देते हैं
  • अगर यह मान लिया जाए कि सभी के पास समान ऊर्जा, कौशल और धन है, या किसी एक व्यक्ति की विशेषता को पूरे समूह पर लागू कर दिया जाए, तो हर व्यक्ति की अलग बाधाओं और निर्णय मानदंडों को ठीक से पकड़ा नहीं जा सकता
  • लोग और संगठन समय, भूमिका, तनाव और समूह गतिशीलता के साथ बदलते रहते हैं, और जो कहा जाता है वह हमेशा असली सोच से मेल नहीं खाता, इसलिए स्थिर requirements अक्सर सॉफ़्टवेयर निर्माण से आसानी से असंगत हो जाते हैं
  • सुनने में विफलता सबसे मूल्यवान insights को खो देती है, और इससे राजस्व अवसर तथा प्रतिस्पर्धी बढ़त का नुकसान होता है, साथ ही गलतफहमियों के जमा होने से tech debt भी बढ़ता है

मुख्य तर्क

  • सॉफ़्टवेयर के कामकाजी माहौल में लोगों के बीच बातचीत की कमी से भी बड़ा मुद्दा सुनने की कमी है, और इसे framework या system जैसे शब्दों में बदलकर हल करने की कोशिश वास्तव में आवश्यक काम से बचने का तरीका है
  • डिज़ाइनर और product से जुड़े लोग अक्सर लोगों के साथ बातचीत को engineering के लिए अधिक स्वीकार्य अभिव्यक्ति में बदलने की कोशिश करते हैं, लेकिन बेहतर व्यवस्था से ज़्यादा ज़रूरी है लोगों की बात सही तरह से सुनना
  • इस आधार पर कि लोगों से बात करने की तुलना में लोगों की बात सुनना अधिक कठिन है, वास्तव में सुनने में बाधा बनने वाले प्रमुख जालों को व्यवस्थित किया गया है

सुनने में बाधा डालने वाले प्रमुख जाल

  • जो कहा गया है वही कर देना और सुनना अलग बातें हैं

    • किसी ने जो चाहा है उसे वैसा ही कर देना और वास्तविक ज़रूरत को सुनना एक ही बात नहीं है
    • इस विषय से जुड़े पुराने तरीकों के रूप में Jobs To Be Done, Outcome Driven Innovation, और UX क्षेत्र की empathy mapping का उल्लेख है

  • विशेषज्ञता प्रभाव के कारण अपनी दृष्टि को कम आंकना

    • किसी क्षेत्र में लंबे समय तक सीखने पर आसानी से यह मान लिया जाता है कि "इतना तो सभी जानते होंगे"
    • सामने वाला उस क्षेत्र का विशेषज्ञ हो तब भी यह ज़रूरी नहीं कि वह वही ज्ञान जानता हो, बल्कि वह अलग तरह का ज्ञान जान सकता है
    • सही तरह से सुनने के लिए यह अधिक समझना ज़रूरी है कि सामने वाला क्या जानता है

  • technical को एक ही श्रेणी मान लेना

    • यह सॉफ़्टवेयर डेवलपर्स में खास तौर पर आम जाल है; technical कोई एक गुण नहीं बल्कि अलग-अलग ज्ञान क्षेत्रों का बहुत व्यापक स्पेक्ट्रम है
    • अगर लोगों को "technical / non-technical" द्विभाजन में देखा जाए, तो insights छूट जाते हैं और सही तरह से सुन न पाने की संभावना बढ़ती है

  • यह मान लेना कि सभी के पास समान संसाधन हैं

    • अगर यह मान लिया जाए कि सभी के पास समान ऊर्जा, समान कौशल और समान अतिरिक्त धन है, तो गलत निर्णय होते हैं
    • समान स्वास्थ्य वाले लोग भी उसे संभालने के तरीके या वास्तव में कर सकने वाले कामों में अलग हो सकते हैं
    • कोई गणित में मजबूत हो सकता है, कोई दूसरी क्षमताओं में, और किसी के पास धन या अतिरिक्त गुंजाइश कम होने के कारण वह अधिक risk-averse तरीके से व्यवहार कर सकता है

  • एक व्यक्ति की विशेषता को पूरे समूह पर लागू कर देना

    • किसी एक विशेषता वाले व्यक्ति से मिलने का मतलब यह नहीं कि बाकी सब भी वैसे ही होंगे
    • उदाहरण के तौर पर यह रवैया कि बुज़ुर्ग लोग कंप्यूटर नहीं समझते
    • पूरे महिला समुदाय को व्यक्तिगत पारिवारिक संबंधों की छवि में समेट देना भी इसी तरह की गलती है

  • यह मान लेना कि लोग और संगठन स्थिर हैं

    • व्यापक स्तर पर व्यक्तित्व समय के साथ बदलता है
    • सूक्ष्म स्तर पर कार्यस्थल की persona और घर की छवि अलग हो सकती है, और तनाव या कुछ विशेष स्थितियों में निर्णय भी बदल जाते हैं

  • यह मान लेना कि कही गई बात और सोच एक ही है

    • कुछ लोग वही मतलब रखते हैं जो वे कहते हैं, लेकिन कुछ नहीं रखते
    • बहुत से लोग खुद को ईमानदार मानते हैं, जबकि वास्तव में ऐसा नहीं होता

  • लोगों का निर्णय करना

    • खराब तरीके से documented चीज़ को गलत समझने वाले व्यक्ति से नफ़रत करना या उसे dismiss कर देना, सही तरह से सुनने की संभावना को बहुत कम कर देता है
    • यह मान लेना कि सामने वाला अपना काम नहीं जानता या जीवन गलत तरीके से जी रहा है, सुनने में बाधा बनता है

  • 80 लोगों को 80 अलग इंसानों की जगह एक ही समूह मानना

    • B2B, B2C की तुलना में अक्सर और भी ज़्यादा मानवीय पहलू रखता है, जहाँ संबंध, dynamics, और org chart के बाहर की soft power जैसी चीज़ें काम करती हैं
    • समूह गतिशीलता जुड़ने पर व्यक्तिगत स्तर से भी अधिक जटिल चर सामने आते हैं

स्थिर requirements और सॉफ़्टवेयर के बीच असंगति

  • लोग और संगठन बदलते हैं, इसी वजह से fixed project management सॉफ़्टवेयर निर्माण के लिए उपयुक्त नहीं है
  • शुरुआत में requirements तय कर देने पर भी इस बीच लोग बदल जाते हैं, और जब परिणाम आता है तो वह अधिकतम शुरुआत के समय किए गए अनुरोध से ही मेल खाता है
  • रिलीज़ के समय तक संभव है कि वही चीज़ अब वांछित न हो, और इंतज़ार के दौरान लोग अपनी-अपनी अपेक्षाएँ जोड़ लेते हैं, इसलिए वास्तविकता उन सब अपेक्षाओं से मेल नहीं खाती

परिणाम और प्रभाव

  • लोगों की बात सही तरह से न सुन पाने पर सबसे मूल्यवान insights छूट जाते हैं, और इससे राजस्व अवसर तथा प्रतिस्पर्धी बढ़त खो जाती है
  • गलतफहमियाँ जितनी जमा होती जाती हैं, उतना ही बाद में साथ काम किए जाने वाले कोड में नए तत्व जुड़ते जाते हैं, और कुछ tech debt के कारणों को कम करने का संबंध भी सुनने से है
  • जितना अधिक हम उन क्षणों को पहचानते हैं जब हम सुन नहीं पा रहे होते, उतनी अधिक संभावना होती है कि हम बेहतर सुन पाएँ

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.