कैसे प्रौद्योगिकी और सामाजिक विज्ञान योजना में मदद करते हैं

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

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

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

प्राकृतिक तनाव (sic)

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

लेकिन इस "संगठित तनाव" की ज़रूरत किसे है? यहां तक ​​कि जब आप सिर्फ वही करते हैं जो आपको करना चाहिए, तो आपके पास पहले से ही पर्याप्त तनाव है - एक नया क्यों जोड़ें, जो, इसके अलावा, समाप्त नहीं किया जा सकता है?

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


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

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

टीम जिस पर काम कर रही है उसकी योजना कठिन और जटिल लग सकती है। हो सकता है कि। लेकिन नहीं करना चाहिए। दूसरे शब्दों में, एक योजना "निर्णय लेने का आधार" है। एक योजना बनाना आसान है जो बताता है कि काम का परिणाम कितना शानदार होगा और उस पर पैसा बनाना कितना अद्भुत होगा। यह योजना का आसान हिस्सा है।

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

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

क्या हाल है?

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

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

एक योजना विकसित करते समय, यह विचार करने के लिए समझ में आता है:

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

इस प्रणाली को देखते समय तीन बातें ध्यान देने योग्य हैं।

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

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

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

पुल का निर्माण

जब एक टीम को ऊपर उल्लिखित सभी मुद्दों की सामान्य समझ होती है, तो अगला कदम एक साथ लिया जा सकता है। योजना के दो प्रमुख भाग हैं जो सब कुछ एक साथ लाते हैं और "विकास योजना" और "सामाजिक विज्ञान" को जोड़ने में मदद करते हैं।

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

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

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

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

PPS यह पद सामान्य प्रकृति का है, न कि किसी विशिष्ट चीज के बारे में, जो अतीत या वर्तमान में लागू हो।