डेवलपर्स को व्यवसाय डोमेन को समझना चाहिए या क्या विनिर्देश पर्याप्त होना चाहिए?


52

मैं एक ऐसी कंपनी के लिए काम करता हूं जिसके लिए डोमेन समझना वास्तव में मुश्किल है क्योंकि यह इलेक्ट्रॉनिक्स में उच्च तकनीक है, लेकिन यह एक जटिल डोमेन में किसी भी सॉफ़्टवेयर विकास के लिए लागू है।

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

इस तरह, डेवलपर वास्तव में व्यवसाय को नहीं समझता है और वह इस कार्य को क्या / क्यों कर रहा है। यह ठीक हो सकता है यदि विनिर्देश वास्तव में विस्तृत है, लेकिन जब यह नहीं है या जब लेखक एक उपयोग के मामले को भूल गया है, तो डेवलपर के लिए समाधान खोजने के लिए यह काफी कठिन है।

दूसरी ओर, हर डेवलपर को सभी व्यावसायिक पहलुओं का प्रशिक्षण बहुत लंबा और कठिन हो सकता है।

क्या हमें विस्तृत विनिर्देश को अधिक महत्व देना चाहिए (लेकिन जैसा कि हम जानते हैं, पूर्ण विनिर्देश मौजूद नहीं है) या क्या हमें सभी डेवलपर्स को व्यावसायिक डोमेन को समझने के लिए प्रशिक्षित करना चाहिए?

संपादित करें: अपने जवाब में ध्यान रखें कि कंपनी बाहरी डेवलपर्स का उपयोग कर सकती है और यह कि सभी डोमेन का गठन लगभग 2 सप्ताह का हो सकता है


अच्छे डेवलपर्स ज्यादातर खुद को प्रशिक्षित करेंगे।
केविन क्लाइन

20
@kevincline: सभी डोमेन स्वयं को आसान शिक्षण के लिए उधार नहीं देते हैं।
FrustratedWithFormsDesigner 15

यह कितना वास्तविक है कि एक विस्तृत विनिर्देशन है जो कुछ डोमेन ज्ञान के पास नहीं है? विनिर्देश में अधिक विवरण प्राप्त करने में व्यापार-बंद भी है जो कि अधिक समय ले सकता है और इस प्रकार कुछ मामलों में सार्थक नहीं होगा।
जेबी किंग

22
मुझे लगता है कि डोमेन जितना जटिल है, उतना ही महत्वपूर्ण यह है कि डेवलपर्स इसे समझें और विकास को आउटसोर्स करने के लिए जितना अधिक महत्वपूर्ण है।
HLGEM

3
नोट: इस प्रश्न में / डेवलपर्स / परीक्षक / और यह अभी भी प्रासंगिक है।
joshin4colours 20

जवाबों:


114

विनिर्देशन वस्तुतः पर्याप्त नहीं है। जिन डेवलपर्स के पास डोमेन ज्ञान नहीं है, वे तब इंगित नहीं कर सकते हैं जब विनिर्देश त्रुटि में है (अक्सर एक घटना होती है) और खराब डिज़ाइन विकल्प बनाते हैं।


52
+1 क्योंकि मैंने वास्तविक जीवन में ऐसा होते देखा है। सीनियर डेवलपर ने बार-बार व्यवसाय को एक आवश्यकता की जांच करने के लिए कहा, व्यवसाय ने टीम को आश्वासन दिया कि आवश्यकता सही थी, फिर विकास को लॉन्च के बाद दिन को हाथापाई करने के लिए मजबूर किया गया क्योंकि व्यवसाय दो राज्यों में राज्य के कानून का उल्लंघन था।
यहोशू ड्रेक

9
या इसे दूसरे तरीके से देखने के लिए, एक पर्याप्त विस्तृत विनिर्देशन स्रोत कोड है और इसलिए इसे लिखने के लिए डोमेन ज्ञान के साथ एक डेवलपर की आवश्यकता होती है
jk।

@ जोशुआ - क्या ऐसा मामला नहीं है, जहाँ डोमेन नॉलेज के लिए बहुत कम अंक थे? - डेवलपर्स से अपेक्षा की गई थी कि वे इस कल्पना पर अमल करें कि (कम से कम पैनिक डे तक)।
स्टीव 314

3
@ स्टीव 314 मेला काफी। और बौद्धिक ईमानदारी के हित में डेवलपर ने मुख्य रूप से मूल विशेषता को लागू करने के आसपास की चर्चा को याद किया, और यहां तक ​​कि उस जानकारी को हटाने के बारे में एक कोड टिप्पणी भी थी, जो कि jk के अनुरूप थी। मैंने पाया है कि डोमेन ज्ञान अक्सर डेवलपर को यह जानने में मदद करता है कि छेद कहाँ हैं, या कम से कम, विनिर्देश में, उच्च गुणवत्ता को सक्षम करने और व्यावसायिक ज़रूरत को पूरा करने के लिए तेज़ी से चालू करने में मदद करता है।
जोशुआ ड्रेक

2
एक व्यवसाय स्वामी एक देव को रख सकता है, लेकिन अंत में विनिर्देश देव के अकेले रखने में है। जब आप राज्य विधानसभाओं के सामने खड़े होते हैं तो आप यह नहीं कह सकते कि "लेकिन मुझे ऐसा करने के लिए कहा गया था" या "बौद्धिक धैर्य सुविधाजनक नहीं था"। यह पर्याप्त नहीं होगा। उसे याद रखो।
बेन डीमोट

63

मेरे अनुभव में, अब 3 बहुत अलग-अलग उद्योगों में काम करने के बाद, आप डोमेन के बारे में बहुत कुछ नहीं जानना शुरू कर सकते हैं, लेकिन आपको इसे अंततः सीखना होगा और किसी को इसे विस्तृत डिग्री के लिए समझना होगा।

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

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

तो हाँ, किसी को डोमेन ज्ञान की आवश्यकता है, और अधिमानतः एक डेवलपर क्योंकि डोमेन समस्याएं कोड समस्याएं नहीं हैं और दोनों के बीच अनुवाद करना तुच्छ नहीं है। आखिरकार, आपकी टीम को रखने लायक किसी भी डेवलपर्स को डोमेन चुनना चाहिए, इसलिए वे अपने कोड की बारीकियों के बारे में अधिक सूचित विकल्प बना सकते हैं।


7
छिपे हुए नियम - मुझे लगता है कि वे अपवाद के बजाय आदर्श हैं।
प्रीत संघ

16

परियोजना पर किसी को पूरी तरह से डोमेन ज्ञान होना चाहिए। वह व्यक्ति डेवलपर हो भी सकता है और नहीं भी।

फुर्तीली परियोजनाओं में, ग्राहक परियोजना का मालिक वह व्यक्ति है, और वे टीम के साथ मिलकर और बारीकी से काम कर रहे हैं। गैर-फुर्तीली परियोजनाओं में, टीम पर किसी को उस ज्ञान को प्राप्त करने की आवश्यकता होती है, लेकिन वे आमतौर पर ऐसा नहीं करते हैं, जो एक कारण है कि गैर-चुस्त परियोजनाएं इतनी असफल हैं।


+1, डेवलपर्स (के रूप में नहीं प्रणाली आर्किटेक्ट) क्षेत्र के किसी भी ज्ञान की आवश्यकता नहीं चाहिए। एक आदर्श संगठन में कोडिंग को छोटे छोटे टुकड़ों में बनाया जाना चाहिए, जिसमें अंतिम उत्पाद के किसी भी ज्ञान की आवश्यकता नहीं होती है। अब, दुनिया में कितने "पूर्ण संगठन" हैं ... आमतौर पर यह कुछ इस तरह है: वाक्यांशों वाली एक पंक्ति के साथ समझाया गया एक फीचर जोड़ें: आप जानते हैं, इस वेबपेज में, जैसे ...
Juha

1
मुझे नहीं लगता कि अकेले डोमेन का ज्ञान रखने वाले उत्पाद के मालिक सफलता के लिए एक नुस्खा है।
केसी

11

बहुत सारे बेहतरीन जवाब हैं। मैं अपनी खुद को जोड़ता हूं क्योंकि उन्हें पढ़ने और खोजने के बाद मैंने पाया कि किसी को भी एक प्रमुख मुद्दे का उल्लेख नहीं है: कीड़े

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

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

याद रखें कि आइंस्टीन ने कहा था "लेकिन विचार और विचार, सूत्र नहीं, प्रत्येक भौतिक सिद्धांत की शुरुआत हैं।" , यह है कि कोई व्यक्ति अमूर्त सूत्रों के संदर्भ में नहीं बल्कि विचारों के बारे में सोचता है ...


1
हां, और उनमें से कई आइटम हैं (आपके नकारात्मक ब्याज उदाहरण की तरह) जो कि व्यापार डोमेन के लिए बहुत बुनियादी हैं, यह कभी भी उन्हें निर्दिष्ट करने के लिए नहीं होता है जैसा कि "हर कोई" जानता है।
HLGEM

10

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

एक युक्ति प्रोग्रामिंग आवश्यकताओं की "अंग्रेजी" के लिए डोमेन आवश्यकताओं के "जापानी" का अनुवाद करने का एक प्रयास है। जब आपको अनुवाद की गुणवत्ता Google अनुवाद की तुलना में मिलती है, तो यह आपका भाग्यशाली दिन होता है; ज्यादातर समय, गुणवत्ता बस वहाँ नहीं है, इसलिए आपके पास कम से कम कुछ डोमेन ज्ञान प्राप्त करने का कोई तरीका नहीं है। कुछ दृढ़ता के साथ, यह आपको परियोजना के अंत तक एक सभ्य "अनुवादक" बनाता है, इसलिए आपकी कंपनी के लिए आपका मूल्य काफी बढ़ता है। अधिकांश समय, आपको प्रक्रिया में बहुत मज़ा आता है, इसलिए यह एक जीत की स्थिति है।


"इसी कारण से, बिना डोमेन ज्ञान वाले विशेषज्ञ प्रोग्रामर भी यह पता लगाने में शक्तिहीन होते हैं कि उन्हें क्या बनाने की जरूरत है, तब भी जब उनके पास सर्वश्रेष्ठ डोमेन विशेषज्ञ के लिए 24x7 पहुंच हो, जो सॉफ्टवेयर विकास में भी विशेषज्ञ नहीं है।" - नहीं। प्रोग्रामर डोमेन विशेषज्ञ का साक्षात्कार करके डोमेन ज्ञान (भाग में) प्राप्त करते हैं। डोमेन विशेषज्ञ प्रोग्रामर को बता सकता है कि वह क्या चाहता है। डोमेन विशेषज्ञ के साथ सुविधाओं पर चर्चा करने में सक्षम होने के लिए प्रोग्रामर को डोमेन के बारे में पर्याप्त सीखना चाहिए।
मर्नेन लाईबो-कोसर

@ MarnenLaibow-Koser डोमेन ज्ञान प्राप्त करने के लिए डेवलपर्स की आवश्यकता मेरे उत्तर के दूसरे भाग का बिंदु है। "ज्ञान" एक विशेषज्ञ से आ सकता है, एक पुस्तक से, इंटरनेट से, और इसी तरह; किसी विशेषज्ञ के पास पहुंचना सहायक है, लेकिन सहायक नहीं।
dasblinkenlight

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

8

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


6

मुझे लगता है कि आपको डोमेन ज्ञान प्राप्त करने का प्रयास करना चाहिए। चश्मा चेक लिस्ट कह रहे हैं कि अंतिम उत्पाद को क्या करना चाहिए और आपके उत्पाद के सत्यापन के लिए आवश्यक है। डेवलपर के रूप में आपको हमेशा यह समझने की कोशिश करनी चाहिए कि वास्तविक समस्या क्या है जिसे आप हल करने की कोशिश कर रहे हैं। डोमेन ज्ञान प्राप्त करने से आपको यह समझने में मदद मिलेगी।

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

आप इसके बारे में बुनियादी ज्ञान के साथ कार चला सकते हैं; लेकिन अगर आप सवारी का आनंद लेना चाहते हैं तो आपको इसका सही उपयोग करने के बारे में अधिक जानने की आवश्यकता है। अन्य ट्रेडों की तरह, डोमेन को समझना अनिवार्य नहीं है, लेकिन यह मजेदार है जब आप इसे करते हैं


5

मुझे लगता है कि एक डेवलपर जो जानता है कि व्यवसाय सोने में उनके वजन के लायक है।

"पारंपरिक" परिदृश्य में, जहां व्यवसाय की कुछ आवश्यकताएं होती हैं और कुछ व्यवसाय विश्लेषक उन तकनीकी आवश्यकताओं में अनुवाद करते हैं, तब डेवलपर उन लोगों से दूर काम करता है जिनके पास अनिवार्य रूप से दो चीजें होती हैं:

  1. आपके पास विफलता के कई बिंदु हैं। व्यापार विश्लेषक पूरी तरह से अनुवाद किए गए सभी व्यावसायिक आवश्यकताओं को प्राप्त नहीं कर सकता है और / या डेवलपर पूरी तरह से तकनीकी विनिर्देश में अनुवाद नहीं कर सकता है। "कमरे के चारों ओर रहस्य" परिदृश्य पर एक प्रकार। संचार की बस जरूरत है।

  2. एक या सभी व्यवसाय के मालिक, व्यापार विश्लेषक या डेवलपर संगठन के लिए महत्वपूर्ण हैं कि वे प्रमुख वस्तुओं को याद कर सकें जो वे सामान्य रूप से नहीं सोचेंगे। अनुभवी डेवलपर जो व्यवसाय को अच्छी तरह से जानता है, उत्पाद को और अधिक पूर्ण बनाने के लिए उन अन्य भूमिकाओं में लोगों को शिक्षित करने में सहायता कर सकता है।


माना। यदि और कुछ नहीं, तो व्यवसाय को उस डेवलपर पर फिर से कॉल करने की अधिक संभावना है, क्योंकि डेवलपर "रस्सियों को जानता है" और व्यवसाय को आईटी प्रोग्राम भेजने के लिए चुनने के लिए हर बार एक नए प्रोग्रामर को अपना समय बर्बाद करने की ज़रूरत नहीं है। आवश्यकताएँ के नवीनतम सेट पर काम करने के लिए अपने नवीनतम, सामान्य, कहीं भी, कुछ भी प्रोग्रामर करें।
Phill W.

3

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

इस तरह के अत्यंत स्थानीय ज्ञान और संभवतः यहां तक ​​कि आंतों की भावनाओं के बिना, परिणाम आसानी से लगभग बहुत बेकार उत्पाद के रूप में समाप्त हो सकता है जो बहुत बारीकी से लिखित कल्पना को पूरा करता है।

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


2

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


2

मेरे अनुभव के आधार पर, समस्या डोमेन के अच्छे ज्ञान और सॉफ्टवेयर विकास के अच्छे ज्ञान के साथ एक एकल व्यक्ति को दो व्यक्तियों की तुलना में समस्या का इष्टतम समाधान खोजने की अधिक संभावना है, एक समस्या डोमेन के उत्कृष्ट ज्ञान के साथ और एक उत्कृष्ट ज्ञान के साथ सॉफ्टवेयर विकास, एक साथ काम करना।

मुझे लगता है कि यह साधारण तथ्य से नीचे आता है कि एक व्यक्ति के मस्तिष्क में जो संचार होता है वह व्यक्तियों के बीच संचार की तुलना में कई गुना तेज और बेहतर होता है।

* इस सवाल का जवाब देने के लिए मैं जो मुख्य अनुभव ले रहा हूं, वह 10+ साल का है, जो एक अकाउंटिंग सॉफ्टवेयर पैकेज विकसित करने के लिए खर्च किया गया है (स्थापना से लेकर रखरखाव मोड तक)। हालाँकि, सॉफ़्टवेयर विकास के बारे में मेरा ज्ञान बहुत अच्छा था, क्योंकि मेरे सहयोगियों की तुलना में, मुझे अक्सर समस्या डोमेन की समझ की कमी से विकलांग महसूस हुआ।


मैंने आमतौर पर पाया है कि जब एक एकल व्यक्ति दूसरों की सलाह के बिना अपने दम पर एक समस्या हल करता है तो यह सबसे अधिक कोड मंथन की ओर जाता है। आप अपने सॉफ़्टवेयर आर्किटेक्चर में दूसरों को शामिल करना नहीं भूल सकते हैं ... आप डोमेन को अच्छी तरह से जानते होंगे, लेकिन सॉफ़्टवेयर एक पहेली नहीं है जिसे आपको कुछ समय से अधिक लेआउट होना चाहिए।
visc

2

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


2

आपके पास नहीं है, लेकिन आप क्यों नहीं करना चाहेंगे?

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

किसी भी विचार के बिना कोड लिखना यह कैसे उपयोग किया जाता है और किस उद्देश्य के लिए बस एक भयानक नौकरी की तरह लगता है। जब आप गिरिजाघरों का निर्माण कर सकते हैं तो ईंटों को कौन तोड़ना चाहता है?


2

एक डेवलपर जितना अधिक शामिल होता है और व्यवसाय में जितना अधिक वरिष्ठ होता है, उतना ही महत्वपूर्ण होता है कि उसे कम से कम मिड-लेवल डोमेन ज्ञान या उस उद्योग के अधिक बारीक क्षेत्र जो महत्वपूर्ण हो सकते हैं, डेवलपर टीम द्वारा समझा नहीं जाएगा।

हालाँकि एक विनिर्देशन निचले स्तर के कार्यों के लिए पर्याप्त होना चाहिए। संक्षेप में, अपने कार्यबल को निचले स्तर तक प्रशिक्षित करना सबसे अच्छा है। वे दुनिया में सबसे अच्छे पॉलीग्लॉट प्रोग्रामर हो सकते हैं, लेकिन अगर वे इस मुद्दे को गहराई से समझ नहीं पाते हैं, तो वे हमेशा विफलता या डेथ मार्च प्रोग्रामिंग के लिए बर्बाद होते हैं।


++ 1 "डेथ मार्च प्रोग्रामिंग"। यह अमेरिका में टार बेबी की कहानी की तरह है ।
माइक डनलैवी

1

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

यह कुछ डोमेन विशेषज्ञों को काम पर रखने के लायक हो सकता है, जिनका काम ग्राहकों और डेवलपर्स के बीच संपर्क करना है, ताकि डेवलपर्स को बेहतर समझ देने के साथ-साथ कल्पना लिखने में मदद मिल सके।


1

मुझे लगता है कि इस तरह से जवाब देना मुश्किल है।

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

दूसरे हाथ पर एक उद्यम डेवलपर, यह मानते हुए कि वे कुछ समय से एक ही व्यवसाय में हैं, वास्तव में यह जानना चाहिए कि व्यवसाय कुछ महीनों (या वर्षों के बाद) कैसे काम करता है। बड़ी टीम में आपके पास एक वास्तुकार भी हो सकता है जो डेवलपर्स की तुलना में व्यवसाय को अधिक स्पष्ट रूप से समझता है।

अकेले डेवलपर्स के साथ एसएमई में यह महत्वपूर्ण है कि डेवलपर मालिकों / प्रबंधकों के साथ बार-बार चर्चा करने से बचें और गलत काम को लागू करने से बचें।

तो इस बारे में सोचने के बहुत सारे संभावित तरीके हैं, लेकिन सभी मामलों में कुंजी समान है: संचार


1
एक फ्रीलांसर के रूप में, मैं आपको विश्वास दिलाता हूं कि मुझे अपने ग्राहकों के व्यवसायों को कम से कम अच्छी तरह से समझना होगा ताकि वे उन विशेषताओं के बारे में समझदारी से बात कर सकें। व्यापार को समझे बिना आप कल्पना लिख ​​सकते हैं कि यह एक विचार है। तो यह विचार है कि आप एक आदर्श कल्पना लिख ​​सकते हैं और इसे "दीवार पर" एक डेवलपर को फेंक सकते हैं।
मार्नेन लाईबो-कोसर

1

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


3
औद्योगिक इंजीनियरों को इस दोहरे ज्ञान की आवश्यकता होती है, जैसा कि लगभग सभी विश्लेषक करते हैं। यह सिर्फ सॉफ्टवेयर डेवलपमेंट तक सीमित नहीं है।
HLGEM

4
एक तकनीकी लेखक की भी यही स्थिति है।
जेनिफर एस

1

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

हम तब अन्य सॉफ्टवेयर कंपनियों के संबंध में उत्पादों का निर्माण कर रहे थे, लेकिन डोमेन विशिष्ट ज्ञान में बहुत कमी थी। जैसा कि आपने वर्णित किया है, पर्यटन उद्योग में एक उत्पाद का निर्माण करना सही है, यदि आप कई क्रॉस-कटिंग चिंताएं हैं, आदि।

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

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


1

यदि कोई डेवलपर किसी कंपनी / उद्योग में लंबे समय तक रहता है, तो वे धीरे-धीरे लेकिन निश्चित रूप से "व्यवसाय" सीखेंगे।

कुछ कंपनियां स्वीकार करती हैं और "व्यवसाय" में प्रशिक्षण प्रदान करती हैं। वित्तीय कंपनियां इसका एक अच्छा उदाहरण हैं।

जितना अधिक आप व्यवसाय सीखते हैं, उतना आसान यह आपके उपयोगकर्ताओं से बात करना होगा। वे आप में अधिक आत्मविश्वास महसूस करेंगे। आप अधिक आसानी से जहां एक प्रणाली गलत हो सकता है के quirks समझ अगर यह काफी उपयोगकर्ता के लिए उम्मीद के रूप में नहीं करता है।

आपके प्रश्न का उत्तर देने के लिए, विनिर्देश मेरे अनुभव में पर्याप्त है। आम समस्या यह है कि वे अक्सर पर्याप्त जानकारी नहीं रखते हैं, और जल्दी से निकल जाते हैं।

कुछ कंपनियों के लिए बिजनेस डोमेन का अनुभव अनिवार्य हो सकता है। वे किराए पर लेते समय डोमेन में अनुभव वाले डेवलपर्स की तलाश करते हैं। कुछ कंपनियों ने इसे वास्तविक तकनीकी कौशल से भी ऊंचा रखा। (कोई वित्तीय अनुभव नहीं, कोई साक्षात्कार बहुत आम नहीं है, निश्चित रूप से यहां यूके में है)।


अंतिम पैराग्राफ व्यावसायिक डोमेन में विशिष्ट रूप से सत्य है जहां आप सिस्टम के ठीक से न बनने पर कानूनी मुसीबत में पड़ सकते हैं।
HLGEM

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

0

व्यक्तिगत अनुभव से, जब तक आप अपने साथ काम करने वाली टीम में किसी को प्राप्त कर लेते हैं, तब तक विनिर्देश पर्याप्त होता है, जिसके पास डोमेन ज्ञान होता है।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.