कंप्यूटर अनुप्रयोगों के विकास के लिए परियोजनाएं। विशेषताएं

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

आपको बाकी परियोजनाओं से और विशेष रूप से संगठन की व्यावसायिक प्रक्रियाओं में कंप्यूटर अनुप्रयोगों को पेश करने की परियोजनाओं से बहुत अच्छी तरह से अंतर को समझने की आवश्यकता है।

दो जोखिम हैं जो अक्सर समस्याओं में तब्दील होते हैं:

1. जो लोग सॉफ्टवेयर विकास के विशेषज्ञ हैं, वे यह नहीं देखते हैं कि वे कार्यान्वयन के क्षेत्र में कैसे प्रवेश करते हैं और परियोजना को भड़काना शुरू हो जाता है ... आमतौर पर एक घातक परिणाम के साथ;

2. जो लोग जटिलता को समझने के बिना कार्यान्वयन और संगठनात्मक परियोजनाओं के विशेषज्ञ हैं, वे विकसित होने लगते हैं और परिणामों की गुणवत्ता में महत्वपूर्ण गिरावट शुरू होती है - और यह सबसे अच्छा मामला है;

उन लोगों के लिए जो एक स्वच्छ कार्यान्वयन या स्वच्छ विकास में लगे हुए हैं - ये समस्याएं अज्ञात हैं। लेकिन ये दुर्लभ भाग्यशाली हैं।

विवरण में जा रहे हैं ...

विशिष्ट विशेषताएं

शुरू करने के लिए, आइए उन मानदंडों का विश्लेषण करें जिनके द्वारा हम एक कंप्यूटर अनुप्रयोग विकास परियोजना को अलग कर सकते हैं:

1. इस तरह की परियोजना का परिणाम एक कंप्यूटर अनुप्रयोग (वेब, विंडोज़, एंड्रॉइड, आईओएस ...), एक मॉड्यूल (फ़ंक्शन ब्लॉक) या कुछ महत्वपूर्ण परिवर्तन (क्या एक "महत्वपूर्ण परिवर्तन" है - हम नीचे विश्लेषण करेंगे);

2. इन परियोजनाओं में कंप्यूटर अनुप्रयोगों की वास्तुकला की गहराई से ज्ञान और संबंधित प्रौद्योगिकी स्टैक की आवश्यकता होती है, लेकिन साथ ही किसी भी व्यावसायिक प्रक्रियाओं में शामिल उपयोगकर्ताओं या कर्मचारियों के साथ न्यूनतम सहभागिता शामिल होती है।

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

यदि विकास परियोजना के दौरान, लोगों के साथ बातचीत का अनुपात बढ़ने लगता है, तो ऐसी परियोजना जोखिम कार्यान्वयन परियोजना में बढ़ जाती है, और यह जटिलता और जोखिमों का एक और भार वर्ग है।

महत्वपूर्ण परिवर्तन

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

यदि कोई परिवर्तन या परिवर्तन का एक समूह एक रिलीज में फिट बैठता है, तो आपको एक परियोजना शुरू नहीं करनी चाहिए।

लेकिन अगर एक परिवर्तन अन्य परिवर्तनों की एक श्रृंखला खींचता है, तो यह पहले से ही एक परियोजना शुरू करने के बारे में सोचने लायक है, क्योंकि:

1. किसी को इन परिवर्तनों को समन्वित करने की आवश्यकता है, क्योंकि विभिन्न विशेषज्ञ परिवर्तन कर सकते हैं, और ऐसा कोई व्यक्ति होना चाहिए जो विभिन्न लोगों के बीच समन्वय स्थापित करने में सक्षम हो

2. एक परिवर्तन से सिस्टम के अन्य तंत्रों में परिवर्तन हो सकते हैं, इससे विभिन्न जोखिम होते हैं जिन्हें भी ध्यान में रखना चाहिए और उनके लिए तैयार रहना चाहिए - परियोजना प्रबंधन के माध्यम से ऐसा करना सबसे अच्छा है

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

उदाहरण के लिए :

कार्य प्रबंधन प्रणाली में, प्रतिभागियों को ब्लॉक का विस्तार करना आवश्यक था। न केवल कर्मचारियों, बल्कि समूहों का चयन करने की क्षमता भी जोड़ें

- हमने इंटरफ़ेस के अध्ययन के साथ शुरुआत की, यह पता चला कि आपको एक्सेस सबसिस्टम को बदलने की आवश्यकता है

- उन्होंने एक्सेस सबसिस्टम को बदलना शुरू कर दिया, उन्होंने महसूस किया कि पुराने को थोड़ी देर के लिए छोड़ना जरूरी था, इसलिए उन्होंने पुराने को तोड़े बिना पास में एक नया तंत्र बनाया।

- इंटरफ़ेस में परिवर्तन किए, नए मॉडल के साथ दोस्त बनाए, एक नए को डीबग किया

- अब आपको पुराने तंत्र को हटाने की आवश्यकता है

सभी 4 अंक - 5 महीने और 3 विकास संस्करणों में फैला है। समन्वय के बिना, यह बहुत लंबा होगा, और परिणामस्वरूप, आप बस लक्ष्य वेक्टर खो सकते हैं और इस तथ्य के बारे में भूल सकते हैं कि पुराने तंत्र को हटाने की आवश्यकता है।

खतरनाक पल

एक बहुत ही खतरनाक, लेकिन साथ ही बेहद सामान्य, स्थिति तब होती है जब ग्राहक एक निश्चित प्रणाली विकसित करने के लिए कहता है: वित्त के लिए लेखांकन, बिक्री प्रबंधकों का काम, या ऐसा कुछ।

ऐसा लगता है कि पहली नज़र में यह एक सामान्य विकास परियोजना है। कुछ विकसित करने की जरूरत है।

लेकिन इस परियोजना के सफल होने की संभावना कम ही है बहुत जल्द यह पता चलता है कि आवेदन तैयार है, लेकिन किसी कारण से ग्राहक संतुष्ट नहीं है। सिस्टम काम नहीं करता है।

कारण यह है कि कार्यान्वयन ज्ञान का एक अलग क्षेत्र है। और कार्यान्वयन परियोजनाएं परियोजनाओं की एक अलग श्रेणी हैं।

लेखक इन परियोजनाओं में एक लंबे समय के लिए विशिष्ट था, और इस बार वह कंप्यूटर अनुप्रयोग विकास परियोजनाओं के अस्तित्व में विश्वास नहीं करता था।

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

कुल मिलाकर

हालांकि, पिछले एक साल में मैं भाग्यशाली था कि मैं कार्यान्वयन परियोजनाओं में शामिल हुआ, विकास परियोजनाओं के साथ निकटता से जुड़ा रहा। यह एक अत्यंत कठिन वर्ष था।

उसके बाद, उन परिभाषाओं को विकसित किया गया था जो आप लेख की शुरुआत में पढ़ते हैं।

संभवतः एप्लिकेशन डेवलपर्स के लिए - मैंने कुछ भी नया नहीं खोजा है। जो अंत उपयोगकर्ताओं से इंटरनेट से दूर दीवार के पीछे बैठे हैं - केवल कंप्यूटर अनुप्रयोग विकास परियोजनाओं में शामिल हैं - यह सब राख दिन के रूप में समझा जाता है।

लेकिन जो लोग विभिन्न संगठनों के आईटी विभागों में काम करते हैं, उनके लिए यह एक कठोर "कार्य दिवस" ​​है।

मैं शर्त लगाता हूं कि ज्यादातर संगठनों में ऐसी कोई प्रक्रिया नहीं है:

1. विकास परियोजना प्रबंधन

2. रिलीज प्रबंधन

3. परिवर्तन प्रबंधन जारी करें

हालाँकि ITIL प्रथा कहती है कि उनकी ज़रूरत है, लेकिन इनमें से कई सिफारिशें उपेक्षित हैं। या कोशिश की, लेकिन असफल रहा।

मुझे अक्सर कार्यान्वयन परियोजनाओं से निपटना पड़ता है, लेकिन इस साल मुझे विकास के विषय में तल्लीन होना पड़ा और उपरोक्त प्रक्रियाओं को धारा पर लाना पड़ा।

आपने क्या देखा?

1. सूचना प्रणाली विकसित करने के संसाधनों और लागतों की भविष्यवाणी करना आसान हो गया है

2. डेवलपर्स के पास तब अधिक सकारात्मक काम होता है जब आप न केवल एक बदलाव या रिलीज़ को बंद करते हैं, बल्कि एक पूरी परियोजना जो उद्देश्यपूर्ण रूप से लंबे समय तक नेतृत्व और समन्वित होती

3. विशेष रूप से अच्छा है जब प्रोजेक्ट डेवलपर द्वारा बंद कर दिया गया है। यह कोई मामूली बदलाव नहीं है - यह पहले से ही एक परियोजना है। बहुत अलग संवेदनाएं।

4. और निश्चित रूप से विकास की गुणवत्ता - पूंछ खो नहीं रहे हैं, परिवर्तनों की एक श्रृंखला अधिक सटीक और कम त्रुटियों के साथ है

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

ITIL सिफारिशें लागू करने में आपका क्या अनुभव है? और आप कंप्यूटर अनुप्रयोग विकास परियोजना को कैसे परिभाषित करते हैं? क्या आप उन्हें कार्यान्वयन परियोजनाओं से अलग करते हैं?