आपको चुनना होगा कि आपको किस सॉफ्टवेयर की आवश्यकता है: समय या उच्च-गुणवत्ता पर लिखा गया

मुझे उम्मीद है कि मैं इस तरह के उत्तेजक (और, बेशक, अतिरंजित) शीर्षक के साथ आपका ध्यान आकर्षित करने में सक्षम था। सब ठीक है। अब मुझे इसे थोड़ा और सुरुचिपूर्ण और कम मोहक तरीके से सुधारने दें:

सिद्धांत रूप में, सॉफ्टवेयर को समय पर या अच्छी तरह से लिखा जा सकता है, लेकिन दोनों एक ही समय में नहीं *

* मौजूदा उच्च प्रदर्शन टीमों में कुछ मामलों को छोड़कर

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

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

Alconost में अनुवादित

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

तो, काम की योजना बनाना और अच्छा सॉफ्टवेयर देना क्यों मुश्किल है, कठिन समय सीमा निर्धारित करना? मुझे लगता है कि यह काफी हद तक रचनात्मकता , कौशल और अप्रत्याशितता के कारण है ।

प्रोग्रामिंग का रचनात्मक पक्ष

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

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

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



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

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

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

फिर से, यह केंद्रीय योजना अधिवक्ताओं को सॉफ्टवेयर विकास परियोजनाओं में हर पल की उम्मीद करने और मापने की कृपा नहीं करेगा।


मिल्की वे , मंगल और उल्का

प्रोग्रामिंग कौशल

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

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


आंखों से खून बहता है

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

संक्षेप में, एक अच्छे इंजीनियर के पास एक मुश्किल काम होता है: गुणवत्ता का ख्याल रखना - जो लंबे समय में महसूस किया जाएगा - एक ऐसी दुनिया में जहां सब कुछ जल्दी से किया जाना तय है।

व्यवहार में, यह समान चीजों में व्यक्त किया जाता है:

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

कहने की जरूरत नहीं है, यह सब पहले से योजना बनाना असंभव है, इसलिए एक समान दृष्टिकोण अभी भी आपको समय सीमा को पूरा करने में मदद नहीं करेगा।

आपकी भविष्यवाणी गलत है

“भले ही स्पष्ट आवश्यकताएं हों - और ऐसा लगता है कि ऐसा कभी नहीं होता है, किसी विशेष काम के लिए कितना समय लगता है, यह गणना करना लगभग असंभव है, क्योंकि हमने इस समस्या को पहले कभी हल नहीं किया है। यदि आप निर्णय लेते हैं, तो बस आपको परिणाम देना है। ”
- रॉन जेफ्रीस, नोस्टिमेट्स मूवमेंट

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

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

इससे भी बदतर, यह देखते हुए कि समय एक नकारात्मक मूल्य नहीं हो सकता है, किसी भी अनियोजित "आश्चर्य" परियोजना के पूरा होने में देरी की संभावना है, बजाय इसे करीब लाने के, क्योंकि परिणामों की एक विषमता है :

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

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


अच्छा सवाल है

यहाँ कुछ उदाहरण दिए गए हैं जो सॉफ्टवेयर विकास की गैर-रैखिकता और परिणामी प्रतिक्रिया को प्रदर्शित करते हैं:

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

क्या हम खराब हैं?

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


क्या आप ऐसा नहीं कहते?

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

“चूंकि तकनीकी प्रबंधक व्यवसाय और तकनीक के बीच की सीमा पर रहते हैं, यह वे हैं जिन्हें उम्मीदों और वास्तविकता के बीच विरोधाभासों को हल करना है। वे एक लीवर निलंबन की तरह हैं, जिसे अलग-अलग दिशाओं में खींचा जाता है: यह दोनों तरफ से स्नैप कर सकता है। यदि व्यवसाय जीतता है, तो डेवलपर्स को मौत के लिए प्रेरित किया जाता है। अगर इंजीनियरिंग व्यवसाय से संबंधित है, तो बजट और समय सीमा को अलविदा कह सकते हैं। किसी भी मामले में, एक विफलता। एक सफल सॉफ्टवेयर प्रोजेक्ट मैनेजर लचीले ढंग से कार्य करने के तरीके ढूंढता है; उपज के लिए, टूटना नहीं, और धीरे-धीरे घर्षण को हल करें। सेवा के दृष्टिकोण के रूप में नेतृत्व आपको अधिक लचीला बनने में मदद कर सकता है। "
- एरोन लॉन्गवेल, क्यों सॉफ्टवेयर डेवलपमेंट के लिए सेवक नेताओं की आवश्यकता होती है

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

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

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

अंत में, मैं कहूंगा कि यह एक हल करने योग्य, यद्यपि जटिल (और आम) समस्या है। मैं कहूंगा कि यदि, आपकी राय में, आपके प्रबंधक या आपके संगठन को अच्छा सॉफ़्टवेयर लिखने की इच्छा नहीं है, तो आपको इसके बारे में बोलने और इसे बदलने की कोशिश करने की आवश्यकता है; यदि यह विफल रहता है, तो दूसरी नौकरी ढूंढें।

अनुवादक के बारे में

लेख का अनुवाद अल्कोनोस्ट ने किया था।

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

हम विज्ञापन और प्रशिक्षण वीडियो भी बनाते हैं - Google Play और ऐप स्टोर के लिए बिक्री, छवि, विज्ञापन, प्रशिक्षण, टीज़र, खोजकर्ता, ट्रेलरों के लिए।

अधिक जानकारी