पुस्तक "बुद्धिजीवियों को कैसे प्रबंधित करें। मैं, बेवकूफ़ और मूर्ख"

परियोजना प्रबंधकों (और जो बॉस बनने का सपना देखते हैं) को समर्पित।

ढेर सारे कोड लिखना कठिन है, लेकिन लोगों को प्रबंधित करना और भी कठिन है! तो दोनों को कैसे करना है यह सीखने के लिए आपको बस इस पुस्तक की आवश्यकता है।

क्या मज़ेदार कहानियों और गंभीर पाठों को जोड़ना संभव है? माइकल लोप (जिसे संकीर्ण दायरे में रैंड्स के नाम से भी जाना जाता है) सफल हुए। आपको अविश्वसनीय रूप से फायदेमंद (यद्यपि काल्पनिक) अनुभवों वाले काल्पनिक लोगों के बारे में काल्पनिक कहानियाँ मिलेंगी। इस तरह रैंड्स ने बड़े आईटी निगमों में काम करने के वर्षों के दौरान प्राप्त अपने विविध, कभी-कभी अजीब अनुभवों को साझा किया है: ऐप्पल, पिनटेरेस्ट, पलान्टिर, नेटस्केप, सिमेंटेक, आदि।

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

यह पुस्तक किसी प्रबंधन या नेतृत्व पांडुलिपि से भिन्न है। माइकल लोप कुछ भी छिपाते नहीं हैं, वह बस इसे वैसे ही बता देते हैं जैसे यह है (शायद सभी कहानियों को सार्वजनिक नहीं किया जाना चाहिए: पी)। लेकिन केवल इसी तरह से आप समझ पाएंगे कि ऐसे बॉस के साथ कैसे जीवित रहना है, मूर्खों और बेवकूफों को कैसे प्रबंधित करना है, और "उस लानत परियोजना" को सुखद अंत तक कैसे लाना है!

अंश. इंजीनियरिंग मानसिकता

इस पर विचार: क्या आपको कोड लिखना जारी रखना चाहिए?

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

लचीले रहो!

यह सोचना कि आप पहले से ही सब कुछ जानते हैं, एक बहुत बुरा विचार है। ऐसी स्थिति में जहां एकमात्र स्थिर तथ्य यह है कि दुनिया लगातार बदल रही है, लचीलापन ही एकमात्र सही स्थिति बन जाती है।

विरोधाभासी रूप से, सूची में दूसरा आइटम आश्चर्यजनक रूप से अनम्य है। हालाँकि, यह बिंदु मेरा निजी पसंदीदा है क्योंकि मेरा मानना ​​है कि यह प्रबंधकीय विकास की नींव बनाने में मदद करता है। यह पैराग्राफ पढ़ता है:

कोड लिखना बंद करो!

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

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

अच्छी सलाह, है ना? पैमाना। प्रबंधन। ज़िम्मेदारी। ऐसे आम प्रचलित शब्द. अफ़सोस की बात है कि सलाह ग़लत है।

ग़लत?

हाँ। सलाह ग़लत है! पूरी तरह से गलत नहीं है, लेकिन इतना गलत है कि मुझे कुछ पूर्व सहकर्मियों को फोन करके माफी मांगनी पड़ी: “आपको मेरा वह पसंदीदा कथन याद है कि आपको कोड लिखना कैसे बंद करना चाहिए? यह गलत है! हाँ... प्रोग्रामिंग फिर से प्रारंभ करें। पायथन और रूबी से शुरुआत करें। हाँ, मैं गंभीर हूँ! आपका करियर इस पर निर्भर करता है!”

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

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

डेवलपर्स पिछले 20 वर्षों से क्या कर रहे हैं? इस दौरान हमने ढेर सारा कोड लिखा। कोड का सागर! हमने इतना कोड लिखा कि हमने निर्णय लिया कि सब कुछ सरल बनाना और ओपन सोर्स पर जाना एक अच्छा विचार होगा।

सौभाग्य से, इंटरनेट की बदौलत यह प्रक्रिया अब यथासंभव सरल हो गई है। यदि आप एक सॉफ़्टवेयर डेवलपर हैं, तो आप इसे अभी देख सकते हैं! Google या Github पर अपना नाम खोजें और आपको वह कोड दिखाई देगा जिसके बारे में आप लंबे समय से भूल गए हैं, लेकिन जिसे कोई भी ढूंढ सकता है। डरावना, है ना? क्या आप नहीं जानते कि कोड हमेशा के लिए रहता है? हाँ, वह सदैव जीवित रहता है।

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

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

हम इन प्रबंधन लोगों को वास्तव में मोटी रकम देते हैं, लेकिन वे इस तरह की बकवास सोचते हैं। एक बार फिर, मेरा मुख्य बिंदु यह है कि हमारे ग्रह पर कई प्रतिभाशाली और बहुत मेहनती डेवलपर्स हैं; वे वास्तव में मेधावी और मेहनती हैं, हालाँकि उन्होंने मान्यता प्राप्त विश्वविद्यालयों में बैठकर एक मिनट भी नहीं बिताया है। अरे हाँ, अब तो इनकी संख्या और भी अधिक हो गई है!

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

कोड लिखना बंद करें, लेकिन...

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

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

आपको आपत्ति है. समझना। चलो सुनते हैं।

“रैंड्स, मैं निर्देशक की कुर्सी की ओर जा रहा हूँ! अगर मैं कोड लिखता रहूं तो कोई भी विश्वास नहीं करेगा कि मैं आगे बढ़ सकता हूं।''

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

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

“उह, रैंड्स! लेकिन किसी को तो मध्यस्थ बनना ही होगा! किसी को बड़ी तस्वीर देखनी होगी. अगर मैं कोड लिखूंगा, तो मैं परिप्रेक्ष्य खो दूंगा।"

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

इंजीनियरिंग मानसिकता बनाए रखने के लिए मेरी युक्तियाँ:

1. विकास परिवेश का उपयोग करें. इसका मतलब है कि आपको अपनी टीम के टूल से परिचित होना चाहिए, जिसमें कोड बिल्ड सिस्टम, संस्करण नियंत्रण और प्रोग्रामिंग भाषा शामिल है। परिणामस्वरूप, आप उस भाषा में पारंगत हो जाएंगे जिसका उपयोग आपकी टीम उत्पाद विकास के बारे में बात करते समय करती है। यह आपको अपने पसंदीदा टेक्स्ट एडिटर का उपयोग जारी रखने की भी अनुमति देगा, जो पूरी तरह से काम कर रहा है।
2. आपको किसी भी समय किसी भी सतह पर अपने उत्पाद का वर्णन करने वाला एक विस्तृत वास्तुशिल्प आरेख बनाने में सक्षम होना चाहिए। अब मेरा मतलब तीन कोशिकाओं और दो तीरों वाले सरलीकृत संस्करण से नहीं है। आपको उत्पाद का विस्तृत आरेख पता होना चाहिए। सबसे कठिन. सिर्फ कोई सुंदर चित्र नहीं, बल्कि एक ऐसा चित्र जिसकी व्याख्या करना कठिन है। यह उत्पाद की संपूर्ण समझ के लिए उपयुक्त मानचित्र होना चाहिए। यह लगातार बदल रहा है, और आपको हमेशा पता होना चाहिए कि कुछ बदलाव क्यों हुए।
3. किसी एक कार्य का कार्यान्वयन अपने हाथ में लें। जब मैं इसे लिख रहा हूं तो मैं सचमुच घबरा रहा हूं क्योंकि इस बिंदु में बहुत सारे छिपे हुए खतरे हैं, लेकिन मुझे वास्तव में यकीन नहीं है कि आप कम से कम एक सुविधा को लागू करने के लिए प्रतिबद्ध हुए बिना बिंदु # 1 और बिंदु # 2 को पूरा कर सकते हैं। किसी एक विशेषता को स्वयं लागू करने से, न केवल आप विकास प्रक्रिया में सक्रिय रूप से शामिल होंगे, बल्कि यह आपको समय-समय पर "हर चीज के प्रभारी प्रबंधक" की भूमिका से "किसी एक को लागू करने के प्रभारी व्यक्ति" की भूमिका में बदलने की भी अनुमति देगा। कार्यों का। यह विनम्र और निश्छल रवैया आपको छोटे-छोटे निर्णयों के महत्व की याद दिलाएगा।
4. मैं अभी भी पूरी तरह काँप रहा हूँ। ऐसा लगता है कि कोई पहले से ही मुझ पर चिल्ला रहा है: "प्रबंधक जिसने समारोह के कार्यान्वयन को अपने ऊपर ले लिया?" (और मैं उनसे सहमत हूं!) हां, आप अभी भी प्रबंधक हैं, जिसका मतलब है कि यह कोई छोटा सा कार्य होना चाहिए, ठीक है? हाँ, तुम्हें अभी भी बहुत कुछ करना है। यदि आप फ़ंक्शन का कार्यान्वयन नहीं कर सकते हैं, तो मेरे पास आपके लिए कुछ अतिरिक्त सलाह हैं: कुछ बग ठीक करें। इस मामले में, आपको सृजन का आनंद महसूस नहीं होगा, लेकिन आपको यह समझ आ जाएगी कि उत्पाद कैसे बनाया जाता है, जिसका अर्थ है कि आप कभी भी काम से वंचित नहीं रहेंगे।
5. इकाई परीक्षण लिखें. मैं अभी भी उत्पादन चक्र के अंत में ऐसा करता हूं जब लोग पागल होने लगते हैं। इसे अपने उत्पाद के लिए स्वास्थ्य जांच सूची के रूप में सोचें। ऐसा अक्सर करें.

फिर आपत्ति?

“रैंड्स, अगर मैं कोड लिखूंगा, तो मैं अपनी टीम को भ्रमित कर दूंगा। वे नहीं जान पाएंगे कि मैं कौन हूं- प्रबंधक या डेवलपर।"

ठीक है.

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

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

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

विकास करना बंद न करें

बोरलैंड में मेरी एक सहकर्मी ने एक बार उसे "कोडर" कहने के लिए मुझ पर मौखिक हमला किया था।

“रैंड्स, कोडर एक नासमझ मशीन है! बंदर! कोडर बेकार कोड की उबाऊ लाइनें लिखने के अलावा कुछ भी महत्वपूर्ण काम नहीं करता है। मैं कोडर नहीं हूं, मैं एक सॉफ्टवेयर डेवलपर हूं!”

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

इसलिए मैंने अपनी सलाह अपडेट कर दी है। यदि आप एक अच्छे नेता बनना चाहते हैं, तो आप कोड लिखना बंद कर सकते हैं, लेकिन...

लचीले बनें। याद रखें कि एक इंजीनियर होने का क्या मतलब है और सॉफ्टवेयर विकसित करना बंद न करें।

लेखक के बारे में

माइकल लोप एक अनुभवी सॉफ्टवेयर डेवलपर हैं जिन्होंने अभी भी सिलिकॉन वैली नहीं छोड़ी है। पिछले 20 वर्षों में, माइकल ने Apple, नेटस्केप, सिमेंटेक, बोरलैंड, पलान्टिर, Pinterest सहित कई नवीन कंपनियों के लिए काम किया है और एक स्टार्टअप में भी भाग लिया है जो धीरे-धीरे गुमनामी में चला गया।

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

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

»पुस्तक के बारे में अधिक विवरण यहां पाया जा सकता है प्रकाशक की वेबसाइट
» लेख-सूची
» अंश

खाब्रोझिटेले के लिए कूपन का उपयोग करके 20% की छूट - लोगों को प्रबंधित करना

पुस्तक के कागजी संस्करण के लिए भुगतान करने पर, पुस्तक का एक इलेक्ट्रॉनिक संस्करण ई-मेल द्वारा भेजा जाएगा।

पुनश्च: पुस्तक की कीमत का 7% नई कंप्यूटर पुस्तकों के अनुवाद में जाएगा, पुस्तकों की एक सूची प्रिंटिंग हाउस को सौंपी गई यहां.

स्रोत: www.habr.com