इंजीनियर से नेता तक। भाग 3: रिपोर्ट

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

इंजीनियर से नेता तक। भाग 1: न्याय की भावना
इंजीनियर से नेता तक। भाग 2: प्रत्यायोजन और समस्या सेटिंग

बाढ़

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

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

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

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

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

underflow

कंप्यूटिंग तकनीक में विश्वास के अलावा, लोगों को समझने की तकनीक द्वारा निर्देशित किया जाना चाहिए। प्रबंधक के उदाहरण द्वारा सिखाया गया, बाद की एक परियोजनाओं में मैंने दैनिक रिपोर्ट तैयार की, जिसमें, दिन के दौरान किए गए सभी चीजों को सूचीबद्ध करने के अलावा, स्वचालित रूप से नियोजित एक के साथ तुलना की गई थी, यह वास्तविक कार्य के सामने केवल पास \ फेल करने के लिए पर्याप्त था। लेकिन, क्योंकि एक महीने के लिए एक अधीनस्थ के रूप में मेरे लिए असाइनमेंट की योजना बनाई गई थी, मुझे बहुत खुशी हुई कि जब मैंने काम तेजी से और अधिक कुशलता से पूरा किया, तो मैंने रिपोर्ट में इसे प्रतिबिंबित किया। "आज 5 मॉड्यूल लिखे गए हैं, 40 नियोजित में से 11 तैयार हैं।" और नए सप्ताह की शुरुआत में मैं रिपोर्ट करना चाहता था कि मैंने काम दो बार तेजी से पूरा किया है। प्रबंधकों के लिए सुंदर कार्यक्रम "नियोजित" और "किया" आशावादी रूप से विचलन और ऊपर जाएगा। टीम लीड के माध्यम से पारित की गई रिपोर्ट में प्रगति है: यह स्पष्ट है कि कब और क्या किया गया है। लेकिन प्रोजेक्ट मैनेजर द्वारा साप्ताहिक ब्रीफिंग मुझे कॉल करने और सवाल पूछने का एक कारण बन गया: “आप समय क्यों बढ़ा रहे हैं? एक महीने के लिए? हम आपको यहाँ क्यों पकड़ रहे हैं? औचित्य यह है कि काम कल किया जाएगा किसी को भी कम रुचि थी, क्योंकि उनके व्यक्ति में इस तरह के "नियोजित" कार्यक्रम ने मेरी प्रेरणा व्यक्त की, इसलिए, नए कार्यों को करने की क्षमता। मैं रुक गया और सोचा कि इसमें गलत क्या है। सबसे पहले, प्रबंधक, जब योजना बनाते हैं, तो जोखिम और समय सीमा निर्धारित करते हैं, अक्सर सबसे खराब उदाहरण द्वारा निर्देशित होते हैं। और जब, किसी कर्मचारी के सबसे खराब उदाहरण के बजाय, वे एक अच्छे पेशेवर बन जाते हैं, तो उन्हें हमेशा निष्कर्ष निकालने और प्रबंधक के लिए अपने सकारात्मक आकलन देने की जल्दी नहीं करनी चाहिए। भूमिकाओं की व्यापकता और अलगाव के कारण इतना भी नहीं है, लेकिन क्योंकि वह हमेशा बड़ी तस्वीर नहीं देख सकता है, जिसमें एक बड़ी सकारात्मक छलांग केवल एक बड़े बर्तन में छेद कर सकती है, जो परियोजना को उसके मूल रूप से नियोजित चैनल पर लौटा सकती है।

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

शून्य से भाग

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

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

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

एक आदर्श रिपोर्टिंग प्रणाली क्या है?

शायद सबसे अच्छा समाधान फिर से स्मार्ट को चालू करना है।

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

रिपोर्टों का पदानुक्रम क्या है?

प्रतिदिन रिपोर्ट करें, फिर साप्ताहिक और त्रैमासिक रिपोर्ट तैयार करें। प्रत्येक स्तर के लिए, अपनी प्रणाली निर्धारित करें।

कार्य स्तर:

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

रोडमैप स्तर:

आमतौर पर, यह आज के लिए X की बनी एक प्रजाति की दैनिक रिपोर्ट है। नया \ पुराना \ कुल। इसका उद्देश्य कार्य नियंत्रण, कार्य जटिलता मूल्यांकन है। यह आज के लिए अद्यतन (अपडेटेड) कार्यों से एक निचोड़ है। आदर्श रूप से, यह सिस्टम में चेकबॉक्स \ मुद्दों के परिवर्तन के आधार पर स्वचालित रूप से उत्पन्न होता है। यह इन रिपोर्टों का विश्लेषण है जो हमें सबसे अधिक जवाबदेह व्यक्ति, कर्मचारी, पिछले समय में उसकी वृद्धि के बारे में, उसकी क्षमताओं के बारे में बात करने की अनुमति देता है। यह न केवल प्रबंधक के लिए महत्वपूर्ण है, बल्कि कर्मचारी के लिए भी, जब वांछित, विश्लेषण के आधार पर, उसकी वास्तविक प्रभावशीलता और विकास प्रगति (ऐसी रिपोर्टों के एक सेट के आधार पर) प्रस्तुत की जा सकती है। इसके अलावा, यह कर्मचारी की सुरक्षा है, जैसे कि औपचारिक रूप से, यह बॉस का एक सुरक्षात्मक कागज है जिसे वह काम करता है, और हैक नहीं करता है, लेकिन यह नेतृत्व के टर्मिनल सुपर-कंट्रोल के मामले में है (जो हम जितना चाहते हैं उससे अधिक बार होता है)। और फिर, आपकी सेवा में आपके पास बग ट्रैकिंग सिस्टम और मॉन्स्टर जैसी परियोजना प्रबंधन प्रणाली जैसे प्रोजेक्ट या एसएपी दोनों हैं, लेकिन सरलतम मामले में, आउटलुक की कार्यक्षमता भी काम करेगी, विशेष रूप से कार्यालय के साथ एक जोड़ा संबंध। अनावश्यक और महंगे बवासीर वाले पांच मिनट के व्यवसाय को जटिल न करें।

परियोजना स्तर:

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

Analytics स्तर:

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



यह लागू नहीं हो सकता है, पहली नज़र में, स्टार्टअप्स के लिए, जहां, वास्तव में, रिपोर्ट करने वाला कोई नहीं है। लेकिन दोनों में और फ्रीलांस में, जैसा कि आप जानते हैं, यह अच्छे आत्म-नियंत्रण और आत्म-प्रबंधन को प्रेरित करता है। और सिर में नहीं, बल्कि उसी बग ट्रैकिंग सिस्टम में, शायद बादलों के वातावरण में, कार्यों को बचाने के लिए यह अधिक सुविधाजनक है, ताकि समय के साथ, आप अपने निर्णयों और उनके परिणामों को ट्रैक और पा सकें। वहाँ लक्ष्य निर्धारित करें - श्रमिकों और उनके विकास के व्यक्तिगत लक्ष्य। सफलता और विकास में खुशी, असफलताओं और कठिनाइयों का विश्लेषण करें। इसके अलावा, यह न पूछें कि प्रबंधन आपके लिए क्या कर सकता है, बल्कि यह पूछें कि आप प्रबंधन के लिए क्या कर सकते हैं। हर हफ्ते, जैसे ही सप्ताह का आखिरी कार्यदिवस समाप्त हुआ, मैंने एक समेकित रिपोर्ट संकलित की और आदत से बाहर, मेरे लिए नए प्लेटफॉर्म में अपर्याप्त ज्ञान से जुड़े जोखिमों को पीले में उजागर किया। एक हफ्ता। महीना। दो। और अप्रत्याशित रूप से, बॉस ने मुझे फोन किया और फोन पर बात की: “अरे, दक्षता बढ़ाने के लिए क्या किया जा सकता है? मैनुअल पढ़ना पर्याप्त नहीं है? क्या तुलसा को तेज होना चाहिए? " मेरे लिए, यह आइटम रिपोर्ट में महत्वपूर्ण नहीं था। वह रिपोर्ट से रिपोर्ट करने के लिए भटक गया, यह रिपोर्ट करते हुए कि मैं अपने लिए काम करता हूं, मैं मैनुअल और मंचों को समझता हूं, लेकिन फिर भी मेरी आँखें बंद होने के साथ अपने कार्यों को पूरा नहीं करता है, और तूफानी छुट्टियों के बाद भी स्वचालित नींद मोड में और भी अधिक। लेकिन अधिकारियों के लिए, यह गधे में कम से कम लेकिन घुसपैठ के दर्द के रूप में निकला। संपूर्ण प्रभावी और हरित रिपोर्ट, समय पर सब कुछ, सब कुछ ठीक लग रहा है, लेकिन एक वाक्यांश ने ऑगियन अस्तबल के सुखद जीवन को बिगाड़ दिया जिससे मैं निपटा। और बर्फ टूटने लगी। सरल और विनीत। मुझे ऊपर से समाधान की पेशकश की गई थी। ग्रीन टी का गिलास पीते हुए सच्चाई पूर्व में बोली जाती है: "एक हजार की यात्रा एक कदम से शुरू होती है।" और मेरे लिए यह रास्ता अपूर्ण रूप से केवल प्रतिक्रिया की उपस्थिति के कारण पारित हुआ।

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

के विश्लेषण

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

फिर मुझे रिपोर्टिंग के उपयोग के विशिष्ट उदाहरण देने चाहिए।

स्थिति 1. "एक पुनर्जन्म बग"

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



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

केस 2: "उत्पादकता"

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



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



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

निष्कर्ष

लॉगिंग सिस्टम को लागू करने के लिए रिपोर्टों के लाभों की व्याख्या करने और तरीके खोजने के अलावा, प्रत्येक कर्मचारी के लिए एक व्यक्तिगत समय प्रबंधन शुरू करना एक महान अभ्यास है। यदि वे अभी तक जीटीडी का उपयोग नहीं करते हैंकृपया उन्हें बताएं कि कार्यों को पार करना कितना अच्छा और अच्छा है। वे कर रहे हैं, यह पता चला है, लाभ! इस विषय के जंगल में जाने के बिना, केवल मुद्दों से सूखी अर्क के अलावा व्यक्तिगत फाइलों के साथ विश्लेषण के पूरक के उद्देश्य से। कर्मचारियों को ईमानदार रहने दें। उन्हें दैनिक रिपोर्ट में लिखें: "मैंने 3 घंटे के लिए काम किया, और 4 घंटे तक पायथन का अध्ययन किया।" बुरा नहीं है, लेकिन ओह प्रिय, हमने एक घंटे खो दिया! वास्तव में, आप इस अध्ययन के लिए नीचे जा सकते हैं कि चाय पीने पर 20 मिनट, सर्फिंग पर 30 और एक सहकर्मी के साथ विवाद पर 10 मिनट लगाए गए थे। लेकिन, संक्षेप में, यह व्यक्तिगत जानकारी है। कचरा समय, जो ... हालांकि, बंद करो! हमारा काम निष्क्रियता के कर्मचारी को दोषी ठहराना नहीं है, बल्कि उसे प्रेरित करना है। कि उन्होंने न केवल प्रदर्शन किए गए कार्यों की संख्या में प्रगति की, बल्कि स्वयं के दैनिक कार्यों में भी देखा। और नेतृत्व के संबंध में - ईमानदारी और खुलेपन, ताकि एक संवाद हो,विश्वास के साथ बनाया गया और अधिकार के साथ प्रतिनिधिमंडल। इसलिए अंत में, एक बिंदु पर वह आपके पास आया "मैंने अध्ययन किया, मैंने पायथन का अध्ययन किया, और अब मैं अपनी परियोजना लेना चाहता हूं"।

लेख में पीएस, वित्तीय रिपोर्टिंग, ऑडिट और कर्मियों की रिपोर्टिंग मौलिक रूप से प्रभावित नहीं होती है। इन रिपोर्टों में से कोई भी डेवलपर द्वारा संबंधित या प्रदर्शन नहीं किया जाना चाहिए। यदि विपरीत सच है, तो यह एक प्रबंधन समस्या का भी संकेत है। यदि, कहते हैं, एंटरप्राइज़ मोड के लिए समय पर नियंत्रण की आवश्यकता है, तो यह विकास इंजीनियर के समय को आकर्षित किए बिना किया जाना चाहिए - एक स्वचालित एक्सेस सिस्टम या सचिव एलोचका। यदि वित्तीय रिपोर्टिंग में विकास इंजीनियरों के हस्ताक्षर की आवश्यकता होती है, तो यह कॉर्पोरेट रिपोर्टिंग विभाग या एकाउंटेंट एलविरा मिखाइलोव्ना की चिंता भी है, लेकिन साइबर विशेषज्ञ तकनीकी विशेषज्ञ से 2.5-लिंक प्रोग्रामर-अकाउंटेंट-जोखिम प्रबंधक बनाने का कोई कारण नहीं है।