इस लेख में, मैं एक छोटे वेब विकास विभाग में वर्कफ़्लोज़ के निर्माण के बारे में बात करूँगा। विभाग का गठन खरोंच से किया गया था और तुरंत स्वायत्त काम शुरू हुआ था, इसलिए हमें उत्पादन प्रक्रियाओं का निर्माण करना था, सभी प्रकार की रेक पर कदम रखना चाहिए और इससे आवश्यक निष्कर्ष निकालना चाहिए। इस आशा में कि यह किसी को समय, धन और तंत्रिकाओं को बचाने में मदद करेगा, मैं उन समस्याओं का वर्णन करूंगा जिनके साथ हम सामना कर रहे हैं और उन्हें हल करने के लिए हमारे विकल्प।
यह ध्यान रखना महत्वपूर्ण है कि यह कुछ सार्वभौमिक पद्धति नहीं है जिसे किसी भी विकास टीम में लागू किया जा सकता है, और सब कुछ तुरंत अद्भुत होगा। यह अच्छी तरह से ज्ञात तकनीकों और व्यावहारिक अनुभव का मिश्रण है, जिसे हम प्रभावी रूप से अपनी विकासात्मक सुविधाओं में समायोजित करने में सक्षम थे। इस मुद्दे का कोई एकल, सरल समाधान नहीं है। आपको हमेशा टीम के आकार और अनुभव, व्यवसाय की विशेषताओं, परियोजनाओं की बारीकियों आदि पर निर्माण करने की आवश्यकता होती है।
हमारे विभाग का प्रारंभिक डेटा: एक छोटा (5-10 लोग), आंशिक रूप से वितरित (कुछ कर्मचारी दूरस्थ रूप से काम करते हैं, कुछ कार्यालय में) उत्पाद टीम कंपनी के अंदर ग्राहकों के साथ। वेब प्रोजेक्ट। विभाग के भीतर कोई सिस्टम एडमिनिस्ट्रेशन विशेषज्ञ नहीं हैं, लेकिन कंपनी में शामिल विभाग हैं।
टीम संचार
आइए विभाग के भीतर प्रभावी संचार का निर्माण शुरू करें। किसी भी टीम में, प्रभावी चैनलों और संचार के तरीकों का निर्माण करना महत्वपूर्ण है, लेकिन जब टीम वितरित हो जाती है, तो इसकी आवश्यकता तेज हो जाती है। यह अपनी अधिकतम तीव्रता तक पहुँच गया क्योंकि टीम केवल आंशिक रूप से वितरित की गई थी। हमें कार्यालय और दूरदराज के कर्मचारियों की दुनिया में विलय करना सीखना था।
हमने जो सबसे महत्वपूर्ण मुद्दा उठाया है, वह मौखिक चर्चा है। कार्यालय के कर्मचारियों को हमेशा एक कप कॉफी पैक करने और परियोजना की स्थिति पर चर्चा करने का प्रलोभन होता है। हालाँकि, इस मामले में, दूरस्थ कार्यकर्ता इस चर्चा में भाग नहीं ले पाएंगे, इसलिए, वे अपने विचारों में योगदान नहीं दे पाएंगे, और वास्तव में उन्हें पता नहीं चलेगा कि कुछ हो रहा है। एक नियम के रूप में, यह टीम के कार्यों के एक वंशानुक्रम में परिणाम करता है, टीम के वितरित हिस्से से नए विचारों और सुझावों के उद्भव के कारण बार-बार चर्चा और बस एक अप्रिय aftertaste।
यह स्पष्ट हो गया कि कुछ महत्वपूर्ण सामान्य बातों पर सामान्य चैट में या कुछ समूह कॉल पर लिखित रूप से चर्चा की जानी चाहिए।
यह एक और बहुत ही सामान्य समस्या को जन्म देता है जो टीमों में दिखाई देती है जहां आपको बहुत कुछ लिखने की आवश्यकता होती है - लेखन की संस्कृति की समस्या। आप सिर्फ एक सहयोगी के पास नहीं जा सकते, अपनी आस्तीन खींच सकते हैं, नैपकिन पर कुछ खींच सकते हैं और अपनी कहानी में इशारों को जोड़ सकते हैं। एक तरफ, यह काम को जटिल बनाता है, और दूसरी तरफ, लोग अपने विचारों को समझने योग्य, संरचित तरीके से लिखने का कौशल विकसित करते हैं। इस दृष्टिकोण के परिणामस्वरूप, प्रलेखन बेहतर औपचारिक रूप से शुरू हुआ, कार्यों को अधिक स्पष्ट रूप से तैयार किया जाना शुरू हुआ, हर कोई इस बारे में सोचने लगा कि अपने विचारों को इस तरह से कैसे प्रस्तुत किया जाए कि वे पहले पढ़ने से दूसरों के लिए स्पष्ट थे।
उपरोक्त सभी का मतलब यह नहीं है कि हमने व्यक्तिगत संचार, आवाज और वीडियो कॉल को पूरी तरह से त्याग दिया। हालाँकि, हमने यह नियम बना दिया कि इस तरह के विचार-विमर्श के परिणामों को लिखित रूप में दर्ज किया जाना चाहिए, ज्ञान की एक तरह की कलाकृतियों के रूप में, हमेशा सभी के लिए उपलब्ध है।
संक्षेप में उन औजारों की सूची को देखें, जिनके साथ हमने टीम के भीतर अपने संचार कार्यों को हल किया था।
सबसे पहले, हमने टेलीग्राम पर एक चैट शुरू की। लेकिन फिर, टीम की वृद्धि के संबंध में, हमने महसूस किया कि एक चैट में हम पहले से ही करीब थे, और स्लैक में बदल गए। वहां हमने सामान्य प्रवाह को विषयगत चैनलों में विभाजित किया और स्पष्ट नियम निर्धारित किए - किन कारणों से किस चैनल को लिखना है। इससे उपयोगी जानकारी और बाढ़ को मिलाने से बचने में मदद मिली।
इसके अलावा, स्लैक में जाने से हमें स्वचालन और एकीकरण के लिए कुछ अच्छे अवसर मिले, जैसे कि रिपॉजिटरी मैनेजमेंट सिस्टम या बग ट्रैकर।
- ऑडियो और वीडियो कॉल - Skype for Business।
- हम जीरा में कार्य करते हैं।
- ज्ञान का आधार Confluence में संग्रहीत है।
कार्य योजना, निष्पादन और नियंत्रण
जब हमने संचार का निर्माण किया, टीम के भीतर कार्यों को स्थापित करने, नियंत्रित करने और पूरा करने की समस्या प्रासंगिक हो गई (मैं इस संबंध में थोड़ी देर बाद ग्राहक के साथ काम करने के बारे में बात करूंगा)।
हमारे पास कार्यों की एक सूची नहीं थी, उनकी प्राथमिकताएं, तत्परता की स्थिति, आदि के बजाय एक स्पष्ट, पारदर्शी और पारगम्य योजना, सहज अल्पकालिक योजना और निष्पादन मौजूद था।
इस स्थिति से निपटने के लिए, हमने एक बगट्रैक्टर का उपयोग करना शुरू कर दिया (वास्तव में, हमने उनमें से पांच की कोशिश की)। परियोजना की सामान्य दिशा की रूपरेखाएँ दिखाई देने लगीं, राज्य की एक समझ जिसमें कुछ कार्य और समग्र चित्र समग्र रूप में दिखाई दिए। हालांकि, हमें बगट्रैकर का उपयोग करते समय अनुशासन की कमी की समस्या का सामना करना पड़ा, जिसने हमारे कई प्रयासों का अवमूल्यन करना शुरू कर दिया। सभी कार्यों को बगट्रैकर में शुरू नहीं किया गया था, मौजूदा वाले हमेशा अपडेट नहीं किए गए थे, आदि। सीधे शब्दों में कहें, परियोजना की स्थिति की तस्वीर प्रासंगिक और विश्वसनीय नहीं रह गई है।
इससे निपटने के लिए, हमने कार्य प्रबंधन की अपनी संस्कृति विकसित और कार्यान्वित की है:
- जब तक संबंधित कार्य शुरू नहीं किया जाता है तब तक कार्य नहीं किया जाना चाहिए। यह परियोजना के इतिहास और टीम के काम की तारीख तक बनाए रखने में मदद करता है।
- किसी कार्य के साथ काम करते समय, इसकी स्थिति को समय पर बदलना आवश्यक है। हमारे मामले में, चार स्थितियां पर्याप्त हैं: "करने के लिए" - कार्य की शुरुआत की स्थिति, "प्रगति में" - वह कार्य जो प्रगति पर है, "होल्ड पर" - वे कार्य जो उन्होंने प्रदर्शन करना शुरू किया था, लेकिन काम निलंबित है (हम कुछ अतिरिक्त जानकारी की प्रतीक्षा कर रहे हैं) ), "हो गया" - कार्य तैयार है। टीम के भीतर ग्राहक या प्रबंधक द्वारा कार्य की तत्परता की पुष्टि की जानी चाहिए।
- समय के साथ, कार्यों और परियोजनाओं की संख्या में काफी वृद्धि हुई है, इसलिए हमने कार्यों की सामान्य सूची को अलग उपप्रोजेक्टों में विभाजित किया है, और इस उपप्रोजेक्ट की सूची के अनुसार कार्य शुरू किया जाना चाहिए।
- कार्य को प्राथमिकता दी जानी चाहिए। यह समझने में मदद करता है कि परियोजना को अधिकतम लाभ पहुंचाने के लिए किन कार्यों को किस क्रम में किया जाना आवश्यक है।
- समय-समय पर कार्यों और उनकी प्राथमिकताओं की समीक्षा की। चूंकि परियोजनाएं रहती हैं और विकसित होती हैं, और व्यापार की योजनाएं कभी-कभी बदलती हैं, समय के साथ, कुछ कार्य कम या अधिक प्रासंगिक हो जाते हैं या यहां तक कि उन्हें हटाने की आवश्यकता होती है।
- कार्यों पर कुछ प्रमुख चर्चाएँ जो मौखिक रूप से या चैट में लिखी गई थीं, उन्हें कार्य में अंतिम समाधान को ठीक करने की आवश्यकता होती है, ताकि जब हम इसे पूरा करें तो हम हमेशा इसके और इसके इतिहास के बारे में सबसे अधिक प्रासंगिक जानकारी देखें। अक्सर ऐसा होता है कि चर्चाओं की एक श्रृंखला के बाद समस्या का प्रारंभिक विवरण कुछ पूरी तरह से अलग हो जाता है, और हमें इसकी निगरानी करने की आवश्यकता है।
- यदि कार्य टीम के भीतर विशेषज्ञों के एक समूह से दूसरे में स्थानांतरित किया जाता है, तो स्थानांतरित समूह को इसमें ज्ञान के सभी आवश्यक कलाकृतियों को ठीक करना होगा जो अगले समूह को स्थानांतरित करना होगा। उदाहरण के लिए, एक डिजाइन टीम को मॉक-अप और विकास के लिए आवश्यक सभी दस्तावेज संलग्न करना चाहिए ताकि विकास टीम को कार्य स्थानांतरित किया जा सके। यह अनावश्यक प्रश्नों, विकर्षणों और संदर्भ स्विच से बचा जाता है।
- कार्यों के लिए संलग्न करना। नामकरण के लिए कुछ नियमों का उपयोग करते हुए, हम स्वचालित रूप से गिटलैब कार्यों के लिए लिंक संलग्न करते हैं। यह विकास को समझने में बहुत मदद करता है कि किसने, क्या, कैसे और कब यह कार्य किया। और विपरीत दिशा में, सही ढंग से नाम से आप हमेशा किए गए परिवर्तनों के कारण युक्त कार्य पा सकते हैं।
ग्राहक संचार
कठिनाइयों की अगली श्रेणी जो हमें हल करने की आवश्यकता थी वह ग्राहकों के साथ काम कर रही थी। पहली चीज जिसे हमें मिटाना था वह शब्दों में शब्द सेट कर रहा था। यदि हमने विभाग के भीतर लेखन की संस्कृति को पेश किया है, तो समय आ गया है कि इसे बाहरी संपर्कों तक बढ़ाया जाए।
यह कोई रहस्य नहीं है कि एक और प्रबंधक डेवलपर से संपर्क करना पसंद करता है, शब्दों में उसे बताएं कि क्या किया जाना चाहिए, दृढ़ता और छुट्टी के लिए स्क्रीन पर उंगलियों को पोक करें, उम्मीद है कि सबकुछ अच्छा और समय पर किया जाएगा। इस स्थिति में, प्रबंधक और डेवलपर को उत्पाद स्वामी और विकास टीम के एक निश्चित प्रबंधक द्वारा प्रतिस्थापित किया जा सकता है जो इन सभी कार्यों का नेतृत्व करता है। इसका नतीजा नहीं बदलेगा।
इस दृष्टिकोण के साथ कई समस्याएं हैं:
- शब्दों और इशारों में जो कहा जाता है वह कल के बारे में (कम से कम आंशिक रूप से) भूल जाएगा, सबसे अच्छा, कल के बाद का दिन। यह कुछ छोटी चीजों के बारे में इतना नहीं है, लेकिन कार्य के बारे में पूरी तरह से भूल जाने के खतरे के बारे में है। उसी समय, किसी भी तरह से यह पुष्टि करना असंभव है कि आप इसे किसी को देते हैं या किसी ने आपको कम से कम कुछ करने का वादा किया है।
- आमतौर पर, समस्या का ऐसा बयान बल्कि अराजक है, और इसमें कोई गहन विवरण नहीं हैं। नतीजतन, लापता जानकारी को स्पष्ट करना बहुत मुश्किल है।
- जैसा कि पहले चर्चा की गई है, शब्दों में समस्या का बयान उनके विचारों को लिखित रूप में तैयार करने के लिए सीखने की भ्रष्टता को बढ़ाता है ताकि अन्य लोग समझ सकें।
जब आपके पास कई ग्राहक होते हैं, और प्रत्येक की अपनी विशेषताएं होती हैं, तो सभी के साथ काम का एक ही क्रम बनाना मुश्किल होता है। आदर्श रूप से, हम सभी ग्राहकों को बग ट्रैकर में लाना चाहते हैं, जहाँ वे कार्य निर्धारित कर सकते हैं, प्राथमिकताएँ निर्धारित कर सकते हैं, विवरणों पर चर्चा कर सकते हैं, कार्य स्वीकार कर सकते हैं। लेकिन यह एक असंभव काम है। हालांकि, हम एक समझौता खोजने में सक्षम थे जिसमें कार्य हमारे कॉर्पोरेट मेल विभाग में कड़ाई से लिखित प्रवाह में एक साथ प्रवाहित होते हैं, और हमारी ओर से प्रबंधक हमारे देश में पहले से ही स्थापित नियमों के अनुसार बग ट्रैकर में शुरू होता है और उन्हें आगे बढ़ाता है। आवश्यक विशेषज्ञों की अपूर्ण रचना द्वारा चर्चा किए गए विशिष्ट लोगों के दिमाग में खोए, भुलाए, संग्रहीत किए जाने वाले कार्य समाप्त हो गए।
अगला, हमने एक और महत्वपूर्ण समस्या का सामना किया: ग्राहक के लिए एक कार्य तैयार करना मुश्किल है। तकनीकी टीम के लिए तकनीकी विशिष्टताओं के निर्माण में ग्राहक हमेशा पर्याप्त रूप से सक्षम (या लगभग हमेशा अपर्याप्त रूप से सक्षम) नहीं होता है। और यह सामान्य है। मानव कारक को नजरअंदाज नहीं किया जा सकता है: यह ग्राहक के लिए शर्मिंदा और असहज होने के लिए एक अनुरोध के साथ टीम में आ सकता है जब वह खुद अभी तक इसे पूरी तरह से तैयार नहीं कर पाया है। एक परिपक्व पेशेवर टीम के मानदंडों में से एक ग्राहक को उसकी समस्याओं, आवश्यकताओं और समाधानों की पहचान करने में मदद करने की क्षमता है।
अक्सर ऐसा होता है कि ग्राहक एक समस्या के साथ आने के बजाय, एक समाधान के कार्यान्वयन के लिए एक अनुरोध के साथ आता है जिसे उसने पहले ही आविष्कार किया है। "नैपकिन पर" तैयार किए गए ToR पर काम के परिणामों के साथ या तो खुद को या ग्राहक को आश्चर्यचकित नहीं करने के लिए, हमने ग्राहक के लिए सवालों की एक मूल सूची बनाई। पहले से ही इन उत्तरों के आधार पर, ग्राहक के लिए यह समझना आसान है कि वह वास्तव में क्या चाहता है और विकास टीम को इसकी आवश्यकता है। और फिर आवश्यकताओं को स्पष्ट करने या पहचानने के लिए कुछ विचारोत्तेजक प्रश्न पूछने की बारी है।
इसलिए, ग्राहक के साथ पहली बैठक से पहले, हम आपको पूर्व-भरण (जितना संभव हो) करने के लिए कहते हैं और हमें इस चेकलिस्ट को भेजते हैं ताकि बाद में आपको उसी प्रश्नों पर समय बर्बाद न करना पड़े, लेकिन तुरंत एक फलदायक संवाद शुरू करें। यह ध्यान देने योग्य है कि ग्राहक के साथ बातचीत करते समय, न केवल उन उत्तरों को स्पष्ट करना महत्वपूर्ण है जो उन्होंने प्रदान किए हैं, बल्कि उनकी बताई गई समस्या के आधार पर उन्हें उन आवश्यकताओं की पहचान करने में मदद करने के लिए भी जिनके बारे में उन्होंने सोचा नहीं था।
ग्राहक के लिए प्रश्नों की सूची:
- परियोजना का उद्देश्य क्या है? इससे क्या समस्या हल होती है? यह किस व्यावसायिक मूल्य पर चलता है?
- क्या इस समस्या का एकमात्र संभव समाधान है? यदि नहीं, तो अन्य विकल्प क्या हैं?
- क्या कोई सामान्य आवश्यकताएं हैं जो पूरी परियोजना से गुजरती हैं? उदाहरण के लिए, यदि यह एक ऑनलाइन स्टोर है, तो इसे ऑनलाइन ट्रेडिंग को नियंत्रित करने वाले कानून का पूरी तरह से पालन करना चाहिए।
- क्या कोई कार्यात्मक आवश्यकताएं हैं? एक अनुभाग (पृष्ठ, परियोजना) क्या करना चाहिए? उदाहरण के लिए, अनुभाग को कंपनी के उत्पादों के बारे में जानकारी प्रदान करनी चाहिए और पेज पर दिए गए फॉर्म के माध्यम से इस उत्पाद के बारे में सवाल पूछने या इसे हासिल करने के इच्छुक लोगों को इकट्ठा करना चाहिए।
- क्या गैर-कार्यात्मक आवश्यकताएं हैं? उसे यह कैसे करना चाहिए? उदाहरण के लिए, पृष्ठ खोलने का समय 5 सेकंड से अधिक नहीं होना चाहिए।
- अतिरिक्त आवश्यकताएं। नि: शुल्क प्रारूप जिसमें आप आत्मा डाल सकते हैं।
एक और समस्या जिसका हमें सामना करना पड़ा: एक साथ सभी पक्षों से आने वाले कार्य। जब विभिन्न परियोजनाओं पर कई ग्राहक होते हैं, तो हर कोई अपने काम को सर्वोच्च प्राथमिकता देना चाहता है। सामान्य आदर्श मामले में, शायद, ऐसी समस्या को 100% हल नहीं किया जा सकता है। हम इसके साथ कैसे रहते हैं? कार्यों के निर्माण और प्रबंधन में, साथ ही साथ फुर्तीली कार्यप्रणाली के कुछ तत्वों में अनुशासन की शुरुआत के साथ, हमारा कार्य पूल अधिक सुव्यवस्थित, बाहरी पर्यवेक्षक के लिए पारदर्शी और सबसे महत्वपूर्ण, पूर्वानुमेय हो गया है। हमने अपनी टीम के भीतर आदेश और योजनाएं स्थापित की हैं, और हमें केवल ग्राहकों के साथ प्रतिक्रिया को मजबूत करने की आवश्यकता है। प्राथमिकताओं, समयसीमाओं और योजनाओं पर चर्चा करने में, हमने सीखा कि कैसे एक तर्कपूर्ण संवाद का निर्माण किया जाए, बजाय इसके कि वह कामों में आँख बंद करके लगातार धधकती हुई आग को बुझाए (जो वास्तव में हमेशा प्रासंगिक नहीं होती हैं और हमेशा नहीं होती हैं)।
साथ ही, इस पैराग्राफ के भाग के रूप में, हमने क्लासिकल एंटीपैटर्न "गूल मैनेजमेंट" को मिटाने की कोशिश की, जब ग्राहक या प्रबंधक ने "कार्य" किया, - और पूरे विश्वास के साथ उड़ान भरी कि एक बार जब वह कार्य सेट कर लेता है, तो उसे निश्चित रूप से एक उत्कृष्ट परिणाम मिलेगा। जैसा कि अभ्यास ने दिखाया है, इस दृष्टिकोण के साथ परिणाम सबसे प्रभावशाली नहीं था। इससे कैसे निपटें? यहां भी, कोई सार्वभौमिक सलाह नहीं है, कोई जादू वाक्यांश नहीं है जो लोगों के व्यवहार को बदलता है। ऐसा करने के लिए, आपको बात करने, शिक्षित करने, समझाने, दिखाने की आवश्यकता है, आप शिक्षित कह सकते हैं। केवल शैक्षिक कार्य और बहुत दृश्य या बहुत औसत दर्जे का (और अधिमानतः दोनों) सकारात्मक और नकारात्मक उदाहरण पर्याप्त रूप से "सीगल प्रबंधन" को दूर करने में मदद करेंगे।
देव बनाम ऑप्स
और हमारा अंतिम महत्वपूर्ण मुद्दा देव और ऑप्स विभागों के बीच संचार समस्या है।
हमें एक क्लासिक स्थिति का सामना करना पड़ता है जहां डेवलपर्स बहुत अच्छी तरह से नहीं समझते हैं कि सर्वर कैसे काम करता है, और एक तृतीय-पक्ष व्यवस्थापक टीम वास्तव में यह नहीं समझती है कि आवेदन कैसे काम करता है। इन दो क्षेत्रों के जंक्शन पर प्रत्येक कठिनाई हमें दर्द और बहुत समय के साथ दी गई थी। समस्या के किस पक्ष का भी निदान करना मुश्किल था:
- आप इसे वहाँ क्रमादेशित!
- नहीं, वहां आपके पास सर्वर के साथ कुछ है!
इस मामले में, इसने हमारी मदद की कि एक डेवलपर टीम में दिखाई दिया जो प्रशासन में अच्छी तरह से वाकिफ था। वह अपनी भाषा में प्रत्येक समूह के साथ बात करने और दोनों ओर से हर समस्या का निदान करने में सक्षम था। विसंगतियां कम होने लगीं, लेकिन हम इस आदमी से बंधे रहे। इन सभी समस्याओं को खुद से दूर करने के लिए, उन्होंने प्रशासकों को यह समझने में मदद करना शुरू कर दिया कि एप्लिकेशन कैसे काम करता है, और प्रोग्रामर - सर्वर पर क्या हो रहा है। हम वॉइस राइटिंग डॉक्यूमेंटेशन के स्पष्टीकरण में जोड़ते हैं और न केवल पूरी टीम का ज्ञान प्राप्त करते हैं, बल्कि देव और ऑप्स विभागों के अधिक समन्वित कार्य भी करते हैं। हां, खूनी उद्यम के बड़े हिस्से में विशेष टीम और योग्य लोग हैं जो सब कुछ सेट कर देंगे ताकि डेवलपर्स को यह भी पता न चले कि सर्वर पर उनका काम कैसे और कहां काम करता है। हालांकि, छोटी टीमों में लोगों में इस स्तर की क्षमता विकसित करना अच्छा होगा, साथ ही कम से कम एक कर्मचारी होगा जो पहले से ही इस संबंध में अच्छी तरह से विकसित है।
डिज़ाइन
इन सभी के समानांतर, हमने एक विकास संस्कृति का विकास किया।
मैं तकनीकी हिस्से पर ध्यान केंद्रित नहीं करूंगा, और अब यह पहले से ही एक वास्तविक मानक है और लगभग सभी को इस बात की समझ नहीं है कि संस्करण नियंत्रण प्रणाली, सीआई / सीडी, और अन्य विकास, विधानसभा और तैनाती उपकरणों की कितनी आवश्यकता है। मैं विकास के नरम पलों पर बसूंगा।
- Codestyle। कोड डिजाइन के नियमों को विकसित करना और स्पष्ट रूप से अनुमोदित करना काफी महत्वपूर्ण है। सबसे पहले, यह विभिन्न शैलियों और मानकों के एक चिड़ियाघर के बजाय, परियोजना में एक सामंजस्यपूर्ण रूप देखने के लिए सौंदर्यवादी रूप से प्रसन्न है। दूसरे, यह कोड की पठनीयता को बढ़ाता है, और जैसा कि हम जानते हैं, ज्यादातर समय प्रोग्रामर अपना कोड नहीं लिखता है, लेकिन किसी और का पढ़ता है।
- नामकरण करता है । हमने नामकरण के लिए कुछ नियमों को पेश किया, ताकि प्रतिबद्ध के नाम से यह स्पष्ट हो सके कि क्या बदलाव किए गए, किसके द्वारा, और किस कार्य के लिए।
- कोड की समीक्षा । हमारी परियोजनाओं और टीम की बारीकियां ऐसी हैं कि हमारे पास कुछ अनिवार्य कोड की समीक्षा नहीं है, जिसके बिना हमारे कोड को उत्पादन में डालना असंभव है। हालाँकि, हमने यह नियम बनाया कि कम से कम एक व्यक्ति उस कोड को देखता है जिसे एक सहयोगी धक्का दे रहा है। यह किसी भी कमियों को नोटिस करने, वैकल्पिक विचारों को पेश करने, और सिस्टम के सभी हिस्सों के बराबर रहने में मदद करता है। कोड की समीक्षा परियोजनाओं की बढ़ती संख्या और जटिलता के साथ विशेष रूप से प्रासंगिक हो गई है, यही वजह है कि प्रत्येक डेवलपर को अब सभी परियोजनाओं पर काम करने का समय नहीं है, जो उनके सभी विवरणों को समझने के लिए पर्याप्त हैं।
- टीम के भीतर स्थापत्य कला को संरेखित करना । , , - , , , . , . . .
- CV Driven Development . , (, , ) , . , , , . : , , ( , , ) LinkedIn, .
,
हमारा विभाग आउटसोर्सरों द्वारा बनाई गई परियोजनाओं के मौजूदा बेड़े के आसपास बनना शुरू हुआ। स्वाभाविक रूप से, वहाँ कोई दस्तावेज नहीं था, किसी ने भी कोड की प्रासंगिकता और गुणवत्ता का पालन नहीं किया। चूँकि हम समझते थे कि हमें अभी भी इसके साथ काम करना है, इसे बनाए रखना है और लंबे समय तक विकसित करना है, इसलिए परियोजना में चीजों को लगाने के लिए समय का कुछ हिस्सा समर्पित करने का निर्णय लिया गया - रिफ्लेक्टरिंग, अप्रासंगिक कोड हटाना आदि।चूंकि यह परियोजना बड़ी थी, इसलिए इसमें एन्ट्रापी का स्तर भी अधिक था। हमने महसूस किया कि एक में बैठने से शारीरिक रूप से सब कुछ दूर करना असंभव है, और इस तरह के भारी काम की संभावना को नैतिक रूप से छोड़ देना चाहिए। हमने निरंतर सुधार "काइज़ेन" के जापानी सिद्धांत को लागू करने का निर्णय लिया। हमने तकनीकी ऋण को कई छोटे भागों में विभाजित किया है और बहुत कम से कम, लेकिन नियमित रूप से इन छोटे भागों को बंद कर दिया है, दोनों परियोजनाओं और टीम के काम को लगातार संशोधित करना और सुधारना। नैतिक रूप से, इससे कोई असुविधा नहीं हुई, लेकिन साथ ही साथ यह नई कार्यक्षमता के विकास और व्यावसायिक आवश्यकताओं के कवरेज पर महत्वपूर्ण प्रभाव नहीं पड़ा। डेढ़ साल बाद, हमने पाया कि पुराने तकनीकी ऋण को पूरी तरह से चुका दिया गया था, और इसने हमारे लिए एक मौलिक रूप से नए स्तर की जटिलता और महत्व की कार्यक्षमता विकसित करने के अवसर खोले।बेशक, इसका मतलब यह नहीं है कि अब हमारे पास कोई तकनीकी ऋण नहीं है। जैसे-जैसे परियोजनाएं जीवंत होती हैं, विकसित होती हैं, विकसित होती हैं और विकसित होती हैं, यह निश्चित रूप से निर्मित होती है। हालांकि, हम इसे सावधानीपूर्वक मॉनिटर करते हैं, इसे कार्यों के एक विशेष पूल में डालते हैं, और नियमित रूप से इसे भुगतान करने के लिए कुछ समय समर्पित करते हैं। तकनीकी ऋण के साथ इस तरह के निरंतर काम हमें पुराने के लिए नई कार्यक्षमता और उच्च-गुणवत्ता वाले समर्थन के विकास के बीच संतुलन खोजने की अनुमति देते हैं।हमारे मामले में, हम, डेवलपर्स, तकनीकी ऋण का भुगतान करने के महत्व को समझाने और दिखाने में सक्षम थे। हमने यह कैसे किया? व्यवहार में, हमने ऐसी स्थितियों का प्रदर्शन किया है, जिसमें यदि आप वर्तमान परियोजना में कुछ अन्य संरचनात्मक परिवर्तन नहीं करते हैं या करते हैं, तो नई कार्यक्षमता विकसित करना या पुराने को बदलना सिद्धांत (या संभव है, लेकिन कई बार धीमा) में असंभव होगा।चुस्त तरीके लागू करें
चंचल कार्यप्रणाली के कुछ विचारों के कार्यान्वयन ने हमें टीम के भीतर और व्यवसाय के लिए अपने काम की पारदर्शिता को बढ़ाने की अनुमति दी, जिससे विकास अधिक पूर्वानुमान और लचीला हो, और परिणाम अधिक स्थिर हो।हमने जो पहला काम किया, वह टीम के भीतर दैनिक स्टैंड-अप का आयोजन था। चूंकि टीम वितरित की गई है, इसलिए स्लैक ने इसके लिए एक अलग चैनल सौंपा, जिसमें प्रत्येक कर्मचारी प्रत्येक सुबह तीन बिंदुओं को लिखता है: कल उसने किन कार्यों में काम किया, आज वह क्या काम करना चाहता है, क्या कोई समस्या है जो उसके काम को बाधित करती है। इस चैनल में बाढ़, किसी के कार्यों या समस्याओं पर चर्चा करना निषिद्ध है। यह चैनल मामलों की स्थिति पर जानकारी एकत्र करने के लिए सख्ती से है। शेष चर्चा उपयुक्त विषयगत चैनलों में आयोजित की जानी चाहिए। इसने टीम के प्रत्येक व्यक्ति को यह समझने की अनुमति दी कि उसके सहकर्मी क्या कर रहे हैं, सामान्य रूप से इस परियोजना के साथ क्या हो रहा है, किसकी मदद की जानी चाहिए। यदि स्टैंड-अप के बिना समस्याओं को हल किया गया था, और लंबे समय के बाद अचानक यह पता चला कि कार्य अभी तक तैयार नहीं था, अब यह स्पष्ट है कि किसे मदद की आवश्यकता है,टीम को और अधिक प्रभावी बनाने के लिए क्या किया जाना चाहिए।अगला, हमने स्प्रिंट विकसित करने का निर्णय लिया। प्रत्येक शुक्रवार को दिन के अंत में, हम एक स्प्रिंट रेट्रोस्पेक्टिव का संचालन करते हैं, यह देखें कि कार्यों की योजना क्या थी, क्या तैयार है, क्या तैयार नहीं है, और अगर कुछ तैयार नहीं है, तो ऐसा क्यों हुआ। हम सोचते हैं कि भविष्य में इसी तरह की कठिनाइयों से बचने के लिए हमारे पास क्या समस्याएं थीं और हम क्या कर सकते हैं। फिर हम टीम और व्यावसायिक प्राथमिकताओं के भीतर विभिन्न क्षेत्रों के कार्यभार के आधार पर अगले सप्ताह के लिए स्प्रिंट की योजना बनाते हैं। नतीजतन, सप्ताह की शुरुआत में, सभी डेवलपर्स जानते हैं कि क्या करना है और किस क्रम में है, और व्यवसाय को पता है कि निकट भविष्य में इसकी जरूरतों को क्या कवर किया जाएगा, और अगले स्प्रिंट के लिए पहले से ही अपनी "विशलिस्ट" बना सकते हैं। यह कहने योग्य है कि हम अचानक उन कार्यों से नहीं बचे हैं जो हमारी स्प्रिंट योजनाओं को बाधित कर सकते हैं।इस मामले में, आपको कार्य की विशिष्ट प्रकृति के आधार पर कार्य करने की आवश्यकता है: ऐसे कार्य कितनी बार उठते हैं? कितना? क्या इसकी भविष्यवाणी की जा सकती है? विकास में हमारे विशिष्ट मामले में, हमने प्रयोगात्मक रूप से गणना की कि अनियोजित कार्यों पर औसतन कितना समय लगता है और स्प्रिंट में इस मार्जिन को रखने की कोशिश करें। अलग-अलग, यह ध्यान देने योग्य है कि स्प्रिंट पर काम शुरू होने के बाद, हम विशेष रूप से यह पता लगाने में सक्षम थे कि एक अनशेड्ड एंट्रेंस पर हमें कितना काम दिया जाता है, इस राशि का विश्लेषण करें और इसे कम करें, ग्राहक के साथ प्राथमिकताओं पर ध्यानपूर्वक चर्चा करें और स्पष्ट रूप से सबसे आवश्यक सुविधा प्राप्त करने की क्षणिक इच्छा अभी कैसे प्रभावित करती है। पूरी टीम की कुल उत्पादकता पर।अनियोजित कार्यों के लिए औसत समय क्या है और स्प्रिंट में इस मार्जिन को रखने की कोशिश करें। अलग-अलग, यह ध्यान देने योग्य है कि स्प्रिंट पर काम शुरू करने के बाद, हम विशेष रूप से यह पता लगाने में सक्षम थे कि एक अनिर्धारित प्रवेश पर हमें कितना काम दिया जाता है, इस राशि का विश्लेषण करें और कम करें, ग्राहक के साथ प्राथमिकताओं पर सावधानीपूर्वक चर्चा करें और स्पष्ट रूप से दिखाएं कि सबसे आवश्यक सुविधा प्राप्त करने की क्षणिक इच्छा अभी कैसे प्रभावित करती है। पूरी टीम की कुल उत्पादकता पर।अनियोजित कार्यों के लिए औसत समय क्या है और स्प्रिंट में इस मार्जिन को रखने की कोशिश करें। अलग-अलग, यह ध्यान देने योग्य है कि स्प्रिंट पर काम शुरू करने के बाद, हम विशेष रूप से यह पता लगाने में सक्षम थे कि एक अनिर्धारित प्रवेश पर हमें कितना काम दिया जाता है, इस राशि का विश्लेषण करें और कम करें, ग्राहक के साथ प्राथमिकताओं पर सावधानीपूर्वक चर्चा करें और स्पष्ट रूप से दिखाएं कि सबसे आवश्यक सुविधा प्राप्त करने की क्षणिक इच्छा अभी कैसे प्रभावित करती है। पूरी टीम की कुल उत्पादकता पर।एक अनावश्यक सुविधा प्राप्त करने की क्षणिक इच्छा अब पूरी टीम की कुल उत्पादकता को कैसे प्रभावित करती है।एक अनावश्यक सुविधा प्राप्त करने की क्षणिक इच्छा अब पूरी टीम की कुल उत्पादकता को कैसे प्रभावित करती है।हम भी लंबे समय से रिलीज से कम लोगों के लिए चले गए। पहले, हमें टीके प्राप्त हुए, सप्ताह या महीनों ने पूरी तरह से सुविधाओं का पैक किया, और उसके बाद ही ग्राहक को दिखाया। नतीजतन, यह अक्सर पता चला कि ग्राहक ने या तो अपना मन बदल दिया या काफी उम्मीद नहीं की थी, और हम सभी या जो हमने पहले से ही किया था उसका कुछ भाग फिर से शुरू कर दिया। और सुविधाओं के लिए तैयार बड़े सेट में बदलाव करना एक संदिग्ध खुशी है। अब हम हर सुविधा को जल्द से जल्द प्रदर्शित कर रहे हैं ताकि ग्राहक एक निर्णय ले सके - क्या यह वही है जो वह वास्तव में चाहता था, या कुछ बदलने की आवश्यकता है। तेजी से वह या तो मंजूरी देता है या संशोधन के लिए भेजता है, कम श्रम हम निवेश करेंगे, इसलिए, तेजी से सुविधा उत्पादन में आ जाएगी। परिणामस्वरूप, उत्पादन में तेजी से विशेषताएं आने लगीं, परिकल्पनाओं का तेजी से परीक्षण किया गया और परियोजना तेजी से आगे बढ़ी।बस कारक
चूंकि हमारी टीम छोटी है, इसलिए हमने तुरंत उन समस्याओं के बारे में सोचना शुरू कर दिया, जो कर्मियों के रोटेशन के दौरान हमारे सामने आ सकती हैं। विशिष्ट लोग कुछ ज्ञान के एकमात्र संरक्षक बन गए हैं, परियोजनाओं का पर्याप्त विस्तार हुआ है, और इसलिए हमने ज्ञान भंडारण और प्रबंधन की संस्कृति विकसित करना शुरू किया।इस समस्या के उन्मूलन में ज्ञान संबंधी कलाकृतियों के संचय की मदद की गई जो विशिष्ट लोगों के सिर से भौतिक दुनिया में चली गई। अर्थात्:- बगट्रैकर में कोई कार्य होने पर ही सभी कार्य किए जाते हैं। यह आपको परियोजना में परिवर्तनों का पूरा इतिहास बनाने की अनुमति देता है।
- अगर कहीं चैट में या रैली में हमने कार्य में परिवर्तन पर चर्चा की, तो हमें इस चर्चा के परिणाम में कार्य को प्रतिबिंबित करना चाहिए।
- . , Gitlab. , .
- Confluence , - , .
- - postmortem « — — — ».
अभी भी अच्छा अभ्यास है, जिसमें, निश्चित रूप से, आपको माप को जानने की जरूरत है और इसे पूर्णता तक नहीं बढ़ाएं: यदि आपको सिस्टम के कुछ हिस्से के बारे में पूछा जाता है, जिसके बारे में आप केवल जानते हैं, तो इसके बारे में दस्तावेज लिखना और इसके लिंक के साथ जवाब देना उचित है। इसलिए आपको इस प्रश्न का उत्तर फिर से कभी नहीं देना होगा, और अन्य लोगों से पूछें।ज्ञान की कलाकृतियों को बनाए रखने की इस पद्धति ने हमें परियोजना के उन हिस्सों के बारे में जानकारी प्राप्त करने में बार-बार मदद की है जो अन्यथा आवश्यक रूप से खो जाएंगे। और उन्होंने कर्मियों के रोटेशन के दौरान परियोजना और टीम के लिए जोखिम को काफी कम कर दिया। अंतिम उदाहरण: हमने व्यावसायिक तर्क, ऑपरेशन के सिद्धांत और उपकरण को तैनात करने की विधि के बारे में जल्दी और आसानी से जानकारी प्राप्त की, जो उस कर्मचारी द्वारा किया गया था जिसने दो साल पहले छोड़ दिया था।यदि हम इस तकनीक के लिए स्टैंड-अप और स्प्रिंट के साथ काम लागू करते हैं, तो बस कारक और भी कम हो जाता है। बहुत पहले नहीं, हमने एक प्रयोग किया: एक डेवलपर छुट्टी पर था, और दूसरे डेवलपर ने काम किया। उस समय, जब पहली छुट्टी पर गया, दूसरा छुट्टी पर गया। प्रयोग का सार किसी भी व्याख्यात्मक पत्र, संदेश को लिखना नहीं था, मामले को सौंपने के लिए नहीं था और यह देखने के लिए कि एक व्यक्ति को लंबी छुट्टी के बाद यह समझना कितना मुश्किल होगा कि उसकी अनुपस्थिति में क्या हो रहा था, क्या बदल गया, वास्तव में भविष्य के लिए कैसे और क्या योजना है। जैसा कि प्रैक्टिस ने दिखाया है, बगट्रक्टर, कमिट्स, डॉक्यूमेंटेशन, स्टैंड-अप्स और स्प्रिंट्स को देखते हुए कर्मचारी को व्यवसाय के पाठ्यक्रम में काफी आसानी से प्रवेश करने और अपने काम को स्वायत्तता से जारी रखने की अनुमति मिलती है।निष्कर्ष
अंत में, मैं यह नोट करना चाहूंगा कि उपरोक्त समस्याओं में से कोई भी तुरंत और त्रुटिपूर्ण रूप से हल नहीं हुई थी। संगठनात्मक परिवर्तन हमेशा एक लंबा और व्यवस्थित कार्य है। आप केवल यह नहीं कह सकते हैं कि "अब हम यह करते हैं" और आशा करते हैं कि अब सब कुछ अलग होगा। आपके द्वारा किए गए कोई भी निर्णय, कोई भी ईवेंट जो आप व्यवस्थित करते हैं, लोगों को नियंत्रण, प्रशिक्षण और ज्ञान की आवश्यकता होती है, दोनों टीम को नई तकनीकों के लिए अनुकूल करने का समय, और खुद को एक विशिष्ट स्थिति में तकनीक। मैं यह भी ध्यान देता हूं कि लोगों पर एक कार्यप्रणाली थोपना एक बहुत ही कठिन और अक्षम प्रक्रिया है। लोग आराम करेंगे, भूल जायेंगे, शायद तोड़फोड़ भी करेंगे।टीम में शुरू करने के लिए आवश्यक परिवर्तनों के लिए, टीम को स्वयं इन परिवर्तनों को करना चाहिए। यह निगरानी करना आवश्यक है कि वह कैसे कर रही है, समस्या क्षेत्रों की पहचान करें, इन समस्याओं से अवगत रहें, समाधान ढूंढें, और उसके बाद ही उन्हें लागू करें। बेशक, प्रत्येक टीम के सदस्य को ऐसा नहीं करना चाहिए और करना चाहिए, लेकिन अगर कोई ऐसा व्यक्ति है जिसने इन समस्याओं को देखा और उनके समाधान के साथ आया, तो वह सबसे पहले टीम को प्रबुद्ध करेगा।अपने ज्ञान, टिप्पणियों, अनुभव, तर्क को साझा करें, दिखाएं और साबित करें कि समस्याएं अब कहां हैं और उन्हें हल करने के लिए क्या कदम उठाए जा सकते हैं। केवल इस तरह से बड़े संगठनात्मक रूपांतरों को यथासंभव कुशलतापूर्वक चलाया जा सकता है। यहां तक कि अगर आप एक नेता हैं और अपनी स्थिति और अपने फैसले को आगे बढ़ाना चाहते हैं - तो इसे जितना संभव हो सके उतना आश्वस्त और आश्वस्त करने का प्रयास करें, जिससे कार्यान्वयन पर समय की बचत हो और टीम को अवांछनीय नकारात्मकता से बचाया जा सके। पॉजिटिव टेक्नोलॉजीज डेवलपमेंट ग्रुप के प्रमुख एवगेनी एंटोनोवद्वारा पोस्ट किया गया