उत्पादों, परियोजनाओं और अन्य जानवरों

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

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

परियोजना गतिविधि का उद्देश्य दिए गए गुणवत्ता के साथ स्पष्ट रूप से परिभाषित समय सीमा और बजट में कार्य को पूरा करना है। भले ही प्रोजेक्ट असाइनमेंट प्रोजेक्ट के पहले चरण में लिखा गया हो, प्रोजेक्ट में हमेशा एक ग्राहक होता है जिसके हित में यह असाइनमेंट लिखा जाता है। परियोजना ग्राहक है, उत्पाद समस्या है।यह एक बहुत महत्वपूर्ण अंतर है! भले ही परियोजना का ग्राहक "मेरे लिए समस्या का समाधान" के रूप में लक्ष्य तैयार करता है, यह एक साधारण कारण के लिए उत्पाद के बराबर नहीं होगा: जिम्मेदारी। जैसे ही परियोजना टीम कार्य बनाती है और इसे ग्राहक के पास हस्ताक्षर के लिए लाती है, इस तथ्य के लिए जिम्मेदारी है कि प्रस्तावित विधि समस्या का समाधान ग्राहक को हस्तांतरित कर देती है। हां, कुछ मामलों में, आप Agile दृष्टिकोण का उपयोग करके मिस्ड समाधान के जोखिम को कम कर सकते हैं (क्रम में एक और holivar शुरू नहीं करने के लिए, चलो मानते हैं कि इस संदर्भ में, Agile "एक दृष्टिकोण है जो लघु विकास चक्रों के परिणामस्वरूप मिसाइलों के जोखिम को कम करता है, निरंतर" परिणाम का विश्लेषण और किसी भी पुनरावृत्ति पर आंदोलन की दिशा बदलने की क्षमता ”)। लेकिन एक परियोजना की हमेशा सीमाएँ होती हैं। कम से कम समय में। तो, के लिए जिम्मेदारीपरियोजना के अंत में, परिणाम प्राप्त नहीं किया जाएगा, यह अभी भी ग्राहक के साथ रहेगा (विशेषकर, विशेष रूप से फुर्तीली दृष्टिकोण के साथ, जहां ग्राहक काफी कसकर काम में शामिल है)।

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

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

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

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

अब, उपरोक्त विशेषताओं के आधार पर, आइए परियोजना और उत्पाद की परिभाषाएं निकालें।

• — , , , . ( ) , .
• — , . , , , , — , . — — .

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

आप क्या कर रहे हैं?" आप अपने हाथों से क्यों उड़ा रहे हैं?
"मैं उन्हें अपनी सांस से गर्म करता हूं।"
दूसरी बैठक में, जो चित्र में है, व्यंग्य किसान से पूछता है: "
आप इसे गर्म करने के लिए सूप पर क्यों उड़ा रहे हैं?" क्या वह इतनी गर्म है?
"नहीं, मैं इसे ठंडा करने के लिए सूप पर उड़ाता हूं!"

इस संवाद से, व्यंग्य यह निष्कर्ष निकालता है कि मनुष्य दो-सामना करने वाले जीवों पर संदेह करते हैं जो सबसे अच्छा बचा है।

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