हैप्पी ProductOwner राइडिंग एक पाउडर केग

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

आइए जानें कि अपनी स्वयं की विकास इकाई को कैसे रोकें और सफल हों।



प्रक्रिया है

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

हम क्या कर रहे हैं?

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

मैं विभाग प्रमुखों से सीधे सवाल पूछने की सलाह नहीं देता हूं - अपने आप को सबसे खराब दुश्मन बनाओ - आप करेंगे, आपको यह रहस्य पता चलता है कि उनके विभागों में कर्मचारी ... नहीं जानते कि वे क्या कर रहे हैं :-)

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

कभी-कभी कंपनी अभी भी परियोजना आवश्यकताओं को एकत्र करने का प्रबंधन करती है।

साथ लाओ

एकत्रित जानकारी के आधार पर, अत्यधिक महत्व की कई कलाकृतियां बनाएं:

1) शब्दावली। यह शब्द = अर्थ। यदि आप ऐसा नहीं करते हैं, तो आप विभागों से "स्मार्ट" कर्मचारियों के साथ संचार जारी रखने में सक्षम नहीं होंगे, आप विश्लेषक को समझने में सक्षम नहीं होंगे, और आप उस विकास को नहीं समझ पाएंगे जो हम जल्द ही जाने वाले हैं।

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

3) इंटरफेस के प्रोटोटाइप। विश्लेषक के साथ वेबसाइट के पृष्ठों के प्रोटोटाइप को हाथ से या पैर से ड्रा करें। कोई विवरण नहीं।

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

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

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

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

हम रिलीज की योजना बनाते हैं

आपके द्वारा देखे गए उत्पाद की तार्किक रीढ़ 50% सफलता है। आगे तकनीक का मामला है। हम डेवलपर्स के पास जाते हैं। हम प्रत्येक श्रेणी की पूर्व निर्धारित औसत रेटिंग के साथ सुविधाओं को जटिल / मध्यम / सरल में वितरित करते हैं।

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

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

मैं StoryMapping नामक एक शो आयोजित करने की अनुशंसा नहीं करता - जब तक कि लोगों का मनोरंजन करना और पार्टी का माहौल बनाना आपका काम नहीं है। धुंधला औपचारिकता वाला एक उपकरण, मुझे लगता है, केवल सरल सिस्टम या ... विशाल सिस्टम के लिए उपयुक्त है।

हम पहली रिलीज में सर्वोच्च प्राथमिकता वाली विशेषताओं में शामिल हैं। नतीजतन, हमें एक मोटा प्रोजेक्ट रिलीज़ प्लान मिलता है। हम प्रत्येक रिलीज के लिए एक तंग लॉन्च की तारीख और समग्र रूप से परियोजना की घोषणा करते हैं।

विशेष विज्ञप्ति

मैं दृढ़ता से अनुशंसा करता हूं कि आप परीक्षण डेटा पर लोड परीक्षण करने के अंतिम चरणों में से एक को शामिल करते हैं। अन्यथा, आप परियोजना शुरू कर सकते हैं, और यह ... 2-3 दिनों में झुक जाएगा।

एक गुणवत्ता रिलीज भी बहुत उपयोगी है - कंपनी के भीतर एक व्यापक बीटा परीक्षण किया जाता है। फिर से हम सभी कार्यक्षमता की जांच करते हैं।

एक संदर्भ बिंदु चुनें

एक महत्वपूर्ण बिंदु। आपको निर्णय लेने और निर्णय लेने की आवश्यकता है:

स्क्रैच से लेखन

यदि आपका काम प्रोग्रामर्स को अपग्रेड करना है, तो मैं एक प्रोजेक्ट लिखने की सलाह देता हूं ... स्क्रैच :-) से। यदि आपको 4 महीने में ऑनलाइन स्टोर शुरू करने की आवश्यकता है - इस आइटम को एक बुरे सपने के रूप में भूल जाएं।

सच है, अगर आप इस रास्ते पर चलते हैं - आप अपनी टीम के प्रोग्रामर के दोस्त बन जाते हैं, तो वे आपको गलियारों में बधाई देंगे। फिर भी - उन्होंने लोगों को पंप करने का ऐसा मौका दिया :-)

हम "इकाई" से लिखते हैं

डेवलपर्स के प्रमुख (यदि वह टीमों के पीछे छिपा है, तो उसे ढूंढना सुनिश्चित करें - कंपनी के पास हमेशा एक है) "निम्न-स्तरीय" ढांचे का उपयोग करके विकास के समय को कम करने का सुझाव दे सकता है। PHP के लिए कई हैं: ZendFramework, Yii, Symfony, CakePHP ...

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

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

विकास टीम के दूसरे भाग के बारे में आपके मित्र बन जाएंगे वे समझते हैं कि आप ढांचे पर थोड़ा पंप कर सकते हैं। पहली छमाही आपके लिए खो गई है।

लेकिन हमारा काम 4 महीने में शुरू होना है। इसलिए, रूपरेखा सबसे अधिक संभावना है कि हमें नहीं बचाएगी।

हम बॉक्सिंग समाधान के आधार पर लिखते हैं

यहां पहला मुख्य कार्य यह समझना है कि बॉक्स कैसे काम करता है और क्या इसका तर्क विकृत बिलिंग के साथ ऑनलाइन स्टोर बनाने के आपके कार्य में फिट बैठता है। मैं अपने आप को यह पता लगाने और विश्लेषक का पता लगाने की सलाह देता हूं। अगर यह पता चला है कि फिट बैठता है - आप भाग्य में हैं।

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

एक बड़ा ऋण - डेवलपर्स आपको ग्रीटिंग को रोकने की संभावना है। उन्हें ALIEN कोड को अंतिम रूप देकर स्पष्ट व्यावसायिक समस्याओं पर काम करना होगा और हल करना होगा - और यह नौसिखिए प्रोग्रामर के लिए बहुत कठिन है। हर कोई अपने दम पर वास्तविकता बनाना चाहता है :-)

एक बॉक्सिंग समाधान चुनना ... यदि आपके पास एक बहुत मजबूत और अनुभवी ओओपी विकास टीम है, तो लगभग 100k के मॉस्को में औसत वेतन और लगभग दस लोगों की एक टीम है, मैगेंटो एक फैंसी स्टोर के लिए एक अच्छा फिट है।

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

इसके अलावा, यदि आप "क्यों ऑनलाइन स्टोर धीमा होना शुरू हुआ, ग्राहकों की शिकायत है" या "क्यों ऑनलाइन स्टोर कल सुबह 9 बजे से सुबह 11 बजे तक उपलब्ध नहीं था, इसके बारे में विकास टीम के साथ बहस नहीं करना चाहते हैं" :-) - IMMEDIATIY एक वेब-प्रकार परियोजना बनाएं -क्लस्टर - उपरोक्त बॉक्स में लाभ एक ऐसा अवसर है ।

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

स्प्रिंट कर

अपने स्वार्थों में स्प्रिंट सुविधाओं की गुणवत्ता है। एक कठिन झरना गुणवत्ता नियंत्रण चक्र की कमी के कारण, आप फेकल संगति सुविधाओं के तेजी से विकास में चलने का जोखिम उठाते हैं।

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

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

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

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

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

कभी-कभी आप एक परीक्षण विभाग के निर्माण को प्राप्त कर सकते हैं और इसके माध्यम से पूरा होने वाले स्प्रिंट को पारित करने की आवश्यकता होती है। मारो और पाओ।

स्प्रिंट लोड करें

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

विश्लेषक आपका दोस्त है

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

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

मूल्यांकन परीक्षा

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

प्रक्रिया समायोजन

स्क्रम अच्छी जैसी लचीली कार्यप्रणाली क्या प्रक्रिया का खुलापन है। यदि यह काम नहीं करता है और परियोजना ध्वस्त हो जाती है, तो यह सभी को दिखाई देता है, इसे अच्छी तरह से देखा जा सकता है। यह पता चला है कि:

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

आप सरलीकृत आरयूपी की दिशा में पागल को कस सकते हैं:

- विश्लेषक के साथ पुनरावृति के लिए टीके लिखें
- विकास विभाग / तकनीकी निदेशक के प्रमुख के साथ टीके का मूल्यांकन करें
- विकास, इकाई परीक्षणों के सफल निष्पादन (काम को स्वीकार करने के समय कम से कम) का प्रदर्शन करते हुए सावधानीपूर्वक पुनरावृति परिणामों का परीक्षण करता है
- प्रदर्शन किए गए कार्य को सावधानीपूर्वक स्वीकार करें, विश्लेषक भी इसमें आपकी मदद करते हैं

हां। यह साम्यवाद के साथ पूंजीवाद का युद्ध होगा। लेकिन एक ऑनलाइन स्टोर जीतने और लॉन्च करने का मौका, हालांकि 4 महीने में नहीं, लेकिन ... एक साल में, :-)