अकेले क्षेत्र में एक योद्धा नहीं है। प्रभावी टीम वर्क का रास्ता

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

कुछ लोगों को इकट्ठा करें और कहें: "अब आप एक टीम हैं, हम आप से परिणाम की प्रतीक्षा कर रहे हैं", यह काम नहीं करेगा। लोगों को संगठित करने, उन्हें एक लक्ष्य देने, प्रेरणा देने और समस्याओं को हल करने की आवश्यकता है।



टीमलीड कॉन्फ पर एवगेनी फेडोरेव की रिपोर्ट के इस डिकोडिंग के बारे में। यूजीन ने रिपोर्ट में, Banki.ru पर एक प्रभावी विकास टीम के आयोजन की प्रक्रिया को चरणों में वर्णित किया: टीम और विभाग के भीतर डेवलपर्स और परीक्षकों को काम पर रखना, संचार करना, ज्ञान साझा करना और विकसित करना।


स्पीकर के बारे में : एवगेनी फेडोरेव ( हार्डज ) 15 वर्षों से वेब विकास में लगे हुए हैं, उनमें से 6 टीम लीडर की स्थिति में हैं, और अब वह Banki.ru पर नई परियोजनाओं के विकास का नेतृत्व करते हैं।

Banki.ru क्या है?

कंपनी के संदर्भ में यह जानना है कि किस अनुभव पर चर्चा की जाएगी। Banki.ru 8 मिलियन से अधिक अद्वितीय उपयोगकर्ताओं के मासिक दर्शकों के साथ रनेट का सबसे बड़ा स्वतंत्र वित्तीय पोर्टल है।

आईटी विभाग 7 विकास टीमों में विभाजित 50-70 लोगों को रोजगार देता है। सभी विकास घर में किए जाते हैं, कोई दूरस्थ डेवलपर्स नहीं हैं, इसलिए उपयुक्त प्रक्रियाओं और मैट्रिक्स की कोई आवश्यकता नहीं है।

विकास टीम का मुख्य कार्य

रिपोर्ट की तैयारी करते समय, मैंने लोगों से एक सवाल पूछा:

- विकास दल का उद्देश्य क्या है?
- विकास करना।
- इसका क्या मतलब है? यदि कोई व्यक्ति बैठता है, रिफ्लेक्टर, लाभ नहीं लाता है, तो व्यावसायिक समस्याओं को हल नहीं करता है - क्या यह भी एक विकास है?
- ... इसे प्रभावी ढंग से विकसित करने की आवश्यकता है।

विकास क्षमता

दक्षता की अवधारणा एक प्रबंधक के लिए एक चीज़ है, और दूसरे के लिए एक डेवलपर है।

प्रबंधक के लिए, प्रभावी विकास पूर्वानुमेय है : जब कुछ व्यावसायिक आयोजनों को करने के लिए फीचर की रिलीज़ की तारीख या कार्य पूरा करने की समय सीमा ज्ञात की जाती है।

एक डेवलपर के लिए, यह एक तकनीकी ऋण के साथ काम करता है । उन लोगों के साथ काम करने के बाद से यह एक दर्द है। सुधार के लिए, सुधार के लिए और बहुत कम समय के लिए ऋण दिया जाता है।

अगला प्रदर्शन मानदंड बग की न्यूनतम संख्या है। कोई लिख सकता है कि मानदंड बग की पूर्ण अनुपस्थिति है, लेकिन हम जानते हैं कि ऐसा नहीं होता है। इसके अलावा, परीक्षक नाराज होंगे, क्योंकि उन्हें ज़रूरत नहीं होगी।

भविष्य की चुनौतियां । मैंने जानबूझकर "विचारशील वास्तुकला" नहीं लिखा। गहराई से सोचना और अग्रिम में वास्तुकला के माध्यम से सोचना बुराई है, इसलिए विकास को भविष्य के लिए छुआ जाना चाहिए, लेकिन कट्टरता के बिना।

हर टीम के पास कोई अन्य मापदंड ।

विकास की प्रक्रिया

कंपनी के विकास और विकास के बाद हमने Banki.ru में विकास प्रक्रियाओं का निर्माण शुरू किया। नए भागीदार और परियोजनाएं दिखाई दीं, और 6-9 बैकएंड डेवलपर्स पर्याप्त नहीं थे। हम इस निष्कर्ष पर पहुंचे हैं कि हमें विकास प्रक्रिया का निर्माण करने और इसे प्रभावी कार्य के लिए औपचारिक रूप देने की आवश्यकता है।

प्रारंभ में, हमारे पास 3 टीम थी, जिनमें से प्रत्येक में 3 बैकएंड डेवलपर्स और एक प्रबंधक थे जो साइट के कुछ हिस्सों के लिए जिम्मेदार थे। बैकएंड डेवलपर्स, अपने काम के अलावा, अभी भी टाइप कर रहे थे और jQuery प्लगइन्स कनेक्ट कर रहे थे, क्योंकि उस समय फ्रंटेंड पर कुछ लोग थे।



हमने बगलों के बिना रहने के लिए दो फ्रंट-एंड डेवलपर्स और दो और परीक्षक लिए और सोचा कि यह कॉन्फ़िगरेशन पर्याप्त होगा।

एक आदर्श दुनिया में, विकास प्रक्रिया को इस तरह देखना चाहिए।

• प्रोजेक्ट मैनेजर कार्य को बैकेंड टीम में छोड़ देता है और वे इसे निष्पादित करते हैं।
• यदि संशोधन की आवश्यकता है, तो वे कार्य को फ्रंट-एंड टीम को भेजते हैं।
• शोधन के बाद, दृश्यपटल इसे QA को देता है।
• कोई कीड़े नहीं? - उत्पादन में।

हमने सुझाव दिया कि दुनिया सही नहीं है, और क्यूए कार्यों को वापस करेगा, क्योंकि बग किसी भी विकास में मौजूद हैं, और दो और तीर जोड़े।



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

हमारी योजना बदल गई है। कार्य पिंग-पोंग में गेंद की तरह कूदते हैं: क्यूए से आगे और पीछे डेवलपर्स तक, और यहां तक ​​कि प्रबंधकों तक पहुंचते हैं।



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

डिलीवरी का समय कैसे कम करें?

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

हमारे पास तीन बैकेंड टीमों की योजना थी। हम योजना बनाने में परीक्षक और फ्रंट-एंड डेवलपर्स शामिल थे , लेकिन 3 टीमों के लिए केवल 2 फ्रंट-एंड डेवलपर्स और 2 परीक्षक थे। अक्सर वे उन्हें बुलाने में सफल नहीं हुए, क्योंकि किसी को काम करना था।

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

हमने सभी उपाय आजमाए। नतीजतन, समय कम हो गया, लेकिन फिर भी हम खुश नहीं थे।

हमने सोचा कि आगे क्या करना है। बाजार में कई कंपनियां और प्रथाएं हैं, और हमने फीचर-टीम को अध्ययन करना, देखना, खोदना और प्राप्त करना शुरू किया।

फ़ीचर-टीम

यह तब है जब टीम के पास काम पूरा करने के लिए लोगों का पूरा सेट है:

• बैकएंड डेवलपर्स।
• फ्रंट-एंड डेवलपर्स।
• क्यूए डेवलपर्स।

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

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

फ़ीचर-टीम के मुद्दे

उस समय, हमारे पास 6 समस्याएं थीं।

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

समस्याएं हैं, हम इसे हल करेंगे।

बस कारक

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

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

फ्रंट-एंड डेवलपर्स ने एक क्रॉस-कमांड कोड-समीक्षा पेश की , जब एक डेवलपर एक टीम में एक समस्या हल करता है और इसे अन्य टीमों को समीक्षा के लिए देता है, और कम से कम दो बयानों के बाद कार्य परीक्षण में जाता है।

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

लंबी योजना

हमने नियोजन के कार्यों का विश्लेषण किया। स्प्रिंट्स के समय, सभी ने काम किया और कोडित किया, और लगभग पहली बार योजना बनाने पर उन्होंने कार्य खोले और यह पता लगाया कि क्या करना है, कार्य को समझने के लिए परीक्षकों ने "किए गए की परिभाषा" को स्पष्ट किया।

प्रक्रिया समय लेने वाली थी। हमने योजना बनाने से पहले कार्यों को अलग करने का फैसला किया: हमने सुझाव दिया कि डेवलपर्स अपने खाली समय में कार्य को देखते हैं, सवाल पूछते हैं ताकि वे योजना के लिए तैयार हो सकें।

हमने प्रबंधकों को कार्यों का अधिक विस्तार से वर्णन करने के लिए आमंत्रित किया, लेकिन बहुत अधिक नहीं ताकि एक टन दस्तावेज में खुदाई न करें।

हमने जानबूझकर एक अतिरिक्त संवारने का समय निर्धारित किया है और खाली समय नहीं। वे एक टीम के रूप में एकत्र हुए, कार्यों पर चर्चा की और योजना के लिए तैयार हुए।

अनछुए स्प्रिंट

यह एक दर्द है। शायद कोई उन्हें बंद कर दे, लेकिन उस समय हमारे साथ - नहीं।

हमने स्प्रिंट क्षमता को 10 कार्य दिवसों से घटाकर 8 करने का निर्णय लिया। हमने सोचा था कि हम 8 दिनों के लिए योजना बनाएंगे, और 2 दिनों के लिए परीक्षकों को छोड़ देंगे।

वास्तव में, यह पता चला कि जब कोई डेवलपर कम कार्य देखता है, तो वह उन्हें धीरे-धीरे करता है। स्प्रिंट में 20% कम कार्यों ने कुछ भी नहीं दिया।

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

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

क्लास! हम इस विचार को बेचने के लिए प्रबंधकों के पास गए:

- हमने परीक्षकों से योजना बनाने का फैसला किया। स्प्रिंट बंद हो जाएगा, यह शांत हो जाएगा!
- रुको, इस समय डेवलपर्स क्या करेंगे? कम कार्य होंगे, उनके पास खाली समय होगा!
- क्या आप चाहते हैं कि स्प्रिंट को बंद कर दिया जाए, विकास का अनुमान लगाया जा सकता है या लोगों का मुख्य लक्ष्य है?
- नहीं, यह अभी भी एक अनुमानित विकास है। चलो स्प्रिंटों को बंद करें।

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

यह पता चला कि डेवलपर्स बहुत सारी चीजें कर सकते हैं जब वे स्वतंत्र होते हैं।

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

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

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

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

टीमों के लिए कार्यों की विभिन्न प्रकृति

हमारे पास उत्पाद टीमें हैं जो कुछ नया करती हैं। उनके पास दो सप्ताह की योजना, स्प्रिंट, लंबी परियोजनाएं हैं और वे 1-2 महीने या उससे अधिक में रिलीज करने के लिए आते हैं।

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

हमने पीएम और बिजनेस से बात करने का फैसला किया:

- दोस्तों, हमारे पास एजाइल, स्क्रैम, स्प्रिंट, प्रक्रियाएं हैं - चलो नए कार्यों में नहीं फेंकते हैं, लेकिन हम पूर्वानुमान विकसित करेंगे।
- देखिए, हम एक लैंडिंग बेचते हैं, इसे 3 दिनों में करने की आवश्यकता है। हमें इसके लिए एक लाख का भुगतान किया जाता है। क्या प्रक्रियाएं? पैसा भी कमाना होगा!

एक लाख ने हमें आश्वस्त किया। हम और सोचने लगे।

हमने स्प्रिंट को एक सप्ताह तक कम करने का फैसला किया - इसलिए हम तेजी से प्रतिक्रिया कर सकते हैं। यह या तो काम नहीं करता था, क्योंकि इस टीम के लिए उस पल की योजना बनाना बिल्कुल भी काम नहीं करता था।
तब हमने स्प्रिंट की योजना नहीं बनाने का फैसला किया, लेकिन स्क्रम के बजाय कानबन पर काम करने के लिए: कार्य आया, काम पर ले गया, जारी किया गया। इसने काम किया। टीम ने अधिक उत्पादक रूप से काम किया, क्योंकि यह शुरू में समझ गया था कि कोई योजना नहीं थी, लेकिन प्रदर्शन करने के लिए केवल कार्य थे।

टीम में प्रक्रियाओं को बेहतर बनाने और प्रतिक्रिया प्राप्त करने के लिए, हमने हर 2 सप्ताह में रेट्रोस्पेक्टिव का संचालन करना शुरू किया: टीम इकट्ठा हुई, चर्चा हुई कि क्या अच्छा हुआ, क्या नहीं, क्या पेशेवरों और विपक्षों और इसके साथ काम किया।

नई टीमों का उदय

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

कंबन को ले जाना संभव था ताकि डेवलपर्स कार्य कर सकें, लेकिन यह एक उत्पाद टीम है, इसे सिखाने की आवश्यकता है। हमने फैसला किया - उन्हें कार्यों की योजना बनाने और मूल्यांकन करने दें, लेकिन स्प्रिंट को 1 सप्ताह तक कम कर दिया ।

हम 1-2 महीने में 2 सप्ताह का समय बढ़ा देंगे, जब टीम को इसकी आदत हो जाएगी, सामान्य उत्पाद कार्य में प्रवेश करेगा, प्रक्रियाएं स्थापित करेगा और डेवलपर्स सामान्य रूप से कार्यों का मूल्यांकन करने में सक्षम होंगे।

टीमों के बीच अनुभव का आदान-प्रदान

टीम के अंदर, डेवलपर्स और परीक्षक एक-दूसरे के साथ संवाद करते हैं और अनुभवों का आदान-प्रदान करते हैं, लेकिन यह अनुभव अपडेट नहीं होता है, क्योंकि टीम "अपने आप में खाना बनाती है।" नया अनुभव कहीं से भी नहीं आया है।

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

पहली बैठकें इस प्रकार थीं:

- नमस्कार, मेरा नाम यूजीन है, हम अब समाचार काट रहे हैं।
- अच्छा!

अगली बैठक:

- नमस्कार, मेरा नाम अभी भी यूजीन है, हम समाचारों को काटना जारी रखते हैं।
- ठीक है।

कुछ भी असाधारण नहीं होता है।

तीसरी बैठक: नमस्कार ... और सभी समान।

हमें एहसास हुआ कि हमें प्रारूप को बदलने की जरूरत है। बैठकों और के बारे में किताबें पढ़ें
एक निश्चित एजेंडा पेश किया।

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

इस निर्णय के फायदे

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

हमें बैठकों का प्रारूप पसंद आया और हमने उन्हें नियमित रूप से पकड़ना शुरू कर दिया।

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

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

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

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

और फिर विकास विषय समाप्त हो गए, हम मनोवैज्ञानिकों के पास चले गए और कहानी फीकी पड़ने लगी। डेवलपर्स को कुछ बताने के लिए कैसे उत्तेजित करें?

और फिर हमें KPI के बारे में याद आया! आइए प्रत्येक डेवलपर को शुक्रवार की सभाओं में छह महीने के लिए अपनी KPI 2 रिपोर्ट में बोलने और शामिल करने के लिए सिखाएं। हमने सोचा कि विचार अच्छा था और हर कोई आगे आएगा।

यह पता चला कि KPI की शुरुआत के बाद, डेवलपर्स ने रिपोर्ट बनाना बंद कर दिया। अनिवार्य प्रदर्शनों के लिए नकारात्मक उपस्थिति पैदा हुई। प्रोग्रामरों ने केवल स्वैच्छिक-अनिवार्य रिपोर्ट नहीं बनाने के लिए 100% KPI कार्यान्वयन का बलिदान करने का निर्णय लिया।

निष्कर्ष

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

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

— .

. , , , : , PM, .

— , .

, :
— . — , PM.
PM .
— , ? — PM , .

, , .

. .

, . Jira Slack, , , . Scrum-, .

, .

.

. , . , . , - , — , — - . , . :

— ?
— !
— !
— , iMessage!

, - : , .

, : , , , 2 , .

« » .

— , , .

. , «», — , , . , , , . , , .
पर्यावरण और टीम के बीच फ़िल्टर करें। डेवलपर्स को डिमोटलाइज न करने के लिए सभी जानकारी होनी चाहिए।

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