हम ऑडिट क्यों और कैसे करते हैं

कल्पना कीजिए कि आप कुछ बीमार हैं (भगवान न करें, निश्चित रूप से)। आप डॉक्टर के पास जाते हैं और दो संभावनाएँ हैं:

• "कट टू हेल!"
• आप परीक्षण लेने जाते हैं और उसके बाद आपको पता चलेगा कि आपने कुछ गलत खाया है

व्यक्तिगत रूप से, मेरे सहयोगियों और मुझे दूसरा विकल्प पसंद है, यही कारण है कि जब हमें "ये आपके एडजैल्स" पेश करने के लिए कहा जाता है, तो हम एक ऑडिट आयोजित करते हैं। लेकिन हम प्राइसवाटरहाउसकूपर्स की तरह नहीं हैं - हम बेहतर हैं, हम अनौपचारिक हैं और हम मूल्यवान परिणाम देते हैं। कैसे बिल्कुल - कटौती के तहत पढ़ा!

सबसे अधिक बार, हम तीन दिनों में एक ऑडिट करते हैं। पहले डेढ़ दिन क्लाइंट के साथ जानकारी इकट्ठा करने में बिताए जाते हैं, दूसरे दिन हम एक विश्लेषण करते हैं, और फिर आधे दिन में एक प्रस्तुति बनाते हैं। अब थोड़ा और।

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



वीएसएम आपको सुधार और अनावश्यक कदमों के लिए क्षेत्रों को समझने की अनुमति देता है जो मूल्य नहीं जोड़ते हैं और नुकसान का एक स्रोत हैं।

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

चूंकि हम एक साथ या तीन ऑडिट करते हैं, तो हम अलग हो जाते हैं और विकास के तकनीकी और उत्पाद भागों के विवरण का पता लगाते हैं।

प्रौद्योगिकी के संदर्भ में, निम्न बातों को जानना हमारे लिए महत्वपूर्ण है:

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

किराने की दृष्टि से, निम्नलिखित पहलू हमारे लिए महत्वपूर्ण हैं:

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

आमतौर पर पहला दिन इस पर समाप्त होता है और हम एक टाइमआउट लेते हैं।

अगले दिन हम टीम के साथ संवाद करना जारी रखेंगे।

डेवलपर, परीक्षक और सिस्टम प्रशासक के लिए, हम निम्नलिखित दो अभ्यास करते हैं।

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



जहाज को समाप्त करने के बाद, हम दूसरे कार्य को एक साथ करते हैं - हम परियोजना के बुनियादी ढांचे का निर्माण करते हैं: सर्वर, भंडारण, सेवाएँ और इसी तरह। इस मामले में सबसे दिलचस्प क्या है, प्रत्येक अगले समूह का कहना है, "और उन्होंने ड्रॉ क्यों नहीं किया ..." या "हां, वे सभी प्रदर्शित किए गए!"



इसके अलावा, स्पीड बोट के प्रारूप में, हम कंपनी के रिक्रूटर्स के साथ संवाद करते हैं। कंपनी में मनोदशा, लोगों की प्रेरणा आदि को समझना आवश्यक है। एक बार, यह भर्तीकर्ताओं के साथ संचार था जिसने समस्या को विस्तार से समझने में मदद की।

उसके बाद, परिणामों को संसाधित करने का समय आ गया है। मैं सभी रहस्यों को उजागर नहीं करूंगा, मैं केवल दो बिंदुओं के बारे में कहूंगा।

सबसे पहले, हम निम्नलिखित समूहों में सभी समस्याओं का विश्लेषण करते हैं:

• कंपनी का माहौल और संस्कृति
• उत्पादों के साथ काम करें
• प्रक्रियाओं
• लोग

यह ब्रेकडाउन हमें अपने आंतरिक मॉडल के अनुसार कंपनी की परिपक्वता के वर्तमान स्तर को समझने की अनुमति देता है:

• आवश्यकताएँ प्रबंधन
• गुणवत्ता
• संचार
• विकास प्रबंधन
• प्रेरणा
• इंजीनियरिंग संस्कृति
• मानव संसाधन प्रबंधन

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

इस तरह हमारे ऑडिट के तीन दिन समृद्ध और ऊर्जावान रूप से गुजरते हैं और हर कोई एक दूसरे से संतुष्ट होता है।