गुणवत्तेची जबाबदारी कोणाची?

अहो हाब्र!

आमच्याकडे एक नवीन महत्त्वाचा विषय आहे - आयटी उत्पादनांचा उच्च-गुणवत्तेचा विकास. HighLoad++ वर आम्ही बर्‍याचदा व्यस्त सेवा जलद कशी बनवायची याबद्दल बोलतो आणि Frontend Conf मध्ये आम्ही एका मस्त यूजर इंटरफेसबद्दल बोलतो जो कमी होत नाही. आमच्याकडे नियमितपणे चाचणी आणि DevOpsConf चाचण्यांसह विविध प्रक्रिया एकत्र करण्याविषयी विषय असतात. परंतु सर्वसाधारणपणे गुणवत्ता कशाला म्हणता येईल आणि त्यावर सर्वसमावेशकपणे कसे कार्य करावे याबद्दल - नाही.

याद्वारे याचे निराकरण करूया QualityConf — आम्ही विकासाच्या प्रत्येक टप्प्यावर वापरकर्त्यासाठी अंतिम उत्पादनाच्या गुणवत्तेबद्दल विचार करण्याची संस्कृती विकसित करू. आपल्या जबाबदारीच्या क्षेत्रावर लक्ष केंद्रित न करण्याची आणि केवळ परीक्षकांशीच नव्हे तर गुणवत्तेची जोड देण्याची सवय.

कट खाली आम्ही कार्यक्रम समितीचे प्रमुख, Tinkoff.Business येथील चाचणी प्रमुख, रशियन भाषिक QA समुदायाचे निर्माता यांच्याशी बोलू. अनास्तासिया असीवा-नगुयेन QA उद्योगाची स्थिती आणि नवीन परिषदेच्या ध्येयाबद्दल.

- नास्तिया हॅलो. कृपया आम्हाला आपल्याबद्दल सांगा.

अनास्तासिया: मी बँकेत चाचणीचे नेतृत्व करतो आणि खूप मोठ्या संघासाठी जबाबदार आहे—आम्ही 90 पेक्षा जास्त लोक आहोत. आमच्याकडे एक महत्त्वाची व्यवसाय लाइन आहे; आम्ही कायदेशीर संस्थांसाठी इकोसिस्टमसाठी जबाबदार आहोत.

मी यांत्रिकी आणि गणिताचा अभ्यास केला आणि सुरुवातीला मला प्रोग्रामर बनायचे होते. पण जेव्हा मला एक मनोरंजक ऑफर मिळाली, तेव्हा मी एक परीक्षक म्हणून प्रयत्न करण्याचा निर्णय घेतला. विचित्रपणे, हे माझे कॉलिंग असल्याचे दिसून आले. आता मी या इंडस्ट्रीत माझे सर्व काम पाहतो.

मी गुणवत्ता हमी शिस्तीचा कट्टर अनुयायी आहे. कोणती उत्पादने तयार केली जातात, कंपनीत, संघात आणि तत्त्वतः, विकास प्रक्रियेत गुणवत्ता कशी हाताळली जाते याची मला काळजी आहे.

हे मला उघड आहे या दिशेने समाज पुरेसा परिपक्व नाहीकिमान रशियामध्ये. आम्‍हाला नेहमी हे समजत नाही की गुणवत्‍ता हमी ही केवळ आवश्‍यकता पूर्ण करण्‍यासाठी अर्जाची चाचणी करण्‍याची वस्तुस्थिती नाही. मला ही परिस्थिती बदलायची आहे.

- तुम्ही क्वालिटी अॅश्युरन्स आणि टेस्टिंग हे शब्द वापरता. सरासरी व्यक्तीच्या दृष्टीने, या दोन संज्ञा बर्‍याचदा ओव्हरलॅप होतात. आपण खोल खणल्यास ते कसे वेगळे असतील?

अनास्तासिया: उलट, ते वेगळे नाहीत. चाचणी हा क्वालिटी अॅश्युरन्स शिस्तीचा एक भाग आहे, ही एक थेट क्रियाकलाप आहे - मी काहीतरी चाचणी करत आहे. प्रत्यक्षात चाचणीचे बरेच प्रकार आहेत आणि विविध प्रकारच्या चाचणीसाठी विविध प्रकारचे लोक जबाबदार आहेत. परंतु येथे रशियामध्ये, जेव्हा कंपन्यांना परीक्षक पुरवणाऱ्या आउटसोर्सर्सची लाट दिसली, तेव्हा चाचणी एकाच प्रकारात कमी केली गेली.

बहुतेक प्रकरणांमध्ये, ते केवळ कार्यात्मक चाचणीपुरते मर्यादित आहेत: ते तपासतात की विकसकांनी जे कोड केले आहे ते तपशीलांचे पालन करते आणि तेच.

— कृपया आम्हाला सांगा की इतर कोणती गुणवत्ता आश्वासन शाखा आहेत? चाचणी व्यतिरिक्त, येथे आणखी काय समाविष्ट आहे?

अनास्तासिया: गुणवत्ता हमी, प्रथम आणि सर्वात महत्त्वाचे म्हणजे गुणवत्तापूर्ण उत्पादन तयार करणे. म्हणजेच, आम्ही स्वतःला विचारतो की आमच्या उत्पादनाची गुणवत्ता कोणती असावी. त्यानुसार, जर आपल्याला हे समजले तर आपण या गुणवत्तेच्या गुणधर्मांवर कोण प्रभाव टाकतो याची तुलना करू शकतो. काही फरक पडत नाही, विकसक, प्रकल्प व्यवस्थापक किंवा उत्पादन विशेषज्ञ उत्पादनाच्या विकासावर, त्याच्या अनुशेषावर आणि त्याच्या धोरणावर प्रभाव टाकणारी व्यक्ती.

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

— असे दिसते की तुम्ही जे वर्णन केले आहे ते उत्पादन तज्ञाचे कार्य आहे. हे, तत्त्वतः, चाचणीबद्दल नाही आणि गुणवत्तेबद्दल नाही - हे सामान्यतः उत्पादन व्यवस्थापनाबद्दल आहे, नाही?

अनास्तासिया: समावेश. गुणवत्ता हमी ही एक शिस्त नाही ज्यासाठी एक विशिष्ट व्यक्ती जबाबदार आहे. आता चाचणीमध्ये एक लोकप्रिय दिशा आहे, ज्याला एक दृष्टीकोन म्हणतात चपळ चाचणी. त्याची व्याख्या स्पष्टपणे सांगते की हा चाचणीसाठी एक सांघिक दृष्टीकोन आहे, ज्यामध्ये विशिष्ट पद्धतींचा समावेश आहे. हा दृष्टिकोन अंमलात आणण्यासाठी संपूर्ण संघ जबाबदार आहे; संघात परीक्षक असणे देखील आवश्यक नाही. संपूर्ण टीम ग्राहकाला मूल्य वितरीत करण्यावर आणि मूल्य ग्राहकांच्या अपेक्षा पूर्ण करेल याची खात्री करण्यावर लक्ष केंद्रित करते.

— असे दिसून आले की गुणवत्ता जवळपास सर्वच विषयांना छेदते, आजूबाजूच्या प्रत्येक गोष्टीवर एक फ्रेमवर्क लादते?

अनास्तासिया: बरोबर. जेव्हा आपण या वस्तुस्थितीचा विचार करतो की आपल्याला दर्जेदार उत्पादन तयार करायचे आहे, तेव्हा आपण गुणवत्तेच्या विविध गुणधर्मांबद्दल विचार करू लागतो. उदाहरणार्थ, आमच्या क्लायंटला आवश्यक असलेले वैशिष्ट्य आम्ही खरोखर बनवले आहे हे कसे तपासायचे.

या प्रकारची चाचणी येथे येते: यूएटी (वापरकर्ता स्वीकृती चाचणी). दुर्दैवाने, हे रशियामध्ये क्वचितच वापरले जाते, परंतु कधीकधी अंतिम क्लायंटसाठी डेमो म्हणून SCRUM संघांमध्ये उपस्थित असते. परदेशी कंपन्यांमध्ये चाचणीचा हा एक सामान्य प्रकार आहे. सर्व ग्राहकांसाठी कार्यक्षमता उघडण्यापूर्वी, आम्ही प्रथम UAT करतो, म्हणजेच, आम्ही अंतिम वापरकर्त्याला चाचणीसाठी आमंत्रित करतो आणि उत्पादन खरोखर अपेक्षा पूर्ण करते आणि वेदनांचे निराकरण करते की नाही यावर त्वरित अभिप्राय प्रदान करतो. यानंतरच इतर सर्व क्लायंटसाठी स्केलिंग शक्य होईल.

म्हणजेच, आम्ही व्यवसायावर, अंतिम क्लायंटवर लक्ष केंद्रित करतो, परंतु त्याच वेळी तंत्रज्ञानाबद्दल विसरू नका. उत्पादनाची गुणवत्ता देखील तंत्रज्ञानावर मोठ्या प्रमाणात अवलंबून असते. आमच्याकडे खराब आर्किटेक्चर असल्यास, आम्ही वैशिष्ट्ये पटकन रिलीझ करू शकत नाही आणि ग्राहकांच्या अपेक्षा पूर्ण करू शकत नाही. स्केल करण्याचा प्रयत्न करताना किंवा रिफॅक्टर करण्याचा प्रयत्न करताना, आम्ही काहीतरी खंडित करू शकतो. या सर्वांचा ग्राहकांच्या समाधानावर परिणाम होईल.

या दृष्टिकोनातून, आर्किटेक्चर असे असले पाहिजे की आपण स्वच्छ कोड लिहू शकू ज्यामुळे आपल्याला त्वरीत बदल करण्याची परवानगी मिळेल आणि आपण सर्वकाही खंडित करू अशी भीती बाळगू नये. आमच्याकडे खूप वारसा असल्यामुळे पुनरावृत्ती पुनरावृत्ती अनेक महिन्यांपर्यंत वाढू नये हे सुनिश्चित करण्यासाठी, आम्हाला दीर्घ चाचणी टप्पे करावे लागतील.

— एकूणच, विकासक, आर्किटेक्ट, उत्पादन शास्त्रज्ञ, उत्पादन व्यवस्थापक आणि परीक्षक स्वतः आधीच गुंतलेले आहेत. गुणवत्ता आश्वासन प्रक्रियेत आणखी कोण सामील आहे?

अनास्तासिया: आता कल्पना करूया की आम्ही हे वैशिष्ट्य क्लायंटला आधीच वितरित केले आहे. साहजिकच, उत्पादनाची गुणवत्ता आधीच उत्पादनात असताना देखील त्याचे परीक्षण करणे आवश्यक आहे. या टप्प्यावर, स्पष्ट नसलेल्या परिस्थिती, तथाकथित बग, दिसू शकतात.

पहिला प्रश्न हा आहे की आम्ही उत्पादन आधीच रिलीज केल्यानंतर आम्ही या बग्सचा सामना कसा करू? आपण, उदाहरणार्थ, तणावावर कशी प्रतिक्रिया देतो? जर पृष्ठ लोड होण्यास 30 सेकंदांपेक्षा जास्त वेळ लागला तर क्लायंटला फार आनंद होणार नाही.

इथेच शोषणाचा खेळ होतो, किंवा ते आता म्हणतात तसे. DevOps. खरं तर, हे असे लोक आहेत जे उत्पादन आधीपासून उत्पादनात असताना ते ऑपरेट करण्यासाठी जबाबदार आहेत. यामध्ये विविध प्रकारच्या देखरेखीचा समावेश आहे. चाचणीचा एक उपप्रकार देखील आहे - उत्पादनावरील चाचणी, जेव्हा आम्ही स्वतःला प्रकाशन करण्यापूर्वी काहीतरी चाचणी न करण्याची परवानगी देतो आणि उत्पादनावर त्वरित चाचणी करतो. पायाभूत सुविधांचे आयोजन करण्याच्या दृष्टिकोनातून ही क्रियाकलापांची मालिका आहे जी आपल्याला एखाद्या घटनेला त्वरित प्रतिसाद देण्यास, त्यावर प्रभाव टाकण्यास आणि त्यास दुरुस्त करण्यास अनुमती देते.

पायाभूत सुविधाही महत्त्वाच्या आहेत. अनेकदा अशी परिस्थिती असते जेव्हा, चाचणी दरम्यान, आमच्याकडे खरोखर सर्वकाही आहे याची खात्री करणे अशक्य आहे जे आम्ही क्लायंटला देऊ इच्छितो. आम्ही ते उत्पादनात आणतो आणि स्पष्ट नसलेल्या परिस्थितींना पकडण्यास सुरुवात करतो. आणि सर्व कारण चाचणीमधील पायाभूत सुविधा उत्पादनातील पायाभूत सुविधांशी संबंधित नाहीत. यामुळे नवीन प्रकारचे चाचणी होते - पायाभूत सुविधा चाचणी. यामध्ये विविध कॉन्फिगरेशन, सेटिंग्ज, डेटाबेस स्थलांतर इ.

हा प्रश्न निर्माण करतो - कदाचित संघाला पायाभूत सुविधा कोड म्हणून वापरण्याची आवश्यकता आहे.

माझा विश्वास आहे की पायाभूत सुविधा थेट उत्पादनाच्या गुणवत्तेवर परिणाम करतात.

मला आशा आहे की परिषदेत वास्तविक प्रकरणासह अहवाल येईल. कोड म्हणून पायाभूत सुविधांचा गुणवत्तेवर कसा परिणाम होतो हे तुम्ही तुमच्या स्वतःच्या अनुभवावरून सांगण्यास तयार असल्यास आम्हाला लिहा. कोड म्हणून पायाभूत सुविधा सर्व सेटिंग्ज तपासणे आणि अन्यथा शक्य नसलेल्या गोष्टी तपासणे सोपे करते. म्हणून, दर्जेदार उत्पादन विकसित करण्याच्या प्रक्रियेत ऑपरेशन देखील सामील आहे.

— विश्लेषण आणि दस्तऐवजीकरण बद्दल काय?

अनास्तासिया: हे एंटरप्राइझ सिस्टमवर अधिक लागू होते. जेव्हा आपण एंटरप्राइझबद्दल बोलतो तेव्हा विश्लेषक आणि सिस्टम विश्लेषक यांसारखे लोक लगेच लक्षात येतात. त्यांना कधीकधी तांत्रिक लेखक म्हटले जाते. त्यांना एक तपशील लिहिण्यासाठी आणि ते पूर्ण करण्यासाठी एक कार्य प्राप्त होते, उदाहरणार्थ, एका महिन्यासाठी.

हे वारंवार सिद्ध झाले आहे की असे दस्तऐवज लिहिल्याने खूप लांब विकास पुनरावृत्ती आणि सुधारणेची दीर्घ पुनरावृत्ती होते, कारण चाचणी प्रक्रियेदरम्यान दोष ओळखले जातात आणि परतावा सुरू होतो. परिणामी, विकासाचा खर्च वाढवणाऱ्या अनेक पळवाटा आहेत. याव्यतिरिक्त, हे असुरक्षा सादर करू शकते. आम्ही संदर्भ संहिता लिहिली आहे असे दिसते, परंतु नंतर आम्ही असे बदल केले जे उत्तम प्रकारे विचारात घेतलेल्या वास्तुकला खंडित करतात.

परिणामी, परिणाम खूप उच्च-गुणवत्तेचे उत्पादन नाही, कारण पॅच आधीच आर्किटेक्चरमध्ये दिसू लागले आहेत, काही ठिकाणी कोड चाचण्यांनी पुरेसा कव्हर केलेला नाही, कारण मुदत संपत आहे, सर्व बग जलद बंद करणे आवश्यक आहे. आणि सर्व कारण मूळ तपशीलाने अंमलबजावणी करणे आवश्यक असलेले सर्व मुद्दे विचारात घेतले नाहीत.

विकसक कीटक नाहीत आणि हेतुपुरस्सर त्रुटींसह कोड लिहित नाहीत.

जर आम्ही सुरुवातीला सर्व आवश्यक मुद्द्यांचा अंतर्भाव असलेल्या तपशीलाद्वारे विचार केला असता, तर सर्वकाही आवश्यकतेनुसार अंमलात आणले गेले असते. पण हा एक यूटोपिया आहे.

एक परिपूर्ण 100-पृष्ठ तपशील लिहिणे कदाचित अशक्य आहे. म्हणून कागदपत्रे लिहिण्याच्या पर्यायी मार्गांचा विचार करणे आवश्यक आहे, तपशील, टास्क स्टेटमेंट जे आम्हाला डेव्हलपर नेमके काय आवश्यक आहे हे सुनिश्चित करण्यासाठी जवळ आणतील.

येथेच चपळ दृष्टीकोन लक्षात येते—स्वीकृती निकषांसह वापरकर्ता कथा. लहान पुनरावृत्तीमध्ये विकसित होणाऱ्या संघांसाठी हे अधिक लागू आहे.

— उपयोगिता चाचणी, उत्पादनाची उपयोगिता, डिझाइन बद्दल काय?

अनास्तासिया: हा एक अतिशय महत्त्वाचा मुद्दा आहे, कारण संघात डिझाइनर आहेत. बर्याचदा, डिझाइनर एक सेवा म्हणून वापरले जातात - एकतर डिझाइन विभागाद्वारे किंवा आउटसोर्स केलेल्या डिझाइनरद्वारे. बर्याचदा अशी परिस्थिती असते जिथे असे दिसते की डिझायनरने उत्पादन शास्त्रज्ञाचे ऐकले आणि त्याला जे समजले ते केले. परंतु जेव्हा आम्ही पुनरावृत्ती सुरू करतो तेव्हा असे दिसून येते की प्रत्यक्षात जे केले गेले ते अपेक्षित नव्हते: डिझायनर काहीतरी विसरला, वर्तनाद्वारे पूर्णपणे विचार केला नाही, कारण तो संघात नव्हता आणि संदर्भात किंवा समोरचा नव्हता. -एंड डेव्हलपरला ते लेआउट पूर्णपणे समजले नाही. डिझाईनबद्दल फ्रंट-एंड डेव्हलपरच्या समजण्यात समस्या असल्यामुळे यास अनेक पुनरावृत्ती लागू शकतात.

शिवाय आणखी एक समस्या आहे. डिझाइन सिस्टम आता लोकप्रिय होत आहेत. ते हायपवर आहेत, परंतु त्यांच्यापासून होणारे फायदे पूर्णपणे स्पष्ट नाहीत.

मला असे मत आहे की डिझाइन सिस्टम, एकीकडे, विकास सुलभ करतात, परंतु दुसरीकडे, ते इंटरफेसवर बरेच निर्बंध लादतात.

परिणामी, आम्ही क्लायंटला हवे असलेले वैशिष्ट्य बनवत नाही, परंतु आमच्यासाठी सोयीचे आहे, कारण आमच्याकडे आधीपासूनच काही घन आहेत ज्यातून आम्ही ते बनवू शकतो.

मला वाटते की या विषयाकडे लक्ष देणे आणि डिझाइनचे काम सोपे करण्याचा प्रयत्न करताना आपण क्लायंटच्या वेदनांचे निराकरण करत आहोत की नाही याबद्दल विचार करणे योग्य आहे.

— गुणवत्ता हमीशी संबंधित विषयांची संख्या आश्चर्यकारक आहे. रशियामध्ये एक परिषद आहे जिथे या सर्वांवर चर्चा केली जाऊ शकते?

अनास्तासिया: चाचणीवरील सर्वात जुनी परिषद आहे, जी या वर्षी 25 व्यांदा आयोजित केली जाईल आणि तिला गुणवत्ता आश्वासन परिषद SQA दिवस म्हणतात. हे मुख्यतः कार्यात्मक परीक्षकांसाठी साधने आणि विशिष्ट चाचणी पद्धतींवर चर्चा करते. नियमानुसार, SQA डेजमधील अहवाल स्वतः परीक्षकांच्या जबाबदारीच्या क्षेत्रातील विशिष्ट क्षेत्रांचे सखोल परीक्षण करतात, परंतु जटिल क्रियाकलाप नाहीत.

हे विविध साधने आणि दृष्टीकोन समजून घेण्यात खूप मदत करते, डेटाबेस, एपीआय इ.ची चाचणी कशी करावी. परंतु त्याच वेळी, एकीकडे, ते अधिक चांगले उत्पादन तयार करण्यासाठी केवळ चाचणी करण्यापेक्षा अधिक सामील होण्यास प्रवृत्त करत नाही. दुसरीकडे, परीक्षक उत्पादनाच्या जागतिक उद्दिष्टाचा आणि त्याच्या व्यावसायिक घटकाचा विचार करण्याच्या प्रक्रियेत अधिक सहभागी होत नाहीत.

मी एक मोठा विभाग चालवतो आणि बर्‍याच मुलाखती घेतो, जे खरोखर संपूर्ण उद्योगाच्या स्थितीबद्दल अंतर्दृष्टी देतात. नियमानुसार, आमची मुले एंटरप्राइझमध्ये काम करतात आणि त्यांच्याकडे जबाबदारीचे स्पष्ट क्षेत्र आहे. परदेशी प्रकल्पांमध्ये काम करणारे सहकारी विविध प्रकारच्या चाचणीचा वापर करतात: ते स्वतः लोड चाचणी, कार्यप्रदर्शन चाचणी आणि कधीकधी सुरक्षा चाचणी देखील करू शकतात, कारण ते उत्पादनाची गुणवत्ता सुनिश्चित करण्यात संघाला खरोखर मदत करतात.

मला वाटते की रशियामधील मुलांनी देखील या वस्तुस्थितीबद्दल विचार करणे सुरू करावे की उद्योग कार्यात्मक चाचणीने संपत नाही.

— या उद्देशासाठी, आम्ही एक नवीन परिषद, QualityConf आयोजित करत आहोत, जी एक अविभाज्य शिस्त म्हणून गुणवत्तेला समर्पित आहे. या कल्पनेबद्दल आम्हाला अधिक सांगा, परिषदेचे मुख्य उद्दिष्ट काय आहे?

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

आजकाल मला अनेकदा चाचणी आणि गुणवत्तेत समस्या आल्यावर काय करावे याबद्दल सल्लागारांकडून विनंती ऐकायला मिळते. जेव्हा तुम्ही संघांशी संवाद साधण्यास सुरुवात करता, तेव्हा तुम्हाला दिसून येते की समस्या स्वतः परीक्षकांची नाही, तर प्रक्रिया ज्या पद्धतीने संरचित केली आहे. उदाहरणार्थ, जेव्हा विकसकांचा असा विश्वास आहे की ते फक्त कोड लिहिण्यासाठी जबाबदार आहेत, तेव्हा त्यांची जबाबदारी अगदी त्याच क्षणी संपते जेव्हा ते कार्य चाचणीकडे हस्तांतरित करतात.

प्रत्येकजण या वस्तुस्थितीचा विचार करत नाही की खराब लिखित, खराब आर्किटेक्चरसह निम्न-गुणवत्तेचा कोड प्रकल्पासाठी मोठ्या समस्यांना धोका देतो. ते त्रुटींच्या किंमतीबद्दल विचार करत नाहीत, कारण उत्पादनात येणारे दोष कंपनी आणि कार्यसंघासाठी मोठ्या खर्चास कारणीभूत ठरू शकतात. याचा विचार करण्याची संस्कृती नाही. आम्ही परिषदेत त्याचे वितरण सुरू करावे अशी माझी इच्छा आहे.

मला समजले आहे की हे नावीन्य नाही. एडवर्ड डेमिंग, गुणवत्तेच्या 14 सिद्धांतांचे लेखक, गेल्या शतकात त्रुटीच्या किंमतीबद्दल लिहिले. एक शिस्त म्हणून गुणवत्ता हमी या पुस्तकावर आधारित आहे, परंतु, दुर्दैवाने, आधुनिक विकास त्याबद्दल विसरतो.

— चाचणी आणि साधनांबद्दल थेट विषयांना स्पर्श करण्याची तुमची योजना आहे?

अनास्तासिया: मी कबूल करतो की साधनांबद्दल अहवाल असतील. अशी सार्वत्रिक साधने आहेत ज्यांच्या मदतीने कंपन्या आणि संघ उत्पादनावर प्रभाव टाकू शकतात.

सर्व अहवाल जागतिक स्तरावर एका समान ध्येयाने एकत्रित केले जातील: प्रेक्षकांना हे सांगण्यासाठी की हा दृष्टिकोन, साधन, पद्धत, प्रक्रिया, चाचणीचा प्रकार याच्या मदतीने आम्ही उत्पादनाच्या गुणवत्तेवर प्रभाव टाकला आहे आणि क्लायंटचे आयुष्य सुधारले आहे.

आमच्याकडे साधनाच्या फायद्यासाठी साधनाबद्दलचे अहवाल नक्कीच नसतील. कार्यक्रमात समाविष्ट केलेले सर्व अहवाल समान ध्येयाने एकत्रित केले जातील.

— तुम्ही कशाबद्दल बोलत आहात, परिषदेचे पाहुणे म्हणून कोणाला पाहता यात कोणाला रस असेल?

अनास्तासिया: आमच्याकडे विकासकांसाठी अहवाल असतील जे त्यांच्या प्रकल्पाच्या, उत्पादनाच्या, प्रणालीच्या भवितव्याची काळजी घेतात. त्याचप्रमाणे, हे परीक्षकांसाठी आणि मला वाटते, विशेषत: व्यवस्थापकांसाठी. व्यवस्थापकांद्वारे, मला असे म्हणायचे आहे की जे लोक निर्णय घेतात आणि इतर गोष्टींबरोबरच उत्पादन, प्रणाली, संघाचे नशीब आणि विकास प्रभावित करू शकतात.

हे असे लोक आहेत ज्यांना उत्पादन किंवा सिस्टमची गुणवत्ता कशी सुधारायची याबद्दल आश्चर्य वाटते. आमच्या परिषदेत, ते उपायांच्या विविध संचांबद्दल जाणून घेतील आणि आता त्यांच्यात काय चूक आहे आणि काय बदलण्याची आवश्यकता आहे हे समजण्यास सक्षम होतील.

मला वाटते की गुणवत्तेत काहीतरी चूक आहे हे समजून घेणे आणि त्यावर प्रभाव टाकायचा आहे हे समजून घेणे हा मुख्य निकष आहे. आम्ही कदाचित अशा लोकांपर्यंत पोहोचू शकणार नाही ज्यांना असे वाटते की हे प्रथमच होईल.

— तुम्हाला असे वाटते का की संपूर्ण उद्योग केवळ चाचणीबद्दलच नव्हे तर गुणवत्तेच्या संस्कृतीबद्दल बोलण्यासाठी योग्य आहे?

अनास्तासिया: मला विश्वास आहे की मी परिपक्व झालो आहे. आता अनेक कंपन्या पारंपारिक धबधब्यापासून दूर चपळतेकडे जात आहेत. क्लायंटवर लक्ष केंद्रित केले आहे, संघातील लोक खरोखरच दर्जेदार उत्पादन कसे तयार करावे याबद्दल विचार करू लागले आहेत. एंटरप्राइझ कंपन्या देखील गुणवत्ता सुधारण्यावर पुन्हा भर देत आहेत.

समाजात किती विनंत्या येत आहेत याचा विचार करून, मला विश्वास आहे की ही वेळ आहे. अर्थात, ही एक मोठ्या प्रमाणावर क्रांती होईल याची मला खात्री नाही, परंतु ही क्रांती जाणीवपूर्वक घडावी असे मला वाटते.

- सहमत! आम्ही संस्कृती रुजवू आणि चेतना बदलू.

आयटी उत्पादनांच्या उच्च-गुणवत्तेच्या विकासावर परिषद QualityConf होईल 7 जून रोजी मॉस्कोमध्ये. आपल्याला माहित आहे की कोणत्या टप्प्यांमधून उच्च-गुणवत्तेचे उत्पादन बनते, आमच्याकडे उत्पादनातील दोषांचा यशस्वीपणे सामना करण्याची प्रकरणे आहेत, आम्ही आमच्या स्वतःच्या सराव मध्ये लोकप्रिय पद्धती तपासल्या आहेत - आम्हाला तुमच्या अनुभवाची आवश्यकता आहे. पाठवा त्यांच्या १ मे पर्यंत अर्ज, आणि कार्यक्रम समिती परिषदेच्या संपूर्ण अखंडतेसाठी थीमवर लक्ष केंद्रित करण्यात मदत करेल.

ला जोडा गप्पा, ज्यामध्ये आम्ही गुणवत्ता समस्या आणि परिषद चर्चा करतो, सदस्यता घ्या टेलिग्राम चॅनेलकार्यक्रमाच्या बातम्यांसह अद्ययावत राहण्यासाठी.

स्त्रोत: www.habr.com