2018 में टाइमलाइड का काम

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

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

लेकिन कोई नाम, कंपनी, ग्राहक, सहकर्मियों के नाम नहीं। गैर-प्रकटीकरण समझौता, सभी चीजें।

पृष्ठभूमि। मैं और कैसे टीम लीडर बने

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

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

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

एक नई जगह में

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

पहले ही दिनों में, कई "बच्चों की" समस्याएँ आ रही थीं:

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

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

मेरी निराशा के लिए, प्रक्रियाएं पहले महीनों के दौरान धीरे-धीरे आगे बढ़ीं। सबसे पहले, मुझे खुद को एक प्रोग्रामर के रूप में दिन में 8 घंटे क्लाइंट कामों पर काम करना पड़ता था, क्योंकि मेरे पास बस पर्याप्त हाथ नहीं थे। दूसरे, ऐसे समय के दबाव की स्थितियों में, बड़े बदलाव करना काफी खतरनाक था जिससे कोड या समय का भ्रम और नुकसान हो सकता है।

अब हम सीधे लेख और समस्या समाधान पर जाते हैं। नई कंपनी में पहली बात यह थी कि किसी तरह उन्मुख होना।

कर्मचारियों के लक्ष्यों से जानकारी खींचना

जब मैं पहुंचा, तो मुझे पता था कि परियोजनाओं या ग्राहकों के बारे में कुछ भी नहीं है, और यह जानकारी संग्रहीत नहीं थी।
पाठ के रूप में कहीं नहीं । इसलिए, पहली बात मैंने ग्रंथों में सहकर्मियों के लक्ष्यों से जानकारी खींचना शुरू किया।

अनिवार्य रूप से, एक विकास कंपनी के पास महत्वपूर्ण और / या उपयोगी ग्रंथों के 2 बड़े उपसमुच्चय हैं:

1. निर्देश, नियम, लेख, कार्यात्मक विवरण, उपयोगकर्ता कहानियां, ...
2. उनके नाम, विवरण, टिप्पणियां, समय लॉग, कमिट करने के लिए हस्ताक्षर, कोड में टिप्पणियां, ऑटोटेस्ट, ...

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

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

कार्यों के निर्माण और प्रबंधन के साथ समस्या के समाधान में एक महीने से अधिक की देरी हुई। यह एक अड़चन बन गया और बाद के अध्यायों में मैं इस विषय को एक से अधिक बार उठाऊंगा।

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

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

लेकिन किसी भी समय कार्यों की वर्तमान स्थिति प्राप्त करने से संबंधित समस्या, हमने दिन के लिए समन्वय फोन और योजनाओं के माध्यम से बायपास करने का निर्णय लिया।

स्टाफ पुनःपूर्ति, टीम एकीकरण

लगभग शुरू में यह स्पष्ट था कि लोगों में कमी थी (मैंने स्वयं पूर्णकालिक कोड लिखा था, लेकिन हमारे पास अभी भी समय नहीं है)।

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

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

लगभग सामने के तुरंत बाद, 2 बीक पाए गए। और कहीं न कहीं, जौन ने छोड़ दिया (जिसका कोड उसके जाने के कुछ महीने बाद मुझे मिला)।

कुल मिलाकर, निम्नलिखित स्थिति विकसित हुई:

• एक "बूढ़ा आदमी"
• मैं
• तीन पूर्ण शुरुआती
• काम अभी तक स्थापित नहीं किया गया है
• कुछ ज्ञान पहले से ही खो गया है

यह स्वाभाविक है कि टीम के नेता के रूप में नए लोगों के दर्जनों सवाल तुरंत मुझ पर बरस पड़े। मूल रूप से, ये कोड के जीवन चक्र (जहां कोड लिखना है, इसे बाद में कहां भेजना है, रिलीज कैसे एकत्र करना है), कार्य प्रबंधन (कार्य को कैसे काम करना है, स्थिति कैसे दिखाना है, प्राथमिकताओं का निर्धारण कैसे करना है) और कैसे git के साथ काम करना है पर प्रश्न थे। । इसके अलावा, लोग अभी भी "ए काम कैसे करता है?" सवाल पूछने की कोशिश कर रहे थे, "क्या हमारी साइट पर एक बी है?", लेकिन उस समय लगभग सब कुछ केवल कोड का अध्ययन करने की आवश्यकता को कम कर दिया गया था।

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

यहाँ यह हमारी कंपनी में भर्ती प्रक्रिया के बारे में कुछ शब्द कह रहा है, जो अभी भी काम कर रहा है।

किराए की प्रक्रिया

सबसे पहले, हमारे पास एक कर्मचारी को आकर्षित करने के लिए एक बोनस है, जो बहुत अच्छा अभ्यास है।

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

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

कुल:

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

एक कोड विकास और वितरण प्रणाली की स्थापना

उस समय, हमारे पास कई परियोजनाएं थीं जिन्हें काफी अनियमित रूप से विकसित किया गया था:

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

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

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

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

प्रणाली इस प्रकार है:

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

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

सभी परियोजनाओं को इस प्रणाली में स्थानांतरित करने की प्रक्रिया में, निश्चित रूप से, देरी हुई (उदाहरण के लिए, एक परियोजना पर हम पहली बार रहस्यमय रूप से मास्टर के पास नहीं जा सकते थे), और यह अभी भी जारी है, लेकिन परिणामस्वरूप हमें कम से कम मिला:

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

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

स्क्रम, संचार, नियम

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

सबसे पहले, उन्होंने स्क्रैम को पेश किया, और मेरे आने के समय, कंपनी में प्रक्रियाओं को सक्रिय रूप से रीमेड किया जाने लगा। इसके अलावा उस पल में उसे Bitrix24 से जीरा में स्थानांतरित कर दिया।

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

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

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

नया प्रबंधक। ग्रंथ, कार्य सेटिंग, बैकलॉग

किसी बिंदु पर, एक अन्य व्यक्ति हमें एक क्वांटम छलांग लगाने में मदद करने के लिए आया - एक नया प्रबंधक (इससे पहले कि हमारे पास एक था)।

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

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

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

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

वह वास्तव में खुद को गड़बड़ से "लटका दिया" और बार-बार छोड़ने की कोशिश की, लेकिन हमने प्रबंधकीय लिंक को एक या दूसरे तरीके से सुधार दिया। बैकलॉग में टास्क कम होने की संभावना है, प्रोग्रामर के दोबारा पूछने की संभावना कम है।

कहानी का नैतिक अंत होगा।

संकट

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

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

और छुट्टी के पहले दिनों में भी, कुछ भी परेशानी का सामना नहीं करना पड़ा।

और फिर एक संकट था।

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

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

, . , . , , .

vue, ( , ).

— , , , - , “ / / / ”.
, , , , .

, , , , , .

, . , - . , - .

. ( ), - :

- , - , - , . .

, . , , , .

. , , , . , , .

, vue, .

, - 5. -, . , .

, : , , , .

, - , - . , , , , , .

.

. , , , - , , .

, , , 1 , - , , , , , . , .

,

. .

, , 3-4 “ 3 ”, 40.

, , .

/ — ( ). , . , . , , -, 8 .

. :

• ,

- :

• -
• -
• -
• ...

( ), :

• , -
• , - -” ” .
• , .
• , ,

— . :

• 1
• , . ,

:

• , , , .
• ,
• ,
• , , , ,

, . , .
, . .

—

, , , , , “ ” , .

, , “” - .

, , , , , 2 . , , .

, , / , . , , .

, . , , / - , , - .

(, )

- . , , , , , , , .

, , . , , .

: , , , , . , .

, - , . , .

:

• ,
• -
• 1

, , , .

, , , ( ), , , .

, ( , 2 , ).

, , . “ ”, :

• , , -
• - .

, .

भाग २

इस लेख ने एक नई स्थिति में मेरे काम के छह महीने को कवर किया। दूसरे भाग में, मैं इस बारे में बात करना चाहूंगा कि हम किस तरह मदद से लक्ष्य की ओर बढ़ते हैं:

• autotests कि हम अभी लागू करने के लिए शुरू कर रहे हैं। अजीब बात है, लेकिन किसी कारण के लिए बिट्रिक्स पर कोई योग्य उदाहरण नहीं हैं।
• कोड में विरासत से छुटकारा
• आगे विकास में तेजी लाना और सरल बनाना
• मैं टिप्पणियों से क्या सीखूंगा
• कई अन्य गुप्त बातें (अचानक मेरे लोग मुझे पढ़ते हैं)

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

सभी को काम और जीवन में शुभकामनाएँ!