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

हम मानते हैं कि एक केंद्रीय स्थान पर सभी कंपनी ज्ञान को उपलब्ध कराना सबसे कुशल है, और हम यह भी जानते हैं कि इंजीनियरिंग टीमों की आवश्यकताएँ विशिष्ट, बारीक और तकनीकी होती हैं। आइए उन कुछ तरीकों के बारे में बात करते हैं जिनसे Guru इंजीनियरिंग टीमों की दस्तावेज़ आवश्यकताओं का समर्थन करता है, हमारे अपने टीम और Guru ग्राहक RS21 के उदाहरणों के साथ।

पर्यावरण सेटअप और पारिस्थितिकी संलग्न

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

कई इंजीनियरिंग टीमों के लिए, ऑनबोर्डिंग प्रक्रिया एक अन्य सहयोगी के लिए श्रमसाध्य हो जाती है, जिसे नए कर्मचारी का "साथी" नामित किया जाता है और जो उन्हें वास्तविक समय में इस जानकारी के माध्यम से ले जाएगा। लेकिन अपनी टीम के लिए विशेषज्ञ-की पुष्टि किए गए, अद्यतन कार्ड Guru में, RS21 के इंजीनियरिंग नेता नए कर्मचारियों को अपने गति पर ऑनबोर्ड होने की लचीलापन देते हैं। इससे उन्हें अपने ऑनबोर्डिंग "साथी" के साथ अधिक व्यक्तिगत संबंध बनाने या असाधारण सवालों के लिए समय बचाने में मदद मिलती है।

जब एक नया इंजीनियर RS21 की टीम में शामिल होता है, तो वे Guru में लॉगिन कर उनकी ऑनबोर्डिंग सामग्री के माध्यम से काम करना शुरू करते हैं। वे "टीम जानकारी" बोर्ड को देखेंगे जहाँ वे अपने सहयोगियों के बारे में थोड़ा जान सकते हैं, बुनियादी ढांचे के कार्ड का उपयोग करके अपने पर्यावरणों को सही तरीके से सेट कर सकते हैं, और अपनी टीम के कोडिंग मानकों को पढ़ सकते हैं ताकि अपने नए सहयोगियों के साथ सहयोग करने का सबसे अच्छा तरीका समझ सकें।

इसी तरह, Guru में, जब कोई इंजीनियर नई टीम में शामिल होता है या एक नई टीम में जाता है, तो उनकी ऑनबोर्डिंग Guru में होती है। वे जीवन कहानी कार्ड का उपयोग करके अपने सहयोगियों को जानेंगे, एक साथ काम करने की उम्मीद कैसे करें के बारे में मार्गदर्शिकाएँ देखेंगे और अपने नए टीम के संग्रह का ब्राउज़ करेंगे ताकि उत्पाद की विशेषताओं और क्षेत्रों से परिचित हो सकें जिनके लिए वे अब जिम्मेदार हैं।

सर्वश्रेष्ठ प्रथाएँ और टीम मानक

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

RS21 की इंजीनियरिंग संग्रह में Guru में एक बोर्ड शामिल है जिसे प्रक्रिया दिशानिर्देशों के लिए समर्पित किया गया है, जिसमें कोड मर्ज करने, बैश स्क्रिप्ट बनाने, कोड समीक्षा का अनुरोध करने और भी बहुत कुछ के लिए दिशानिर्देश शामिल हैं। उनके पास उनके टीम के सहमत कोडिंग सिंटैक्स स्टाइल, AWS सेटअप दिशानिर्देश, सिस्टम एडमिन जानकारी और अन्य के लिए समर्पित बोर्ड भी हैं। वे यहाँ तक कि Guru कार्ड में आसानी से कॉपी और पेस्ट करने के लिए अक्सर उपयोग किए जाने वाले कोड स्निपेट भी उपलब्ध रखते हैं।

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

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

परियोजना योजना और विकास दस्तावेज़ीकरण

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

और, निश्चित रूप से, उन्हें अक्सर किसी भी तकनीकी दस्तावेज़ का संदर्भ लेने की आवश्यकता होगी जो उस फीचर को प्रभावित करता है जिस पर वे काम कर रहे हैं, या जिसे उन्हें बाद में विकास के दौरान अपडेट करने की आवश्यकता होगी।

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

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

भविष्य के प्रमाण दस्तावेज़ीकरण

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