स्कॉट बर्कुन - "परियोजना प्रबंधन मूल बातें"

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



स्कॉट बर्कुन के बारे में

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



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



कार्यशाला "परियोजना प्रबंधन के बुनियादी ढांचे"

भाग 1. योजना और समस्या का बयान

शुरुआत में, जनता को एक डरावनी कहानी की पेशकश की गई थी - संयुक्त राज्य अमेरिका में अध्ययनों से सांख्यिकीय जानकारी: 50% परियोजनाएं योजनाबद्ध की तुलना में 2 गुना अधिक महंगी हैं, 30% चरणबद्ध हैं और केवल 16% समय पर और आवंटित बजट के भीतर पूरे होते हैं। इसके मुख्य कारण हैं कि शुरू में कोई स्पष्ट दृष्टि नहीं है (लक्ष्य का वर्णन नहीं किया गया है), अनुमान अत्यधिक आशावादी हैं (संसाधनों का पुनर्मूल्यांकन)। इसके अलावा, जोखिमों को ध्यान में नहीं रखा जाता है: त्रुटियां, परिवर्तन, बीमार छुट्टी आदि।



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



नियोजन प्रक्रिया का वर्णन करते हुए, स्कॉट ने निम्नलिखित मॉडल का प्रस्ताव किया:

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

स्कॉट ने उपरोक्त नियोजन प्रक्रिया को एक पिरामिड के रूप में वर्णित किया, जिसके आधार पर एक दृष्टि है, और शीर्ष पर विशिष्ट प्रकार के कार्य हैं। यदि आपको किसी तत्व में परिवर्तन करने की आवश्यकता है, तो ऊपर का पूरा पिरामिड बदल जाएगा।



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



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



भाग 2. परियोजना की प्रगति

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



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



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



स्क्रम बैठक

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



बैठक आवश्यक रूप से एक जिम्मेदार कर्मचारी के नेतृत्व में होती है, आमतौर पर एक पीआर। कम से कम प्रतिभागियों के साथ सबसे प्रभावी बैठकें आयोजित की जाती हैं। अलग-अलग, स्कॉट ने इस तथ्य पर ध्यान आकर्षित किया कि फास्ट फ्लायर्स की सभी उपयोगिता के लिए, बहुत "उबाऊ" हैं न कि उपयोगी बैठकें जिन्हें टाला जाना चाहिए और निश्चित रूप से शुरू नहीं किया जाना चाहिए। स्कॉट ने इस तरह की बैठकों को आयोजित करने के लिए कुछ विकल्पों का वर्णन किया, उदाहरण के लिए: स्क्रैम * । ऐसी बैठक में केवल 4-5 प्रश्नों पर चर्चा की जाती है, प्रत्येक प्रतिभागी 10-15 मिनट के लिए बोलता है। आप स्प्रे नहीं कर सकते हैं - केवल उन सवालों पर जो परियोजना को लागू करने में मदद करेंगे, उन पर चर्चा की गई है: "एक नए चरण में संक्रमण को क्या रोकता है?", "" कारण को कैसे समाप्त करें? "," समय पर समाप्त करने के लिए क्या करना है? "



3 सूचियाँ

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

लक्ष्यों उच्च प्राथमिकता मध्यम प्राथमिकता कम प्राथमिकता

की विशेषताओं उच्च प्राथमिकता मध्यम प्राथमिकता कम प्राथमिकता

काम के प्रकार उच्च प्राथमिकता मध्यम प्राथमिकता कम प्राथमिकता

परियोजना में परिवर्तन करना

पहले से विचार किए जाने से यह याद रखना आवश्यक है कि परियोजना में कोई भी बदलाव एक बदलाव को दर्शाता है। यदि आवश्यक हो, तो हमेशा अतिरिक्त काम करें:

• या परियोजना पर खर्च होने वाला समय बदल जाएगा;
• या परियोजना की लागत बदल जाएगी;
• या परियोजना की गुणवत्ता बदल जाएगी;
• या परियोजना के भीतर अन्य कार्य कम हो जाएंगे।
  
  

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



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



श्रम लागत का आकलन करने की पद्धति

सेमिनार में, स्कॉट ने परियोजना की श्रम लागत के मूल्यांकन के लिए 2 विकल्प प्रस्तावित किए।



पहला निराशावादी, यथार्थवादी और आशावादी मूल्यांकन विकल्पों पर आधारित है। एक आशावादी विकल्प - संभव जोखिमों को ध्यान में रखे बिना। यथार्थवादी - सबसे अधिक संभावना जोखिमों को ध्यान में रखा जाता है। निराशावादी - सभी जोखिमों को ध्यान में रखा जाता है, जिनमें संभावना नहीं है (जोखिम यथार्थवादी होना चाहिए)।



एक वास्तविक अनुमान सूत्र द्वारा प्राप्त किया गया है:

(आशावादी संस्करण। + ४ * यथार्थवादी संस्करण। निराशावादी संस्करण।) / ६



Pescimists के लिए =) एक अलग सूत्र है:

(आशावादी संस्करण। + ४ * यथार्थवादी संस्करण। + २ * निराशावादी संस्करण।) / +



समूह मूल्यांकन पद्धति

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

इवान	30 दिन 50 दिन 70 दिन
ओल्गा	40 दिन 60 दिन 70 दिन
पीटर	45 दिन 60 दिन 80 दिन

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



यह ध्यान दिया जाना चाहिए कि एक समूह मूल्यांकन में, कर्मचारी अधिक अनुभवी सहयोगियों से मूल्यांकन करना सीखते हैं।



श्रम लागतों की योजना बनाते समय, आपको बीमार छुट्टी, छुट्टियों और सप्ताहांत के बारे में याद रखना होगा। इसके अलावा, आंकड़ों के अनुसार, एक कर्मचारी दिन में सभी 8 घंटे काम नहीं कर पाएगा, उसे कर्मचारियों के साथ वर्तमान मुद्दों पर चर्चा करने के लिए समय चाहिए, परियोजना के बाहर अन्य कार्यों के लिए समय। संयुक्त राज्य अमेरिका में आँकड़ों के अनुसार, काम के घंटे के 30% कर्मचारी अकेले काम करते हैं, 50% दूसरे कर्मचारियों के साथ काम करने के मुद्दों पर संवाद करते हैं, 20% समूहों (बैठक) में अन्य कर्मचारियों के साथ काम करने के मुद्दों पर संवाद करते हैं।



निर्णय लेने की विधि

1. शुरुआत में, निर्णय लेने के संबंध में स्पष्ट रूप से समझना आवश्यक है;
2. क्या विकल्प मौजूद हैं;
3. प्रत्येक विकल्प का + और - का विश्लेषण;
4. विकल्प के बारे में संदेहपूर्ण और आलोचनात्मक विश्लेषण। फैसले के एक हफ्ते बाद क्या होगा।
5. निर्णय लेना;
6. निर्णय का निष्पादन;
7. निर्णय का विश्लेषण। यदि कोई गलती की जाती है, तो इसका विश्लेषण कैसे किया जा सकता है।

यह समझना अनिवार्य है कि प्रश्न वास्तव में कैसा लगता है जिस पर निर्णय किया जाता है। उदाहरण के लिए।

प्रश्न: "क्या मुझे विकास को आउटसोर्स करने की आवश्यकता है?"

इसका मतलब यह हो सकता है: "उच्चतम दक्षता प्राप्त करना आवश्यक है" या "प्रोग्रामर को अनलोड करना आवश्यक है" या "उच्चतम गुणवत्ता वाले उत्पाद को विकसित करना आवश्यक है"।



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



प्रश्न की वास्तविक ध्वनि का निर्धारण करने और प्राथमिकताएं निर्धारित करने के बाद, 5-4 विकल्प एकत्र करना और प्रत्येक के लिए पेशेवरों और विपक्षों को पेंट करना आवश्यक है। वैसे, विकल्प "कुछ भी मत करो" को दूसरों के साथ भी माना जाता है। विकल्प, ध्वनि संदेह और निष्पक्षता के लिए एक महत्वपूर्ण दृष्टिकोण बहुत महत्वपूर्ण है।



कुछ मामलों में, विकल्प का परीक्षण करना उपयोगी है। एक प्रोटोटाइप बनाएं।



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

विकल्प	के लिए (+)	विरुद्ध (-)	रेटिंग (प्राथमिकता)
एक
बी
कुछ मत करो

किसी चीज़ के पहले संस्करण के बारे में कुछ शब्द कहना आवश्यक है। निर्णय लेने के लिए, आपको समस्या का अध्ययन करने की आवश्यकता है। उपयोगकर्ता क्या सामना कर रहा है। पहचान के वाक्य। एक समान उत्पाद श्रेणी।



प्रोजेक्ट क्रैश

यदि कोई प्रोजेक्ट क्रैश अपरिहार्य है, तो निम्न विकल्प संभव हैं:

1. परियोजना का लक्ष्य बदलना;
2. परियोजना रद्द करना;
3. धीमा करें और अगले चरणों पर विचार करें (लक्ष्य को बदलें, परियोजना को रद्द करें और त्रुटियों का विश्लेषण करें);
4. कुछ भी न करें और आपदा का आनंद लें (अच्छा विकल्प नहीं);
5. यह दिखाने के लिए कि इस तरह के एक परियोजना के समापन की कल्पना की गई थी (एक बुरा विकल्प, लेकिन लोग अपनी गलतियों को स्वीकार नहीं करते हैं);
6. संकट को गति दें (कुछ मामलों में, यह विकल्प सबसे अच्छा है)।

भाग 3. टीम प्रबंधन

पिछले भाग "प्रोजेक्ट प्लानिंग एंड टास्क सेटिंग", "प्रोजेक्ट प्रोग्रेस" में, स्कॉट पहले ही प्रोजेक्ट में भाग लेने वाली टीम को संबोधित कर चुके हैं। अब इस मुद्दे पर अधिक विस्तार से विचार करें।



प्रारंभ में, स्कॉट ने दो प्रबंधन विकल्प प्रस्तावित किए - 1. तानाशाही (प्रबंधक अधीनस्थों को बताता है कि क्या करना है, प्रबंधन अटूट अधिकार पर आधारित है) 2. संचार (प्रबंधक कार्य को हल करने के सर्वोत्तम तरीके से मदद करता है, यह बताता है कि इसे करने का सबसे अच्छा तरीका क्या है, प्रबंधक विचार के चारों ओर बुद्धिजीवियों को एक साथ लाता है)। संचार वह नहीं है जो मैं कहता हूं, लेकिन वे मुझे कैसे समझते हैं।



परिचालन संचार बनाना महत्वपूर्ण है। यह महत्वपूर्ण है कि कर्मचारी आरपी को सहायक के रूप में मानते हैं। यह महत्वपूर्ण है कि कर्मचारी न केवल यह समझें कि किस कार्य पर काम किया जाना चाहिए, बल्कि अपने काम और परियोजना के विशिष्ट लक्ष्य को स्पष्ट रूप से जोड़ना चाहिए।



इसे कैसे हासिल किया जा सकता है। स्कॉट कार्य दिवस की शुरुआत में डेवलपर के कार्यालय को देखने और स्पष्ट करने की सिफारिश करता है: एक कर्मचारी क्या कर रहा है? परियोजना के लिए कोई कठिनाइयों और खतरे? आरपी उन्हें हल करने में कैसे मदद कर सकता है? साथ में कॉफी पीने का अच्छा विचार है। परियोजना में शामिल कर्मचारियों की राय और कार्य में रुचि होना महत्वपूर्ण है।



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



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

मैं हूं	एक साथ	कर्मचारी
मैं एक विनिर्देश लिख रहा हूं ...	... ...	मैं एक कोड लिख रहा हूं मैं कीड़े को ठीक करता हूं ...

एक अच्छा समाधान मेज को एक प्रमुख स्थान पर लटका देना होगा।



टीम गठन के चरण में, निर्देशक प्रबंधन आवश्यक है, फिर आपको बस कार्य को निर्देशित करने की आवश्यकता है। यह महत्वपूर्ण है (जैसा कि ऊपर वर्णित है) एक स्थिति बनाने के लिए जहां प्रत्येक टीम का सदस्य समझता है कि वर्तमान में किस लक्ष्य को लागू किया जा रहा है।



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



नए संसाधनों को आवंटित करते समय, अराजकता की अवधि को ध्यान में रखा जाना चाहिए। इसलिए, नए कर्मचारियों पर रिटर्न तुरंत नहीं होगा (संभवतः परियोजना के अंत के बाद)।



हर दिन के लिए आरपी सवाल

1. क्या गलत हो सकता है? किन चीजों के गलत होने की संभावना है?
2. उन्हें रोकने के लिए क्या किया जा सकता है?
3. क्या चेतावनी सेंसर हम सिस्टम में एकीकृत कर सकते हैं?

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



स्कॉट इस बात पर जोर देता है कि समस्या के लिए जिम्मेदार व्यक्ति को किसी भी समस्या को हल करने की आवश्यकता है। लेकिन किसी भी मामले में, आरपी समस्या के समाधान को नियंत्रित करता है।



यदि कोई समस्या होती है, तो आप चिल्ला नहीं सकते, आपको एक समाधान खोजने की आवश्यकता है। सवाल पूछा जाना चाहिए: "क्या करने की जरूरत है ताकि समस्या की पुनरावृत्ति न हो?"



IE टीम संस्करण 1 की संरचना (1994 में)

10-15 कर्मचारियों के लिए 1 आरपी

5-6 प्रोग्रामर

3-4 परीक्षक

2 तकनीकी लेखक



IE टीम संरचना संस्करण 3

40 कर्मचारियों के लिए 2 आरपी



IE टीम संरचना संस्करण 4

200 कर्मचारियों के लिए 25 आरपी



* स्क्रैम बैठकों के बारे में एक छोटा सा विषयांतर

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



मुझे स्क्रेम मीटिंग्स के अन्य विवरण (उदाहरण के लिए, अस्कैट उरगबायेव) मिले हैं: एक दैनिक (आमतौर पर सुबह) 10-15 मिनट की बैठक। इसके अलावा, बैठक परियोजना में समस्याओं को हल करने का इरादा नहीं है। विशेष चर्चा की आवश्यकता वाले सभी मुद्दों को बैठक के दायरे से बाहर लाया जाना चाहिए।



प्रत्येक बैठक के प्रतिभागी 3 प्रश्नों के उत्तर देते हैं:

1. कल क्या किया था?
2. आज क्या किया जाएगा?
3. आपको किन समस्याओं का सामना करना पड़ा?

खराब घोटाले के उदाहरण:

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

उपरोक्त के कारण, अक्सर ऐसा होता है कि बैठकें बहुत देरी से होती हैं। नतीजतन, वे दैनिक समस्या-समाधान बैठकों में बदल जाते हैं। घोटाले में रुचि तुरंत गिर जाती है, इसकी उपयोगिता की भावना गायब हो जाती है।



स्क्रैम के गलत कोर्स से कैसे निपटें:

समस्या	निर्णय
टीम के सदस्य आरपी को "रिपोर्ट" करते हैं, टीम को नहीं	सुनिश्चित करें कि हर कोई समझता है कि एक घोटाले की आवश्यकता क्यों है (टीम के भीतर जानकारी साझा करें); ( ).
	() : :
	; . ; , " Item list " ; " Item list ". , " Item list " //:
	, ; , ; ; — .
—	.. Scrum Notes. ( onsite team) , . , .

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



Development के बारे में

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

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

आप सोच सकते हैं कि यह बकवास है, और इसलिए आप सफल नहीं होंगे। आइए देखें कि जब आप कई वर्षों तक एक ही लोगों के साथ एक घोटाले पर खर्च करते हैं तो आप क्या कहते हैं।