इसे लें और इसे करें: कभी-कभी विश्लेषण के लिए स्कोर करना और सिर्फ विकास करना क्यों उपयोगी होता है

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

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



और ... सब कुछ काम कर गया!

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

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

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

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

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

क्या आपको याद है कि यह सब कैसे शुरू हुआ? .. (ग)

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


इस दृष्टिकोण से, मैक्रोस्कोप मॉड्यूल गिनती कर सकता है


और इसमें - सीखा

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

मॉड्यूल की अंतिम भिन्नता में, लोगों की गणना का कार्य कंप्यूटर दृष्टि के शास्त्रीय तरीकों द्वारा हल किया गया था, जिसने उपयोग की शर्तों पर गंभीर प्रतिबंध लगाए थे। लेकिन नए कार्य के ढांचे में, मॉड्यूल को लोगों को मौलिक रूप से अलग, बहुत अधिक कठिन परिस्थितियों में गिनना सीखना था।

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

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

दुर्भाग्य से, हमने दोनों विधियों को अस्वीकार कर दिया, क्योंकि उनके आधार पर बनाए गए काउंटर की सटीकता कम थी।

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

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

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

सुखद अंत

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

यदि संक्षेप में कहें, तो तुलना के लिए: कतार में लोगों की गिनती के लिए मॉड्यूल के पुराने संस्करण का विकास और परिशोधन (4 साल पहले) लगभग 8 महीने लगे । हमने 2 महीने में नया मॉड्यूल बनाया (पहला कामकाजी प्रोटोटाइप 2-3 सप्ताह में उपयोगकर्ता को सौंप दिया गया था)।

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

किसी भी मामले में, हमारे लिए, हम कई नियमों के साथ आए हैं, जिनका अनुपालन करना तेजी से कार्य करने की आधी सफलता है:

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