:
— , , — .
- :
— . .
:
— .
— ?
— . , .
— ?
— , , , , , .
- वे कहते हैं कि विश्वसनीयता की गारंटी ब्लॉकचैन नामक तकनीक से मिलती है।
- अह्ह्ह्ह अह्ह्ह्ह !!! वे जो भी कहते हैं, उसे मत छुओ! गहरी खुदाई। दस्ताने मत भूलना!
स्रोत: XKCD , क्रिएटिव कॉमन्स 2.5 लाइसेंस।

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

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

ट्विटर ने हैशटैग #app और #problems की एक लहर का अनुसरण किया, और सॉफ्टवेयर इंजीनियरों ने केडीपीवी का हवाला दिया। मैं भी ऐसा सोचा था। इस कैरिकेचर के शब्द अच्छी तरह से महसूस हो रहे हैं कि क्या हो रहा है: सॉफ्टवेयर इंजीनियर इसे सीधे नहीं कहते हैं। लेकिन यह बहुत समान लगता है। हमें क्या मतलब है?

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

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

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

लेकिन, जैसा कि मैंने कहा, "हम सॉफ्टवेयर अच्छा करते हैं, बशर्ते कि विफलता के परिणाम मायने नहीं रखते।" यह दृष्टिकोण भयानक विफलताओं की ओर जाता है यदि परिणाम सस्ते नहीं हैं, जैसे आयोवा में। सॉफ्टवेयर विकास का आम चलन इंटरनेट के आर्थिक मॉडल से बढ़ा है, और जब इस मॉडल की मान्यताओं का उल्लंघन किया जाता है, तो सॉफ्टवेयर इंजीनियर खराब काम करते हैं।

वेब कंपनियों में प्रोग्रामिंग कैसे काम करती है?

काल्पनिक कंपनी QwertyCo की कल्पना करें। यह एक उपभोक्ता-उन्मुख सॉफ्टवेयर कंपनी है जो प्रति वर्ष $ 100 मिलियन कमाती है। हम अन्य कंपनियों के साथ तुलना करके QwertyCo के आकार का अनुमान लगा सकते हैं। WP इंजन, वर्डप्रेस होस्टिंग, 2018 में $ 100 मिलियन एआरआर तक पहुंच गया । ब्लू एप्रन ने वर्ष के लिए $ 667 मिलियन उत्पन्न किए । इस प्रकार, QwertyCo एक मध्यम आकार की कंपनी है। उसके पास कई दर्जन से लेकर कई सौ इंजीनियर हैं और उसने सार्वजनिक प्रसार में शेयर जारी नहीं किए।

सबसे पहले, QwertyCo में परियोजना प्रबंधन के अर्थशास्त्र पर विचार करें। नेताओं ने सीखा है कि आप तुरंत एक नई सुविधा की घोषणा नहीं करना चाहते हैं। आपके पास सॉफ्टवेयर गुणवत्ता, समय सीमा और कार्यान्वयन की गति के बीच एक समझौता है।

सॉफ्टवेयर की गुणवत्ता उनके लिए कितनी महत्वपूर्ण है? ज़रुरी नहीं। यदि QwertyCo वेबसाइट एक वर्ष में 24 घंटे काम नहीं करती है, तो वे केवल $ 273,972 पर नुकसान का अनुमान लगाते हैं (यह मानते हुए कि अपटाइम रैखिक रूप से राजस्व के साथ सहसंबद्ध है)। वे कहते हैं कि साइट अक्सर 15 मिनट के लिए ऑफ़लाइन हो जाती है, और कोई भी वास्तव में परवाह नहीं करता है। यदि फ़ंक्शन साइट को क्रैश करता है, तो वे इसे वापस रोल करेंगे और बाद में फिर से प्रयास करेंगे। बार-बार किए गए प्रयास सस्ते होते हैं।

QwertyCo के लिए नई सुविधा कितनी मूल्यवान है? मेरी व्यक्तिगत टिप्पणियों के आधार पर, एक इंजीनियर का एक महीने का काम in2% से 1% की सीमा में एक अनुकूलित साइट की आय को बदलने में सक्षम है। यह प्रत्येक इंजीनियर के लिए $ 1 मिलियन अतिरिक्त QwertyCo राजस्व प्राप्त करने का एक मासिक मौका है। ए / बी परीक्षण जैसे तरीके भी त्रुटियों को कम करते हैं: कुछ हफ्तों के भीतर, आप नकारात्मक या तटस्थ परिवर्तनों का पता लगा सकते हैं और इन सुविधाओं को हटा सकते हैं। खराब विशेषताएं सस्ती हैं - वे समय की एक सीमित मात्रा के लिए सक्रिय हैं। जीत हमेशा के लिए प्राप्त होती है। यहां तक कि जीतने वाले दांव का कम प्रतिशत QwertyCo लाभ बनाता है।

पेशेवरों और विपक्ष को देखते हुए, QwertyCo को एक समारोह कब जारी करना चाहिए? आर्थिक गणना से पता चलता है कि उच्च-जोखिम वाले कार्यों को भी लॉन्च किया जाना चाहिए यदि वे कभी-कभी लाभ कमाते हैं। तदनुसार, प्रत्येक परियोजना एक अनुकूलन खेल में बदल जाती है: "इस तिथि तक कितना एहसास किया जा सकता है?", "पूरी परियोजना को लागू करने के लिए कितना समय आवश्यक है? यदि आप इसे से एक्स को हटा दें तो क्या होगा? यदि आप X और Y को हटा दें तो क्या होगा? कैसे एक निश्चित भाग के कार्यान्वयन को गति देने के लिए? ”

अब सॉफ्टवेयर इंजीनियर के दृष्टिकोण से एक सॉफ्टवेयर प्रोजेक्ट पर विचार करें।

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

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

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

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

इस प्रकार, प्रबंधन और विकास की गुणवत्ता के दृष्टिकोण का विरोध है। मैनुअल उच्च त्रुटि दर (लेकिन बहुत अधिक नहीं) से सहमत है, और इंजीनियर चाहते हैं कि त्रुटि पूर्ण न्यूनतम हो।

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

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

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

अगर इस तरह के आर्थिक मॉडल की धारणाओं का उल्लंघन होता है तो क्या होगा?

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

संक्षिप्त नोट: इस खंड में मैं "रिट्रीटिंग की असंभवता के साथ स्थितियों" और "रिटायरिंग की महंगी संभावना के साथ स्थितियों" के लिए संक्षिप्त नाम के रूप में "उच्च-जोखिम" वाक्यांश का उपयोग करता हूं।

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

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

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

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

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

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

ठीक है, चलो समस्याओं को सूचीबद्ध करना बंद करें। एक बात स्पष्ट है: यह सुनिश्चित करने में बहुत समय और संसाधन लगता है कि सब कुछ काम करता है।

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

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

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

समय इंतजार नहीं करता। दो महीने की अवधि समाप्त हो गई है - आप अंतिम प्रयास के साथ फिनिश लाइन पर आते हैं और अंतिम रिलीज जारी करते हैं।

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

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

जाँच - परिणाम

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

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

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

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

हम इतनी खराब गुणवत्ता के कार्यक्रम क्यों लिख रहे हैं?

वेब कंपनियों में प्रोग्रामिंग कैसे काम करती है?

अगर इस तरह के आर्थिक मॉडल की धारणाओं का उल्लंघन होता है तो क्या होगा?

जाँच - परिणाम

More articles: