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

"सुविधा द्वारा चश्मा" में क्या गलत था

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

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

प्रोटोटाइप का निर्माण

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

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

प्रोटोटाइप में सुधार और स्केलिंग

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

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

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

पूर्ण माइग्रेशन निष्पादित करना

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

इस नई सुविधा के अपने (सकारात्मक!) अनुभव को प्रदर्शित करना सुनिश्चित करें और टेक और उत्पाद अधिकारियों से बाय-इन प्राप्त करने के लिए दूसरों को इसके लाभों को बढ़ावा देने में संकोच न करें।

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

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

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

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

Qonto एसएमई और फ्रीलांसरों के लिए डिज़ाइन किया गया एक वित्त समाधान है जिसकी स्थापना 2016 में स्टीव अनावी और एलेक्जेंडर प्रोट द्वारा की गई थी। जुलाई 2017 में हमारे लॉन्च के बाद से, क्यूंटो ने 350,000 से अधिक कंपनियों के लिए व्यापार वित्तपोषण को आसान बना दिया है।

Qonto के सुव्यवस्थित अकाउंट सेट-अप, असीमित लेन-देन इतिहास, लेखा निर्यात और एक व्यावहारिक व्यय प्रबंधन सुविधा के साथ एक सहज ज्ञान युक्त दैनिक उपयोगकर्ता अनुभव के कारण व्यवसाय के मालिक समय बचाते हैं।

रीयल-टाइम सूचनाओं और उपयोगकर्ता-अधिकार प्रबंधन प्रणाली के माध्यम से अपनी टीमों को अधिक स्वायत्तता देने में सक्षम होने के दौरान वे नियंत्रण में रहते हैं।

वे स्मार्ट डैशबोर्ड, लेन-देन ऑटो-टैगिंग और कैश-फ्लो मॉनिटरिंग टूल के माध्यम से बेहतर कैश-फ्लो दृश्यता से लाभान्वित होते हैं।

उन्हें उचित और पारदर्शी कीमत पर शानदार ग्राहक सहायता भी मिलती है।

एक चुनौतीपूर्ण और गेम-चेंजिंग कंपनी में शामिल होने के इच्छुक हैं? हमारे नौकरी प्रस्तावों से परामर्श करें !