चंचल घोषणा पत्र (मानव रीमिक्स)

बड़ी वेब परियोजनाओं के प्रबंधन में, वे अक्सर क्लासिक अमेरिकी परियोजना प्रबंधन के सिद्धांतों को लागू करते हैं - एक कार्य योजना का सटीक निर्माण और इसके सटीक कार्यान्वयन। पावर प्वाइंट (अतिरंजना) पर सख्त रिपोर्ट, मुश्किल ग्राफिक्स और प्रस्तुतियाँ।

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

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

एक योजना का पालन करने की तुलना में परिवर्तन का जवाब देना अधिक महत्वपूर्ण है

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

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

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

योजनाओं में होने वाले परिवर्तनों के प्रति प्रतिक्रिया व्यक्त करना रोबोटों के मानवीय लाभों में से एक है।

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

इस मद की चर्चा पिछले एक से सुचारू रूप से बहती है - अनुबंध जो भी हो, हमेशा एक ऐसी स्थिति होगी जहां इसकी गैर-पूर्ति दोनों पक्षों के लिए फायदेमंद है।

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

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

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

"क्या आप मुझे टेप रिकॉर्डर पानी में फेंकना चाहते हैं?" खैर, मैं इसे करूंगा। " (नहीं किया)

व्यक्तित्व और उनकी बातचीत प्रक्रियाओं और उपकरणों की तुलना में अधिक महत्वपूर्ण हैं

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

वेब विकास में, आप डिजाइनरों के साथ काम करते हैं - जो अनिवार्य रूप से वैन गॉग कलाकार हैं - और प्रोग्रामर के साथ - जो और भी अधिक पागल और मूर्ख गणितज्ञ हैं, आइंस्टीन। इस जंगली समाज में आप किस तरह की व्यवस्था, कौन सी प्रक्रिया और नियम की बात कर सकते हैं? भूल जाओ!

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

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

जब मैं प्रोजेक्ट में आया और बिल्ड एडिटर से परिचित हो गया, तो मैंने कॉन्ट्रैक्ट को रेड कर दिया। उन्होंने दो तस्वीरों की अनिवार्य सीमा को हटा दिया और कलाकार को सचित्र समाचार चुनने का अधिकार दिया। आदमी ने स्वतंत्रता महसूस की, आराम किया, और वर्ष के दौरान एक सप्ताह में कम से कम अठारह चित्र दिए। दक्षता - एक ही पैसे के लिए 180% और एक ही गुणवत्ता के साथ।

जनरलों के आदेश का पालन करते हुए रैम्बो के एक फ्रीथिक दुश्मन के आधे सौ सैनिक थे।

पूर्ण प्रलेखन की तुलना में रनिंग सॉफ्टवेयर अधिक महत्वपूर्ण है

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

प्रबंधक का परिवर्तन उत्कृष्ट था, और परियोजना एक सेकंड के लिए भी बंद नहीं हुई। और दो महीने बाद लीड प्रोग्रामर चला गया और प्रोजेक्ट की मृत्यु हो गई।

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

लेकिन फुर्तीले घोषणापत्र का पालन करने वाले प्रोग्रामर के लिए, मैं खुद को विशेषता नहीं दे सकता - न कि चरित्र। फिर भी, मैं वेब परियोजनाओं का प्रमुख हूं।

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

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