विचार, टीम, तकनीक, पैसा, कार्यप्रणाली - किसी परियोजना की सफलता वास्तव में किस पर निर्भर करती है?

अस्वीकरण:

नीचे लिखा सब कुछ सिर्फ मेरे विचार है, विशेष रूप से परियोजनाओं में भाग लेने के मेरे अनुभव का परिणाम है। मैं विषय का पूर्ण रूप से निष्कासन का ढोंग नहीं करता, क्योंकि परियोजनाओं की सफलता का अध्ययन भारी संख्या में पुस्तकों, समुदायों आदि में किया जाता है। यदि आपकी राय अलग है, तो आप यहाँ एक तर्कपूर्ण राय दे सकते हैं, मुझे खुशी होगी कि एक ठोस चर्चा होगी।



यहाँ परियोजना से मेरा मतलब है कि एक साइट या सॉफ्टवेयर को विकसित करने और बढ़ावा देने के लिए एक परियोजना।

मेरे अनुभव के बारे में, मुझे निष्कर्ष निकालने की अनुमति है:

मेरा पहला स्टार्टअप 2005 में था। यह एक ऑनलाइन स्टोर था, जिसके प्रचार के लिए द्वार और मंच पोस्टिंग का उपयोग किया गया था। 2006 से, मैं सक्रिय रूप से एसईओ और स्टार्टअप के प्रचार में लगा हुआ हूं। मेरा आखिरी (सबसे हालिया) स्टार्टअप एक साल पहले शुरू हुआ था। एक महीने पहले जमे हुए। मुझे तुरंत कहना होगा कि मेरे एक भी स्टार्टअप को विश्वव्यापी प्रसिद्धि नहीं मिली है, लेकिन बहुत सारे शंकु भरे हुए हैं, और कितना अधिक भरा जाना बाकी है!



इसके अलावा, मैं उन कारकों का विश्लेषण करने का प्रस्ताव करता हूं जो परियोजना को सफलता की ओर ले जाते हैं।

ऐसा करने के लिए, पहले, आइए चर्चा करें कि परियोजना की सफलता पर क्या विचार करें:

बहुत से लोग परियोजना प्रबंधन के क्लासिक त्रिकोण को जानते हैं (चित्र 1 देखें)





चित्र 1. परियोजना प्रबंधन का त्रिकोण।



मैं एक परियोजना की सफलता का आकलन करने के लिए ऐसे मानदंडों को पूरा करता हूं:

1. यदि काम की स्वीकृत गुंजाइश और स्वीकृत लागत के अनुसार, समय पर पूरा हो जाता है, तो परियोजना सफल होती है।

2. यदि ग्राहक संतुष्ट है तो परियोजना सफल है - समय, लागत आदि की परवाह किए बिना।

3. एक परियोजना तभी सफल होती है जब वह आर्थिक रूप से सफल हो।



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

अपनी परियोजना (स्टार्टअप) को लागू करते समय, वित्तीय सफलता की कसौटी महत्वपूर्ण है - अर्थात हम समय सीमा को याद कर सकते हैं, पूरी तरह से लागू नहीं कर सकते हैं, ग्राहक असंतुष्ट है, लेकिन ऐसा हुआ है कि परियोजना आर्थिक रूप से लड़ी और पैसा लाती है।



मेरा निष्कर्ष : कोई फर्क नहीं पड़ता कि हम सफलता के आधार के रूप में क्या कसौटी लेते हैं, सामान्य कारक हैं जो प्रभावित करते हैं कि क्या कोई परियोजना सफल होगी।

सब कुछ बहुत सरल है: यदि परियोजना सफल है - यह स्पष्ट है ।

हमें लगता है कि परियोजना की सफलता कारकों पर निर्भर करती है:

दोनों मामलों में (आउटसोर्सिंग या आपकी परियोजना), जब हम किसी परियोजना की योजना बनाते हैं, तो हमें लगता है कि सफलता ऐसे कारकों पर निर्भर करती है:

• हमारे पास स्मार्ट लोग हैं जिनकी हमें ज़रूरत है, हम उन पर भरोसा कर सकते हैं।

• हमारे पास वे संसाधन हैं जिनकी हमें आवश्यकता है (जिसका अर्थ है कि हमने उनकी सही गणना की है), काम का भुगतान किया जाएगा, और एक स्टार्टअप के मामले में हम सभी योग्य होंगे।

• हम इसे सही कर रहे हैं (यानी, या तो हमने ग्राहक की आवश्यकताओं को सही ढंग से समझा, या अपनी आवश्यकताओं को सही ढंग से बनाया)।

• हम परियोजना को लागू करने के लिए अच्छी तकनीक का उपयोग करते हैं (अर्थात, हमारी परियोजना नैतिक रूप से मंद नहीं होगी)।

• हमारी टीमवर्क स्थापित की जाती है ताकि हम परियोजना पर यथासंभव कुशलता से काम करें (कार्यप्रणाली, दृष्टिकोण, कार्य ट्रैकिंग प्रणाली, आदि)।

• हम जानते हैं कि तैयार परियोजना के साथ क्या करना है ताकि बाजार या ग्राहक यह पहचान सके कि यह परियोजना सफल है (विशेष रूप से, बाजार पर उत्पाद की मांग है)।

वास्तविकता - हम क्या सामना करते हैं:

यहां मैं विभिन्न परियोजनाओं पर विभिन्न टीमों में काम करने से केवल उदाहरण दूंगा। शायद किसी को अपने मामलों का पता चलता है, या शायद परियोजनाओं में किसी और को अलग तरीके से।



1. सामान्य रूप से लोग अच्छे, मजाकिया, मजाकिया किस्म के होते हैं, लेकिन प्रत्येक का व्यक्तिगत परिणाम नहीं होता है। "मुझे अकेला छोड़ दो" के लिए कार्य करता है।

2. डेवलपर का कहना है कि "समस्या का विवरण स्पष्ट नहीं है, और अधिक विस्तार से लिखें कि क्या प्राप्त करना है, आदि" - लेकिन इसके बाद यह सभी को एक समान नहीं करता है।

3. डेवलपर कहता है, "ऐसे और ऐसे ट्रैकर रखो, और फिर मैं कार्य करना शुरू कर दूंगा", लेकिन परिणामस्वरूप, इसे न तो निर्वासन में बनाए रखना और न ही झटका देना। प्रोग्रामर समय सीमा के साथ नशे की लत है।

4. डेवलपर का कहना है कि "हमें स्क्रम को लागू करने की आवश्यकता है," लेकिन यहां तक ​​कि काम करने के बजाय, टैबलेट पर खेलने के बजाय स्क्रैम का उपयोग करना।

5. प्रोग्रामर कहता है, “मैं तुम्हें समझता हूं। आगे कहने की जरूरत नहीं है, मुझे पता है कि बेहतर कैसे करना है, "लेकिन नहीं करता है।

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



बहुत अधिक उदाहरण हो सकते हैं; मैं 80% बुनियादी होने का ढोंग नहीं करता। मैं समय सीमा में देरी का भी उल्लेख नहीं करूंगा (मुझे ऐसा लगता है कि यह सभी परियोजनाओं में है, जिसका अर्थ है कि यह पहले से ही आदर्श है)।

परियोजना के दौरान लोगों को बदलना हमेशा संभव होता है, आपको किसी तरह काम करना होगा।

परियोजना क्यों मर जाती है:

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



आमतौर पर, जब परियोजना के प्रमुख आग पर होते हैं, तो समस्याएं भयानक नहीं होती हैं, वे हल हो जाती हैं।

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



उदाहरण:

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

2. परियोजना प्रतिभागी परियोजना के बहुत विचार के साथ "जल रहा था" (पैसा कोई फर्क नहीं पड़ता)। उसने देखा कि वे उसका उपयोग कर रहे थे। संस्थापक कार खरीदते हैं, बड़े पैमाने पर रहते हैं, और इसमें बहुत कम आते हैं। यद्यपि पैसा सबसे महत्वपूर्ण कारक नहीं था, लेकिन संस्थापकों में विश्वास गायब हो जाता है, और, तदनुसार, प्रतिभागी समय के साथ "बाहर जलता है"।

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

4. प्रोग्रामर कुछ समय सीमा का वादा करता है, लेकिन हर समय समय सीमा को तोड़ता है, और यहां तक ​​कि काम सही ढंग से नहीं करता है। जितनी जल्दी या बाद में, एक सक्षम निष्पादक के रूप में उसका अविश्वास उठता है।



जाहिर है, जीवन से अन्य उदाहरण हो सकते हैं, लेकिन मैं दोहराता हूं: मेरा मानना ​​है कि किसी परियोजना की सफलता के लिए मुख्य आवश्यक कारक विश्वास है ।



टीम के सदस्यों, भागीदारों, ग्राहक और ठेकेदार सभी को एक दूसरे पर भरोसा करना चाहिए। तभी हम एक वास्तविक साझेदारी का निर्माण कर सकते हैं, एक "फ्यूज" बनाए रख सकते हैं, और तदनुसार परियोजना के दौरान आने वाली सभी समस्याओं को हल कर सकते हैं।

निष्कर्ष क्या है?

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