कठोर रूसी आईटी और डिजिटलाइजेशन पीड़ितों के बारे में किस्से

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

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

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

आइए, मैं आपको कुछ और दिखाता हूँ कि आप विकास की प्रक्रिया में कैसे गलती कर सकते हैं, और इसके क्या दिलचस्प परिणाम सामने आते हैं।

एक और उदाहरण

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

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

हम कहीं न कहीं सुरक्षा को देखते हैं, यहाँ एक महाकाव्य उदाहरण है । सौभाग्य से, यह एक अभी भी सरल है, वहाँ बस किसी ने पांच साल तक कुछ भी नहीं किया है, और व्यवसाय संघीय स्तर का नहीं है।

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

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

हम रूस में चुस्त भी शुरू कर रहे हैं। मैं अब सर्कस में नहीं हँसता। लगभग हर बार यह व्यवसाय के डिजिटलीकरण पर एक फैशनेबल कहानी के रूप में शुरू होता है। मुख्य बात यह है कि हर कोई यह समझने की कोशिश कर रहा है कि ये शब्द क्या हैं। लेकिन कोई नहीं समझता। आदेशों को स्वीकार करता है, अजीब लोगों को किराए पर लेता है। वे कहते हैं कि शब्द "ऐसा लगता है", "परिकल्पना", स्टार्टअप को आमंत्रित किया जाता है, त्वरण muddied है, smoothies नशे में हैं - सामान्य तौर पर, यह सभी किसी न किसी तरह की घाटी के बाहरी लक्षण हैं। तब एजाइल लागू होना शुरू हो जाता है, लेकिन यह बंद नहीं होता है। यदि आप एक गंभीर प्रणाली बनाते हैं, तो आपको इसे लंबे समय तक जांचना होगा। यदि आप प्रक्रियाएं नहीं करते हैं, तो स्प्रिंट लंबे समय (एक या दो महीने) के लिए होंगे, यदि आप प्रक्रियाएं निर्धारित करते हैं, तो आपको परीक्षण बुनियादी ढांचे, डिवोप्स से शुरू करने, डिलीवरी पाइपलाइन बनाने, टीमों के बीच और टीमों के बीच काम करने की प्रक्रियाओं की आवश्यकता होगी। और यह सब आमतौर पर भुला दिया जाता है। यदि पुराने विश्वासियों की प्रक्रियाएं 98% हैं, तो यह परियोजना नहीं की जाएगी। अंत में, हम रेक करते हैं और दौड़ते हैं। सामान्य तौर पर, हम शिकायत नहीं करते हैं: रोटी भी। लेकिन कभी-कभी मैं बस किसी तरह समझाना चाहता हूं, या क्या, कि आईटी पहले एक बुनियादी ढांचा है, और फिर टीटीएम तेजी से। और चारों ओर दूसरा रास्ता नहीं।

आमतौर पर क्या गलत होता है? उदाहरण के सेट

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

1. डेवलपर्स द्वारा योगदान सॉफ्टवेयर में त्रुटियों के लिए जुर्माना।

मैं यह भी नहीं जानता कि तर्कसंगत रूप से इसका वर्णन कैसे करें। पहचान किए गए कीड़े के लिए बस एक जुर्माना। इस ज्ञान के साथ अब जियो। स्वाभाविक रूप से, किसी भी रिलीज (यहां तक ​​कि छोटे) की तुलना में दस गुना धीमी गति से जारी किया जाता है।

2. सुबह से शाम तक बैठकें।

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

3. कार्गो पंथ। हम लचीली कार्यप्रणाली लेते हैं और उन्हें सख्ती से लागू करते हैं।

मैंने जो सबसे अच्छा देखा है: फुर्तीले को लागू किया, लेकिन पहले की तरह काम किया। वे सिर्फ डेवलपर्स को दैनिक स्टैंड-अप पर आते हैं। वे बनते हैं और बताते हैं: मैंने कुछ नहीं किया। यह हर दिन होता है।

4. उपकरण: हम लागू होने वाली रिपोर्ट पर लागू होते हैं।

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

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

5. कोडिंग मानक: 10 साल तक बिना समझे या अपडेट किए लिखे गए।

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

एक बार फिर मैंने देखा कि कैसे नेता ने Notepad.exe में कोड लिखा, फिर इसे त्रुटियों के बिना संकलक में फेंक दिया। वह अभी भी पंच कार्डों के साथ अध्ययन कर रहा था। ऐसा कौशल निश्चित रूप से सम्मान का पात्र है। लेकिन केवल जब तक यह पेशेवर विकृति बाकी विकास विभाग के मानकों को प्रभावित करना शुरू नहीं करता है।

6. नियमों की त्रुटियां।

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

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

एक कंपनी में वर्तमान रिलीज के लिए जिम्मेदारी वाला कोई व्यक्ति नहीं था, कभी-कभी दो सप्ताह के लिए उत्पादों को जारी करने की समय सीमा टूट गई थी।

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

7. सुरक्षा गार्ड से लड़ना।

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

8. डेवलपर्स और विश्लेषकों के बीच संचार स्थापित नहीं है।

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

9. सम्मेलन संचालित विकास।

नेता ने सम्मेलन में कुछ शांत देखा, और उन्होंने इसे ट्रेस के बिना पेश किया। तीन महीने बाद दोहराया। नतीजतन, रिपोर्ट सुंदर है, लेकिन काम इसके लायक है।

आंतरिक सम्मेलनों के कारण, "हमेशा 80% तैयार" योजना के अनुसार परिणाम लाना अभी भी संभव है। सार्वजनिक रिपोर्टों पर - "लगभग पूरा हो चुका है," और यह अंतहीन है। 100% तक लाना कभी नहीं होता है। क्यों? उदाहरण के लिए, बिंदु 1 देखें।

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

10. परिवर्तन करने के लिए डरावना।

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

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

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

और अंतिम राग। एक कंपनी में कोई और सही ठेस पर कोडिंग कर रहा है। "एक छोटी सी बेला है, मुझे पता है कि मैं क्या कर रहा हूं।" धन्यवाद, प्रिय व्यक्ति, लेकिन अगर मैं आपको ढूंढता हूं, तो मुझे यह भी पता नहीं है कि आपके साथ क्या करना है।

सामान्य तौर पर, बाहर बात की। यदि आपको अपनी समस्याएं पता हैं, तो oeremeev@croc.ru पर लिखें। बड़े व्यवसायों के लिए, हमारे पास एक्सप्रेस डायग्नोस्टिक्स (3-5 दिनों में अड़चनों की खोज) के साथ लगभग मुफ्त पायलट हैं। यदि आपके व्यवसाय के किसी व्यक्ति को यह समझाने की आवश्यकता है कि तकनीकी ऋण के साथ काम करना असंभव है, - भी लिखें, हम इसे सामान्य रूप से गिन सकते हैं।