🚂 🌴 🚣🏿 अंतरिक्ष यान और अंतरिक्ष के बारे में। रास्ते में पूरे उत्पाद को बदलकर एक सुविधा कैसे बनाएं ☹️ 🎟️ 👨🏼‍🤝‍👨🏻

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

स्पेस का आविष्कार क्यों किया गया?

जब वरिके बनाया गया था, तो यह 15-20 लोगों की छोटी टीमों की प्रभावशीलता की समस्याओं को हल करने पर केंद्रित था। ऐसी टीमों के लिए एक जगह पर काम करना सुविधाजनक होता है, जहां सभी के लिए "स्पेस" हो।

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

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

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

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

"रिक्त स्थान", सबसे पहले, टीमों के लिए एक सुविधा है। हालांकि, यह जीवित व्यक्तिगत स्थान की अवधारणा पर आधारित है, जिसे सभी को अनावश्यक जानकारी और बाहरी शोर को बाहर करने की आवश्यकता है।

रिक्तियाँ क्या समस्याएँ हल करती हैं?

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

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

_{यह था}

_{बन गया है}

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

रिक्त स्थान विकसित करने की प्रक्रिया में, हम दो प्रमुख कार्यों में आए:

उपयोगकर्ता को केवल वही देखना चाहिए जो उसके लिए प्रासंगिक है
प्रतिनिधिमंडल और स्व-संगठन को ऊर्ध्वाधर प्रबंधन के स्थान पर आना चाहिए

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

"अगर खाता व्यवस्थापक के पास प्रक्रियाओं के लिए उच्च स्तर की जिम्मेदारी थी, तो अब वह टीम के वर्कफ़्लो के संगठन को अपने तत्काल पर्यवेक्षक को सौंपने में सक्षम होगा, जो अक्सर अपनी टीम की विशेषताओं को बेहतर तरीके से जानता है।"

- इवान सेवलीव, व्रीक प्रोडक्ट मैनेजर

हमें किन कठिनाइयों का सामना करना पड़ा?

बेशक, उत्पाद में महत्वपूर्ण परिवर्तन महान जोखिम और कई कठिनाइयों को जन्म देते हैं। यहाँ उनमें से कुछ हैं:

कठिनाई 1. जोखिम कम करें

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

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

कठिनाई 2. ग्राहक के समाधान का मूल्य लाना

व्रीके के पास कई ग्राहक हैं जो पहले से ही सेवा का उपयोग करते हैं और अपनी कार्य प्रक्रियाओं को स्थापित करते हैं, इसलिए एक जोखिम था कि नई कार्यक्षमता अनिच्छुक होगी।

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

बाद में, हमने कोई कॉल नहीं किया: ग्राहक खुद ही प्रारंभिक परीक्षण कार्यक्रम में आने लगे और एक नई सुविधा का उपयोग करने लगे।

कठिनाई 3. एक सुधार के लिए कई परिवर्तनों की आवश्यकता होती है

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

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

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

टीमों ने आपस में कैसे बातचीत की?

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

संचार का मुद्दा एक प्राथमिकता थी: जहां पहले से ही सब कुछ पर चर्चा करना और समझौतों को औपचारिक रूप देना संभव था, बातचीत उन टीमों के साथ बेहतर हुई, जिनके साथ प्रारंभिक चर्चा नहीं हुई थी। बाद के मामले में, विकास टीम को किसी अन्य व्यक्ति के स्वयं में परिवर्तन करना या संशोधित करना पड़ा।

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

- एलेक्सी कार्तेंको, फ्रंटेंड टीमलेड

जब 30 टीमें एक-दूसरे के साथ बहुत ही फुर्तीले माहौल में बातचीत करती हैं, तो यह समस्या पैदा होती है। लगभग किसी भी कंपनी के लिए, एक स्क्रम प्रक्रिया की व्यवस्था करना पहले से ही एक उपलब्धि है, और स्क्रैच का एक फंतासी एक कल्पना है: यहां उत्पाद-शक्तियां, लीड, और सामान्य डेवलपर्स को एक दूसरे के साथ काम करना सीखना चाहिए।

ये एक बड़ी परियोजना बनाने की तैयारी करने वालों को स्पेस टीम द्वारा दिए गए टिप्स हैं:

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

अंतरिक्ष यान और अंतरिक्ष के बारे में। रास्ते में पूरे उत्पाद को बदलकर एक सुविधा कैसे बनाएं

स्पेस का आविष्कार क्यों किया गया?

हमें किन कठिनाइयों का सामना करना पड़ा?

टीमों ने आपस में कैसे बातचीत की?

More articles: