यह सब क्या है?
यह एक छोटा पद होगा। पहले, एक व्यक्तिगत कहानी, और फिर इसे कर्मचारी प्रबंधन के लिए कैसे व्यवहार में लाया जाए।
शुद्ध अनुभव, सिद्धांत नहीं।
पहले, वे अक्सर परिणाम पर काम करने के बारे में बात करते हैं। लोगों ने प्रक्रिया पर या परिणाम पर ध्यान केंद्रित किया। अनुपात 95% से पांच बताया गया है। मैं सभी परियोजना प्रबंधकों को सलाह देता हूं कि वे इस विषय में एक शानदार
वीडियो सर्गेई कोटिरेव शुरू करें। वैसे, मैं दृढ़ता से अनुशंसा करता हूं कि आप अन्य वीडियो भी देखें - सर्गेई ने एक कठिन बाजार में सफलता हासिल की है और जानता है कि वह किस बारे में बात कर रहा है।
वीडियो आपको सवालों के जवाब देगा कि आपके आस-पास के लोग (यदि आप स्वभाव से एक परियोजना प्रबंधक हैं) जिम्मेदारी नहीं लेना चाहते हैं, तो अक्सर उस तरह से कार्य नहीं करना चाहते हैं जो आपने किया होगा, और सामान्य तौर पर, आपके दृष्टिकोण से, अप्रभावी और अप्रभावी हैं। वे उद्देश्य पर नहीं हैं, यह लोगों की ऐसी प्रकृति है जो जीवन को एक प्रक्रिया में उन्मुख करती है।
व्यक्तिगत मामला
अब मेरी कहानी। मैं बहुत देर तक शिथिलता के अंधेरे में भटकता रहा। और हाल ही में मुझे एहसास हुआ कि मैं अक्सर खुद के लिए निर्धारित नहीं कर सकता कि वास्तव में परिणाम क्या है, और इसलिए विभिन्न कार्यों के बीच खो गया। अब यह नहीं है, मेरी आंखों के सामने हर दिन, सप्ताह के लिए एक वेक्टर है, जिसे मैंने खुद के लिए निर्धारित किया है। और सटीक होने के लिए - मैं
myTinyTodo का उपयोग करता
हूं । एक बहुत सुविधाजनक उपकरण, एक्सेल की तरह लचीला, और किसी भी होस्टिंग पर डाल दिया।
मैं एक टैब बनाता हूं जितना मुझे पसंद है - विचारों के लिए, काम छोड़ने से पहले कार्यों के लिए, एक महीने के लिए - और हर बार मैं इस चीज के साथ एक टैब खुला रखता हूं। यह मुझे लक्ष्य को चकमा नहीं देने की अनुमति देता है। इस तरह के एक सरल मामला है, लेकिन यह मेरे लिए दो साल से काम कर रहा है, और इसने मेरे कई सहयोगियों के लिए काम किया (लोगों ने अन्य उपकरण लिए, लेकिन सार - मेरी आंखों से पहले चीजों की एक सूची देखने के लिए - वही रहा)।
और अब प्रक्रिया को उन्मुख करने के लिए कैसे लोगों को परिणाम (या बल्कि, परिणाम प्राप्त करने के तरीके, जीवित और वर्तमान)। जीवन से कुछ मामले भी। उनमें से लगभग सभी प्रोग्रामर से संबंधित हैं (मैं दर्जनों प्रोग्रामर के साथ लोगों की श्रृंखला के माध्यम से या सीधे काम करता हूं, सभी में, परियोजनाओं में विभिन्न विशेषताओं के सैकड़ों लोग शामिल हैं)।
लोगों के साथ कैसे रहें
1. RERO
RERO - "रिलीज़ जल्दी, रिलीज़ अक्सर" (जल्दी रिलीज़, अक्सर रिलीज़) का सिद्धांत।
यह आपकी संपूर्ण विचार प्रक्रिया से गुजरना चाहिए। विचारों के लिए आपके सिर में पक रहे हैं, "मेगा-महंगी डिज़ाइन, सुपरप्रोजेक्ट बनाने और सही आर्किटेक्चर के साथ इसे सही स्तर पर ले जाने के स्तर से" जितना संभव हो उतना सरल और सस्ता बूटस्ट्रैपिंग के स्तर पर, जितनी जल्दी हो सके, बाजार में मिल रहा है, स्पष्ट रूप से और तेज़ी से प्रतिक्रिया एकत्र कर रहा है। "विकसित लाइव डेटा और वास्तविक व्यावसायिक आवश्यकताओं के लिए वास्तुकला को फिर से संगठित करने और पुनर्गठन के लिए बिंदुओं को उजागर करें।"
और बाकी सभी प्रोग्रामर, डिज़ाइनर - आपकी श्रृंखला में शामिल होते हैं, और जब आप प्रभावी ढंग से सोचते हैं और पूरी प्रक्रिया देखते हैं तो सबसे प्रभावी ढंग से काम करते हैं।
जीवन से एक उदाहरण। अब, ईआरपी में मेगाकम्पलेक्स रिपोर्ट एम्बेड करने के बजाय, हम पहले एक सरल संस्करण बनाते हैं और उपयोग के आंकड़े एकत्र करते हैं। व्यक्तिगत परियोजनाओं में रिलीज की दर 10 गुना तक बढ़ गई है।
सीमाओं के अधिकतमकरण के साथ समस्या का एक सरल विवरण (यह ऊपर चर्चा की जाएगी) (विशेष रूप से, सार्वभौमिक नहीं, 100500 फ़िल्टर या सार्वभौमिक न बनाएं, 10 डिज़ाइन आदि के बजाय तैयार बूटस्ट्रैप टाइपसेटिंग का उपयोग करें) कार्यों का मूल्यांकन करते समय प्रोग्रामर और अन्य सभी प्रतिभागियों को दोनों प्रदान करेगा। एक स्वीकार्य अवधि, और यह परिणाम प्राप्त करेगा।
2. कार्य के कार्यान्वयन से बोनस
एक प्रोग्रामर के साथ, मैं कार्यान्वयन के संदर्भ में संपर्क नहीं कर सका। फिर मैंने विशेष रूप से कार्यान्वित कार्यक्षमता के लिए बोनस आवंटित करना शुरू किया। बॉक्स्ड सॉफ़्टवेयर की कॉपी की बिक्री के लिए भुगतान की तरह बोनस सरल, स्पष्ट, स्पष्ट है।
और एक सप्ताह के बाद, सहकर्मियों ने मुझसे पूछना शुरू किया कि कार्यक्षमता को लागू करने के विषय पर मेरा प्रोग्रामर उन्हें क्यों परेशान कर रहा था (यह एक सामान्य अंतर-परियोजना घटक है)। दरअसल, वे प्रोग्रामर को लागू करना शुरू कर दिया - एक परिणाम प्राप्त करने के लिए, और इस तरह एक बोनस कमाते हैं। मुझे उस पर गर्व है।
3. गैर-पूछताछ + कुचल कार्य
आमतौर पर मैं ओलंपियाड के रूप में लक्ष्य निर्धारित करने की कोशिश करता हूं। समस्या का सार, उपयोगकर्ता की कहानी, इनपुट, आउटपुट, जांचने के लिए डेटा। बेशक, बहुत से लोगों को इसकी आवश्यकता नहीं है, लेकिन यदि आप अंतिम कार्य निर्धारित करते हैं और दिखाते हैं कि अंतिम रिलीज़ को कैसे दिखना चाहिए और काम करना चाहिए, तो आपको जो चाहिए, वह प्राप्त होने की उच्च संभावना है।
मैं अलग से कहता हूं कि आपको 1-2 दिनों की रिलीज़ के साथ कार्य (या अपने प्रेजेंटर्स) को टुकड़ों में विभाजित करना होगा। बस ऐसे ही। और फिर आप बदू जैसी रिलीज़ दे पाएंगे (प्रति दिन 5 रिलीज़? या कितने लोगों ने लंबे समय तक नहीं देखा है)।
जीवन से एक ठोस उदाहरण। दो ऐतिहासिक रूप से जुड़े ग्राहक आधारों का एक जटिल एकीकरण करना आवश्यक है। मैं पूरे सिस्टम की वास्तुकला को ध्यान में रखते हुए सर्किट (सीआरएम पक्ष में सुधार) से केवल बुनियादी तंत्र का वर्णन करता हूं। यदि हम ग्राहक संबंधों की पूरी प्रणाली (होटल, एक नेटवर्क में होटल का संयोजन, एक सुपरनेट में नेटवर्क, जटिल एसीएल के साथ) का वर्णन करते हैं, तो एक निर्णय लिखने में एक महीने का समय लगेगा।
और समस्या (होटल और नेटवर्क और एक साधारण एसीएल) के हिस्से को हल करने के लिए सरल सुधारों में कुछ दिन लगेंगे, और प्रोग्रामर इसे पूरा करता है। क्योंकि कार्य सक्षम रूप से टूट गया है।
4. बाजार की जाँच
यह स्ट्रैटोप्लान (पोस्ट पेड, इनफ 100%) के लोगों द्वारा पाठ्यक्रमों में से एक में बहुत अच्छी तरह से वर्णित है। बिंदु सरल है - एक बाजार विचार के परीक्षण पर $ 1000 से अधिक खर्च न करें। ग्राहकों पर लक्षित स्पैम खर्च करना सबसे अच्छा है और देखें कि कार्यक्षमता की रिलीज़ के लिए कितने लोग ईमेल छोड़ते हैं।
जब आप लोगों को यह कार्य समझाते हैं, तो आपको यह बताना होगा कि सत्यापन यथासंभव सरल और त्वरित होना चाहिए। यदि संभव हो तो विकास के एक दिन ले लो। कहने का मतलब है कि एक महीने में कोडिंग एक ऐसी चीज है जिसकी तब जरूरत नहीं होगी।
और प्रोग्रामर - और वे, एक नियम के रूप में, चतुर लोग हैं - यह समझेंगे कि एक दिन के लिए एक चीज का परीक्षण करने से बेहतर है कि एक महीने के लिए कुछ करना चाहिए जो बाद में ज़रूरत नहीं होगी। यह काम करता है।
5. चीजों के सार की एक व्याख्या
कभी-कभी समस्या हल करने वाले होते हैं। मैं खुद ऐसा हूं, मुझे लगता है, यह एक प्रोग्रामर के लिए और प्रोजेक्ट मैनेजर के लिए बहुत महत्वपूर्ण गुण है।
एक आदमी दूसरे लोगों की समस्याओं को हल करना पसंद करता है।
इसलिए, यदि आप कार्यों में समस्या का सार समझाते हैं (ऊपर देखें), अक्सर एक प्रोग्रामर एक सरल और तेज समाधान की पेशकश कर सकता है जितना कि आप भी आएंगे। क्योंकि वह विषय में, कोड में, वास्तुकला में है, और परियोजना की तकनीकी क्षमताओं को आपसे बेहतर समझता है।
जीवन से एक उदाहरण। मैं दो अराजक आधारों को जोड़ने की समस्या के बारे में बताता हूं और इसे प्राप्त करने की आवश्यकता है। प्रोग्रामर स्वयं (सुंदर और चतुर) अलग-अलग रिपोर्ट और फ़िल्टर प्रदान करता है, इन रिपोर्टों से निष्कर्ष निकालता है। और पूरी तस्वीर पूरे दृश्य में है। इसने हमें यह देखने की अनुमति दी कि व्यवस्था कैसे की जानी चाहिए।
6. पुन: प्रयोज्य (पुन: प्रयोज्य) समाधान
हमारे पास होटल परियोजनाओं का एक समूह है। और वहाँ, होटलों के लेखांकन के लिए, मैंने एक विशेष काउंटर बनाने के लिए कार्य निर्धारित किया है जो होटल की आईडी को स्वीकार करेगा, जिसने सिस्टम में प्रवेश किया है। और परियोजना पर हर प्रोग्रामर (मैं केवल होटल परियोजनाओं और बुनियादी ढांचे के हिस्से का प्रबंधन करता हूं) ने खुशी से अपने स्वयं के बजाय काउंटर को खराब कर दिया।
यदि आप अतीत में एक प्रोग्रामर हैं, तो आप पुन: उपयोग की शक्ति को समझते हैं। चर्चा जब सिस्टम में पहले से लिखे गए ब्लॉकों से इकट्ठा करने की नई कार्यक्षमता है, तो यह बताना असंभव है।
यदि नहीं, तो मुझ पर विश्वास करें, यदि आप एक समाधान प्रस्तुत करते हैं जो तब दोहराया और स्केल किया जाएगा, तो प्रोग्रामर इसे समाप्त करने के लिए खुश होगा, क्योंकि लोगों को जल्दी करने का पुन: उपयोग और जब वे अपनी रचनात्मकता के उत्पादों का उपयोग करते हैं
आगे क्या है?
टिप्पणियों में मैं अनुभवी सहयोगियों का सुझाव देता हूं जो अपने अनुभवों को साझा करने में शर्मिंदा नहीं हैं, अपने जीवन से सफल मामलों के बारे में बता रहे हैं।