एक आईटी परियोजना की प्रगति की कल्पना के लिए एक वैकल्पिक तरीका

परिचय

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

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

यह सब कैसे शुरू हुआ?

एक बच्चे के रूप में, मुझे वास्तव में 1941-1945 के महान देशभक्तिपूर्ण युद्ध के बारे में किताबें पसंद आईं। मुझे विशेष रूप से सैन्य मानचित्रों पर विचार करना पसंद था। उपयोग किए गए पदनामों में मुझे ज्यादा समझ नहीं थी, लेकिन मैं अपने देश में गर्व की भावना से अभिभूत था, जब मुझे महसूस हुआ कि इस तथ्य के बावजूद कि "नीले तीर" बाईं ओर हमला करने वाले पहले थे, और उनमें से बहुत से थे, और वे बहुत बोल्ड थे, हम अभी भी सक्षम थे पहले उन्हें रोकें, और फिर इन "नीले" को उस जगह से भी आगे बढ़ाएं जहां से उन्होंने वास्तव में हमला किया था। मुझे अभी भी समझ में नहीं आया कि "आर्मी ग्रुप सेंटर" के शिलालेखों का क्या मतलब है, मुझे समझ नहीं आया कि वास्तव में क्या हुआ था जहां "3TGr", "4TGr", "4A", "9A" के रूप में चिह्नित आंकड़े स्थित थे। लेकिन मुझे नक्शे पर रंगीन तीर, रेखाएं और मंडलियां पसंद हैं।
और जाहिर तौर पर इस बच्चों के शौक ने एक भूमिका निभाई, जब बहुत बाद में, एक परियोजना प्रबंधक के रूप में काम करते हुए, उनकी स्थितियों को देखने के सबसे उपयुक्त साधनों को चुनने के सवाल का सामना करना पड़ा, मैं "प्रोजेक्ट मैप्स" की अवधारणा पर आया।
वास्तव में, वास्तव में, लगभग किसी भी युद्ध को एक परियोजना माना जा सकता है, जहां अनुमानित शुरुआत और समाप्ति तिथियां निर्धारित की जाती हैं, योजनाएं विकसित की जाती हैं, सैनिकों की आवश्यक संख्या तैयार की जाती है, प्राथमिक टोही को बाहर किया जाता है, और मुख्य हमलों की दिशा निर्धारित की जाती है। और किसी भी परियोजना में, हम क्रमशः "युद्ध" जैसी अवधारणा के साथ उपमा पा सकते हैं। उदाहरण के लिए, विश्लेषक "खुफिया" के अनुरूप होंगे, "टैंक" प्रोग्रामर हैं, और "भारी टैंक" अच्छे, मजबूत प्रोग्रामर हैं, और "लाइट टैंक" प्रोग्रामर कमजोर हैं। डिवीजन कमांडर प्रमुख डेवलपर्स हैं, सेना कमांडर परियोजना प्रबंधक हैं, सर्वोच्च कमांडर एक परियोजना निदेशक है, और राज्य का प्रमुख कंपनी का सामान्य निदेशक है। मैं दोहराता हूं, कई उपमाएं हैं।
लेकिन हमारे लिए सबसे महत्वपूर्ण बात यह है कि इस मामले में परियोजना की योजना को एक सरल संकेतन प्रणाली का उपयोग करते हुए मानचित्र के रूप में प्रदर्शित किया जा सकता है।

पदनाम

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



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



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



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



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

उदाहरण 1. लागत अधिक हो गई

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



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



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



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



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



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



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





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

उदाहरण 2. कलाकारों की कमी

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



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



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

पेशेवरों, विपक्ष, संभावनाएँ

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

अब संभावनाओं के बारे में।

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