सबक परियोजना से सीखा दफनाया गया था

यह पाठ पर मेरे प्रदर्शन पर आधारित है GRWebDev । यह एक परियोजना की कहानी है जिसे गीथहब पर रद्द और दफन किया गया था, साथ ही साथ इस पर काम करने से सबक भी सीखा गया था।





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



जब 6 लोगों को एक टीम के रूप इकट्ठा की हमारी टीम किक शुरू परियोजना है, हम दो बातें पता था:

1) हम रिकॉर्ड बातचीत के कुछ आंतरिक घटनाओं था, और

2) हम rassharivaniya स्लाइड प्रदर्शन के लिए एक वेबसाइट बनाने के अनुभव है ( speakerdeck.com )



हमारा मिशन एक उत्पाद है कि किसी भी कंपनी या उपयोगकर्ताओं के समूह रिकॉर्ड और बातचीत (वार्ता) की रिकॉर्डिंग वापस खेल सकते हैं और उन्हें साझा करने की अनुमति होगी में इन दो चीजों गठबंधन करने के लिए किया गया था।



11 महीनों के बाद, हमारी टीम इस परियोजना पर काम करना बंद करने का निर्णय लिया।

एक आम दृष्टि विकसित करने के लिए

हमारी टीम के सदस्यों ने पहले कभी साथ काम नहीं किया। हम एक आम अनुभव नहीं था, और भरोसा नहीं था। विशिष्ट शैली में, GitHub, हम न तो एक प्रबंधक और न ही एक "रोड मैप" था। हम में से कोई भी वास्तव में जानता था कि, आम तौर पर कहा जाए तो, हमारे उत्पाद की क्या होना चाहिए?



सर्वश्रेष्ठ कार्यक्रम टीमों से आते हैं जहां हर कोई एक साझा दृष्टिकोण साझा करता है, वास्तव में परिणाम की परवाह करता है, और इसे प्राप्त करने के लिए प्रेरित होता है। भागीदारी के इस स्तर को केवल वहीं प्राप्त किया जा सकता है जहां हर कोई एक सामान्य दृष्टि के निर्माण में भाग लेता है और इसका हिस्सा "मालिक" होता है।



धीरे-धीरे, हमने एक दूसरे का विश्वास जीता और उत्पाद के बारे में हमारे विचार एकजुट होने लगे, लेकिन तब तक 6 महीने बीत चुके थे।



पाठ 1: एक टीम में एक एकल उत्पाद विज़न बनाएँ

"सफलता" और "विफलता" परिभाषित करें

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



वहाँ कैसे सफल होने के लिए के लिए कोई जादू फार्मूला है, और कहा कि मैं आपको बता नहीं होगा। लेकिन मुझे पता है कि आप यह नहीं कह सकते हैं कि आपने इसे हासिल किया है या नहीं, अगर आप नहीं जानते कि इसका मूल्यांकन कैसे किया जाए, तो यह किस मापदंड से होगा। हम परियोजना पर काम किया है 6 महीने से पहले पहली बार मेज पर एक साथ बैठ गए और क्या एक सफलता माना जा सकता है पर चर्चा, और कहा कि - परियोजना पर एक विफलता।



पाठ 2: जब आप एक आम दृष्टि विकसित किया है,, विफलता (विफलता) की परिभाषा सफलता की परिभाषा का विस्तार, और, पिछले नहीं बल्कि कम से कम। "सफलता" करने के लिए और नियमित रूप से करने के लिए पथ पर लक्ष्य निर्धारित करें इन उद्देश्यों के साथ इस परियोजना की स्थिति की जांच

सार्थक कृत्रिम प्रतिबंध बनाएं

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



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



एक ही बात परियोजनाओं में होता है। सॉफ्टवेयर विकास "सही" की सभी आवश्यकताओं को पूरा करने के लिए - paralyzing। सॉफ्टवेयर "एक समय में फ़ंक्शन द्वारा" बनाया जाता है। सीमा का चयन कर उन्हें आप पर ध्यान केंद्रित करने में मदद करने के लिए "इस विशेष क्षण में महत्वपूर्ण है।"



मील के पत्थर इस तरह के प्रतिबंध का एक रूप हैं (कुछ उन्हें "समय सीमा" कहते हैं, लेकिन मैं "मील के पत्थर" पसंद करता हूं)। मील का पत्थर - यह एक विशिष्ट तिथि है जिसके द्वारा आप एक निश्चित लक्ष्य को प्राप्त करने जा रहे हैं। फिक्स्ड दिनांकों एक "स्कोप" (विशिष्ट आवश्यकताओं का एक सेट) शामिल नहीं किया जाना चाहिए। आप 60 घंटे एक सप्ताह, मील के पत्थर को पूरा करने के काम करते हैं, तो इसका मतलब है आप समझ में नहीं आता कि मैं क्या कह रहा हूँ। प्रतिबंध किसी को भी अधिक काम करने के लिए मजबूर नहीं करना चाहिए। यह आपको बेहतर प्रदर्शन की मदद करनी चाहिए।



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



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



पाठ 3: कृत्रिम बाधाओं कि विफलताओं और सफलता प्राप्त करने में मदद के परिहार के लिए योगदान देगा बनाएं

लोग उत्पाद से अधिक महत्वपूर्ण हैं

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



सभी टीम burnout से पीड़ित हैं। लगातार आपसी आलोचना मिल्ड millstones हम में से प्रत्येक। हम चीजों को करने से पहले हमें इतना मोहित कर रहे हैं उस पर काम करने के लिए प्रेरणा खो दिया है क्योंकि तुम सब क्या कर रहे थे, जल्द ही "बेकार" या "हो गया गलत" हो सकता है।



अध्याय 4: आप लोगों के बारे में परवाह है, तो परियोजना खुद का ख्याल रखना। सुनिश्चित करने के लिए कोई प्रयास नहीं zhaleyti है कि वह क्या करता है की तरह टीम में प्रत्येक व्यक्ति को। मुबारक लोगों को सबसे अच्छा उत्पादों का उत्पादन

"विफलता" - नहीं एक विफलता

परियोजना की समाप्ति लोगों के लिए opustoschayuschim अनुभव हो सकता है। कई सहयोगियों अप "अपने आप की तरह ठीक है, तुम?" सवाल के साथ तो मेरे पास आया, एक नज़र के साथ के रूप में अगर मैं खो दिया था एक एक प्यार करता था। यह बहुत अनुभव ले लिया है, लेकिन धीरे-धीरे मैं "विफलताएं" अनुभव करने के लिए सीखा है।



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



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



अध्याय 5: "विफलता" - यह है जब आप कैसे अगली बार बेहतर करने के लिए सीखना है। मैं विफलताओं की तरह।

हम परियोजना क्यों रद्द कर दिया है है

हमें 11 महीनों में कई उपयोगी सबक मिले हैं। उपरोक्त वह है जो मुझे व्यक्तिगत रूप से सबसे महत्वपूर्ण लगता है। लेकिन उन त्रुटियों में से कोई भी कारण नहीं है कि परियोजना को छोड़ दिया गया था।



जैसे github.com (साइट) ध्वनियों के लिए हमारे नारे "एक कार्यक्रम एक साथ बेहतर बनाएं।" हमारे विकास और प्रगति के रूप में, हम लगातार कि क्या यह दृष्टि GitHub, इंक (कंपनी) की एक पर्याप्त वर्णन है के सवाल का सामना कर रहे हैं। हम अक्सर कहते हैं कि हमारी कंपनी के दर्शन के रूप में वर्णित किया जा सकता है "एक से अधिक आसानी से एक साथ काम कर रहे हैं।" यह देखते हुए कि हमारे कर्मचारियों में से 75% दूर से काम करते हैं, विशेष रूप से सहयोग तुच्छ हो जाता है जब आप विभिन्न समय क्षेत्रों में सहयोगियों के साथ कर रहे हैं। हम, अद्वितीय के साथ सामना कर रहे हैं ज्यादातर कंपनियों, चुनौतियों के लिए विशिष्ट नहीं।



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



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



वैसे भी, मैं इन सबक के लिए आभारी हूँ और अपनी अगली परियोजना के लिए इस ज्ञान का उपयोग करने की उम्मीद है।