गैर-डेवलपर निर्णयकर्ताओं के लिए तकनीक को स्पष्ट रूप से समझाने का तरीका [अनुवादित लेख]

1. इस बात पर ज़ोर दिया गया है कि संगठन के भीतर तकनीकी स्पष्टता प्रदान करने में इंजीनियर की भूमिका सबसे केंद्रीय होती है.

   • तकनीकी स्पष्टता का मतलब ऐसी स्थिति से है जिसमें गैर-डेवलपर लीडर software system में होने वाले बदलावों को पर्याप्त रूप से समझ सकें और तर्कसंगत निर्णय ले सकें.

2. संगठन के भीतर तकनीकी स्पष्टता दुर्लभ क्यों होती है और इसे आसानी से हासिल क्यों नहीं किया जा सकता.

   • software बहुत जटिल होता है, और इंजीनियरों के लिए भी अपने system को पूरी तरह समझ पाना कठिन होता है.
   • गैर-तकनीकी लीडरों के पास समय और background knowledge सीमित होती है.

3. व्यावहारिक तकनीकी सवालों के उदाहरण.

   • नई feature deploy करते समय गैर-तकनीकी लीडरों को ज़रूर जानने चाहिए ऐसे प्रतिनिधि सवाल:
     1. क्या paid feature को free users तक सुरक्षित रूप से उपलब्ध कराया जा सकता है?
     2. क्या gradual rollout संभव है?
     3. समस्या होने पर क्या सुरक्षित rollback संभव है?
     4. क्या early access अधिकार दिया जा सकता है?
     5. capacity issue होने पर क्या paid users को प्राथमिकता दी जा सकती है?

4. औपचारिक/अनौपचारिक तकनीकी सलाहकार का अर्थ और उसका महत्व.

   • staff engineer या senior engineer गैर-डेवलपर लीडरों के ‘प्रतिनिधि’ की तरह system की जटिलता को abstract करके आसान भाषा में समझाने की भूमिका निभाते हैं.
   • जो इंजीनियर तकनीकी स्पष्टता अच्छी तरह प्रदान करते हैं, वे संगठन का भरोसा जीतते हैं और महत्वपूर्ण projects में लगाए जाते हैं.

5. इंजीनियरों द्वारा अनुभव की जाने वाली अनिश्चितता और उसका संतुलन.

   • इंजीनियर अपनी विशेषज्ञता को लेकर हमेशा थोड़ी असुरक्षा और सतर्कता बनाए रखते हैं, और अधिकतर मामलों में केवल 95% भरोसा ही रखते हैं.
   • गैर-डेवलपर लीडरों के सामने इस चिंता या सभी तकनीकी details को पूरी तरह उजागर करने के बजाय, केवल मुख्य बात स्पष्ट रूप से बतानी चाहिए.

6. अनिश्चितता को उजागर करना हमेशा सही नहीं होता.

   • जब इंजीनियर तकनीकी रूप से अत्यधिक विस्तृत जानकारी देकर स्पष्टता (सरल समझ) को धुंधला कर देते हैं, तो निर्णयकर्ताओं के लिए सही निर्णय लेना कठिन हो जाता है.
   • केवल मुख्य recommendation और risk factors को स्पष्ट रूप से व्यवस्थित करके साझा करना चाहिए.

7. तकनीकी स्पष्टता पहुँचाने के 3 सिद्धांत.

   • (1) क्या बताना है और क्या छोड़ना है, इसे पहचानने की सहज समझ.
   • (2) system की गहरी तकनीकी समझ (सीधे coding और project execution के माध्यम से).
   • (3) management के सामने आत्मविश्वास के साथ सरल बनाई गई बड़ी तस्वीर पेश करना.

[ng0301]

असलियत यह है... उसे जानते हों तब भी, उससे आगे बहुत कुछ होता है...

[geekgig]

मुझे नहीं पता कि यह टिप्पणी इस लेख के उद्देश्य के अनुरूप है या नहीं...

यह नज़रिए का फर्क हो सकता है,
लेकिन आखिरकार मुझे लगता है कि सबसे महत्वपूर्ण चीज़ निर्णय लेने वाले की इच्छा ही होती है।

वह जानना ही नहीं चाहता,
बस यह सुनना चाहता है कि हर हाल में हो जाएगा,
और यह भी सुनना चाहता है कि आप खुद ही संभाल लेंगे,

तो लगता है कि समझाना दरअसल निर्णयकर्ता को असुविधाजनक बात कहना ही होगा।

ps.
लगता है कि इस बात के पीछे यह पूर्वधारणा है कि निर्णयकर्ता ही सही होता है?
अगर निर्णयकर्ता = रेफरी को यह पसंद नहीं है, तो आखिरकार मुझे लगता है कि कोई भी तरीका बेकार ही होगा।