पुस्तक "बुद्धिजीवींचे व्यवस्थापन कसे करावे. मी, अभ्यासू आणि गीक्स"

प्रकल्प व्यवस्थापकांना समर्पित (आणि ज्यांना बॉस बनण्याचे स्वप्न आहे).

अनेक कोड लिहिणे कठीण आहे, परंतु लोकांचे व्यवस्थापन करणे अधिक कठीण आहे! त्यामुळे दोन्ही कसे करायचे हे शिकण्यासाठी तुम्हाला फक्त या पुस्तकाची गरज आहे.

मजेदार कथा आणि गंभीर धडे एकत्र करणे शक्य आहे का? मायकेल लोप (अरुंद वर्तुळात रँड्स म्हणूनही ओळखले जाते) यशस्वी झाले. तुम्हाला अविश्वसनीय फायद्याचे (काल्पनिक असले तरी) अनुभव असलेल्या काल्पनिक लोकांबद्दल काल्पनिक कथा सापडतील. मोठ्या आयटी कॉर्पोरेशनमध्ये काम करताना अनेक वर्षांमध्ये मिळवलेले विविध, कधीकधी विचित्र अनुभव रॅंड्स अशा प्रकारे शेअर करतात: Apple, Pinterest, Palantir, Netscape, Symantec, इ.

तुम्ही प्रोजेक्ट मॅनेजर आहात का? किंवा तुमचा बॉस दिवसभर काय करतो हे समजून घ्यायचे आहे? रँड्स तुम्हाला फुगलेल्या टर्कीच्या विषारी जगात कसे टिकून राहायचे आणि अकार्यक्षमपणे भडक लोकांच्या सामान्य वेडेपणात कसे जगायचे ते शिकवेल. वेडेपणाच्या या विचित्र समुदायात अगदी अनोळखी प्राणी - व्यवस्थापक आहेत ज्यांनी, एका गूढ संस्थात्मक विधीद्वारे, अनेक लोकांच्या योजना, विचार आणि बँक खात्यांवर सत्ता मिळवली आहे.

हे पुस्तक कोणत्याही व्यवस्थापन किंवा नेतृत्व हस्तलिखितापेक्षा वेगळे आहे. मायकेल लोप काहीही लपवत नाही, तो जसे आहे तसे सांगतो (कदाचित सर्व कथा सार्वजनिक केल्या जाऊ नयेत: पी). परंतु केवळ अशा प्रकारे तुम्हाला अशा बॉससोबत कसे टिकायचे, गीक्स आणि नर्ड्सचे व्यवस्थापन कसे करायचे आणि "त्या उद्दाम प्रकल्पाचा" आनंदी शेवट कसा करायचा हे समजेल!

उतारा. अभियांत्रिकी मानसिकता

यावर विचार: तुम्ही कोड लिहिणे सुरू ठेवावे का?

व्यवस्थापकांच्या नियमांवरील रँड्सच्या पुस्तकात आधुनिक व्यवस्थापकीय "मस्ट-डॉस" ची एक अतिशय छोटी यादी आहे. या यादीचा संक्षेप या वस्तुस्थितीतून उद्भवतो की "अवश्यक" ही संकल्पना एक प्रकारची परिपूर्ण आहे आणि जेव्हा लोकांचा विचार केला जातो तेव्हा अगदी कमी संकल्पना असतात. एका कर्मचार्‍यासाठी यशस्वी व्यवस्थापन पद्धत दुसर्‍यासाठी वास्तविक आपत्ती असेल. हा विचार व्यवस्थापकाच्या "करायलाच पाहिजे" सूचीतील पहिला आयटम आहे:

लवचिक रहा!

तुम्हाला सर्वकाही आधीच माहित आहे असा विचार करणे ही खूप वाईट कल्पना आहे. अशा परिस्थितीत जिथे जग सतत बदलत आहे हे एकच सत्य आहे, लवचिकता ही एकमेव योग्य स्थिती बनते.

विरोधाभासाने, यादीतील दुसरा आयटम आश्चर्यकारकपणे नम्र आहे. तथापि, हा मुद्दा माझा वैयक्तिक आवडीचा आहे कारण मला विश्वास आहे की तो व्यवस्थापकीय वाढीचा पाया तयार करण्यास मदत करतो. हा परिच्छेद वाचतो:

कोड लिहिणे थांबवा!

सैद्धांतिकदृष्ट्या, जर तुम्हाला व्यवस्थापक व्हायचे असेल, तर तुम्हाला तुमच्यासाठी काम करणाऱ्यांवर विश्वास ठेवायला आणि कोडिंग पूर्णपणे त्यांच्याकडे सोपवायला शिकले पाहिजे. हा सल्ला सामान्यतः पचणे कठीण असते, विशेषत: नव्याने नियुक्त केलेल्या व्यवस्थापकांसाठी. कदाचित ते व्यवस्थापक बनण्याचे एक कारण म्हणजे त्यांची विकासातील उत्पादकता, आणि जेव्हा गोष्टी चुकीच्या होतात, तेव्हा त्यांची पहिली प्रतिक्रिया ही असते की त्यांना ज्या कौशल्यांवर पूर्ण विश्वास आहे, ती म्हणजे कोड लिहिण्याची त्यांची क्षमता.

जेव्हा मी पाहतो की एक नवीन टांकसाळ व्यवस्थापक कोड लिहिण्यात “बुडतो” तेव्हा मी त्याला सांगतो: “तुम्ही कोड लिहू शकता हे आम्हाला माहीत आहे. प्रश्न आहे: आपण नेतृत्व करू शकता? यापुढे तुम्ही एकटे स्वत:साठी जबाबदार नाही, तुम्ही संपूर्ण संघासाठी जबाबदार आहात; आणि मला खात्री करून घ्यायची आहे की तुम्ही स्वतः कोड लिहिल्याशिवाय तुमची टीम स्वतःच समस्या सोडवू शकता. आपले कार्य स्वतःला कसे मोजायचे हे शोधणे आहे. तुम्ही फक्त एक व्हावे अशी माझी इच्छा नाही, तुमच्यासारखे अनेक असावेत अशी माझी इच्छा आहे.”

चांगला सल्ला, बरोबर? स्केल. व्यवस्थापन. जबाबदारी. असे सामान्य buzzwords. सल्ला चुकीचा आहे हे खेदजनक आहे.

चुकीचे?

हं. सल्ला चुकीचा आहे! पूर्णपणे चुकीचे नाही, परंतु इतके चुकीचे आहे की मला काही माजी सहकाऱ्यांना कॉल करून माफी मागावी लागली: “तुम्ही कोड लिहिणे कसे थांबवावे याबद्दल माझे ते आवडते विधान लक्षात ठेवा? ते चुकीचे आहे! होय... पुन्हा प्रोग्रामिंग सुरू करा. पायथन आणि रुबी सह प्रारंभ करा. होय, मी गंभीर आहे! तुमचं करिअर यावर अवलंबून आहे!”

जेव्हा मी माझ्या करिअरला बोरलँड येथे सॉफ्टवेअर डेव्हलपर म्हणून सुरुवात केली, तेव्हा मी पॅराडॉक्स विंडोज टीममध्ये काम केले, जो एक मोठा संघ होता. एकट्या 13 ऍप्लिकेशन डेव्हलपर होते. जर तुम्ही इतर संघातील लोकांना जोडले जे या प्रकल्पासाठी मुख्य तंत्रज्ञानावर सतत काम करत होते, जसे की कोर डेटाबेस इंजिन आणि कोर अॅप्लिकेशन सेवा, तुम्हाला या उत्पादनाच्या विकासात थेट 50 अभियंते सहभागी झाले आहेत.

मी कधीही काम केलेला दुसरा कोणताही संघ या आकाराच्या जवळ येत नाही. खरं तर, प्रत्येक उत्तीर्ण वर्षासह, मी काम करत असलेल्या संघातील लोकांची संख्या हळूहळू कमी होत आहे. काय चालू आहे? आम्ही विकासक एकत्रितपणे अधिक हुशार आणि हुशार होत आहोत का? नाही, आम्ही फक्त भार सामायिक करत आहोत.

गेल्या 20 वर्षांपासून विकासक काय करत आहेत? या वेळी आम्ही कोडचा एक शिटलोड लिहिला. संहितेचा समुद्र! आम्ही इतका कोड लिहिला की आम्ही ठरवले की सर्वकाही सोपे करणे आणि मुक्त स्रोत जाणे ही चांगली कल्पना असेल.

सुदैवाने, इंटरनेटचे आभार, ही प्रक्रिया आता शक्य तितकी सोपी झाली आहे. तुम्ही सॉफ्टवेअर डेव्हलपर असल्यास, तुम्ही ते आत्ता तपासू शकता! Google किंवा Github वर तुमचे नाव शोधा आणि तुम्हाला कोड दिसेल ज्याबद्दल तुम्ही विसरला आहात, परंतु तो कोणालाही सापडेल. भितीदायक, बरोबर? तुम्हाला माहीत नव्हते का की कोड कायम राहतो? होय, तो कायमचा जगतो.

संहिता कायम राहते. आणि चांगला संहिता केवळ कायमचाच राहत नाही, तर तो वाढतो कारण जे त्याचे महत्त्व देतात ते सतत ताजे राहतील याची खात्री करतात. हा उच्च-गुणवत्तेचा, सुव्यवस्थित कोडचा ढीग सरासरी अभियांत्रिकी संघाचा आकार कमी करण्यात मदत करतो कारण तो आम्हाला नवीन कोड लिहिण्याऐवजी विद्यमान कोडवर लक्ष केंद्रित करण्यास आणि कमी लोकांसह आणि कमी वेळेत काम पूर्ण करण्यास अनुमती देतो.

तर्कशक्तीची ही ओळ निराशाजनक वाटते, परंतु कल्पना अशी आहे की आपण सर्व फक्त एकाच गोष्टीची थोडी वेगळी आवृत्ती तयार करण्यासाठी विद्यमान गोष्टींचे वेगवेगळे बिट एकत्र जोडण्यासाठी डक्ट टेप वापरून एकत्रीकरण ऑटोमेटाचा एक समूह आहोत. आउटसोर्सिंगची आवड असलेल्या वरिष्ठ अधिकाऱ्यांमध्ये ही एक उत्कृष्ट विचारसरणी आहे. “ज्याला Google कसे वापरायचे हे माहित आहे आणि ज्याच्याकडे काही डक्ट टेप आहे तो हे करू शकतो! मग आम्ही आमच्या मशिनला खूप पैसे का देत आहोत?”

आम्ही या मॅनेजमेंट लोकांना खरोखरच मोठे पैसे देतो, परंतु ते असे मूर्खपणाचे विचार करतात. पुन्हा एकदा, माझा कळीचा मुद्दा असा आहे की आपल्या ग्रहावर अनेक हुशार आणि खूप मेहनती विकासक आहेत; ते खरोखरच हुशार आणि मेहनती आहेत, जरी त्यांनी मान्यताप्राप्त विद्यापीठांमध्ये बसून एक मिनिटही घालवला नाही. अरे हो, आता त्यापैकी अधिक आणि अधिक आहेत!

काही हुशार कॉम्रेड कथितपणे त्याची शिकार करत असल्यामुळे तुम्ही तुमच्या जागेची काळजी करू नका असे मी सुचवत नाही. मी सुचवितो की आपण याबद्दल काळजी करणे सुरू करा कारण सॉफ्टवेअर विकासाची उत्क्रांती कदाचित आपल्यापेक्षा वेगाने पुढे जात आहे. तुम्ही दहा वर्षे काम करत आहात, त्यापैकी पाच व्यवस्थापक म्हणून, आणि तुम्हाला वाटते: “सॉफ्टवेअर कसे विकसित केले जाते हे मला आधीच माहित आहे.” होय, तुम्हाला माहिती आहे. बाय…

कोड लिहिणे थांबवा, पण...

जर तुम्ही माझ्या मूळ सल्ल्याचे पालन केले आणि कोड लिहिणे थांबवले, तर तुम्ही स्वेच्छेने निर्मिती प्रक्रियेत भाग घेणे देखील थांबवाल. या कारणास्तव मी सक्रियपणे आउटसोर्सिंग वापरत नाही. ऑटोमॅटा निर्माण करत नाहीत, ते निर्माण करतात. चांगल्या प्रकारे डिझाइन केलेल्या प्रक्रिया खूप पैसे वाचवतात, परंतु ते आपल्या जगात नवीन काहीही आणत नाहीत.

जर तुमची छोटी टीम थोड्या पैशासाठी खूप काही करत असेल, तर कोड लिहिणे थांबवण्याची कल्पना माझ्यासाठी वाईट करियर निर्णयासारखी वाटते. अक्राळविक्राळ कंपन्यांमध्येही त्यांचे अंतहीन नियम, प्रक्रिया आणि धोरणे, तुम्हाला स्वतः सॉफ्टवेअर कसे विकसित करायचे हे विसरून जाण्याचा अधिकार नाही. आणि सॉफ्टवेअर विकास सतत बदलत आहे. ते सध्या बदलत आहे. तुझ्या पायाखाली! या अगदी सेकंदाला!

तुमचा आक्षेप आहे. समजून घ्या. चला ऐकूया.

“रँड्स, मी दिग्दर्शकाच्या खुर्चीकडे जात आहे! जर मी कोड लिहित राहिलो तर मी वाढू शकेन यावर कोणाचाही विश्वास बसणार नाही.”

मी तुम्हाला हे विचारू इच्छितो: तुम्ही तुमच्या “मी सीईओ बनणार आहे!” खुर्चीवर बसल्यापासून, तुमच्या लक्षात आले आहे की सॉफ्टवेअर डेव्हलपमेंट लँडस्केप बदलत आहे, अगदी तुमच्या कंपनीतही? जर तुमचे उत्तर होय असेल, तर मी तुम्हाला आणखी एक प्रश्न विचारेन: ते नेमके कसे बदलत आहे आणि या बदलांबद्दल तुम्ही काय करणार आहात? जर तुम्ही माझ्या पहिल्या प्रश्नाला "नाही" असे उत्तर दिले असेल, तर तुम्हाला वेगळ्या खुर्चीवर जावे लागेल, कारण (मी पैज लावतो!) सॉफ्टवेअर डेव्हलपमेंटचे क्षेत्र या सेकंदात बदलत आहे. सॉफ्टवेअर कसे विकसित करायचे हे तुम्ही हळूहळू पण निश्चितपणे विसरल्यास तुमची वाढ कशी होईल?

तुमच्‍या पुढील उत्‍पादनासाठी अनेक वैशिष्‍ट्ये लागू करण्‍यासाठी स्‍वत:ला वचनबद्ध न करण्‍याचा माझा सल्ला आहे. तुमचा कार्यसंघ सॉफ्टवेअर कसा तयार करत आहे याच्या शीर्षस्थानी राहण्यासाठी तुम्हाला सतत पावले उचलण्याची आवश्यकता आहे. तुम्ही हे संचालक आणि उपाध्यक्ष म्हणून करू शकता. काहीतरी?

“अग, रँड्स! पण कोणीतरी मध्यस्थ व्हायला हवे! कोणीतरी मोठे चित्र पहावे लागेल. जर मी कोड लिहिला तर मी दृष्टीकोन गमावेन.

तुम्हाला अजूनही रेफरी व्हायचे आहे, तुम्हाला अजूनही निर्णय प्रसारित करायचे आहेत, आणि तरीही तुम्हाला दर सोमवारी सकाळी तुमच्या एका अभियंत्यासोबत इमारतीभोवती चार वेळा फिरावे लागते आणि त्याचे साप्ताहिक "आम्ही सर्व नशिबात आहोत" हे ३० रुपये ऐकण्यासाठी मिनिटे.! पण त्यापलीकडे, तुम्हाला अभियांत्रिकी मानसिकता जपली पाहिजे, आणि ते करण्यासाठी तुम्हाला पूर्ण-वेळ प्रोग्रामर असण्याची गरज नाही.

अभियांत्रिकी मानसिकता राखण्यासाठी माझ्या टिपा:

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

पुन्हा आक्षेप?

“रँड्स, जर मी कोड लिहिला तर मी माझ्या टीमला गोंधळात टाकीन. मी कोण आहे हे त्यांना कळणार नाही—व्यवस्थापक किंवा विकासक.”

Хорошо.

होय, मी म्हणालो, "ठीक आहे!" विकासकाच्या तलावात पोहून तुम्ही तुमच्या टीमला गोंधळात टाकू शकता असे तुम्हाला वाटते याचा मला आनंद आहे. हे सोपे आहे: सॉफ्टवेअर डेव्हलपमेंटमधील विविध भूमिकांमधील सीमा सध्या खूप अस्पष्ट आहेत. UI लोक तेच करतात ज्याला व्यापकपणे JavaScript आणि CSS प्रोग्रामिंग म्हटले जाऊ शकते. विकसक वापरकर्ता अनुभव डिझाइनबद्दल अधिकाधिक शिकत आहेत. लोक एकमेकांशी संवाद साधतात आणि बग्सबद्दल, इतर लोकांच्या कोडच्या चोरीबद्दल जाणून घेतात आणि या मोठ्या, जागतिक, क्रॉस-परागकण माहिती बॅचनालियामध्ये सहभागी न होण्याचे कोणतेही चांगले कारण व्यवस्थापकासाठी नाही.

याशिवाय, तुम्ही सहजपणे बदलता येण्याजोग्या घटकांचा समावेश असलेल्या संघाचा भाग होऊ इच्छिता? हे फक्त तुमचा कार्यसंघ अधिक चपळ बनवणार नाही, ते प्रत्येक कार्यसंघ सदस्याला उत्पादन आणि कंपनीला विविध दृष्टीकोनातून पाहण्याची संधी देईल. त्याच्या बिल्ड स्क्रिप्ट्सची साधी अभिजातता पाहिल्यानंतर तुम्ही फ्रँकचा आदर कसा करू शकता, जो बिल्डचा प्रभारी शांत माणूस आहे?

तुमचा संघ गोंधळलेला आणि अराजक होऊ नये अशी माझी इच्छा आहे. याउलट, तुमच्या टीमने अधिक प्रभावीपणे संवाद साधावा अशी माझी इच्छा आहे. मला विश्वास आहे की जर तुम्ही उत्पादन तयार करण्यात आणि वैशिष्ट्यांवर काम करत असाल तर तुम्ही तुमच्या टीमच्या अधिक जवळ असाल. आणि सर्वात महत्त्वाचे म्हणजे, तुम्ही तुमच्या संस्थेतील सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेतील सतत बदलांच्या जवळ असाल.

विकास थांबवू नका

बोरलँड येथील माझ्या एका सहकाऱ्याने तिला “कोडर” म्हटल्याबद्दल माझ्यावर शाब्दिक हल्ला केला.

“रँड्स, कोडर हे एक निर्बुद्ध मशीन आहे! माकड! निरुपयोगी कोडच्या कंटाळवाण्या ओळी लिहिण्याशिवाय कोडर काहीही महत्त्वाचे करत नाही. मी कोडर नाही, मी सॉफ्टवेअर डेव्हलपर आहे!”

ती बरोबर होती, तिने नवीन सीईओंना माझ्या सुरुवातीच्या सल्ल्याचा तिरस्कार केला असेल: "कोड लिहिणे थांबवा!" मी सुचवत आहे की ते कोडर आहेत म्हणून नाही, परंतु अधिक कारण मी सक्रियपणे सुचवत आहे की ते त्यांच्या कामाच्या सर्वात महत्वाच्या भागांपैकी एकाकडे दुर्लक्ष करू लागतात: सॉफ्टवेअर डेव्हलपमेंट.

म्हणून मी माझा सल्ला अपडेट केला आहे. जर तुम्हाला चांगला नेता व्हायचे असेल तर तुम्ही कोड लिहिणे थांबवू शकता, पण...

लवचिक व्हा. अभियंता होण्याचा अर्थ काय आहे हे लक्षात ठेवा आणि सॉफ्टवेअर विकसित करणे थांबवू नका.

लेखकाबद्दल

मायकेल लोप हा एक अनुभवी सॉफ्टवेअर डेव्हलपर आहे ज्याने अद्याप सिलिकॉन व्हॅली सोडलेली नाही. गेल्या 20 वर्षांत, मायकेलने Apple, Netscape, Symantec, Borland, Palantir, Pinterest यासह विविध नाविन्यपूर्ण कंपन्यांसाठी काम केले आहे आणि हळूहळू विस्मृतीत गेलेल्या स्टार्टअपमध्येही भाग घेतला आहे.

कामाच्या बाहेर, मायकेल रँड्स या टोपणनावाने तंत्रज्ञान आणि व्यवस्थापनाबद्दल एक लोकप्रिय ब्लॉग चालवतो, जिथे तो वाचकांशी व्यवस्थापन क्षेत्रातील कल्पनांवर चर्चा करतो, नाडीवर सतत बोट ठेवण्याच्या गरजेबद्दल चिंता व्यक्त करतो आणि स्पष्ट करतो की, तरीही उत्पादन तयार करण्यासाठी उदार बक्षिसे, तुमचे यश केवळ तुमच्या कार्यसंघामुळेच शक्य आहे. ब्लॉग येथे आढळू शकतो www.randsinrepose.com.

कॅलिफोर्नियातील रेडवुड येथे मायकेल आपल्या कुटुंबासह राहतो. तो नेहमी माउंटन बाईक, हॉकी खेळण्यासाठी आणि रेड वाईन पिण्यासाठी वेळ काढतो, कारण व्यस्त असण्यापेक्षा निरोगी राहणे अधिक महत्त्वाचे आहे.

» पुस्तकाबद्दल अधिक तपशील येथे आढळू शकतात प्रकाशकाची वेबसाइट
» सामग्री सारणी
» उतारा

Khabrozhiteley साठी कूपन वापरून 20% सूट - लोकांचे व्यवस्थापन

पुस्तकाच्या कागदी आवृत्तीसाठी पैसे दिल्यानंतर, पुस्तकाची इलेक्ट्रॉनिक आवृत्ती ई-मेलद्वारे पाठविली जाईल.

P.S.: पुस्तकाच्या किमतीच्या 7% नवीन संगणकीय पुस्तकांच्या अनुवादावर जाईल, पुस्तकांची यादी मुद्रणगृहाला सुपूर्द केली जाईल येथे.

स्त्रोत: www.habr.com