🤴🏽 🚤 👨🏽‍💼 इलेक्ट्रॉनिक्स का अनुबंध विकास। परियोजना की गणना 🐓 👩🏻 👼🏿

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

किन परियोजनाओं पर विचार नहीं किया जाना चाहिए

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

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

प्रोजेक्ट के सफल होने की संभावनाओं का आकलन करने के लिए हमें क्या पूछना चाहिए?

किसी संगठन को किसी दिए गए उत्पाद (उत्पाद निर्माण लक्ष्यों) की आवश्यकता क्यों है? हमें व्यावसायिक कार्य के सबसे सटीक सूत्रीकरण का पता लगाने की आवश्यकता है। इसलिए हम स्वप्नदोषियों को एक स्वचालित स्नान चटाई के अगले "शानदार विचार" के साथ ब्लूटूथ और एक मोबाइल एप्लिकेशन के साथ फ़िल्टर करते हैं।
परियोजना का आरंभकर्ता (DM) कौन है? हमें पता चलता है कि प्रौद्योगिकी के लिए कौन जिम्मेदार है और कौन बजट आवंटित करता है। आमतौर पर ये अलग-अलग लोग होते हैं, और उन्हें बिक्री के मामले में अलग-अलग तरीकों की आवश्यकता होती है।
( )?
. : , , , .?
( , )?
. , , , .
( )? , , , . « » =)
( .., )?
?
- — :
  1. (, )?
  2. ?
  3. (), ? -? ?
- — : . , , . « », , .
- ? ? ? — .
? — :
- (, )?
- (, )?
- ?
- , ?
- ( )?
() ( )? «», - . , 9 .
? , . , , .
(, , , )? « , ». , -.
? : , .
? – .
? (, , , , ). . ?
? ?
(, , )?
? .

-

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

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

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

सभी कार्यों को घंटों में श्रम सौंपा गया है। विधि एक विशेषज्ञ मूल्यांकन है । एक घड़ी दो की शक्तियों से मान ले सकती है: 2, 4, 8, 16, 32, 64, 128 ... 128 घंटे या अधिक के मूल्यांकन के साथ कार्य जब कार्यान्वयन स्पष्ट नहीं है। इसका मतलब यह है कि आवश्यकताओं को स्पष्ट करने, प्रौद्योगिकी की प्रयोज्यता को सत्यापित करने और कभी-कभी सिर्फ एक Google को फैलाने और ~~धूम्रपान~~ करने के लिए काम करना सार्थक है ।
मेरी टिप्पणियों के अनुसार, मूल्यांकन की सटीकता को बढ़ाना संभव है, सबसे पहले, कम अनुभवी डेवलपर्स की राय का अनुरोध करना। इसलिए वे अपने दम पर तेजी से कार्यों का मूल्यांकन करना सीखते हैं। यदि एक प्रतिष्ठित इंजीनियर ने पहले ही बात की है, तो बाकी सभी लोग बस उसकी राय से सहमत हैं। और जब परियोजना पर काम शुरू होता है, तो कार्यों को संभवतः उसके द्वारा नहीं बल्कि उन लोगों द्वारा हल किया जाएगा जिन्होंने कुछ नहीं कहा। हम अभी भी उनका आकलन सुनेंगे, लेकिन सही समय पर नहीं।
जब सभी कार्यों का मूल्यांकन किया जाता है, तो हम परिणामों को सारांशित करते हैं और डीबगिंग के लिए सॉफ़्टवेयर में 30% और सॉफ़्टवेयर परीक्षण के लिए 30% जोड़ते हैं। ये आंकड़े पूर्ण परियोजनाओं पर आंकड़ों से लिए गए हैं।
परिणामस्वरूप, बोर्ड पर निम्न चित्र दिखाई देता है:

मूल्यांकन आमतौर पर विवरणों की गहन चर्चा के साथ होता है, क्योंकि समस्या को हल करने के लिए कई विकल्प हो सकते हैं। तो यह एक घंटे से कम नहीं लेता है। तैयार करने के समय को देखते हुए, यहां तक कि परियोजना के प्रारंभिक मूल्यांकन में अग्रणी डेवलपर्स के 5-20 घंटे खर्च हो सकते हैं।

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

वांग क्लब से प्राप्त रेटिंग्स रेडमिन में दर्ज की जाती हैं। EasyWBS दृश्य रूप में कार्यों को जल्दी से जोड़ने के लिए उपयुक्त है:

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

गणना मॉड्यूल में, विशेषज्ञों के लिए दरों को जोड़ा जाता है और सह-ठेकेदारों, उत्पादन, सामग्री, उपकरणों आदि के लिए लागत जोड़ी जाती है। Customer.pdf के लिए एक उत्कृष्ट व्यावसायिक पेशकश हम सीधे यहाँ से बनाते हैं। पढ़ें कि हमारे सहयोगी एकल अनुरोध के उदाहरण का उपयोग करके परियोजनाओं का अलग-अलग मूल्यांकन कैसे करते हैं। बारह केपी के छोटे विश्लेषण । तो, परियोजना को स्वीकार किया जाता है, मूल्यांकन किया जाता है। यह अनुबंध पर हस्ताक्षर करने के लिए बनी हुई है - और आगे बढ़ो, कार्यों को फिर से लिखना, तकनीकी समाधान बदलना, आवश्यकताओं का विस्तार करना, मान्यता से परे परियोजना को बदलना!

हमारे लिए यह सवाल नहीं है कि परियोजनाओं का मूल्यांकन करना है या नहीं, क्योंकि हम ग्राहकों के लिए परियोजनाएं कर रहे हैं, यह मूल्यांकन के बिना अनुबंध प्राप्त करने के लिए काम नहीं करेगा। लेकिन कंपनियों में आंतरिक परियोजनाओं के साथ, स्थिति अलग है। अक्सर, आंतरिक परियोजनाओं का मूल्यांकन नहीं किया जाता है। और बहुत व्यर्थ। इस दृष्टिकोण का परिणाम समय और संसाधनों का कम आंकना है। न तो टीम और न ही प्रबंधन परियोजना की वर्तमान प्रगति का मूल्यांकन कर सकता है। इसलिए टीम की गलतफहमी और अवमूल्यन।

और अब - चलिए टिप्पणियों में परियोजना मूल्यांकन के आपके दृष्टिकोण पर चर्चा करते हैं!

इलेक्ट्रॉनिक्स का अनुबंध विकास। परियोजना की गणना

किन परियोजनाओं पर विचार नहीं किया जाना चाहिए

प्रोजेक्ट के सफल होने की संभावनाओं का आकलन करने के लिए हमें क्या पूछना चाहिए?

-

More articles: