एक कठिन परियोजना की कहानी: नौकरशाही, आधारभूत संरचना और सॉफ्टवेयर विकास प्रक्रिया के बारे में एक छोटी सी बात

एक कठिन परियोजना की कहानी: नौकरशाही, आधारभूत संरचना और सॉफ्टवेयर विकास प्रक्रिया के बारे में एक छोटी सी बात

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

ग्राहक एक काफी बड़ा निवेश बैंक है। अंतिम उपयोगकर्ताओं की संख्या: 10 हजार से अधिक

प्रोजेक्ट टीम

• 200 से अधिक डेवलपर्स (31 टीम लीड, 7 टीम लीडर सहित)
• 3 आर्किटेक्ट, उनमें से एक मुख्य है
• 19 परीक्षक (1 लीड, 2 तनाव परीक्षण पर, बाकी कार्यात्मक परीक्षण)
• 5 सिस्टम प्रशासक जिनकी जिम्मेदारी डीबीएमएस प्रबंधन और उच्चतर क्षेत्र में है। विशेष एचडब्ल्यू टीम की जिम्मेदारी के क्षेत्र में ओएस और हार्डवेयर प्रशासन
• पार्ट टाइम में काम करने वाले विश्लेषकों की चर संख्या (2 से 16 तक)
• 12 तकनीकी लेखक और अनुवादक
• 3 परियोजना प्रबंधक, लगातार एक की देखरेख करते हैं - छुट्टियों के दौरान प्रतिस्थापन पर दूसरा और तीसरा, बीमारी या सक्रिय और उपलब्ध होने पर परियोजना प्रबंधक के सहायक के रूप में कार्य करता है।

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

विकसित प्रणाली और एक संक्षिप्त इतिहास क्या है?

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

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

आंतरिक विकास से बचने की कोशिश के बारे में

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

उत्पाद या उत्पाद नहीं?

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

प्रक्रिया आरेख

कई वर्षों के लिए, साज़िश, अनुकूलन और सामान्य ज्ञान के समावेश के माध्यम से, काम के आयोजन की प्रक्रिया एक योजना, एक सरलीकृत संस्करण में बनाई गई है जिसे मैं आपके ध्यान में लाता हूं।

प्रतिभागियों
अंतिम उपयोगकर्ता - सिस्टम का अंतिम उपयोगकर्ता
मैनेजर - प्रोजेक्ट मैनेजर
परीक्षक - परीक्षक
वास्तुकार - वास्तुकार
विश्लेषक - विश्लेषक
आवेदन डेवलपर - डेवलपर
कोड reviwer - कोड समीक्षा के लिए जिम्मेदार डेवलपर



1. अंतिम उपयोगकर्ता BPM सिस्टम के माध्यम से नई कार्यक्षमता के लिए लागू होता है। अब यह ओरेकल बीपीएम में प्रवास को देखते हुए एक मालिकाना समाधान है।
2. परियोजना प्रबंधक आवेदन को स्वीकार करता है, अवास्तविक / डुप्लिकेट को फ़िल्टर करता है।
3. प्रोजेक्ट मैनेजर एप्लिकेशन को एनालिस्ट / आर्किटेक्ट को बीपीएम सिस्टम के माध्यम से फिर से पास करता है।
4 ए। विश्लेषक / वास्तुकार पहले व्यावसायिक \ कार्यात्मक आवश्यकताओं के संदर्भ में कार्य तैयार करते हैं, फिर एक निजी तकनीकी कार्य के रूप में। कार्य का पाठ स्रोत नियंत्रण (Git), जिरा और BPM को कार्य को जाता है, आवश्यकताओं का पता लगाया जाता है (तर्कसंगत समाशोधन)।
4 बी। आर्किटेक्ट कार्य के लिए समय सीमा की भविष्यवाणी करता है और परियोजना प्रबंधन प्रणाली (Microsoft प्रोजेक्ट सर्वर + सुधार) में जानकारी दर्ज करता है।
4 सी। परियोजना प्रबंधन प्रणाली कार्य के अनुमानित समय और लागत के बारे में अंतिम उपयोगकर्ता को सूचित करती है।
5. डेवलपर स्रोत कोड का नवीनतम संस्करण लेता है, कार्यक्षमता को कार्यान्वित करता है।
6. डेवलपर कोड समीक्षा (गेरिट के माध्यम से) पर कोड पोस्ट करता है।
7. CI सिस्टम (हडसन) कोड लेता है, एक टेस्ट असेंबली आयोजित करता है।
8. टेस्ट असेंबली रिपोर्ट रिपोर्टिंग सिस्टम (Microsoft SQL सर्वर विश्लेषण सेवाओं पर आधारित) पर जाती है। एक कोड विश्लेषण करने के लिए कोड समीक्षा के लिए जिम्मेदार व्यक्ति को एक नोटिस भेजा जाता है।
9. कोड reviwer परिवर्तनों को हरी रोशनी देता है।
10. कोड को मुख्य विकास शाखा में स्थानांतरित किया जाता है।
11. सीआई प्रणाली मुख्य शाखा से कोड लेती है, विधानसभा का संचालन करती है।
12. वह रिपोर्ट जिस पर रिपोर्टिंग प्रणाली रखी गई है।
13. CI सिस्टम परीक्षण वातावरण के लिए एक कोड परिनियोजन पैदा करता है।
14. CI सिस्टम फंक्शनल और लोड टेस्टिंग के सिस्टम को कॉल करता है।
15. एक स्वचालित मोड में परीक्षण प्रणाली एक परीक्षण वातावरण (जेमीटर, सेलेनियम, रेशनलरोबोट) पर परीक्षण प्रक्रियाओं को पूरा करती है।
16A। जिस पर रिपोर्ट प्रणाली में रखी गई है। परीक्षक को परीक्षण करने की आवश्यकता के बारे में सूचित किया जाता है।
16b। परीक्षण प्रणाली एक परियोजना प्रबंधन प्रणाली में एक कार्य की स्थिति को बदल देती है।
17. परीक्षक परीक्षण करता है।
18. सफल होने पर, BPM प्रणाली में स्थिति बदल जाती है, जिसके बारे में
19. परियोजना प्रबंधक को सूचित किया जाता है।
20a। बीपीएम प्रणाली विधानसभा को पूर्व ठेस वातावरण में स्थानांतरित करने की पहल करती है।
20b। इस घटना पर एक निशान परियोजना प्रबंधन प्रणाली में रखा गया है।
20C। अंत उपयोगकर्ता को क्या सूचित किया जाता है जो पूर्व ठेस वातावरण पर कार्यक्षमता देख सकता है।
21. परियोजना प्रबंधक और अंतिम उपयोगकर्ता पूर्व ठेस वातावरण पर कार्यक्षमता का परीक्षण करते हैं।
22. इस घटना में कि कार्यक्षमता को उत्पादक को हस्तांतरित करने का निर्णय लिया जाता है, BPM प्रणाली के माध्यम से परियोजना प्रबंधक, उत्पादक वातावरण में कार्य को आरंभ करता है।

पृष्ठभूमि में

1. स्वचालित पर्यावरण सेटिंग्स (कठपुतली) की प्रणाली बुनियादी सॉफ्टवेयर की सेटिंग्स के संदर्भ में परिदृश्य का संरेखण बनाती है।
2. स्टेटस मॉनिटरिंग एंड ट्रैकिंग सिस्टम (ज़ैबिक्स) इंफ्रास्ट्रक्चर की निगरानी करता है, जिसमें न केवल देव, परीक्षण, पूर्व-ठेस और ठेस, बल्कि अन्य अवसंरचना भी शामिल हैं, जिसमें जेरिट, गिट, हडसन, आदि शामिल हैं।
3. बैकअप सिस्टम, प्रोजेक्ट रिपॉजिटरी और इन्फ्रास्ट्रक्चर सॉफ्टवेयर का बैकअप लेने के अलावा, फोर्स मैज्योर या सिस्टम के पिछले रिलीज को प्रदर्शित करने की आवश्यकता के मामले में पूर्व-ठेस परिदृश्य मशीनों की छवियों का बैकअप लेता है।
4. दिन में एक बार, कोड का स्थैतिक विश्लेषण किया जाता है, मुख्य रूप से कमजोरियों की खोज करने के लिए।

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

परियोजना में भागीदारी के कई वर्षों के बाद लेखक ने जो सलाह दी, उसमें सूखे के निष्कर्षों की निंदा की गई

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