प्रेरणा, प्रतिनिधिमंडल और स्वचालन: सुपर टीम बनाने का नुस्खा

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



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


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

आप पहले से ही दीमा से परिचित हैं। वह एक अच्छा डेवलपर हुआ करता था - वह हर दिन 3 कार्य करता था और उन्हें अंत तक करता था - यह सबसे महत्वपूर्ण बात है। दीमा के बगल में हरे रंग का मरना उसके जीवन में नरक का सूचक है।



दीमा के साथ आगे क्या होता है? अगर आपको लगता है कि वह एक डरपोक बन जाता है और नरक थोड़ा और अधिक हो जाता है, तो आपने अनुमान लगाया। उत्पाद दीमा के पास आता है और कहता है: “ चलिए प्लान Q2! टास्क 1653 कब होगा? हमारी जल्द ही रिलीज होगी ! ” और नरक थोड़ा बड़ा हो रहा है।

और फिर CTO आता है: “ हमें एक और डेवलपर को नियुक्त करना होगा। आपका तकनीकी ऋण क्या है? और यहाँ Google डॉक में एक और प्रश्नावली है - इसे भरें, कृपया! " और नरक और भी बड़ा हो गया है।

फिर डेवलपर्स आए: “ हम विकास करना चाहते हैं! हमारा वेतन बढ़ाओ! ” और दीमा जलने लगती है।



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

स्थानीय रूप से, यह खराब परिणाम हो सकता है जब दीमा कहता है: “ यह बात है! मैं अब टीम लीडर नहीं रहूंगा! मैं सिर्फ अपने काम करना चाहता हूं, मुझे अकेला छोड़ दो! ” या कार्य को निराश करते हैं, क्योंकि उनमें से बहुत सारे हैं, और दीमा अकेली है - हर चीज पर ध्यान केंद्रित रखना कठिन है। परिणामस्वरूप, हम बहुत सारा पैसा खो देंगे या समय पर कुछ जारी नहीं करेंगे।

मैं आपको बताऊंगा कि जीवन से नरक कैसे निकालें और एक सुपर टीम बनाएं। अंत में, परंपरा के अनुसार, बोनस होगा।

पहचान

स्काईेंग 17 विकास दल हैं, जिनमें से प्रत्येक स्वतंत्र रूप से अपने उत्पाद पर काम करता है। ज्यादातर अक्सर, डेवलपर्स के अलावा, टीम में कम से कम उत्पाद और टीम का नेतृत्व शामिल होता है।

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

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

आइए उन कार्यों को देखें जो डिमा करता है। मैं उन्हें में विभाजित करता हूं:

• महत्वपूर्ण कार्य ;
  
• ऐसे कार्य जिन्हें प्रत्यायोजित या स्वचालित किया जा सकता है ताकि कोई और उन्हें कर सके, लेकिन आपको इस पर समय बिताने की आवश्यकता है;
  
• दिनचर्या - सरल कार्य जो आवश्यक रूप से किए जाने चाहिए।
  

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

सतह समाधान

हम पूरी दिनचर्या से छुटकारा पा लेते हैं, जो कुछ भी प्रत्यायोजित किया जा सकता है, उसे सब कुछ स्वचालित कर देते हैं जो स्वचालित हो सकता है।

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

यह वह तरीका है जो हर कोई जानता है, लेकिन कोई भी नहीं करता है। लेकिन एक और तरीका है, समान, जो मैं गया था।

दिनचर्या से छुटकारा पाएं

पहले आपको कम-लटकने वाले फलों को खोजने की आवश्यकता है - बहुत सरल कार्य जो सबसे अधिक समय लेते हैं, लेकिन जो कि छुटकारा पाने में भी आसान हैं। आप इन कार्यों को जानते हैं, और यदि नहीं, तो काम करने वाले मदद करेंगे।

मैं हर दिन काम कर रहा हूं, जो कुछ भी मैंने किया है उसे लिख लें, और फिर उसका विश्लेषण करें।

संदेश और सवाल

सबसे अधिक संभावना है, यह कॉल के साथ काम करेगा। मेरे अनुभव में, टीम लीडर्स डेवलपर्स, उत्पादों, सीटीओ, ग्राहकों से सवालों के जवाब देने में बहुत समय बिताते हैं - स्लैक हमेशा संदेशों से भरा होता है। अब मैं आपको बताऊंगा कि इस शोर से छुटकारा पाना कितना आसान है।

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

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

फिर मैंने देखा कि लोग कैसे अपील लिखते हैं:

- आह !!! कुछ भी काम नहीं करता, कुछ भी नहीं मिलता है! पैसा हो गया! हम सब मर जाएंगे!

इसलिए मैंने समर्थन कॉल लिखने के लिए नियम लिखे। फिर हमने जल्दी से एक बॉट को कोडित किया जो चैनल में प्रवेश करते समय इन नियमों को लिखता है।



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

कुल: एक घंटे में मुझे सवालों के जवाब देने के लिए अतिरिक्त समय का एक गुच्छा खर्च करने से छुटकारा मिला। हां, कोई नाराज था, शायद, लेकिन आप अन्य काम कर सकते हैं।

इस समाधान को और कैसे सुधारें?

सामान्य प्रश्न अनुभाग । उपस्थित लोगों से सबसे लोकप्रिय प्रश्नों के उत्तर लिखने और एक संक्षिप्त निर्देश लिखने के लिए कहें, ताकि उत्तर देने में समय बर्बाद न हो।

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



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

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

प्रशासनिक सहायक

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

इसलिए, स्काईेंग के पास प्रशासनिक सहायकों का एक विशेष विभाग है । यह एक आंतरिक YouDo है, लेकिन मतभेदों के साथ।

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

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

हमने प्रशासनिक सहायकों, उनके कार्य कार्यक्रम और गुणवत्ता नियंत्रण की कीमत पर दीमा के जीवन में दिनचर्या की मात्रा को भी कम कर दिया।

जेडी तकनीक

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

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

उत्पादन ठीक करें

यहाँ सब कुछ बहुत मामूली है। हम ऑटो - एस्केलेशन का उपयोग करते हैं - हम एक विशेष बॉट को कॉन्फ़िगर करते हैं। स्काईेंग में, यह ऑप्सजीनी है, जो रात में हमें फोन करता है अगर उत्पाद टूट जाता है और हमें इसे ठीक कर देता है। लेकिन हम सिर्फ इससे दूर होना चाहते हैं और रात को नहीं उठना चाहते हैं!

इसलिए, हम एक ड्यूटी शेड्यूल बनाते हैं और इस शेड्यूल से खुद को दूर करते हैं। टिमलीड को रात में नहीं जगाना चाहिए।

वृद्धि द्वारा ड्यूटी लगाई जाती है: यदि डेवलपर ने समस्या नहीं ली, तो बॉट टीम लीडर को बुलाएगा। अगले दिन, टीम के नेता यह पता लगाएंगे कि डेवलपर क्यों नहीं उठा। लेकिन यह बेकार हो जाएगा अगर डेवलपर 10 मिनट में जागने के बाद खुद को टीम लीडर कहना शुरू कर दे।

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

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

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

दीमा ने आज जो किया उसे देखती हैं:

• सुबह की रैली।
  
• तकनीकी समीक्षा - इसे हम कार्यों की तकनीकी चर्चा कहते हैं।
  
• ओलेग के साथ 1: 1।
  
• पूर्वव्यापी या काइज़न।
  

पूरे दिन कुछ बैठकें!

आप मुझे इंतजार कर रहे हैं कहने के लिए, "चलो प्रतिनिधियों की बैठकों!" यह एक "माथे" समाधान है, जिसे हम एक तकनीकी समीक्षा के उदाहरण के रूप में जांचेंगे।

तकनीकी समीक्षा

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

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

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

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

आगे क्या है? आप इस दस्तावेज़ के साथ किसी ऐसे व्यक्ति के मांस का डिब्बा नहीं फेंक सकते: " इस एल्गोरिथम पर एक तकनीकी समीक्षा करें! "यह काम नहीं करता है। मैंने पूछा कि तकनीकी समीक्षा कौन करना चाहता है - यह पता चला, पूरी टीम! हमने एक शेड्यूल बनाया और बारी-बारी से समीक्षा करना शुरू किया।

यह महत्वपूर्ण है कि अपने आप को प्रक्रिया से बाहर न करें, क्योंकि जो आप स्वयं ठीक से नहीं कर रहे हैं, उसे अच्छी तरह से करना असंभव है। टाइमलाइड चालू होना चाहिए, देखें कि सब कुछ कैसे होता है और खुद को भी पंप करें।

मैंने इस त्रुटि को कई बार देखा है, यदि आप स्वयं भाग नहीं लेते हैं और 10 में से 10 नहीं करते हैं, तो यह बुरी तरह से बदल जाएगा।



हमने बारी-बारी से एक तकनीकी समीक्षा शुरू की और प्रतिक्रिया एकत्र की: प्रत्येक बैठक के बाद, प्रत्येक प्रतिभागी को एक प्रश्नावली प्राप्त हुई, जहाँ उसने "रोचक" , "रचनात्मक" , "सभी राय सुनी गई" और "मुक्त प्रतिक्रिया" श्रेणियों की बैठक की प्रक्रिया का मूल्यांकन किया।

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

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



नतीजतन, डिमा को सभी बैठकों को आयोजित करने की आवश्यकता से छुटकारा मिल गया । ऐसा लगता है कि समय आ गया है, लेकिन वैसे भी, जब तकनीकी बैठकों में सहयोगियों को एक आम राय नहीं आ सकती है, तो वे डिमा से बातचीत में शामिल होने और तकनीकी संघर्ष को हल करने में मदद करने के लिए कहते हैं।

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

तकनीकी सिद्धांत

हमने पूरी बिलिंग टीम को इकट्ठा किया, मैंने इन सिद्धांतों के आधार को स्केच किया, हमने उनसे लंबे समय तक चर्चा की, मतदान किया, सुधार किया। परिणाम 12 सिद्धांतों की एक सूची है। यहां बारह में से तीन हैं: हमारे लिए क्या मायने रखता है - कोड की गुणवत्ता या विकास की गति, क्या हमारे विकास को आउटसोर्स करना संभव है और क्या हम परिणामों के बारे में सोच रहे हैं?



बिलिंग टीम के जवाबों से पता चला कि बिलिंग सब कुछ अच्छा है और सब कुछ खराब के खिलाफ है: हम हमेशा गुणवत्ता के लिए हैं , आप परिणामों के बारे में आउटसोर्स नहीं कर सकते हैं और न ही सोच सकते हैं ।

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

लेकिन दर्जनों अन्य टीमें हैं जो परिणामों के बारे में नहीं सोचती हैं, और यह उनके उत्पादों के लिए सामान्य है।

प्रत्येक टीम के अपने सिद्धांत होने चाहिए, जो उत्पाद और टीम पर निर्भर करते हैं।

कार्य सिद्धांत

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

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

जब मैंने सारांश दिया, तो मैंने वोट के मानक विचलन की गणना की और सबसे विरोधाभासी सिद्धांतों को काट दिया, जहां हम आम राय में नहीं आते हैं।

• स्काईेंग की तुलना में व्यक्तिगत जीवन अधिक महत्वपूर्ण है । लोग उन पर समान रूप से विभाजित हैं जिनके लिए व्यक्तिगत जीवन अधिक महत्वपूर्ण है, और जिनके लिए - कंपनी।
  
• घर पर घर का काम, काम पर काम करना । हम "ऑफटॉपिक" नहीं हैं!
  

भगवान का शुक्र है कि हम एक लोकतंत्र नहीं हैं, और सिद्धांतों को स्वीकार करने का सिद्धांत काम करता है: "एक टीम नेता सिद्धांतों का चयन कर सकता है।" इसलिए, पहला पैराग्राफ हटा दिया गया था, और दूसरा छोड़ दिया गया था।

दीमा ने तकनीकी और कामकाजी सिद्धांतों के साथ तकनीकी समीक्षा की और सभी बैठकों में भाग नहीं लिया।

केवल उन लोगों को भाग लेना है, जो वास्तव में जटिल या अवांछनीय मामले माने जाते हैं। लेकिन फिर सिद्धांतों को भी पूरक बनाया जा सकता है।

ढकेलनेवाला

उत्पाद आता है और दीमा को पीड़ा देता है - हमें इससे छुटकारा नहीं मिला।

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

मैं कानबन का प्रशंसक हूं, क्योंकि वह आपको ऐसा करने की अनुमति देता है। मेरी राय में, कन्वेयर इस तरह दिखता है: कॉलम हैं, हम कार्यों को धक्का देते हैं।



हर कोई आर्सेनी बॉट के बारे में पहले ही सुन चुका है। बॉट कॉलम से कॉलम तक काम करता है, और हर सुबह लिखता है: "आप बावले नहीं हुए हैं, आप नहीं करेंगे।

मैंने देखा कि यह हमेशा काम नहीं करता है, क्योंकि कुछ कार्य हफ्तों तक प्रतीक्षा कॉलम में लटके रहे हैं। उदाहरण के लिए: "मैं बुनियादी ढांचे की टीम से एलेक्सी की प्रतिक्रिया की प्रतीक्षा कर रहा हूं," और एलेक्सी को यह बिल्कुल नहीं पता है कि कार्य उसका इंतजार कर रहा है। और आर्सेनी भी नहीं जानता कि एलेक्सी को नहीं पता है।



इसलिए, मैंने एक पुशर की भूमिका पेश की, जिसे मैंने 2 जीआईएस से जासूसी की। , , , . , , - ?

, , — , - - , , . — .

. . , .

Kanban + Demo

: Kanban-, , 40 . , , .

SCRUM Demo day — - -demo. Kanban, , 7 , . , — , , , .

, , :

99% — .

— - .

« » , .

.

, . , , , .

Skyeng : — — — — . .


, .

, : « !». , .

, . , , , .



: « — 2 » « 10%». .

. , . .

. , . . .

, , . - : « , », , , , , 3 .

, , . - , .

. , — :

— , ! , , !

, . , . .

. . — , . , , .

1:1, . . , . .

. -. . , . , .

— , 10 , PHP Go.

.



, . . , .

— , — , . — , . , . : « , — !»

— . , - , . — , .



, . . , — .

— , .

— . , .

. . 12 12 . , , . , , . — , . . - . , - .

— telegram (@ax8080) Facebook . telegram- , .

इस बीच, हम 23-24 सितंबर को सेंट पीटर्सबर्ग में अगले टीमलेड कॉन्फिडेंस की तैयारी कर रहे हैं । हम नए वक्ताओं की तलाश कर रहे हैं, हम परिचित विशेषज्ञों के साथ वर्तमान मुद्दों का चयन करते हैं। यहां उन विषयों की एक नमूना सूची दी गई है, जिन्हें हम सेंट पीटर्सबर्ग सम्मेलन के कार्यक्रम में ध्यान देना चाहते हैं:

• प्रक्रियाएं, योजना, प्रबंधन।
• एक कर्मचारी के साथ व्यक्तिगत काम।
• एक टीम और आंतरिक संबंधों का निर्माण।
• हितधारकों के साथ बातचीत।
• व्यक्तिगत विकास।

मैं आपको निम्नलिखित पोस्टों में से एक में अधिक बताऊंगा, लेकिन यदि पहले से सूचीबद्ध कोई भी कांटेदार मार्ग पूरा हो चुका है , तो आप पहले ही रिपोर्ट सौंप देंगे । यदि संदेह है, तो आप सबसे पहले मुझे या किसी और को कार्यक्रम समिति से लिख सकते हैं - हम चर्चा करेंगे, सुझाव देंगे, मदद करेंगे।