प्रदर्शन की समीक्षा और गुप्त ज्ञान की पहचान (समीक्षा और वीडियो रिपोर्ट)

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

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

प्रदर्शन की समीक्षा क्यों?

फ्लंट से पहले, मैं विकास कंपनी में सीटीओ था। मैं चाहता था कि टीम विकसित हो, अधिक से अधिक जटिल कार्यों को हल करने में सक्षम हो, और कर्मचारी अपने कौशल में सुधार करें। और इसके लिए, दो चीजों की आवश्यकता थी:

1. पारदर्शी विकास नियम।
2. हमसे संपर्क करें।

कुछ नियमों को प्राप्त करना आवश्यक था जिसके द्वारा एक कर्मचारी कंपनी में विकसित हो सकता है और जिसके द्वारा उसे रास्ते में समस्याओं के साथ मदद करने के लिए समय पर प्रतिक्रिया देना संभव था।

क्या करियर की सीढ़ी बनाना आसान है?

जैसा कि यह निकला, नहीं। यहां तक ​​कि अगर आपके पास उच्च स्तर के कर्मचारी का नौकरी का विवरण है, तो आप केवल इसमें से कीवर्ड सेट नहीं कर सकते हैं और कह सकते हैं कि ये आपके करियर को बढ़ाने के लिए आवश्यक कदम हैं। यदि आप किसी कर्मचारी को बताते हैं: "सिम्फनी 4, पोस्टग्रेक्यूएल और मायक्यूसी सीखें," तो इससे उसे बहुत मदद नहीं मिली। उसे पूरी तरह से MySQL मत सिखाओ! विवरण महत्वपूर्ण हैं, इसलिए किसी व्यक्ति के कौशल को मापने के कुछ साधनों की आवश्यकता होगी ... एक शासक की तरह कुछ।



एक शासक की कल्पना करें, लेकिन विभाजन के बजाय, इसमें कौशल का गुणात्मक स्तर होता है जिसे स्वाभाविक रूप से प्रतिष्ठित किया जा सकता है। यदि हमारे पास ऐसी कोई रेखा होती, तो हम वास्तविक कार्य, वास्तविक अनुभव और विशिष्ट प्रशिक्षण सामग्री को बाँध सकते थे। तो?

दुर्भाग्य से, नहीं: व्यवहार में, ऐसी रेखा "पवित्र युद्धों" के लिए एक अलग विषय बन जाती है, क्योंकि गणितीय सटीकता के साथ यह कहना असंभव है कि क्या कोई व्यक्ति जानता है कि जटिल व्यावसायिक तर्क को कैसे लागू किया जाए या नहीं। लेकिन अच्छी खबर है: एक ही अभ्यास में, गणितीय सटीकता इतनी आवश्यक नहीं है । आप विशेषज्ञ मूल्यांकन की विधि का उपयोग कर सकते हैं: कर्मचारी को कौशल के स्तर से संबंधित निर्णय लेने का अवसर देने के लिए सबसे अनुभवी और सबसे अधिक डूबे हुए स्थिति को देने के लिए, और इस पर पहले से ही निर्माण होता है।

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

क्या प्रतिक्रिया देना आसान है?

यह तर्कसंगत लगता है कि आपको समय-समय पर (उदाहरण के लिए, एक बार एक चौथाई) एक कर्मचारी से मिलना चाहिए और उसे प्रतिक्रिया देनी चाहिए। और इसे व्यवस्थित करने का प्रयास करें ताकि प्रक्रिया अर्थ से भर जाए, न कि कार्गो पंथ। यह कौशल के साथ हमारी "लाइनों" को लेने के लिए एक अच्छा विचार है:



... उनसे एन-डायमेंशनल स्पेस व्यवस्थित करें और उस व्यक्ति को बताएं कि वह इस स्पेस में कहां है, फिर इस बात पर सहमत हों कि वह कहां पर जाएगा:



एन-आयामी अंतरिक्ष की कल्पना करना कठिन है, इसलिए हम इन उद्देश्यों के लिए एक तालिका का उपयोग कर सकते हैं। इसमें पंक्तियाँ हमारा कौशल होंगी, और कॉलम में - कौशल के विकास का स्तर। यदि हम ऐसे दो सत्र आयोजित करते हैं, तो हम निम्नलिखित चित्र देख सकते हैं:



... जो, यह प्रतीत होता है, हमें चुने हुए मार्ग की निष्ठा और चुने हुए साधनों से आश्वस्त करेगा - आखिरकार, लोग विकसित हो रहे हैं। और जब महत्वपूर्ण द्रव्यमान बदलता है, तो आप कर्मचारी के वेतन को बढ़ा सकते हैं और उसकी स्थिति के लिए नेमप्लेट बदल सकते हैं, उदाहरण के लिए, यह कहते हुए कि वह अब मिडल PHP डेवलपर है।

लेकिन व्यवहार में सब कुछ कैसे होता है?

सिद्धांत रूप में, यह शांत और पारदर्शी लगता है। मैंने तंत्र को इस रूप में शुरू करने के प्रयास किए - और वे थे ... स्पष्ट रूप से, वास्तव में नहीं। मुझे जाना जाता है, कार्यशाला में मेरे सहयोगियों के प्रयास भी प्रेरित नहीं हुए। मुख्य समस्याएं हैं:

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

फ्लंट की आवश्यकता प्रदर्शन की समीक्षा के लिए

जब मैं फ्लंट में आया, मैंने कई समस्याएं देखीं, जिन्होंने मुझे प्रदर्शन की समीक्षा के बारे में सोचने का मौका दिया, अर्थात्:

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

इसलिए, मैं वास्तव में प्रत्येक स्थिति के लिए आवश्यक कौशल को उजागर करना चाहता था, और कैरियर के विकास के लिए परिस्थितियां बनाना चाहता था।



लेकिन सब कुछ इतना स्पष्ट नहीं था ...

कौशल की एक सूची के लिए देख रहे हैं

यह पता चला कि कोई भी DevOps इंजीनियरों के कौशल की आवश्यकताओं को उजागर नहीं कर सकता है और आम तौर पर किसी भी "कौशल स्तर" को उजागर कर सकता है। इस पद का निकटतम विवरण अमर रॉबर्ट हेनलेन में है:

किसी को डायपर बदलने, आक्रमण करने, वध करने वाले सूअरों, इमारतों के निर्माण, नियंत्रण जहाजों, सोननेट्स लिखने, खाते रखने, दीवारें बनाने, हड्डियों को सेट करने के लिए सक्षम होना चाहिए <...>, प्रोग्राम कंप्यूटर, स्वादिष्ट खाना बनाना, अच्छी तरह से लड़ना, योग्य बनना।

यही है, टीम के नेताओं ने उम्मीद की और अपने लोगों को फुलस्टैक इंजीनियरों के रूप में उभारा, जो कि कार्य के बारे में विवरणों का सही ढंग से पता लगाने और सभी तकनीकी मुद्दों को हल करने में सक्षम हैं, और इसे उत्पादन में लाते हैं।

बेशक, इसने मुझे प्रेरित किया। एक ऐसी कंपनी में काम करना बहुत अच्छा है जहाँ हर कोई एक सार्वभौमिक लड़ाकू, एक बहुमुखी व्यक्तित्व और एक उत्कृष्ट इंजीनियर है! यह केवल इस तथ्य से अभिभूत था कि सब कुछ गुप्त ज्ञान के साथ एक विशाल अंधेरी गुफा जैसा दिखता था , जो प्रवेश करने के लिए डरावना है । मैं ऐसी यात्राओं के लिए इंजीनियरों को बर्बाद नहीं करना चाहता था।

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

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

इन शर्तों के तहत, कर्मचारियों के मूल्यांकन के लिए प्रौद्योगिकियों की एक सूची तैयार करना कोई तुच्छ कार्य नहीं है। और इसे लगातार अद्यतित रखना बहुत कठिन है और व्यवस्थित करना मुश्किल है। इसलिए, हमने एक समाधान खोजने की कोशिश की और इसे साझा करना चाहते हैं।

रीथिंकिंग पीआर

हमने एक अलग मार्ग आज़माने का फैसला किया, लेकिन पहले, अपने कार्यों और अपेक्षाओं पर पुनर्विचार करें। समीक्षा शुरू करके, हम करेंगे:

• ... कर्मचारियों के प्रदर्शन को मापने की कोशिश की;
• ... उनसे बात की;
• ... उम्मीद थी कि अंत में वे खुश हो जाएंगे, बेहतर उनकी संभावनाओं और उनके करियर की वृद्धि को समझेंगे।

हमने इन बिंदुओं पर पुनर्विचार करने के लिए लगभग डेढ़ महीने का निवेश किया है और नीचे मैं आपको बताऊंगा कि इसका क्या हुआ।

प्रदर्शन रेटिंग

मैं समझने की कोशिश में कुछ इस तरह से देखने लगा कि यहां क्या गलत हो सकता है:



और कुछ बिंदु पर एक दिलचस्प विचार आया: एक अतिरिक्त जानकारी को यहां दर्शाया गया है। वास्तव में, विशिष्ट "विभाजन" इतने महत्वपूर्ण नहीं हैं - एक तस्वीर को इसके लिए सरल बनाया जा सकता है:



हम विकास की गति में रुचि रखते हैं, और इस तथ्य में नहीं कि कोई व्यक्ति एक विशिष्ट स्तर पर पहुंच गया है। क्या कोई विकास हुआ था? क्या बहुत से लोगों ने सीखा है या थोड़ा? यह एक वास्तविक संकेतक है!

कौशल सूची के रहस्यों की जांच

इससे पहले, हम इस निष्कर्ष पर पहुंचे कि कौशल की सूची हमारे लिए एक गुप्त ज्ञान है: इंजीनियर हर दिन कुछ करने, कुछ करने में सक्षम हैं, लेकिन वास्तव में क्या बनाना मुश्किल है।

गुप्त ज्ञान प्रकट करने के तरीकों में से एक "वेक" में है, वह है: जो हो रहा है उसे ठीक करना, फिर उसका विश्लेषण करना।



जिस तरह हम जंगल में पैरों के निशान का पालन कर सकते हैं कि गिलहरी, लोमड़ी और भालू वहां पाए जाते हैं, हम गुप्त ज्ञान प्रकट करने की कोशिश करेंगे ...

पायलट प्रोजेक्ट

टिम्लिड पीटर ने एक अद्यतन रूप में समीक्षा शुरू करने के लिए कृपया पायलट प्रोजेक्ट में भाग लेने के लिए सहमति व्यक्त की। पीटर ने विचारों में देरी की, और हमने कर्मचारियों के साथ बैठक की योजना बनाई। स्व-तैयारी के परिणामस्वरूप, पीटर ने अपने एक इंजीनियर लियोनिद के बारे में यह प्रतिक्रिया तैयार की:



यह खराब-गुणवत्ता वाली प्रतिक्रिया का एक उदाहरण है: यदि आपने ऐसे योगों में अपने बारे में सुना होता, तो शायद ही इससे आपको बहुत मदद मिलती। यहां तक ​​कि अगर सब कुछ अधिक स्पष्ट रूप से डरपोक के सिर में तैयार किया गया है (जो पूरी तरह से एक तथ्य नहीं है), इस रूप में जानकारी दर्ज करना बहुत उपयोगी नहीं है, क्योंकि छह महीने के बाद इस तरह के "निशान" कोई लाभ नहीं लाएंगे - यहां तक ​​कि लेखक को यह याद नहीं होगा कि यह किस बारे में है।

हम चाहते हैं कि फीडबैक जितना संभव हो उतना उद्देश्यपूर्ण हो, विनम्र हो और एक-दूसरे के बारे में अधिक जानने के लिए "प्रेरणा" देने के साधन के रूप में सीखने में मदद करें।

अग्रणी प्रशिक्षण

परिणामस्वरूप, हमने टीम के नेताओं के लिए पीआर की तैयारी के लिए निम्नलिखित नियम तैयार किए:

1. प्रत्येक समीक्षा से पहले, आपको तैयार करने के लिए आधे घंटे से एक घंटे और आधे घंटे तक आवंटित करना होगा। एक दिन पहले तैयार करना बेहतर है, और उसी दिन नहीं।
2. सभी ट्रैकर्स (टिकट सिस्टम, संदेशवाहक, कर्म प्रणाली, आदि) के माध्यम से जाओ, भले ही नेता बहुत आलसी हो और वह अपनी खूबसूरत स्मृति के लिए अपील करता है। पिछली समीक्षा से नोट्स देखें।
   
   
3. चर्चा के लिए कई बिंदु लिखें। इन सार में होना चाहिए:
   
   • ट्रैकर्स के लिंक के रूप में औचित्य के साथ तथ्य;
   • समीक्षक का व्यक्तिगत रवैया: वह क्यों (ए) इस आइटम को हाइलाइट करता है, और इसमें क्या महत्वपूर्ण है, इसकी व्याख्या।

वैसे, हमने यहां खराब और अच्छे शब्दों के उदाहरण पोस्ट किए हैं।

पीआर प्रक्रिया

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

एक समीक्षा कई चरणों से गुजरती है:

• एक-दूसरे के साथ बातचीत करने के लिए ध्यान भंग करने के बारे में बात करें।
• कहानी जो एक व्यक्ति ने अच्छी की , जिसके लिए मैं उसे धन्यवाद देना चाहता हूं और समझाता हूं कि यह महत्वपूर्ण क्यों है। आखिर, हम चाहते हैं कि आगे अच्छा हो?
• असंदिग्ध रूप से खराब को अस्वीकार करें: समझौतों, अनुशासन और अन्य चीजों का उल्लंघन जो आप अक्षम्य मानते हैं और जो निर्विवाद हैं।
• निम्नलिखित नियमों के अनुसार समझ से बाहर या विवादास्पद :
  
  • इन तथ्यों को तथ्यों और व्यक्तिगत रवैये की पहचान करें।
  • एक सामान्य प्रश्न पूछें (जैसे "आप इस बारे में क्या सोचते हैं?") समस्या के बारे में कर्मचारी से अधिक जानकारी प्राप्त करने के लिए।
  • प्रश्न पूछने के लिए: क्या कर्मचारी को लगता है कि कोई समस्या है? यह पता चल सकता है कि कुछ व्यक्तिगत कारणों से वह इस महत्वपूर्ण पर विचार नहीं करता है। हमें यह सुनिश्चित करने की आवश्यकता है कि वह हमारी धारणा को साझा करे।
  • प्रश्न पूछने के लिए: समस्या को हल करने के लिए कर्मचारी स्वयं क्या करने जा रहा है?
  • यदि कोई कर्मचारी आपकी समस्या को साझा नहीं करता है, तो उचित समाधान प्रस्तुत करता है - यह अत्यधिक संभावना है कि वह इसके साथ कुछ भी नहीं करेगा। और इस स्थिति में उस पर दबाव डालने का कोई मतलब नहीं है - यह समझने की कोशिश करना बेहतर है कि यह मामला क्यों है।
• एक कर्मचारी से प्रतिक्रिया के लिए पूछें। क्या इस चक्र के दौरान कंपनी में उनका जीवन उनकी उम्मीदों से मेल खाता था? यदि आप वास्तव में पहले एक संवाद का निर्माण करने में सक्षम थे, तो इस स्तर पर आपको एक प्रतिक्रिया मिल जाएगी, न कि एक स्लेटेड मू, जैसा कि अक्सर होता है।
• वेतन के बारे में बात करें: क्या आप इसे बढ़ाते हैं, और यदि नहीं, तो इसे बढ़ाने के लिए विशेष रूप से क्या तय किया जाना चाहिए। वेतन का मुद्दा बहुत महत्वपूर्ण और जटिल है और सामान्य तौर पर कर्मचारी का प्रदर्शन समीक्षा में भाग लेना मुख्य उद्देश्य है। एक संदेह है कि यह कुछ समीक्षा प्रक्रियाओं को शुरू करने की कोशिश करने के लिए बहुत कम समझ में आता है, अगर यह वेतन को प्रभावित नहीं करता है, लेकिन यह 100% नहीं है ...

कुल:

प्रथम वर्ष के परिणाम

पहले वर्ष के दौरान संचित अभिलेखों के विश्लेषण से हमें मदद मिली:

• हमारे इंजीनियरों की पहचान की गोपनीयता का पर्दा खोलने के लिए;
• निर्देशों और सूचनाओं के साथ ज्ञान के आधार को फिर से भरना, जो कर्मचारियों के लिए सबसे अधिक समस्याएं पैदा करता है;
• टीमों में जलवायु में सुधार।

इंजीनियर बहुत अधिक मूर्त रूप से और तेज़ी से बढ़ने लगे, उन्हें अपने करियर के निर्माण की दिशा की समझ थी।



अन्य महत्वपूर्ण क्षण:

• शुरुआती लोगों ने अनुकूलन के दौरान समस्याओं को अधिक रचनात्मक तरीके से हल करना शुरू किया: प्रबंधकों ने अचानक खुद के लिए पाया कि वे समस्याओं के बारे में नवागंतुक से बात कर सकते हैं ... और उसे सही किया जाएगा!
• यह स्पष्ट हो गया कि कंपनी में हम किस तरह के कर्मचारियों की प्रतीक्षा कर रहे हैं, इसलिए भर्ती के लिए आवश्यकताओं को समायोजित किया गया था।
• यह स्वयं कर्मचारियों के लिए और अधिक स्पष्ट हो गया कि वे क्या चाहते हैं और उनके पास क्या विकास संभावनाएं हैं।
• रेखाचित्र दक्षता के मैट्रिक्स पर दिखाई दिए, और इसके निरंतर अद्यतन के लिए एक तंत्र है।

इंजीनियर का चित्र

यह स्पष्ट प्रतीत हो सकता है कि एक इंजीनियर, उदाहरण के लिए, वास्तव में प्यार करना चाहिए कि वह क्या कर रहा है और काम करने का आनंद ले सकता है ... वैसे भी - यहां चार कौशल हैं जो सबसे अधिक मांग (एक विस्तृत मार्जिन द्वारा) किए गए हैं:



अन्य महत्वपूर्ण कौशल निकला:

चलो दूसरे वर्ष में पता लगाने की कोशिश करते हैं

इस बीच, विवरण पाठक के लिए एक चौकस नोटिस हो सकता है कि हमने प्रदर्शन को बहुत अधिक नहीं मापा है ... शायद, समय के साथ, कौशल की सूची बस जाएगी और एक उपयुक्त योग्यता मैट्रिक्स का गठन किया जाएगा, या हम कुछ अन्य रेटिंग प्रणाली पेश करेंगे।

इसके अलावा, अभी हम प्रबंधकों के बीच समीक्षा आयोजित करने के प्रशिक्षण को व्यवस्थित करने के तरीकों की तलाश कर रहे हैं - हमारे पास अभी भी तैयार समाधान नहीं है।

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

वीडियो और स्लाइड

प्रदर्शन से वीडियो (~ 50 मिनट):



रिपोर्ट की प्रस्तुति:

पुनश्च

आपको निम्नलिखित प्रकाशनों में भी रुचि हो सकती है:

• " फ्लिंट शुरुआती लोगों की मदद कैसे करता है ";
• " कर्मचारी कैसे काम पर रखते हैं "
• " सफल साइट विश्वसनीयता इंजीनियरों की 7 आदतें (नए अवशेष के अनुसार) ।"

हमारे ब्लॉग पर अन्य रिपोर्टों में:

• " विस्तार और पूरक कुबेरनेट्स " (एंड्री पोलोव; 8 अप्रैल, 2019 को सेंट हाईलाड ++) ;
• " डेटाबेस और कुबेरनेट्स " (दिमित्री स्टोलारोव ; 8 नवंबर, 2018 को हाईलाड ++) ;
• " निगरानी और कुबेरनेट्स " (दिमित्री स्टोलारोव ; 28 मई, 2018 रूटकॉन्फ़ पर) ;
• " कुबेरनेट्स और गिटलैब के साथ सर्वश्रेष्ठ सीआई / सीडी अभ्यास " (दिमित्री स्टोलिरोव ; 7 नवंबर, 2017 को हाईलाड ++) ;
• " छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव " (दिमित्री स्टोलिरोव; 6 जून, 2017 को रूटकॉन्फ़) ।