वीम इंडोर किचन: आर एंड डी प्रक्रिया कैसे काम करती है

शाम को। एक और आर एंड डी साक्षात्कार समाप्त हो रहा है, और हमारे साक्षात्कारकर्ताओं को भविष्य के सहकर्मी से अनपेक्षित प्रश्नों के लिए तैयार किया गया है। लेकिन कोई आश्चर्य की बात नहीं है: विल्फ्रेडो पेरेटो द्वारा कटौती अनुपात भी यहां काम करता है। 80% मामलों में, हम चार प्रश्न सुनते हैं - कुल प्राप्त संख्या का लगभग 20%। आपकी प्रक्रिया कैसी है? मैं क्या करूंगा? एक साल में वरिष्ठ / टीम लीडर कैसे बनें? यूरोप में स्थानांतरण के बारे में क्या?

इस पोस्ट में, हम पहले प्रश्न का उत्तर देंगे और वीम में विकास प्रक्रिया के बारे में बात करेंगे - टीम से टीम के लिए यह उत्तर सबसे कम बदलता है।



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

विकास प्रक्रिया कार्यों का एक क्रम है जो उपयोगकर्ताओं की इच्छाओं को मूर्त उत्पादों में बदल देती है। ये इच्छाएँ विश्लेषकों और उत्पाद प्रबंधकों द्वारा तैयार की जाती हैं, डेवलपर्स द्वारा कार्यान्वित की जाती हैं, जो समीक्षकों द्वारा समीक्षकों द्वारा मूल्यांकन की जाती हैं, और तकनीकी लेखकों द्वारा वर्णित हैं।

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

पात्र

प्रत्येक रिलीज़ कई समूहों का परिणाम है:

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

कुछ टीमें खुली जगह पसंद करती हैं, लेकिन अधिक बार - अलमारियाँ

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

पेड़ के छल्ले: विकास चक्र

हमारे उत्पाद का विकास चक्रीय है, प्रत्येक चक्र अगले संस्करण की रिहाई के साथ समाप्त होता है - रिलीज। यहाँ विज्ञप्ति में परिलक्षित होता है:

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

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

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

सुबह से शाम तक: जारी क्रोनिकल

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

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

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

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


परियोजना की वर्तमान स्थिति पर चर्चा करने के लिए विशिष्ट बैठक कक्ष

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

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

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

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

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

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

प्राथमिकताओं के बारे में

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

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

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

दूसरा, लगभग अविनाशी प्राथमिकता समय है। अद्यतनों के मामले में, रिलीज़ की तारीखें SLA द्वारा सेट की जाती हैं, बड़ी रिलीज़ के मामले में - व्यापारिक कैलेंडर द्वारा। आंकड़ों के अनुसार, प्रत्येक रिलीज चक्र में, लगभग 50% समय विकास पर खर्च किया जाता है, उत्पाद को दिमाग में लाने पर 50% (बगफिक्स)।

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

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

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

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

आगे क्या है?

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


हमारे प्राग कार्यालय की लॉबी

एक विकास कार्यालय हाल ही में इज़राइल में दिखाई दिया है, कनाडा और जर्मनी में टीमें बढ़ रही हैं। HP, NetApp, Nutanix, EMC के साथ संयुक्त विकास परियोजनाओं की संख्या बढ़ रही है।
कारख़ाना भौगोलिक रूप से वितरित कन्वेयर में बदल जाता है, और एक ही समय में, नई प्रक्रियाएं क्रिस्टलीकृत होती हैं। हालाँकि, यह एक अलग लेख के लिए एक विषय है।
जुड़े रहें।