🍲 🐘 🚴🏽 वेब प्रोग्रामिंग कंपनी को कैसे काम करना चाहिए 🔈 💭 ♿️

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

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

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

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

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

चलो परिभाषाओं के साथ शुरू करते हैं।
डेवलपर्स का एक छोटा समूह (5-6 लोग) काम करने के लिए एक कंपनी (फर्म) में एकजुट होते हैं:

इस कंपनी की गतिविधियों से आय प्राप्त करें,
इस काम और परिणामों का आनंद लें।

हम पहले से ही जानते हैं कि कैसे और क्या करना चाहते हैं, इसके आधार पर, हमारी कंपनी को इससे निपटना चाहिए:

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

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

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

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

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

ठीक है, चलो कहते हैं कि हमें इस सब की समझ है और उन्हें भूमिकाएँ सौंपी गई हैं।
टीम को कैसे काम करना चाहिए?

मेरी राय में, हमारे काम में निम्नलिखित चीजों / प्रथाओं / दृष्टिकोणों की आवश्यकता होती है।
तो, महत्वपूर्ण:

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

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

यहाँ, यदि संभव हो तो, संक्षेप में और वह सब।

वेब प्रोग्रामिंग कंपनी को कैसे काम करना चाहिए

More articles: