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