सहयोगी संस्कृति के 4 स्तंभ

सुरक्षा, गति, स्पष्टता और प्रतिबद्धता।

सहयोगी संस्कृति के 4 स्तंभ

क्या आपकी टीम के सभी सदस्य नियमित रूप से विचार साझा करते हैं? प्रतिक्रिया देते या प्रश्न पूछते हैं? क्या वे कमजोर हो सकते हैं? मिशन को सुरक्षित रूप से चुनौती दे सकते हैं?

सहयोग की संस्कृति के 4 आवश्यक स्तंभ हैं:

• सुरक्षा।
• गति।
• स्पष्टता।
• प्रतिबद्धता।

पहले दो एक-दूसरे को काफी प्रभावित करते हैं: सुरक्षा और गति। अगले 2 स्तंभ सुनिश्चित करेंगे कि आपकी प्रक्रिया निकट और दीर्घकालिक दोनों में मूल्य प्रदर्शित करे।

4 स्तंभ

• सुरक्षा: क्या विफल होना सुरक्षित है? क्या प्रयोगों का स्वागत किया जाता है?
  • एक “विफलता” हमेशा सीखने और सुधारने का अवसर होती है।
  • क्या आप स्थिति या राय बदलने पर चर्चा करते हैं और उसे अपनाते हैं?
  • नेतृत्व को “अस्वीकृत” प्रस्तावों से मिली सीख को उजागर करना चाहिए। भले ही कोई प्रस्ताव “जीता” न हो
  • दिखाएं कि मूल कारण विश्लेषण कहाँ उचित है? (क्या यह OKRs के साथ संरेखित नहीं था? क्या नेतृत्व लक्ष्यों को स्पष्ट या संकीर्ण कर सकता था?)
• गति: मसौदा तैयार करने में कितना समय लगना चाहिए?
  • अंगूठे का नियम: आदर्श रूप से 1-20 मिनट; अधिकतम 2 घंटे।
  • यहाँ गति दक्षता के बारे में है। यह आप और आपके सहकर्मियों दोनों के समय का सम्मान करता है।
• स्पष्टता: क्या आप स्पष्ट और क्रियान्वयन योग्य निर्णय देते हैं? क्या सभी शामिल लोगों के लिए मूल्य स्पष्ट है? बाहरी टीमों को पहले सूचना मिलने से होने वाले मूल्य पर विचार करें, कानूनी और अनुपालन वाले लोग जिन कोड पर आपत्ति कर सकते हैं उस पर बर्बाद हुए प्रयास से बचें।
• प्रतिबद्धता: क्या आप 2 सप्ताह पहले लिए गए निर्णय ढूंढ सकते हैं? 3 स्पिंट पहले? यदि नहीं, तो अधिक समय बिताना समझदारी नहीं होगी

टीमों को अपने नियम और अपेक्षाएँ परिभाषित करनी चाहिए

सुझाव: टीम के रूप में काम करने का सबसे अच्छा तरीका चर्चा करें और निर्धारित करें। आवश्यकतानुसार समायोजित करें।

अपने निष्कर्षों को यथासंभव संक्षिप्त रूप से दस्तावेज़ करें, उदाहरण के लिए:

• UI से संबंधित किसी भी चीज़ के लिए इंट्रो में स्क्रीनशॉट पसंद किए जाते हैं।
• 1-पंक्ति पाठ सारांश पसंद किया जाता है। (BizDev या नई सुविधाओं के लिए 1-पैराग्राफ का उपयोग करें।)
• अंतिम निर्णय की नियत तिथि से पहले प्रस्तावित समाधान में मॉक स्क्रीन।
• क्या आप विशिष्ट लेबल सिफारिशें करते हैं: (उदा. Urgent, [Team-Name], Needs C-Level Approval, Hackathon, Spike related.)

आपकी टीम के लिए विचार

इस प्रक्रिया के बारे में सोचने के लिए कुछ समय निकालें, अपनी टीम को दिखाएं कि आप एक ऐसे वातावरण को महत्व देते हैं जहाँ उनके विचार सुने जाते हैं।

इन क्षेत्रों पर ध्यान दें:

• स्पष्ट और न्यूनतम अपेक्षाएँ निर्धारित करें। आमतौर पर यह प्रति भूमिका/प्रभाग परिभाषित होता है (उदा. वित्त, सुरक्षा, घटना प्रतिक्रिया, इंजीनियरिंग, कार्यकारी।)
  • साझा करने के लिए कोई मसौदा बहुत कच्चा नहीं है। (ऐसा संकेत देने के लिए स्पष्ट लेबल का उपयोग करें।)
  • क्या सही वर्तनी और व्याकरण की अपेक्षा की जाती है? (कार्यकारी प्रस्तावों के लिए, हाँ। लेकिन सुरक्षा घटनाएँ व्याकरण को कम प्राथमिकता दे सकती हैं।)
  • क्या स्केच या आरेख पसंद किए जाते हैं? (नेटवर्क परिवर्तनों के लिए फ्लोचार्ट आवश्यक हो सकते हैं। बिक्री पूर्वानुमान उस टीम में सामान्य हो सकते हैं।)
  • क्या लेखक से समस्या का समाधान प्रस्तावित करने की अपेक्षा की जाती है? (या एक प्लेसहोल्डर “स्ट्रॉ” समाधान?)
• कई उदाहरण प्रस्ताव प्रदान करें
  • प्रत्येक मोड में संक्षिप्त उदाहरण बनाएं।
  • टीम के साथियों को शामिल करने के लिए लंबित निर्णयों का उपयोग करें।
• अपने समूह की प्रकृति के आधार पर, आचार संहिता पर विचार करें
  • यदि तृतीय पक्ष, गैर-कर्मचारी, ओपन सोर्स समुदाय आदि शामिल हैं तो महत्वपूर्ण।
• सहानुभूति
  • लोग अक्सर विचार साझा करते समय चिंतित होते हैं। यह मानवीय है, यहाँ तक कि रॉक स्टार्स भी प्रदर्शन करते समय घबराते हैं।
  • अपनी टीम के लोगों की संचार प्राथमिकताओं और आवश्यकताओं को समायोजित करें।
  • इसके बारे में बात करें अपने समूह के साथ (या व्यक्तिगत रूप से) नियमित रूप से। अक्सर एक त्वरित पेयरिंग सत्र या ब्रेनस्टॉर्मिंग अनब्लॉक करने और पुनः ऊर्जा देने में मदद कर सकता है।

सुझाव: शीर्षक लिखते ही प्रस्ताव साझा करने की आदत बनाएं।

यह ठीक है यदि यह कुछ समय तक ड्राफ्ट में है।

जब भी कोई प्रस्ताव आगे बढ़ने के लिए तैयार हो, हितधारकों को शामिल करें, चर्चा करें और आगे बढ़ें।

जैसे-जैसे प्रस्ताव विकसित होते हैं, ड्राफ्ट विचारों का बैकलॉग अवसरों का स्रोत बन जाता है।

क्या नए विचारों का स्वागत किया जाता है? क्या आप “अजीब” प्रस्तावों का जश्न मनाते हैं? इससे विचारों के मूल्य और मात्रा पर प्रभाव पड़ेगा।

आप जो देखना चाहते हैं उसका मॉडल बनाने के बारे में जानबूझकर रहें।

दायरा और अपेक्षाएँ

जब भी संभव हो, प्रस्ताव का उत्तर देना आदर्श रूप से कुछ क्लिक की प्रक्रिया होनी चाहिए।

तय करें कि क्या आपको विस्तृत नोट्स के साथ लंबे विश्लेषण की आवश्यकता है, या एक त्वरित 1-पंक्ति टिप्पणी, या यहाँ तक कि इमोजी वोट।

अपेक्षाएँ स्पष्ट होनी चाहिए। “WORK IN PROGRESS,” या “Feasibility Comments Requested” जैसे लेबल से दस्तावेज़ों की गुणवत्ता के स्तर का वर्णन करने की कोशिश करने से आमतौर पर टिप्पणीकारों को ऊर्जा नहीं मिलती है। टीमों को यह जानने का लाभ होता है कि किस प्रकार के डिलिवरेबल की अपेक्षा की जाती है।

अस्वीकृति (या विफलता की धारणा) कभी भी हतोत्साहित करने वाली नहीं बननी चाहिए। यहाँ “त्रुटि की संस्कृति” महत्वपूर्ण है: जल्दी/अधिक बार विफल होने को अपनाएं! सस्ते और शुरुआती फीडबैक लूप को महत्व दें!

प्रत्येक टीम के यहाँ अलग नियम और प्राथमिकताएँ होंगी। रेट्रोस्पेक्टिव के हिस्से के रूप में अपने दृष्टिकोण पर प्रतिबिंबित करने और उसे सुधारने का प्रयास करें।

सफलता मापना

विचार करें कि आपके संगठन में विचार कैसे आते और विकसित होते हैं:

• आपके कर्मचारियों/टीम का कितना प्रतिशत विचार साझा करता है?
• किसी कर्मचारी के पहले सुझाव से पहले औसत समय कितना है? दिन? महीने? साल?!?!?
• क्या आपकी टीम के सभी सदस्य नियमित रूप से विचार साझा करते हैं?
• क्या लोग सुरक्षित महसूस करते हैं? क्या वे कमजोर हो सकते हैं? यहाँ तक कि मिशन पर प्रश्न उठा सकते हैं?