पुस्तक "कसरी बौद्धिक व्यवस्थापन गर्ने। म, नर्ड र गिक्स"

परियोजना प्रबन्धकहरूलाई समर्पित (र मालिक बन्ने सपना देख्नेहरू)।

धेरै कोडहरू लेख्न गाह्रो छ, तर मानिसहरूलाई व्यवस्थापन गर्न अझ गाह्रो छ! त्यसोभए तपाईलाई यो पुस्तक चाहिन्छ कि दुबै कसरी गर्ने भनेर जान्नको लागि।

के यो हास्यास्पद कथाहरू र गम्भीर पाठहरू संयोजन गर्न सम्भव छ? माइकल लोप (जसलाई साँघुरो सर्कलमा रान्ड्स पनि भनिन्छ) सफल भए। तपाईंले अविश्वसनीय रूपमा इनामदायी (काल्पनिक भए पनि) अनुभवहरू भएका काल्पनिक व्यक्तिहरूको बारेमा काल्पनिक कथाहरू फेला पार्नुहुनेछ। ठूला आईटी कर्पोरेसनहरूमा काम गरेको वर्षौंमा प्राप्त भएका विभिन्न, कहिलेकाहीँ अनौठो अनुभवहरू: Apple, Pinterest, Palantir, Netscape, Symantec, आदि Rands ले यसरी साझा गर्छन्।

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

यो पुस्तक कुनै पनि व्यवस्थापन वा नेतृत्व पाण्डुलिपि भन्दा फरक छ। माइकल लोपले केहि पनि लुकाउँदैन, उसले यो जस्तो छ भन्ने मात्र भन्छ (सम्भवतः सबै कथाहरू सार्वजनिक गरिनु हुँदैन: P)। तर केवल यस तरिकाले तपाईले यस्तो मालिकसँग कसरी बाँच्ने, कसरी गीक्स र नर्डहरू व्यवस्थापन गर्ने, र कसरी "त्यो धिक्कार परियोजना" लाई सुखद अन्त्यमा ल्याउने भनेर बुझ्नुहुनेछ!

अंश। इन्जिनियरिङ मानसिकता

विचारहरू: के तपाईंले कोड लेखन जारी राख्नु पर्छ?

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

लचिलो रहनुहोस्!

तपाईलाई पहिले नै सबै कुरा थाहा छ भन्ने सोच्नु धेरै नराम्रो विचार हो। यस्तो अवस्थामा जहाँ एकमात्र स्थिर तथ्य यो हो कि संसार निरन्तर परिवर्तन भइरहेको छ, लचिलोपन मात्र सही स्थिति बन्छ।

विरोधाभासको रूपमा, सूचीमा दोस्रो वस्तु आश्चर्यजनक रूपमा लचिलो छ। यद्यपि, यो बिन्दु मेरो व्यक्तिगत मनपर्ने हो किनभने मलाई विश्वास छ कि यसले व्यवस्थापकीय वृद्धिको लागि आधार बनाउन मद्दत गर्दछ। यो अनुच्छेद पढ्छ:

कोड लेख्न रोक्नुहोस्!

सिद्धान्तमा, यदि तपाइँ प्रबन्धक बन्न चाहानुहुन्छ भने, तपाइँले तपाइँको लागि काम गर्नेहरूलाई विश्वास गर्न सिक्नुपर्छ र कोडिङ पूर्णतया तिनीहरूलाई हस्तान्तरण गर्नुपर्छ। यो सल्लाह सामान्यतया पचाउन गाह्रो हुन्छ, विशेष गरी भर्खरका प्रबन्धकहरूका लागि। सम्भवतः तिनीहरूको प्रबन्धक बन्नुको एउटा कारण तिनीहरूको विकासमा उत्पादकता हो, र जब चीजहरू गलत हुन्छन्, तिनीहरूको पहिलो प्रतिक्रिया तिनीहरूमा पूर्ण विश्वास भएको कौशलहरूमा फर्कनु हो, जुन तिनीहरूको कोड लेख्ने क्षमता हो।

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

राम्रो सल्लाह, हैन? स्केल। व्यवस्थापन। जिम्मेवारी। यस्ता सामान्य buzzwords। सल्लाह गलत हुनु दुखद कुरा हो।

गलत?

हो। सल्लाह गलत छ! पूर्णतया गलत होइन, तर पर्याप्त गलत छ कि मैले केही पूर्व सहकर्मीहरूलाई फोन गरेर माफी माग्नुपर्ने भयो: "तपाईंले कोड लेख्न कसरी रोक्नु पर्छ भन्ने मेरो मनपर्ने कथन सम्झनुहोस्? यो गलत छ! हो... फेरि प्रोग्रामिङ सुरु गर्नुहोस्। पाइथन र रुबीसँग सुरु गर्नुहोस्। हो, म गम्भीर छु! तपाईंको क्यारियर यसमा निर्भर गर्दछ! ”

जब मैले बोर्ल्यान्डमा सफ्टवेयर विकासकर्ताको रूपमा मेरो क्यारियर सुरु गरें, मैले प्याराडक्स विन्डोज टोलीमा काम गरें, जुन ठूलो टोली थियो। त्यहाँ 13 अनुप्रयोग विकासकर्ताहरू एक्लै थिए। यदि तपाइँ यस परियोजनाको लागि मुख्य प्रविधिहरूमा निरन्तर काम गरिरहेका अन्य टोलीहरू, जस्तै कोर डाटाबेस इन्जिन र कोर एप्लिकेसन सेवाहरूमा काम गरिरहेका व्यक्तिहरू थप्नुहुन्छ भने, तपाइँले यस उत्पादनको विकासमा प्रत्यक्ष रूपमा संलग्न 50 इन्जिनियरहरू पाउनुभयो।

मैले काम गरेको कुनै पनि अन्य टोली यो आकारको नजिक पनि आउँदैन। वास्तवमा, प्रत्येक बितेको वर्ष संग, मैले काम गर्ने टोलीमा मानिसहरूको संख्या क्रमशः घट्दै गएको छ। के हुँदैछ? के हामी विकासकर्ताहरू सामूहिक रूपमा स्मार्ट र स्मार्ट हुँदैछौं? होइन, हामीले लोड मात्र बाँडिरहेका छौं।

विगत २० वर्षदेखि विकासकर्ताहरूले के गरिरहेका छन्? यस समयमा हामीले कोडको शिटलोड लेख्यौं। कोडको सागर! हामीले यति धेरै कोड लेख्यौं कि हामीले निर्णय गर्यौं कि सबै कुरालाई सरल बनाउन र खुला स्रोतमा जानु राम्रो विचार हुनेछ।

सौभाग्य देखि, इन्टरनेट को लागी धन्यवाद, यो प्रक्रिया अब सकेसम्म सरल भएको छ। यदि तपाइँ सफ्टवेयर विकासकर्ता हुनुहुन्छ भने, तपाइँ यसलाई अहिले नै जाँच गर्न सक्नुहुन्छ! Google वा Github मा आफ्नो नाम खोज्नुहोस् र तपाईंले कोड देख्नुहुनेछ जुन तपाईंले लामो समयदेखि बिर्सनुभएको छ, तर जो कोहीले फेला पार्न सक्छ। डरलाग्दो, सही? के तपाईंलाई थाहा थिएन कि कोड सधैंभरि रहन्छ? हो, उहाँ सधैंभरि जीवित हुनुहुन्छ।

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

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

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

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

कोड लेख्न रोक्नुहोस्, तर...

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

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

तपाईहरुको आपत्ति छ । बुझ्नुहोस्। आउनुहोस् सुनौं।

"रान्ड्स, म निर्देशकको कुर्सीमा जाँदैछु! यदि मैले कोड लेखिरहेँ भने, म बढ्न सक्छु भनेर कसैले विश्वास गर्दैनन्।

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

मेरो सल्लाह तपाईको अर्को उत्पादनको लागि धेरै सुविधाहरू लागू गर्न आफैलाई प्रतिबद्ध नगर्नुहोस्। तपाइँको टोलीले कसरी सफ्टवेयर निर्माण गरिरहेको छ भन्ने बारे शीर्षमा रहनको लागि तपाइँले निरन्तर कदम चाल्न आवश्यक छ। तपाईं निर्देशक र उपाध्यक्ष दुवै रूपमा यो गर्न सक्नुहुन्छ। अरु केही?

"उ, रान्ड्स! तर कसैलाई मध्यस्थ हुनुपर्छ! कसैले ठूलो तस्वीर हेर्नु पर्छ। यदि मैले कोड लेखें भने, म परिप्रेक्ष्य गुमाउनेछु।"

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

ईन्जिनियरिङ् मानसिकता कायम राख्नका लागि मेरो सुझावहरू:

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

फेरी आपत्ति ?

"रान्ड्स, यदि मैले कोड लेखें भने, म मेरो टोलीलाई भ्रमित गर्नेछु। तिनीहरूले म को हुँ - प्रबन्धक वा विकासकर्ता थाहा पाउने छैनन्।

Хорошо।

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

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

म तपाईंको टोली भ्रमित र अराजक बन्न चाहन्न। यसको विपरित, म तपाईंको टोलीले अझ प्रभावकारी रूपमा सञ्चार गर्न चाहन्छु। मलाई विश्वास छ कि यदि तपाईं उत्पादन सिर्जना गर्न र सुविधाहरूमा काम गर्न संलग्न हुनुहुन्छ भने, तपाईं आफ्नो टोलीको नजिक हुनुहुनेछ। र अझ महत्त्वपूर्ण कुरा, तपाईं आफ्नो संगठन भित्र सफ्टवेयर विकास प्रक्रियामा निरन्तर परिवर्तनहरूको नजिक हुनुहुनेछ।

विकास गर्न नरोक्नुहोस्

बोर्ल्यान्डमा मेरो एक सहकर्मीले एक पटक मलाई "कोडर" भनेर बोलाएकोमा मौखिक रूपमा आक्रमण गरे।

"रान्ड्स, कोडर एक दिमागहीन मेसिन हो! बाँदर! बेकार कोडको बोरिंग लाइनहरू लेख्नु बाहेक कोडरले महत्त्वपूर्ण केही गर्दैन। म कोडर होइन, म सफ्टवेयर विकासकर्ता हुँ!”

उनी सहि थिइन्, उनले नयाँ सीईओहरूलाई मेरो प्रारम्भिक सल्लाहलाई घृणा गर्थे: "कोड लेख्न बन्द गर्नुहोस्!" किनभने मैले सुझाव दिइरहेको छु कि तिनीहरू कोडरहरू हुन्, तर थप किनभने म सक्रिय रूपमा सुझाव दिइरहेको छु कि उनीहरूले आफ्नो कामको सबैभन्दा महत्त्वपूर्ण भागहरू मध्ये एकलाई बेवास्ता गर्न थाल्छन्: सफ्टवेयर विकास।

त्यसैले मैले मेरो सल्लाह अपडेट गरेको छु। यदि तपाइँ राम्रो नेता बन्न चाहनुहुन्छ भने, तपाइँ कोड लेख्न बन्द गर्न सक्नुहुन्छ, तर ...

लचिलो हुनुहोस्। ईन्जिनियर हुनुको अर्थ के हो सम्झनुहोस् र सफ्टवेयर विकास गर्न नरोक्नुहोस्।

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

माइकल लोप एक अनुभवी सफ्टवेयर विकासकर्ता हुन् जसले अझै सिलिकन भ्याली छोडेका छैनन्। विगत २० वर्षमा, माइकलले Apple, Netscape, Symantec, Borland, Palantir, Pinterest लगायत विभिन्न अभिनव कम्पनीहरूको लागि काम गरेका छन् र बिस्तारै विस्मृतिमा डुबेको स्टार्टअपमा पनि भाग लिएका छन्।

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

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

» पुस्तकको बारेमा थप विवरणहरू यहाँ पाउन सकिन्छ प्रकाशकको ​​वेबसाइट
» सामग्रीको तालिका
» अंश

Khabrozhiteley को लागि कुपन प्रयोग गरेर 20% छुट - मान्छे व्यवस्थापन

पुस्तकको पेपर संस्करणको लागि भुक्तानी गरेपछि, पुस्तकको इलेक्ट्रोनिक संस्करण इ-मेल मार्फत पठाइनेछ।

PS: पुस्तकको मूल्यको 7% नयाँ कम्प्युटर पुस्तकहरूको अनुवादमा जान्छ, पुस्तकहरूको सूची मुद्रण गृहलाई हस्तान्तरण यहाँ.

स्रोत: www.habr.com