संदर्भ की शर्तें: गलतियों और जोखिमों से खुद को कैसे बचाएं

क्या होगा अगर सबसे जटिल परियोजना नहीं के ToR के विकास में कुछ महीने लगते हैं? टीके विकसित करने में कौन से कदम जोखिम और त्रुटियों से बचा सकते हैं? इस लेख में हम इस समस्या पर विचार करेंगे कि दस्तावेज़ की सामग्री नहीं, बल्कि इसके विकास की पद्धति।

क्या और कैसे

संदर्भ की शर्तें परियोजना का केवल एक हिस्सा हैं। चाहे वह स्टार्टअप हो या किसी मौजूदा उत्पाद के अंदर एक नई सेवा।

किसी भी मामले में, TK को कार्यान्वयन के लिए पर्याप्त और संभावित रूप में ग्राहकों और ठेकेदारों की कल्पनाओं को प्रस्तुत करना चाहिए। जब हम विकास पद्धति के बारे में बात करते हैं, तो हमें टीके को छोटी या बड़ी परियोजनाओं में विभाजित नहीं करना चाहिए। यह हमेशा एक गंभीर दस्तावेज होता है, जहां तकनीकी कार्य के डेवलपर (और प्रबंधक, निश्चित रूप से) को दोष देना होगा।

तकनीकी विशिष्टताओं के विकास के चरण

1. प्रारंभिक संक्षिप्त / कार्य अध्ययन

एक नियम के रूप में, ग्राहक जो चाहता है उसका एक अल्पकालिक विचार है - संक्षिप्त के रूप में, "विशलिस्ट", टीके के साथ एक पत्र। विषय क्षेत्र का अध्ययन करें, प्रश्नों की सूची बनाएं।

कंपनी, बाजार, ग्राहकों, प्रतियोगियों के बारे में जानकारी इकट्ठा करें। देखी गई जानकारी आपको ग्राहक के व्यवसाय के बारे में समझ देगी, जो बदले में आपको उसकी नज़र में बढ़ा देगा।

2. बैठक आयोजित करना

हमेशा प्रश्नों की एक विशिष्ट सूची बनाएं और धीरे-धीरे ग्राहक से सब कुछ पता करें।

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

प्रश्नों के आगे उत्तर रिकॉर्ड करें, उन्हें फिर से पढ़ें।

यदि उत्तर प्राप्त नहीं हुआ है (ऐसा होता है कि ग्राहक प्रश्न का उत्तर संक्षेप में देता है और परिणाम के रूप में कोई उत्तर नहीं होता है), शब्द को फिर से शब्द बदलकर पूछें। उदाहरण के लिए, "मैं इस तरह की कार्यक्षमता की कल्पना करता हूं ... क्या मैं आपको सही तरीके से समझता हूं? क्या यह आपकी दृष्टि से मेल खाता है? "

सवाल पूछने से डरो मत, चाहे वे कितने भी अनपेक्षित लगें। कई चीजें एक विशेष व्यवसाय के भीतर इतनी स्पष्ट हैं कि आप उनका उल्लेख करना भूल सकते हैं।

3. विकास की अवधारणा

अवधारणा में आमतौर पर भविष्य के टीके के लिए संक्षिप्त विवरण होते हैं, अर्थात्:

• लक्ष्य और उद्देश्य;
• नियुक्ति;
• भूमिकाओं;
• संरचना;
• सामग्री;
• सुविधाओं की सूची (सेवाओं के रूप में - संक्षेप में)।
• कभी-कभी किसी अवधारणा में व्यावसायिक विचार का विस्तृत विवरण होता है, यह समझने के लिए कि परियोजना कैसे जीती जाती है।

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

4. आवश्यकताओं का स्पष्टीकरण

अवधारणा के अनुमोदन के बाद, आप लापता आवश्यकताओं को स्पष्ट और औपचारिक करते हैं। टीओआर में आवश्यकताओं को ठीक करें, उन्हें तैयार किए गए ब्लॉकों में विवरण के साथ बनाएं (और अधिमानतः इंटरफेस के साथ)। ग्राहक के लिए इस बारे में जानकारी प्राप्त करना आसान है कि वह क्या चाहता है जब वर्णित आवश्यकताओं की एक ग्राफिक संगत हो।

टीके के विकास पर कई पुनरावृत्तियों के माध्यम से जाओ, हर बार ग्राहक टिप्पणियों के अनुसार दस्तावेज़ को जोड़ना और बदलना।

यहां तक ​​कि अगर सब कुछ स्पष्ट और स्पष्ट लगता है, तो आपको सवाल पूछने की ज़रूरत है कि क्या आप सही तरीके से समझते हैं। यह बहुत समय और तंत्रिकाओं को कम करेगा। यहां तक ​​कि साधारण समाचार के बारे में बात करते हुए, यह मत भूलो कि "प्रकाशन की आवृत्ति" की अवधारणाएं हैं, कौन अपडेट करता है, समाचार में क्या सामग्री हो सकती है, आदि। ऐसे सवालों के जवाब से, पृष्ठ की संरचना और सूचना की प्राथमिकता मौलिक रूप से बदल सकती है।

5. टीके की स्वीकृति

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

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

हमेशा यह सोचने की कोशिश करें कि उत्पाद का उपयोग कौन करेगा। उपयोगकर्ता को सभी संभावनाएं प्रदान करना संभव है, लेकिन या तो सुविधा की हानि के लिए, या कार्यान्वयन समय की गिरावट के लिए।

मुश्किलें और कैसे बचें

1. समय सीमा को पूरा करने में विफलता

कभी-कभी ऐसा होता है कि दस्तावेज़ लिखने के लिए कोई तथाकथित संग्रह नहीं है। बैठो, एक दिलचस्प किताब पढ़ें, एक दिलचस्प कार्यक्रम या कार्टून देखें। नेट सर्फ करने की कोई जरूरत नहीं है। एक पुस्तक या देखी गई नई भावनाएं कल्पना को विकसित कर सकती हैं, ताकत और प्रेरणा दे सकती हैं। आखिरी दिन तक सब कुछ बंद न करें।

प्रोजेक्ट की समय सीमा और अपनी क्षमताओं के बारे में गलत विचार न दें, कार्य योजना में अनुमोदन के लिए समय सीमा निर्धारित करें। परियोजना के लिए आवंटित समय की योजना बनाएं: कार्यों के लिए दिन निर्धारित करें, और विकसित अनुसूची का पालन करें।

2. मूल्य-शर्तें-कार्य का दायरा

हमेशा सोचें कि किसी भी कार्य की एक समय सीमा और कीमत होती है। इन अर्थों में अमूर्तता के बिना समाधान प्रस्तावित करना महत्वपूर्ण है।
3. प्रतिक्रिया

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

4. जिस चीज पर आप सहमत हैं उसे ठीक करने की कोशिश करें।

ग्राहक की सभी इच्छाओं, एक वार्तालाप या व्यक्ति में आपके लिए प्रेषित, एक पत्र के साथ पुष्टि, प्रदर्शन की जाने वाली वस्तुओं को सूचीबद्ध करना; ऊपर के निष्पादन के समय की आवाज।

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

5. परिणाम प्रस्तुत करें

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

ग्राहक की इच्छा के अनुसार नहीं करने का प्रयास करें। एक नियम के रूप में, इस मामले में सबसे खराब विकल्प स्वीकार किया जाएगा।

छोटी सिफारिशें

जब आप पहली बार तकनीकी कार्य के निर्माण पर काम नहीं कर रहे हैं, तो अपने नियमों का पालन करें। उदाहरण के लिए, नियम इस प्रकार हो सकते हैं:

मानसिक कार्ड

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

संस्करण और फ़ाइल नाम

फाइलों को सही से नाम दें। उदाहरण के लिए, यह प्रोजेक्ट का नाम हो सकता है - एन्कोडेड या इसकी संपूर्णता में। प्रत्येक संस्करण फ़ाइल के नाम पर लिखें। इससे आपके लिए यह समझना आसान हो जाएगा कि कौन सी फाइल अंतिम थी।

अनुभव से, निम्न रूप के नाम और संस्करण बनाना सुविधाजनक है:

NameProject.0.1.doc ,

जहां NameProject प्रोजेक्ट का नाम है,

0 - क्लाइंट को भेजा गया संस्करण; यदि 0 - इसका मतलब है कि कंपनी (विभाग) के अंदर काम करते समय इसे नहीं भेजा गया था;

1 - वह संस्करण जो आप कंपनी (विभाग) के अंदर बनाते हैं।

उदाहरण के लिए, आपने क्लाइंट को संस्करण 0.1 भेजा, जबकि आगे ToR पर काम किया जा रहा है। आप संस्करण 0.2 बनाते हैं, क्योंकि यह एक बदलाव है, लेकिन यह पहले से ही आपकी आंतरिक या आंतरिक कंपनी है। आप क्लाइंट से टिप्पणियां प्राप्त करते हैं और एक नया संस्करण भी बनाते हैं - 1.3।

यदि कई दस्तावेज़ हैं (उदाहरण के लिए, अवधारणा, TK), तो दस्तावेज़ का नाम दस्तावेज़ नाम में जोड़ें - NameProject.Concept.0.1।

संरचना

एक स्पष्ट TK संरचना है। जानकारी एकत्र करते समय, साथ ही एक दस्तावेज विकसित करने के लिए, इसका पालन करें। ग्राहकों की अपेक्षाओं के आधार पर, तकनीकी कार्य टेम्पलेट चुनने के लिए 4 विकल्प हैं। यह GOST, IEEE, कॉर्पोरेट टेम्प्लेट, आपका अपना टेम्प्लेट हो सकता है (या कंपनी का टेम्प्लेट जिसमें आप काम करते हैं)।

स्वरूपण

एक अच्छा दस्तावेज़ एक सक्षम और सही ढंग से निष्पादित दस्तावेज़ है। अच्छी तरह से बनाए गए दस्तावेजों को पढ़ना आसान है, क्योंकि उनके पास दर्जनों शैलियों नहीं हैं, विभिन्न डिजाइन के पाठ के कई ब्लॉक हैं।

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