IT परियोजनामा ​​रहेको टोलीमा कार्यप्रवाहको संगठन

नमस्ते साथीहरु। प्रायः, विशेष गरी आउटसोर्सिङमा, म उही चित्र देख्छु। विभिन्न परियोजनाहरूमा टोलीहरूमा स्पष्ट कार्यप्रवाहको अभाव।

सबैभन्दा महत्त्वपूर्ण कुरा यो हो कि प्रोग्रामरहरूले ग्राहकसँग र एकअर्कासँग कसरी कुराकानी गर्ने भनेर बुझ्दैनन्। गुणस्तरीय उत्पादन विकास गर्ने निरन्तर प्रक्रिया कसरी निर्माण गर्ने। तपाईंको कार्य दिन र स्प्रिन्टहरू कसरी योजना गर्ने।

र यी सबैले अन्तत: छुटेको समयसीमा, ओभरटाइम, कसलाई दोष दिने भन्ने बारे निरन्तर शोडाउन, र सबै कुरा कहाँ र कसरी चलिरहेको छ भन्ने बारे ग्राहकको असन्तुष्टिमा परिणाम हुन्छ। प्रायः, यो सबै प्रोग्रामरहरू, वा सम्पूर्ण टोलीहरूको परिवर्तनमा जान्छ। ग्राहकको हानि, प्रतिष्ठाको ह्रास, र यति।

एक पटक, म भर्खरै यस्तो परियोजनामा ​​पुगें, जहाँ यी सबै आनन्दहरू थिए।

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

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

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

हाम्रो तर्फबाट यस दृष्टिकोणको लागि धन्यवाद, ग्राहकले हाम्रो कम्पनीबाट अर्को बजार अर्डर गर्ने निर्णय गरे, जुन राम्रो समाचार हो।

यो मेरो परियोजना मा काम गर्दछ, हुनसक्छ यो पनि कसैलाई मद्दत गर्नेछ। त्यसोभए, प्रक्रिया आफैले हामीलाई परियोजना बचत गर्न मद्दत गर्‍यो:

परियोजना "मेरो मनपर्ने परियोजना" मा टोली काम को प्रक्रिया

क) आन्तरिक टोली प्रक्रिया (विकासकर्ताहरू बीच)

• जिरा प्रणालीमा सबै समस्याहरू सिर्जना हुन्छन्
• प्रत्येक कार्यलाई सकेसम्म धेरै वर्णन गरी कडाईका साथ एक कार्य गर्नुपर्दछ
• कुनै पनि सुविधा, यदि यो पर्याप्त जटिल छ भने, धेरै साना कार्यहरूमा विभाजित हुन्छ
• टोलीले एकल कार्यको रूपमा सुविधाहरूमा काम गर्दछ। पहिले, हामी सबै एउटै सुविधामा सँगै काम गर्छौं, यसलाई परीक्षणको लागि पठाउनुहोस्, त्यसपछि अर्को लिनुहोस्।
• प्रत्येक कार्य ब्याकइन्ड वा फ्रन्टएन्डको लागि चिन्ह लगाइएको छ
• त्यहाँ प्रकारका कार्यहरू र बगहरू छन्। तपाईंले तिनीहरूलाई सही रूपमा संकेत गर्न आवश्यक छ।
• कार्य पूरा गरेपछि, यो कोड समीक्षा स्थितिमा हस्तान्तरण गरिन्छ (यस अवस्थामा, एक सहकर्मीको लागि पुल अनुरोध सिर्जना गरिएको छ)
• कार्य पूरा गर्ने व्यक्तिले तुरुन्तै यस कार्यको लागि आफ्नो समय ट्र्याक गर्दछ।
• कोड जाँच गरेपछि, PR ले अनुमोदन गर्नेछ र त्यस पछि, यो कार्य गर्ने व्यक्तिले यसलाई स्वतन्त्र रूपमा मास्टर शाखामा मर्ज गर्दछ, त्यसपछि उसले यसको स्थितिलाई dev सर्भरमा डिप्लोइमेन्टको लागि तयार पार्छ।
• dev सर्भरमा तैनातीका लागि तयार भएका सबै कार्यहरू टोली नेतृत्व (उहाँको जिम्मेवारीको क्षेत्र), कहिलेकाहीँ टोली सदस्यद्वारा, यदि केहि जरुरी छ भने, द्वारा तैनात गरिन्छ। डिप्लोयमेन्ट पछि, डिप्लोयमेन्टका लागि तयार देखि dev मा सबै कार्यहरू स्थितिमा हस्तान्तरण गरिन्छ - dev मा परीक्षणको लागि तयार
• सबै कार्यहरू ग्राहक द्वारा परीक्षण गरिन्छ
• जब ग्राहकले dev मा कार्य परीक्षण गरेको छ, उसले यसलाई उत्पादनमा प्रयोगको लागि तयार स्थितिमा स्थानान्तरण गर्दछ।
• उत्पादनमा डिप्लोइमेन्टको लागि, हामीसँग छुट्टै शाखा छ, जहाँ हामी डिप्लोइमेन्ट अघि मात्र मास्टर मर्ज गर्छौं।
• यदि परीक्षणको क्रममा ग्राहकले बगहरू फेला पार्छ भने, उसले संशोधनको लागि कार्य फिर्ता गर्छ, यसको स्थितिलाई संशोधनको लागि फिर्ता गरिएको रूपमा सेट गर्दछ। यसरी हामी नयाँ कार्यहरू परीक्षणमा उत्तीर्ण नभएकाहरूबाट अलग गर्छौं।
• नतिजाको रूपमा, सबै कार्यहरू सिर्जनाबाट पूरा गर्न जान्छन्: गर्न → विकासमा → कोड समीक्षा → dev मा डिप्लोय गर्न तयार → ​​dev मा QA → (dev मा फर्कनुहोस्) → उत्पादनमा डिप्लोय गर्न तयार → ​​उत्पादनमा QA → सम्पन्न
• प्रत्येक विकासकर्ताले आफ्नो कोड स्वतन्त्र रूपमा परीक्षण गर्दछ, साइट प्रयोगकर्ताको रूपमा सहित। कोडले काम गर्छ भनेर निश्चित रूपमा थाहा नभएसम्म शाखालाई मुख्यमा मर्ज गर्न अनुमति छैन।
• हरेक कामको प्राथमिकता हुन्छ । प्राथमिकताहरू ग्राहक वा टोली नेतृत्व द्वारा सेट गरिन्छ।
• विकासकर्ताहरूले प्राथमिकताका कार्यहरू पहिले पूरा गर्छन्।
• विकासकर्ताहरूले एकअर्कालाई कार्यहरू तोक्न सक्छन् यदि प्रणालीमा विभिन्न बगहरू फेला परेका थिए वा एउटा कार्यमा धेरै विशेषज्ञहरूको काम समावेश हुन्छ।
• ग्राहकले सिर्जना गर्ने सबै कार्यहरू टोलीको नेतृत्वमा जान्छन्, जसले तिनीहरूलाई मूल्याङ्कन गर्छ र या त ग्राहकलाई तिनीहरूलाई परिमार्जन गर्न वा टोलीका सदस्यहरू मध्ये एकलाई तोक्न अनुरोध गर्दछ।
• dev वा prod मा डिप्लोइमेन्टका लागि तयार भएका सबै कार्यहरू पनि टोलीको नेतृत्वमा जान्छन्, जसले कहिले र कसरी डिप्लोइमेन्ट गर्ने भनेर स्वतन्त्र रूपमा निर्धारण गर्दछ। प्रत्येक तैनाती पछि, टोली नेतृत्व (वा टोली सदस्य) ले यस बारे ग्राहकलाई सूचित गर्नुपर्छ। र dev/cont को लागि परीक्षणको लागि तयार कार्यका लागि स्थितिहरू पनि परिवर्तन गर्नुहोस्।
• प्रत्येक दिन एकै समयमा (हाम्रो लागि यो 12.00 मा छ) हामी सबै टोली सदस्यहरू बीच बैठक राख्छौं
• बैठकमा उपस्थित सबैले टोलीको नेता सहित, उनीहरूले हिजो के गरे र आज के गर्ने योजनामा ​​रिपोर्ट गर्छन्। के काम गर्दैन र किन। यसरी सम्पूर्ण टोलीलाई कसले के गरिरहेको छ र परियोजना कुन चरणमा छ भन्ने कुरा थाहा हुन्छ। यसले हामीलाई भविष्यवाणी गर्ने र समायोजन गर्ने अवसर दिन्छ, आवश्यक भएमा, हाम्रा अनुमानहरू र समयसीमाहरू।
• बैठकमा, टोली नेतृत्वले परियोजनामा ​​भएका सबै परिवर्तनहरू र हालको बगहरूको स्तरको बारेमा पनि बोल्छ जुन ग्राहकले फेला परेन। सबै बगहरू क्रमबद्ध छन् र तिनीहरूलाई समाधान गर्न प्रत्येक टोली सदस्यलाई तोकिएको छ।
• बैठकमा, टोली नेताले विकासकर्ताहरूको हालको कार्यभार, तिनीहरूको व्यावसायिक प्रशिक्षणको स्तर, र विकासकर्ताले हाल के गरिरहेको छ भन्ने कुरामा विशेष कार्यको निकटतालाई ध्यानमा राख्दै प्रत्येक व्यक्तिलाई कार्यहरू तोक्छ।
• बैठकमा, टोली नेताले वास्तुकला र व्यापार तर्कको लागि एक सामान्य रणनीति विकास गर्दछ। त्यसपछि सम्पूर्ण टोलीले यसबारे छलफल गर्छ र समायोजन गर्ने वा यो रणनीति अपनाउने निर्णय गर्छ।
• प्रत्येक विकासकर्ताले कोड लेख्छन् र एल्गोरिदमहरू एकल वास्तुकला र व्यापार तर्कको ढाँचा भित्र स्वतन्त्र रूपमा निर्माण गर्दछ। सबैले आफ्नो कार्यान्वयनको दृष्टिकोण व्यक्त गर्न सक्छन्, तर कसैले कसैलाई यसरी गर्न बाध्य पार्दैन र अन्यथा होइन। हरेक निर्णय जायज छ। यदि त्यहाँ राम्रो समाधान छ, तर अहिले यसको लागि कुनै समय छैन, त्यसपछि कोडको निश्चित भागको भविष्यको रिफ्याक्टरिंगको लागि फ्याटमा कार्य सिर्जना गरिएको छ।
• जब एक विकासकर्ताले कार्य लिन्छ, उसले यसलाई विकास स्थितिमा स्थानान्तरण गर्दछ। ग्राहक संग कार्य को स्पष्टीकरण को बारे मा सबै संचार विकासकर्ता को काँध मा पर्छ। प्राविधिक प्रश्नहरू टोली नेतृत्व वा सहकर्मीहरूलाई सोध्न सकिन्छ।
• यदि विकासकर्ताले कार्यको सार बुझ्दैन भने, र ग्राहकले यसलाई स्पष्ट रूपमा व्याख्या गर्न असमर्थ थियो, त्यसपछि उसले अर्को कार्यमा जान्छ। र टोली नेतृत्वले हालको लिन्छ र ग्राहकसँग छलफल गर्दछ।
• हरेक दिन, विकासकर्ताले ग्राहकको च्याटमा लेख्नु पर्छ कि उसले हिजो कुन कार्यहरूमा काम गर्यो र कुन कार्यहरूमा उसले आज काम गर्नेछ।
• कार्य प्रक्रिया Scrum अनुसार लिन्छ। सबै कुरा स्प्रिन्टहरूमा विभाजित छ। प्रत्येक स्प्रिन्ट दुई हप्ता सम्म रहन्छ।
• स्प्रिन्टहरू बनाइन्छ, भरिन्छ र टोली नेतृत्वद्वारा बन्द हुन्छ।
• यदि परियोजनामा ​​कडा समयसीमा छ भने, हामी लगभग सबै कार्यहरू अनुमान गर्न प्रयास गर्छौं। र हामीले तिनीहरूलाई स्प्रिन्टमा सँगै राख्यौं। यदि ग्राहकले स्प्रिन्टमा थप कार्यहरू थप्ने प्रयास गर्छ भने, हामी प्राथमिकताहरू सेट गर्छौं र अर्को स्प्रिन्टमा केही अन्य कार्यहरू स्थानान्तरण गर्छौं।

ख) ग्राहकसँग काम गर्ने प्रक्रिया

• प्रत्येक विकासकर्ताले ग्राहकसँग कुराकानी गर्न सक्छ र गर्नुपर्छ
• ग्राहकलाई खेलको आफ्नै नियमहरू लागू गर्न अनुमति दिन सकिँदैन। यो ग्राहकलाई विनम्र र मैत्रीपूर्ण तरिकाले स्पष्ट गर्न आवश्यक छ कि हामी हाम्रो क्षेत्रका विशेषज्ञहरू हौं, र केवल हामीले कार्य प्रक्रियाहरू निर्माण गर्नुपर्छ र ग्राहकलाई त्यसमा समावेश गर्नुपर्छ।
• यो आवश्यक छ, आदर्श रूपमा, कुनै पनि कार्यक्षमता लागू गर्न सुरु गर्नु अघि, सुविधा (कार्यप्रवाह) को लागि सम्पूर्ण तार्किक प्रक्रियाको फ्लोचार्ट सिर्जना गर्न। र पुष्टिकरणको लागि ग्राहकलाई पठाउनुहोस्। यो केवल जटिल र स्पष्ट कार्यक्षमता मा लागू हुन्छ, उदाहरण को लागी, एक भुक्तानी प्रणाली, सूचना प्रणाली, आदि। यसले हामीलाई ग्राहकलाई ठ्याक्कै के चाहिन्छ भनेर बुझ्न, सुविधाको लागि कागजातहरू बचत गर्न, र ग्राहकले भविष्यमा हामीले उसले सोधेको कुरा हामीले गरेनौं भन्ने तथ्यको बिरूद्ध आफैलाई बीमा गर्न अनुमति दिनेछ।
• सबै रेखाचित्र/फ्लोचार्ट/तर्क आदि। हामी यसलाई कन्फ्लुएन्स/फ्याटमा बचत गर्छौं, जहाँ हामी ग्राहकलाई टिप्पणीहरूमा भविष्यको कार्यान्वयनको शुद्धता पुष्टि गर्न सोध्छौं।
• हामी प्राविधिक विवरणहरूको साथ ग्राहकलाई बोझ नदिने प्रयास गर्छौं। यदि हामीलाई ग्राहकले यो कसरी चाहन्छन् भन्ने बुझाइ चाहिन्छ भने, हामी एक फ्लोचार्टको रूपमा आदिम एल्गोरिदमहरू कोर्छौं जुन ग्राहकले आफैंले बुझ्न र सच्याउन/परिमार्जन गर्न सक्छ।
• यदि ग्राहकले परियोजनामा ​​बग फेला पार्छ भने, हामी तपाईंलाई फ्याटमा यसलाई विस्तृत रूपमा वर्णन गर्न सोध्छौं। कुन परिस्थितिमा यो भयो, कहिले, परीक्षणको क्रममा ग्राहकद्वारा कार्यहरूको कुन क्रम गरिएको थियो। कृपया स्क्रिनसटहरू संलग्न गर्नुहोस्।
• हामी हरेक दिन प्रयास गर्छौं, हरेक दिन धेरैमा, dev सर्भरमा डिप्लोय गर्न। ग्राहकले त्यसपछि कार्यक्षमता परीक्षण गर्न थाल्छ र परियोजना निष्क्रिय खडा हुँदैन। एकै समयमा, यो ग्राहकको लागि मार्कर हो कि परियोजना पूर्ण विकासमा छ र कसैले पनि उसलाई परी कथाहरू बताइरहेको छैन।
• यो अक्सर हुन्छ कि ग्राहकले पूर्णतया बुझ्दैन कि उसलाई के चाहिन्छ। किनभने उसले आफ्नो लागि नयाँ व्यवसाय सिर्जना गर्दैछ, प्रक्रियाहरू जुन अहिलेसम्म स्थापित भएको छैन। त्यसकारण, एक धेरै सामान्य अवस्था हो जब हामी कोडको सम्पूर्ण टुक्राहरू रद्दीटोकरीमा फाल्छौं र अनुप्रयोग तर्कलाई पुन: डिजाइन गर्छौं। यो यसबाट पछ्याउँछ कि तपाईंले परीक्षणको साथ सबै कुरा कभर गर्नु हुँदैन। यो परीक्षणको साथ मात्र महत्वपूर्ण कार्यक्षमता कभर गर्न को लागी अर्थ बनाउँछ, र त्यसपछि मात्र आरक्षण संग।
• त्यहाँ परिस्थितिहरू छन् जब टोलीले महसुस गर्छ कि हामीले समयसीमा पूरा गरिरहेका छैनौं। त्यसपछि हामी कार्यहरूको द्रुत अडिट सञ्चालन गर्छौं र तुरुन्तै ग्राहकलाई यसको बारेमा सूचित गर्दछौं। परिस्थितिबाट बाहिर निस्कने उपायको रूपमा, हामी महत्त्वपूर्ण र महत्वपूर्ण कार्यक्षमतालाई समयमै सुरू गर्न र बाँकीलाई पोस्ट-रिलीजको लागि छोड्ने सुझाव दिन्छौं।
• यदि ग्राहकले आफ्नो टाउकोबाट विभिन्न कार्यहरू लिएर आउन थाल्छ, कल्पना गर्न थाल्छ र औंलाहरूले व्याख्या गर्न थाल्छ, तब हामी उहाँलाई पृष्ठ लेआउट प्रदान गर्न र सम्पूर्ण लेआउटको व्यवहारलाई पूर्ण रूपमा वर्णन गर्ने तर्कसहित प्रवाह गर्न अनुरोध गर्छौं। यसको तत्वहरू।
• कुनै पनि कार्य लिनु अघि, हामीले यो सुविधा हाम्रो सम्झौता/अनुबंधका सर्तहरूमा समावेश गरिएको छ भनी सुनिश्चित गर्नुपर्छ। यदि यो नयाँ सुविधा हो जुन हाम्रो प्रारम्भिक सम्झौताहरू भन्दा बाहिर जान्छ भने, हामीले यो सुविधाको मूल्य (अनुमानित समाप्ति समय + 30%) x 2) र ग्राहकलाई संकेत गर्नुपर्छ कि यसले हामीलाई पूरा गर्न यति धेरै समय लिनेछ, साथै समयसीमा अनुमानित समयलाई दुईले गुणा गरेर सारियो। कार्य छिटो गरौं - उत्कृष्ट, सबैले यसबाट लाभान्वित हुनेछन्। यदि होइन भने, हामीले तपाइँलाई कभर गरेका छौं।

ग) हामीले टोलीमा के स्वीकार गर्दैनौं:

• असीमितता, संयमताको कमी, बिर्सनेपन
• "ब्रेकफास्ट खुवाउने।" यदि तपाइँ कार्य पूरा गर्न सक्नुहुन्न र कसरी थाहा छैन भने, तपाइँ तुरुन्तै टोलीको नेतृत्वलाई सूचित गर्न आवश्यक छ, र अन्तिम मिनेट सम्म पर्खनु हुँदैन।
• एक व्यक्तिबाट ब्राउज र गर्व गर्दछ जसले अझै आफ्नो क्षमता र व्यावसायिकता प्रमाणित गरेको छैन। यदि यो प्रमाणित भयो भने, यो सम्भव छ, शालीनताको सीमा भित्र :)
• यसको सबै रूपहरूमा धोखा। यदि कुनै कार्य पूरा भएन भने, तपाईंले यसको स्थितिलाई पूर्णमा परिवर्तन गर्नु हुँदैन र क्लाइन्ट च्याटमा लेख्नुहोस् कि यो तयार छ। कम्प्युटर बिग्रियो, प्रणाली क्र्यास भयो, कुकुरले ल्यापटपमा चबायो - यो सबै अस्वीकार्य छ। यदि एक वास्तविक बल majeure घटना हुन्छ, टोली नेतृत्व तुरुन्तै सूचित गर्नुपर्छ।
• जब एक विशेषज्ञ सबै समय अफलाइन हुन्छ र कामको घण्टामा उसलाई पुग्न गाह्रो हुन्छ।
• टोलीमा विषाक्तता अनुमति छैन! कसैको कुनै कुरामा असहमति भएमा सबैजना भेला भएर र्‍यालीमा बसेर छलफल गरेर निर्णय गर्छन् ।

र धेरै प्रश्नहरू/थीसहरू जुन मैले कहिलेकाहीँ मेरो ग्राहकलाई सबै गलतफहमीहरू हटाउन सोध्छु:

1. तपाईको गुणस्तर मापदण्ड के हो?
2. परियोजनामा ​​समस्या छ वा छैन भनेर कसरी निर्धारण गर्नुहुन्छ?
3. प्रणाली परिवर्तन/सुधार गर्ने सम्बन्धमा हाम्रा सबै सिफारिसहरू र सल्लाहहरू उल्लङ्घन गरेर, सबै जोखिमहरू तपाईंले मात्र वहन गर्नुहुन्छ।
4. परियोजनामा ​​कुनै पनि प्रमुख परिवर्तनहरू (उदाहरणका लागि, सबै प्रकारका अतिरिक्त प्रवाहहरू) बगहरूको सम्भावित उपस्थितिको नेतृत्व गर्नेछ (जसलाई हामी निश्चित रूपमा ठीक गर्नेछौं)
5. यो परियोजनामा ​​कस्तो प्रकारको समस्या आयो केहि मिनेट भित्र बुझ्न असम्भव छ, धेरै कम यसलाई तुरुन्तै समाधान गर्नुहोस्
6. हामी एक विशिष्ट उत्पादन प्रवाह (Zhira मा कार्य - विकास - परीक्षण - तैनाती) मा काम गर्दछौं। यसको मतलब हामी च्याटमा भएका अनुरोध र गुनासोहरूको सम्पूर्ण प्रवाहलाई जवाफ दिन सक्दैनौं।
7. प्रोग्रामरहरू प्रोग्रामरहरू हुन्, व्यावसायिक परीक्षकहरू होइनन्, र परियोजना परीक्षणको उचित गुणस्तर सुनिश्चित गर्न सक्दैनन्
8. अन्तिम परीक्षण र उत्पादन कार्यहरूको स्वीकृतिको लागि जिम्मेवारी पूर्ण रूपमा तपाईंसँग छ
9. यदि हामीले पहिले नै एउटा कार्य लिइसकेका छौं भने, हामीले हालको कार्य पूरा नगरेसम्म हामी तुरुन्तै अरूमा स्विच गर्न सक्दैनौं (अन्यथा यसले अझ धेरै बगहरू र विकास समय बढाउँछ)।
10. टोलीमा कम व्यक्तिहरू छन् (बिदा वा बिरामीहरूको कारण), तर त्यहाँ धेरै काम छ र हामीसँग शारीरिक रूपमा तपाईले चाहानु भएको सबै कुराको जवाफ दिने समय हुँदैन।
11. हामी तपाईंलाई dev मा परीक्षण गरिएका कार्यहरू बिना उत्पादनमा डिप्लोयमेन्ट गर्न सोध्छौं - यो केवल तपाईंको जोखिम हो, विकासकर्ताहरूको होइन।
12. जब तपाइँले अस्पष्ट कार्यहरू सेट गर्नुहुन्छ, सही प्रवाह बिना, डिजाइन लेआउट बिना, यसको लागि हामीबाट धेरै प्रयास र कार्यान्वयन समय चाहिन्छ, किनकि हामीले तपाइँको सट्टा थप काम गर्नु पर्छ।
13. बगहरूमा कुनै पनि कार्यहरू, तिनीहरूको घटना र स्क्रिनसटहरूको विस्तृत विवरण बिना, हामीलाई के गल्ती भयो र हामी यो बग कसरी समाधान गर्न सक्छौं भनेर बुझ्ने मौका दिँदैन।
14. कार्यसम्पादन र सुरक्षा सुधार गर्न परियोजनालाई निरन्तर परिष्करण र सुधारहरू आवश्यक छ। त्यसकारण, टोलीले आफ्नो समयको केही भाग यी सुधारहरूमा खर्च गर्दछ
15. हामीसँग घण्टा (अत्यावश्यक समाधानहरू) द्वारा ओभरटाइम भएको तथ्यको कारणले गर्दा, हामीले अन्य दिनहरूमा तिनीहरूको लागि क्षतिपूर्ति गर्नुपर्छ।

एक नियमको रूपमा, ग्राहकले तुरुन्तै बुझ्छ कि सफ्टवेयर विकासमा सबै कुरा यति सरल छैन, र एक्लै इच्छा स्पष्ट रूपमा पर्याप्त छैन।

सामान्यतया, यो सबै हो। म पर्दा पछाडि धेरै वार्तालापहरू र सबै प्रक्रियाहरूको प्रारम्भिक डिबगिङ छोड्छु, तर नतिजाको रूपमा, सबै काम भयो। म भन्न सक्छु कि यो प्रक्रिया हाम्रो लागि एक प्रकारको "सिल्भर बुलेट" बन्यो। परियोजनामा ​​​​आएका नयाँ व्यक्तिहरू तुरुन्तै पहिलो दिनबाट काममा संलग्न हुन सक्छन्, किनकि सबै प्रक्रियाहरू वर्णन गरिएको थियो, र रेखाचित्रको रूपमा कागजात र वास्तुकलाले तुरुन्तै हामी सबै यहाँ के गर्दैछौं भनेर एक विचार दिन्छ।

PS म स्पष्ट गर्न चाहन्छु कि हाम्रो पक्षमा कुनै परियोजना प्रबन्धक छैन। यो ग्राहकको पक्षमा छ। प्राविधिक पटक्कै होइन। युरोपेली परियोजना। सबै संचार अंग्रेजी मा मात्र छ।

तपाईका परियोजनाहरूमा सबैलाई शुभकामना। जलाउन नदिनुहोस् र आफ्नो प्रक्रियाहरू सुधार गर्ने प्रयास गर्नुहोस्।

मेरो मा स्रोत ब्लग पोष्ट.

स्रोत: www.habr.com