क्या एक प्रोग्रामर को थोड़ा "उत्पाद प्रबंधक" होना चाहिए?

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

पहली चीजें पहले, पृष्ठभूमि की जानकारी की एक श्रृंखला जो मेरी बारीकियों को दर्शाएगी:



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

इसलिए, काम के दौरान, जेआईआरए में अनगिनत कार्यों को निर्धारित और परीक्षण किया गया था। और समाधान के लिए दो मुख्य दृष्टिकोण थे।

किनारे से मेरी झोपड़ी ।।

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

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

क्या होगा अगर?

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

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

नैतिकता

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

और आप किस पद पर हैं? रोचक टिप्पणियों की प्रतीक्षा है।