अपना प्रोजेक्ट

जून 2021

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

इस अर्थ में स्केटिंग करने वाले लोगों द्वारा कितना महान काम किया गया है? यदि सब कुछ नहीं, तो निश्चित रूप से बहुत कुछ।

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

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

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

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

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

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

यह अपरिहार्य हो सकता है कि स्कूल वैसा ही हो जैसा वह है। मैं यह नहीं कह रहा हूं कि हमें इसे फिर से डिजाइन करना है (हालांकि मैं यह नहीं कह रहा हूं कि हम नहीं करते हैं), बस इतना है कि हमें यह समझना चाहिए कि यह काम के प्रति हमारे दृष्टिकोण को क्या करता है - कि यह हमें काम के कर्तव्यनिष्ठ, धीमे प्रकार की ओर ले जाता है, अक्सर प्रतिस्पर्धा को चारा के रूप में उपयोग करता है, और स्केटिंग से दूर ले जाता है।

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

तो अपने प्रोजेक्ट का किनारा वास्तव में कहाँ है? यह एक दिलचस्प सवाल है, आंशिक रूप से इसलिए कि उत्तर बहुत जटिल है, और आंशिक रूप से इसलिए कि इसमें बहुत कुछ दांव पर लगा है। काम दो अर्थों में अपना हो सकता है: 1) कि आप इसे स्वेच्छा से कर रहे हैं, बजाय इसके कि कोई आपको बताए, और 2) कि आप इसे स्वयं कर रहे हैं।

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

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

किसी प्रोजेक्ट के अपने होने का दूसरा अर्थ - इसे स्वयं करना - का किनारा बहुत नरम है। यह धीरे-धीरे सहयोग में बदल जाता है। और दिलचस्प बात यह है कि यह दो अलग-अलग तरीकों से सहयोग में बदल जाता है। सहयोग करने का एक तरीका एक एकल प्रोजेक्ट साझा करना है। उदाहरण के लिए, जब दो गणितज्ञ एक ऐसे प्रमाण पर सहयोग करते हैं जो उनके बीच बातचीत के दौरान आकार लेता है। दूसरा तरीका तब होता है जब कई लोग अपने अलग-अलग प्रोजेक्ट पर काम करते हैं जो जिग्सॉ पहेली की तरह फिट होते हैं। उदाहरण के लिए, जब एक व्यक्ति एक किताब का पाठ लिखता है और दूसरा ग्राफिक डिजाइन करता है। [3]

सहयोग के ये दो रास्ते निश्चित रूप से संयुक्त हो सकते हैं। लेकिन सही परिस्थितियों में, अपने प्रोजेक्ट पर काम करने का उत्साह काफी समय तक बना रह सकता है, इससे पहले कि वह किसी बड़े संगठन में काम के अशांत प्रवाह में विघटित हो जाए। वास्तव में, सफल संगठनों का इतिहास आंशिक रूप से उस उत्साह को बनाए रखने की तकनीकों का इतिहास है। [4]

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

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

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

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

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

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

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

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

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

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

नोट्स

[1] "शौक" एक अजीब शब्द है। अब इसका मतलब है काम जो वास्तविक काम नहीं है - ऐसा काम जिसके लिए किसी को आंका नहीं जाना चाहिए - लेकिन मूल रूप से इसका मतलब केवल एक सामान्य अर्थ में जुनून था (यहां तक कि एक राजनीतिक राय, उदाहरण के लिए) जिस पर कोई लाक्षणिक रूप से सवारी करता था जैसे बच्चा हॉबी-हॉर्स की सवारी करता है। यह कहना मुश्किल है कि क्या इसके हालिया, संकीर्ण अर्थ में बदलाव बेहतर या बदतर के लिए है। निश्चित रूप से बहुत सारे झूठे सकारात्मक हैं - बहुत सारे प्रोजेक्ट जो अंततः महत्वपूर्ण हो जाते हैं लेकिन शुरू में केवल शौक के रूप में खारिज कर दिए जाते हैं। लेकिन दूसरी ओर, यह अवधारणा शुरुआती, बदसूरत बत्तख के बच्चे के चरण में परियोजनाओं के लिए मूल्यवान कवर प्रदान करती है।

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

[3] अपने प्रोजेक्ट पर काम करने और दूसरों के साथ सहयोग करने के बीच जटिल, क्रमिक किनारा एक कारण है कि "अकेले प्रतिभा" के विचार पर इतना असहमति क्यों है। व्यवहार में लोग विभिन्न प्रकार के तरीकों से सहयोग करते हैं (या नहीं), लेकिन अकेले प्रतिभा का विचार निश्चित रूप से एक मिथक नहीं है। इसमें सच्चाई का एक मूल है जो काम करने के एक निश्चित तरीके के साथ जाता है।

[4] सहयोग भी शक्तिशाली है। इष्टतम संगठन सहयोग और स्वामित्व को इस तरह से जोड़ देगा कि प्रत्येक को कम से कम नुकसान हो। दिलचस्प बात यह है कि कंपनियां और विश्वविद्यालय विभाग विपरीत दिशाओं से इस आदर्श तक पहुंचते हैं: कंपनियां सहयोग पर जोर देती हैं, और कभी-कभी स्केटर्स को भर्ती करने और उन्हें स्केट करने की अनुमति देने का प्रबंधन करती हैं, और विश्वविद्यालय विभाग स्वतंत्र अनुसंधान करने की क्षमता पर जोर देते हैं (जिसे रिवाज के अनुसार स्केटिंग माना जाता है, चाहे वह हो या न हो), और जिन लोगों को वे नियुक्त करते हैं वे उतना ही सहयोग करते हैं जितना वे चुनते हैं।

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

धन्यवाद ट्रेवर ब्लैकवेल, पॉल बुचहाइट, एंडी हर्ट्ज़फेल्ड, जेसिका लिविंगस्टन, और पीटर नॉरविग को इस लेख के ड्राफ्ट पढ़ने के लिए।