2010-06-24 11 views
10

हम लगभग 8 पूर्णकालिक एलएएमपी डेवलपर्स के साथ एक छोटी (15 पीपीएल) वेब डेवलपमेंट/डिज़ाइन कंपनी हैं। हमारे द्वारा किए गए त्रुटियों की मात्रा को कम करने और हमारे अनुमानों को आगे बढ़ाने के हमारे बजट को रोकने के लिए मैंने विकास परियोजनाओं से पहले हमारी परियोजनाओं के कुछ प्रकार के तकनीकी विश्लेषण पेश किए हैं। यह एक एप्लिकेशन डेवलपर के लिए कोई ब्रेनर नहीं है लेकिन हमारे क्षेत्र (वेबडेव) में यह सामान्य अभ्यास से कम लगता है। अब तक हमें एक छोटा सा संक्षिप्त प्रोजेक्ट मैनेजर मिला है (अक्सर एक पृष्ठ से भी कम) और परिणामस्वरूप कुछ विनाशकारी बजटीय विफलताओं के साथ पहले विकास में आगे बढ़ गया।एक परियोजना विश्लेषण या परियोजना संक्षिप्त कैसे लिखें?

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

उत्तर

17

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

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

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

तो, क्या आप शामिल करना चाहिए: क्या किया जा रहा है की

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

  • उच्च स्तरीय कार्यात्मक आवश्यकताएं - प्रमुख सुविधाओं को रेखांकित करने वाले बुलेट बिंदु जिन्हें बनाया/डिज़ाइन किया जाएगा। प्रत्येक डेटा इकाई के लिए यह शामिल है कि क्या यह बनाता है, पढ़ता है, अपडेट करता है और/या हटा देता है क्योंकि इससे आपको कार्य को बेहतर ढंग से समझने में मदद मिलेगी। इसलिए उपयोगकर्ताओं को बनाने/पढ़ने/अपडेट/हटाने, ऑर्डर बनाने, पढ़ने और अपडेट करने की क्षमता, उत्पाद श्रेणियां बनाने/पढ़ने/अपडेट/हटाने की क्षमता, पाठ सहित उत्पादों को बनाने/पढ़ने/अपडेट/हटाने की क्षमता शामिल करें , छवियों और वीडियो।

  • गैर-कार्यात्मक आवश्यकताएं - एक अन्य क्षेत्र जहां सामानों का भार मिस हो जाता है। गैर-कार्यात्मक आवश्यकताओं में प्रदर्शन, उपयोगकर्ता भार, लेखा परीक्षा, संग्रह, सुरक्षा आदि जैसी चीजें शामिल हैं। रिपोर्टिंग यहां फिट हो सकती है - हालांकि यह वास्तव में कार्यात्मक है, यह कुछ ऐसा है जो कि भूल जाता है क्योंकि यह अक्सर ऐसा कुछ होता है जो सिस्टम का उपयोग करने के बजाए सिस्टम का उपयोग करता है। यदि आप किसी क्षेत्र में कुछ नहीं कर रहे हैं (उदाहरण के लिए कोई ऑडिट ट्रेल्स नहीं होगा) तो स्पष्ट रूप से बताएं कि शायद किसी अन्य खंड में ...

  • दायरे से बाहर - इस बारे में चर्चा के दौरान चीजें आती हैं या नहीं कुछ (कार्यक्षमता का थोड़ा सा, किसी अन्य सिस्टम के लिए एक इंटरफ़ेस) है या शामिल नहीं है। इन्हें नीचे लिखें! उन प्रमुख क्षेत्रों में से एक जहां मेरे अनुभव में गुंजाइश विफल होती है, इन बातचीत के अलग-अलग यादें हैं और इसे पेपर अप फ्रंट पर लेना इससे छुटकारा पाता है या उससे अधिक है। यह एक और क्षेत्र है जहां रिपोर्टिंग आ सकती है (उन्हें पता चलेगा कि वे रिपोर्ट चाहते हैं, लेकिन यह नहीं कि आप किस तरह के बदलाव करते हैं और फिर वे पूछते हैं कि वे कहां हैं), लेकिन उपयोगकर्ता प्रबंधन (पासवर्ड रीसेट?) और सुरक्षा भी।

  • धारणाएं - इस समय परियोजना के दौरान आपको वास्तव में सटीक अनुमान के साथ अपर्याप्त जानकारी होगी। यह ठीक है, आप अपने आप में अंतराल भर सकते हैं, जब तक आप इसे स्पष्ट करते हैं कि यह वही है जो आपने किया है। इसलिए यदि आप यह धारणा बना रहे हैं कि वे आपको चीजों को बिछाने के लिए कॉर्पोरेट टेम्पलेट्स प्रदान कर रहे हैं तो उसे लिखें। अगर आपको लगता है कि वे सब कुछ के लिए प्रतिलिपि और छवियां प्रदान कर रहे हैं, तो इसे फिर से लिखें।

अन्य वर्गों मैं शामिल करने पर विचार करेंगे:

  • तकनीकी मंच - अगर आपको लगता है कि यह एक उच्च स्तर (इस मामले दीप प्लस किसी अन्य बिट्स में) पर तकनीकी मंच का वर्णन महत्वपूर्ण है। मेरे अनुभव में यह ऐसा क्षेत्र नहीं है जहां स्कोप पंथ वास्तव में होता है लेकिन ऐसा करने में दो मिनट लगते हैं जिससे यह चोट नहीं पहुंचा सकता है।

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

  • निर्भरता - फिर से, यह आपकी नियंत्रण चीज़ के बाहर का हिस्सा है। यदि प्रोजेक्ट में योगदान देने वाली अन्य पार्टियां हैं (क्लाइंट समेत), तो आप उन चीज़ों को सूचीबद्ध करना सबसे अच्छा हो सकते हैं, जिन्हें आप उम्मीद कर रहे हैं। प्रतिलिपि कौन प्रदान कर रहा है, किस प्रारूप में (क्या यह एक अच्छी तरह से संरचित एक्सेल फ़ाइल है जिसे आसानी से आयात किया जा सकता है या एक लाख शब्द दस्तावेज़)? तीसरे पक्ष के आवेदन के लिए एक परीक्षण प्रणाली के बारे में क्या आपको इंटरफेस करने की उम्मीद है? आपको इन चीजों की आवश्यकता कब होती है?

उम्मीद है कि इससे मदद मिलती है।

संपादित करें: मैंने अपने आखिरी नौकरी में उपयोग किए गए कुछ टेम्पलेट्स को खोला और थोड़ा अनामित किया है। वे आंतरिक हैं (यह है कि हम एक आंतरिक टीम कंपनी के भीतर काम कर रहे थे क्योंकि एक टीम के विरोध में एक संगठन के लिए काम कर रहा था) लेकिन संरचना और प्रधानाचार्य समान हैं।

मैं जो सुंदर दस्तावेज़ के प्रकार के करीब है एक परियोजना जनादेश टेम्पलेट को शामिल किया है आप चाहते हैं:

http://seventeensix.tumblr.com/post/749062608/a-sample-project-mandate-template

और जो भी कुछ बिट्स हो सकता है एक विनिर्देश टेम्पलेट आप उपयोगी मानते हैं:

http://seventeensix.tumblr.com/post/749077647/a-sample-specification-template

परियोजना जनादेश एक वहाँ परियोजनाओं में से एक (एक बहुत कठिन वित्तीय प्रणालियों सुलह पैकेज) से कुछ वास्तविक नमूने शामिल हैं, दोनों अजीब उदाहरण के साथ कहां जाता है, इस बारे में संरचना और सूचक शामिल है।

+0

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

+1

मैंने अतीत में टम्बलर (मुख्य उत्तर में लिंक) में उपयोग किए गए कुछ टेम्पलेट्स चिपकाए हैं। क्षमा करें स्वरूपण थोड़ा गड़बड़ हो गया है लेकिन उम्मीद है कि उपयोगी है। –

+0

अरे जॉन, क्या आपके पास अभी भी आपके उत्तर में पोस्ट किए गए दो डाउनलोड हैं जो अभी भी ऑनलाइन उपलब्ध हैं? लिंक मरने लगते हैं। – ChrisR

1

ये सभी अच्छी किताबें हैं। मैं सुझाव दे सकता हूं कि "सॉफ्टवेयर आवश्यकताएं 2" और "पीपुल्स: उत्पादक परियोजनाएं और टीम" (मैंने अभी तक पर्सवेयर नहीं पढ़ा है; यह थोड़ी देर के लिए मेरी टोडो सूची पर रहा है, मुझे डर है।)

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

मेरे अनुभव में, यह बड़ी समस्याओं को बड़ी समस्याओं में तोड़ने की कोशिश करने के लिए कभी दर्द नहीं होता है। दोहराएं। जब आपको लगता है कि आपको आखिरकार टुकड़े मिल गए हैं जो 5 से 1 प्रोग्रामर-डे लेते हैं, तो आप उस बिंदु तक पहुंच रहे हैं जहां समय का अनुमान लगाते समय मुझे सबसे अच्छी सफलता मिली है।

बेशक

, आप को ध्यान में रखना है कि आप के लिए काम कर प्रोग्रामर: ऐलिस आधे से एक दिन में एक शिप करने योग्य समाधान कोड सकता है, बॉब एक ​​दिन लग सकता है, और चार्ली से एक घंटे के साथ दो दिन लग वहाँ पहुँचने के लिए हो सकता है, कोड समीक्षा के लिए बॉब। अपने प्रोग्रामर की ताकत और कमजोरियों को जानना भी अनुभव लेगा।

+1

लोगवेयर एक अच्छी किताब है लेकिन इससे मदद नहीं मिलेगी। मैं वास्तव में स्टीव मैककनेल द्वारा रैपिड डेवलपमेंट के साथ जाऊंगा - इसे परियोजना प्रबंधक के लिए कोड पूर्ण के रूप में सोचें। –

संबंधित मुद्दे