परियोजना प्रबंधकों की जरूरत नहीं है

कृपया ध्यान दें कि शीर्षक में कोई प्रश्नचिह्न नहीं है। मैं यह तर्क नहीं देना चाहता कि परियोजना प्रबंधकों को आधुनिक सॉफ्टवेयर विकास में आवश्यकता है या नहीं। अभ्यास से पता चलता है कि नहीं। मैं सिर्फ यह पता लगाने की कोशिश कर रहा हूं कि ऐसा क्यों हुआ।

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

लेकिन मेरे लिए यह एक स्वयंसिद्ध था कि परियोजना कार्यालय और परियोजना प्रबंधक सफलता का आधार हैं। और मुझे पांच साल पहले किसी को बताएं कि परियोजना प्रबंधकों की जरूरत नहीं है, मैं अंत तक उसके साथ बहस करूंगा।

संपादक का ध्यान दें: यह पाठ दिमित्री क्रुगलोव की आगमन से लेकर पाइमनाया रैली की रिपोर्ट का परिणाम है।

या आपको अभी भी ज़रूरत है?

आइए इस पेशे की रक्षा करने की कोशिश करते हैं। यदि केवल इसलिए कि काम के अंतिम स्थानों पर परिणाम प्राप्त किए गए हैं, जिसमें सफलतापूर्वक निर्मित परियोजना कार्यालयों के लिए धन्यवाद भी शामिल है।

परियोजना प्रबंधन आईटी का विशेषाधिकार नहीं है। यह एक ऐसा विज्ञान है जो 50 वर्ष से अधिक पुराना है। एक विज्ञान जिसकी अपनी एक पवित्र पुस्तक है । बेशक, PMBoK एक तरह से नहीं है, वहाँ PRINCE है और, शायद, कई और किताबें जो लॉरेल्स के लिए अधिक या कम दावा करती हैं। लेकिन PMBK अंतर्राष्ट्रीय मानकों का आधार है और यह इसकी उच्च स्तर की मान्यता को इंगित करता है। तो हम उस पर निर्माण करेंगे।

चलो खेल खेलते हैं: यदि आप एक परियोजना प्रबंधक के रूप में काम करते हैं, तो कोशिश करें, बिना किसी अंतर्राष्ट्रीय मानक और एक संस्थान के दृष्टिकोण से गतिविधि के अपने मुख्य क्षेत्रों को याद करने की कोशिश करें, जो 50 वर्ष से अधिक पुराना है?

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

PMBoK से सूची के साथ आपको जो याद आया उसकी तुलना करें:

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

गैन्ट चार्ट

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

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

इन क्षेत्रों में अधिकांश कार्यों को एक इकाई - गैंट चार्ट के प्रबंधन के माध्यम से हल किया जाता है।

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

क्या निकलता है: हमारे पास एक पेशा है, एक गतिविधि है और एक अच्छी कलाकृति है, जिसके परिणामस्वरूप। तो क्या पकड़ है?

यह सभी बारीकियों के बारे में है। उदाहरण के लिए, गैंट के साथ, सब कुछ इतना अच्छा नहीं है।

सबसे पहले, बड़ी परियोजनाओं के चित्र जल्दी या बाद में अपठनीय हो जाते हैं। मुझे Microsoft प्रोजेक्ट में "एक वर्ष से अधिक" प्रोजेक्ट के साथ काम करने का अनुभव था। उनकी योजना को मुद्रित करने के लिए, ए 4 की छह शीटों को गोंद करना आवश्यक था। एक शीट पर, पाठ बहुत छोटा था।

दूसरे, बड़ी परियोजनाओं के आरेख बनाए रखने के लिए बहुत श्रम गहन हैं। अक्सर बदलाव करना केवल लेखक द्वारा स्वयं किया जा सकता है, अन्यथा निर्भरता की एक जटिल प्रणाली के कारण योजना अलग हो जाती है।

तीसरा, यह स्वीकार किया जाना चाहिए कि परियोजना प्रबंधक को छोड़कर कोई भी कई डायग्राम नहीं पढ़ता है। यह पता चलता है कि यह कलाकृतियों का निर्माण पीएम ने किया था और वह अकेले ही इसे समझती हैं।

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

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

मैं यह नहीं कहता कि वैश्विक विवाद में संतुलन पीएम को खारिज करने के पक्ष में है, लेकिन कम से कम इस दृष्टिकोण के समर्थकों की संख्या महत्वपूर्ण है।

चंचल तरीके

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

कारणों के बारे में मेरे शोध से यह समझ आई कि आईटी में कई अद्वितीय गुण हैं जो लचीली कार्यप्रणाली के कार्यान्वयन में सक्षम हैं। एक क्लासिक तुलना है: एक घर बनाना और सॉफ्टवेयर विकसित करना। ये कुछ इसी तरह के विषय हैं, न कि बिना कारण दोनों में वास्तुविद की भूमिका है। दोनों वहाँ, और वहाँ कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं का एक सेट मौजूद है, बुनियादी ढांचे, आंतरिक संचार, विधानसभा, वितरण और एकीकरण है।

लेकिन निर्माण वास्तविक दुनिया में किया जाता है और पहले परीक्षण से पहले, प्रतिक्रिया प्राप्त करने से पहले और परिणाम प्राप्त करने से पहले एक बहुत लंबा और महंगा उत्पादन चक्र होता है। निर्माण में गलती की कीमत बहुत अधिक है।

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

भूमिका

चंचल कार्यप्रणालियाँ वास्तव में मानक बन गई हैं और सॉफ्टवेयर विकास प्रक्रिया में नई भूमिकाएँ लाई हैं। और इन नई भूमिकाओं ने परियोजना प्रबंधकों से गतिविधियों और कलाकृतियों को दूर करना शुरू कर दिया।

उत्पाद स्वामी (PO)

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

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

टेकलाइड (TL)

लगभग दस साल पहले, आईटी ने स्थापित वास्तुकला को बदलना शुरू किया।

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

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

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

सिस्टम विश्लेषक (SA)

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

स्क्रम मास्टर (SM)

स्क्रैम मास्टर ने परियोजना प्रबंधक की भूमिका को बहुत निचोड़ा। यह अफ़सोस की बात है कि अब एसएम खुद विलुप्त होने के लिए उम्मीदवार बन गए हैं।

गंभीरता से, जल्द या बाद में स्क्रम मास्टर स्कूलों में पढ़ाएगा। एजाइल के बारे में पाठ होंगे, जहां स्क्रैम मास्टर 12 वर्षीय छात्रों को बताएगा कि चुस्त कार्यप्रणाली कैसे काम करती है और क्या अभ्यास मौजूद हैं। चंचल अनुभव अब एक सर्वव्यापी विकास अनुभव बन गया है। एक साक्षात्कार में, 20 में से 19 लोग दो सप्ताह के पुनरावृत्तियों पर काम करते हैं, और प्रक्रियाओं के बारे में बात करना उनके मापदंडों की सूची में बदल जाता है:

- मूल्यांकन क्या है?
- कहानी अंक
- वेग क्या है?
- 68।
- आप परियोजनाओं की योजना कैसे बनाते हैं?
- एस, एम, एल की "टी-शर्ट" रेटिंग में।

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

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

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

या अभी भी जरूरत नहीं है

क्या बचा है? मैंने उन कार्यों को उजागर करने की स्वतंत्रता ली, जो लचीली कार्यप्रणाली पर काम करते समय, अन्य भूमिकाओं द्वारा हल किए जाते हैं।

इसके बाद परियोजना प्रबंधकों के पास क्या है? संचार, एकीकरण और खरीद बने रहे। ऐसा लगता है कि इस भूमिका पर समर्पित व्यक्ति को रखने के लिए बहुत कुछ नहीं है? यह कहने का समय है कि पीएम की जरूरत नहीं है। लेकिन नहीं।

अभी भी जरूरत है

आईटी परियोजनाओं की श्रेणियां हैं जिनमें एक समर्पित प्रबंधक के बिना विफलता व्यावहारिक रूप से गारंटी है।

वास्तविक विश्व परियोजनाएँ

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

लेकिन यह पीएम के दर्द का सौवां हिस्सा है, जो सॉफ्टवेयर के विकास का प्रबंधन करता है, उदाहरण के लिए, 5 मिलियन इकाइयों के सामान के पैमाने के साथ एक गोदाम में छंटाई कन्वेयर का प्रबंधन करने के लिए। ऐसी परियोजनाओं में, उपकरण आपूर्तिकर्ताओं पर दर्जनों निर्भरता, महीनों में पुनरावृत्तियों को मापा जाता है, और त्रुटि की कीमत परिमाण के एक क्रम से बढ़ जाती है।

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

छाता परियोजनाओं

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

त्रुटि की उच्च लागत वाली परियोजनाएं

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

ऐसे क्षेत्रों में, पीएम मांग में बने रहेंगे, लेकिन दक्षताओं और अनुभव के संदर्भ में उन पर बहुत अधिक मांगें रखी जाएंगी। और ऐसी परियोजनाओं का अनुपात जितना छोटा होगा, उम्मीदवारों का चयन उतना ही कठोर होगा।

भूमिकाओं के बिना परियोजनाएं

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

यदि हम समय के साथ उन रुझानों का विस्तार करते हैं जो अब उद्योग में हो रहे हैं, तो हमारे पास एक भविष्य होगा जिसमें पीएम की शुद्ध रूप में भूमिका सॉफ्टवेयर विकास परियोजनाओं की एक छोटी संख्या के लिए प्रासंगिक बनी हुई है, जिनका काम हम अभी तक दूसरों के बीच स्वचालित या वितरित करना नहीं जानते हैं। टीम के सदस्य।

द्वारा तैयार पाठ:
लेखक - दिमित्री क्रूगलोव
संपादक - यूजीन शकीलार, डेनिस वोनसरोवस्की
कुछ मुद्दों पर लेखक की राय ब्लॉग और Yandex.Money कंपनी के संपादकीय बोर्ड की राय से मेल नहीं खा सकती है।