फ्रीलांसरों: आप आवश्यकताओं के बारे में कैसे जाना है?

Question

एक फ्रीलांस प्रोग्रामर के रूप में:

1. एक ग्राहक से आवश्यकताओं को इकट्ठा करने के लिए आपकी प्रक्रिया क्या है?
2. आवश्यकता एकत्रित करने की प्रक्रिया में आपको कितना समय लगता है? मुझे पता है कि यह तय नहीं है, और चर भी हैं जैसे कि ग्राहक जवाब देने में कितना शीघ्र है और इस तरह से। सामान्य तौर पर, प्रतिक्रियाओं में देरी के लिए लेखांकन और, अंतिम आवश्यकता होने में कितना समय लगता है?
3. कौन सा संचार चैनल (ईमेल, फोन, इंस्टेंट मैसेंजर, अन्य) आप इन आवश्यकताओं को इकट्ठा करने के लिए उपयोग करते हैं?
4. क्या आप आवश्यकताओं को इकट्ठा करने में लगने वाले समय के लिए शुल्क लेते हैं?
5. क्या आपकी आवश्यकताओं को पूरा करने की प्रक्रिया में कोई डिलिवरेबल्स हैं? यदि ऐसा है, तो वो क्या हैं?

Comments

Upvote'd.. मुझे इस एक का जवाब भी जानना अच्छा लगेगा।

— जार्ज डुप्लेसी

# 4 के अलावा (जो एक आरओआई कारक का कुछ हिस्सा हो सकता है) क्या आप इस बात की अपेक्षा करेंगे कि यदि आप कर्मचारी थे तो यह अलग होगा?

— जेफ

Answer 1

1. ग्राहक से आवश्यकताओं को इकट्ठा करने के लिए आपकी प्रक्रिया क्या है?

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

2. आवश्यकता समय कितना समय एकत्रित करने की प्रक्रिया आपको ले जाती है? मुझे पता है कि यह तय नहीं है, और चर भी हैं जैसे कि ग्राहक जवाब देने में कितना शीघ्र है और इस तरह से। सामान्य तौर पर, प्रतिक्रियाओं में देरी के लिए लेखांकन और, अंतिम आवश्यकता होने में कितना समय लगता है?

स्पष्ट रूप से यह परियोजना के आकार पर निर्भर करता है। बहुत छोटी परियोजना के लिए आवश्यकताओं और मॉडलिंग में 20 घंटे खर्च करना असामान्य नहीं है (<100 घंटे), क्योंकि आपको व्यवसाय के संदर्भ को अच्छी तरह से समझना होगा कि ग्राहक उन समस्याओं की परतों को वापस छील सकता है जो ग्राहक को प्राप्त करने के लिए प्रस्तुत कर रहा है। असली समस्या जो आपको उन्हें खुश करने के लिए हल करनी होगी

चाहे वह 20 घंटे दो कैलेंडर दिन हो या छह सप्ताह, ग्राहक की जवाबदेही और उपलब्धता पर निर्भर करता है, और आपको सत्र के बीच (कठिन समस्याओं के लिए) कितनी सोच रखनी है

3. जो संचार चैनल (ईमेल, फोन, इंस्टेंट मैसेंजर, अन्य) क्या आप इन आवश्यकताओं को इकट्ठा करने के लिए उपयोग करते हैं?

उन सभी को

4. आवश्यकताओं को इकट्ठा करने में बिताए गए समय के लिए आप क्या चार्ज करते हैं?

अरे हाँ!

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

5. अपनी आवश्यकताओं को इकट्ठा करने की प्रक्रिया में कोई डिलिवरेबल्स हैं? यदि ऐसा है, तो वो क्या हैं?

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

Comments

+1: उत्कृष्ट जवाब। मुझे आपके द्वारा मेरे पास दिए गए कुछ मोक्स या टेम्प्लेट देखने में बहुत दिलचस्पी होगी (लेकिन मेरी अपनी है, लेकिन मैं तुलना करना पसंद करूंगा)

— स्टीवन एवर्स 15'10

@SnOrfus: मेरी आगामी पुस्तक "CITA: चेंज द जवाब" में, सभी को प्रकाशित किया जाएगा ... उह ... मैं आपको उस पर वापस लाऊंगा ;-)

— स्टीवन ए। लोव

दिलचस्प है, मैं इसे पढ़ने के लिए उत्सुक हूं।

— स्टीवन एवर्स

@ StevenA.Lowe दस्तावेज़ों को इकट्ठा करने की आवश्यकताओं को लिखने के लिए कोई मानक शैली है। मुझे यह लगता है कि ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Requirements/… लेकिन मैं और अधिक वर्णनात्मक उदाहरण

— खोजता हूँ

@AminM: हाँ ऐसे कई मानक हैं; उन सभी को नमक के एक ब्लॉक के साथ लें - आवश्यकताओं के दस्तावेज को केवल उसी तक कम करें जो आपकी स्थिति के लिए उपयोगी है। उदाहरण: कई बार, स्वीकृति-परीक्षण विवरण (BDD प्रारूप) के साथ कहानियों की एक सूची न केवल आवश्यकताओं को स्वीकार करने के लिए पर्याप्त है, बल्कि स्वीकृति मानदंड भी है, और यह IEEE "मानक" की तुलना में बहुत कम है )

— स्टीवन ए लोव