प्रक्रियाओं का निर्माण कैसे करें और एक टीम का मज़ाक करना बंद करें

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

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

विकास प्रक्रिया चुनौतियां

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

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

वास्तव में, किसी भी नेता का कार्य, चाहे वह टीएल हो या सीटीओ, वह व्यापार और विकास के बीच की कड़ी बन सकता है।

किसी तरह इस स्थिति से बाहर निकलने के लिए, हमने कानबन विधि की ओर रुख किया। वह हमें क्या बताता है? जो पहले से है, उसे सुधारते हैं। खैर, हम अपनी विकास प्रक्रिया को बेहतर बनाने के लिए गए।

बोर्ड पर आदेश डालना

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



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



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

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

ग्रेड कार्य

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



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



हमने ग्राहक के साथ सहमति व्यक्त की, जो व्यवसाय के साथ सेवा गुणवत्ता समझौते (SLA) पर है। एक प्रबंधक हमारे पास आता है और पूछता है: "और आप इस सुविधा को कितना बनाएंगे?" हम यह नहीं कह सकते कि हम निश्चित रूप से कितना काम करेंगे, लेकिन हम यह कह सकते हैं कि ऐसे कार्यों के पूरे बैच पर कितना समय व्यतीत होगा। स्कोर पोकर की कोई आवश्यकता नहीं थी, और हमने समय के सवालों के साथ लोगों को यातना देना बंद कर दिया। हमने सिर्फ आंकड़ों को देखा और व्यापार के लिए तारीखों को बुलाया।



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



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

विकास को गति कैसे दें

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

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



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


इस प्रकार, हमें एक उपकरण मिला जिसमें स्पष्ट रूप से दिखाया गया था कि कौन सा सुधार कार्य करता है और कौन सा नहीं।

व्यापार की योजना, तत्काल और बेकार कार्य

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

सापेक्ष रूप से, हम WIP- सीमा के अनुसार एक निश्चित आकार के स्लॉट आवंटित करते हैं, जहाँ आप कार्य कर सकते हैं। प्रत्येक स्लॉट केवल सीमित संख्या में कार्य करता है। दूसरे तरीके से, इस विधि को "कप प्लानिंग" कहा जाता है।



हमने व्यापार के लिए एक सरल उपकरण बनाया (एक्सेल में एक टेबल), जिसमें वह नेत्रहीन योजना बना सकता था। प्रबंधकों ने आपस में लड़ाई की, तर्क दिया कि किसका कार्य अधिक महत्वपूर्ण है, और फिर वे हमारे पास आए और विकास को कार्य दिया।

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

हमने अत्यावश्यक कार्यों की समस्या की ओर भी ध्यान दिलाया। उन्होंने उन पर आँकड़ों का विश्लेषण करना शुरू किया और महसूस किया कि ये कार्य इतने जरूरी नहीं हैं। उदाहरण के लिए, हमें मोटर चालकों से पहियों के मौसमी परिवर्तन के लिए प्रचार की आवश्यकता है। हम जानते हैं कि ऐसा हमेशा साल में 2 बार होता है। एक बार जब वे दोहराए जाते हैं, तो पहले से बोर्ड पर ऐसे कार्यों के लिए स्लॉट आरक्षित करें। कुछ भी जरूरी नहीं होगा - हम कतार से एक और काम करेंगे, हम काम के बिना नहीं रहेंगे। नतीजतन, हमें पता चला कि 60% तत्काल कार्य वास्तव में जरूरी नहीं हैं।

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

हमने 85% विशेषताओं को इस तरह से परीक्षण करना शुरू किया कि अंत में हमने बहुत समय मुक्त कर दिया, जिसे हमने अभ्यास में परीक्षण किए गए परिकल्पनाओं पर खर्च किया। वे पहले ही कंपनी का पैसा ले आए। इसके अलावा, अगर इस प्रक्रिया में कुछ गलत हुआ है, तो व्यवसाय से फीचर का ग्राहक प्रारंभिक चरण में सुधार कर सकता है, न कि पूरे विकास चक्र के माध्यम से।

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

बैठकों

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

परिणामस्वरूप, बोल्टोलॉजी पर सभी बैठकें निम्न प्रकार की बैठकों में बदल गईं:

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

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

टीम की प्रेरणा और भागीदारी

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

परिणामों का सारांश

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

निष्कर्ष

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

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

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