व्यवसाय चलाने के लिए नोट्स। भाग २

हाय हबर, मेरा नाम अलेक्जेंडर है। मेरे लेख से कई लोग प्रेरित हुए, जिसने मुझे अगली कड़ी लिखने के लिए प्रेरित किया। मैंने पहले लेख प्रकाशित किया था और यह यहाँ है ।
उन लोगों के लिए जो पहले पढ़ने के बिना दूसरे भाग को पढ़ते हैं, मैं दृढ़ता से आलसी न होने और लेख के पहले भाग को पढ़ने की सलाह देता हूं।

चलो चलें!

भाग 4 (जारी) परियोजनाओं

मैं पहले लेख से चार बिंदुओं की नकल करूँगा ताकि अखंडता को न खोऊँ।

1. एक आला का चयन करें।

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

2. सादगी।

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

3. अधिक से अधिक कम करने के लिए।

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

4. प्रतिरूपकता और मापनीयता।

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

5. तारीखें।

आईटी परियोजनाओं में तीन सबसे महत्वपूर्ण मानदंडों में से एक परियोजना विकास का समय है। मेरी राय में, यह सबसे महत्वपूर्ण मानदंड है। चूंकि कहावत "समय पैसा है" कहीं नहीं गया है। वास्तव में, विकास का समय उन कारकों में से एक होगा जो आप और आपकी टीम पर दबाव डालेंगे।
कभी-कभी बहुत ही अपर्याप्त ग्राहक सामने आते हैं, लेकिन बहुत दिलचस्प परियोजनाओं के साथ। ऐसा लगता है कि मूल्य टैग सूट करता है, और परियोजना दिलचस्प है, लेकिन समय अवास्तविक है। इस मामले में क्या करना है।
सबसे पहले, बैठो और वास्तविक समय की गणना करें जो आपको डिजाइन और विकास के लिए आवश्यक होगा। उसके बाद, इस आंकड़े को 3 से गुणा करें। तीन से क्यों? ऐसा हुआ कि यह आंकड़ा व्यवहार में लाया गया। मैं समझाता हूं: एक तिहाई विकास के लिए जाता है, एक तिहाई परीक्षण और बग फिक्सिंग के लिए, और एक तिहाई ग्राहक पक्ष में एकीकरण के लिए आवश्यक है। आप कह सकते हैं कि यह आंकड़ा अवास्तविक है, लेकिन मेरे लिए बहुत है। जब मैंने इस तरह की गणनाओं का उपयोग करना शुरू किया, तो मेरे पास एक भी परियोजना नहीं थी जो समय में विफल रही।
अपने अनुभव से: मैं हमेशा ग्राहकों को वास्तविक संख्या बताता हूं, मैं जोर देता हूं - हमेशा। चूंकि संख्याओं के बारे में झूठ बोलना व्यर्थ है, क्योंकि झूठ और चूक के कारण समय सीमा टूट जाएगी। यह कानून है! यदि परियोजना के लिए उदाहरण के लिए 100 घंटे की आवश्यकता होती है। फिर 50 के लिए यह कभी पूरा नहीं होगा। एक परियोजना में, मैंने श्रम लागतों की गणना की और उन्हें ग्राहक को देने की घोषणा की। जहां तक ​​मुझे याद है, मैंने फुल टाइम पर यह आंकड़ा 1.5 महीने निर्धारित किया था। वह सदमे में था। और ASAP ने कहा कि एक से अधिक बार कल्पना की जा सकती है। फिर उन्होंने कहा कि उनके पास एक और टीम है जिसने उन्हें 3 सप्ताह में एक ही परियोजना विकसित करने के लिए आमंत्रित किया है। बेशक, मुझे यह विश्वास नहीं था, क्योंकि यह आंकड़ा आम तौर पर उस परियोजना के लिए अवास्तविक है। और मैंने उसे इसके बारे में बताया, लेकिन वह मेरी बात सुनना भी नहीं चाहता था। और हमने अलविदा कह दिया। और मैं सुरक्षित रूप से परियोजना के बारे में भूल गया, लेकिन 4 महीने बाद इस ग्राहक ने मुझे एक पत्र लिखा जिसमें उसने कहा कि मैं सही था। 4 महीनों के लिए, दूसरी टीम डेमो संस्करण भी प्रदान नहीं कर सकी। वैसे, यह परियोजना बिल्कुल मेरी प्रोफ़ाइल में थी, और यह टीम स्पष्ट रूप से इस विषय में नहीं थी। इसलिए वे समय सीमा से चूक गए।

6. तीन में से दो।

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

7. वास्तविक परियोजनाओं पर अध्ययन न करें।

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

भाग 5. वित्तीय पहलू, साझेदारी और कर्मचारी

1. ये बिजनेस है, बेबी!

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

2. मूल्य निर्धारण।

चूंकि आप व्यवसाय में लगे हुए हैं, स्वाभाविक रूप से, आपको परियोजना के लिए, काम के लिए लागत की सही गणना करने में सक्षम होना चाहिए। परियोजना लागत की गणना व्यवसाय में सबसे मुश्किल काम है। प्रत्येक व्यवसायी अपने तरीके से इसकी गणना करता है। मैं आपको नीचे बताऊंगा कि मैं इसकी गणना कैसे करता हूं, लेकिन इससे पहले मैं एक सामान्य गलती का उल्लेख करना चाहता हूं। ग्राहक से कभी न पूछें कि वह कितना भुगतान कर सकता है। यदि क्लाइंट आपको प्रोजेक्ट बजट नहीं बताता है, तो इसका मतलब यह नहीं है कि वह आपको धोखा देना चाहता है। अक्सर, ग्राहक को वास्तविक मूल्य का पता नहीं होता है। यदि आप कहना शुरू करते हैं: "आप कितना भुगतान करने को तैयार हैं?" - यह कम से कम लाभहीन है। ग्राहक आपको संकोच और संदेह करना शुरू कर देगा और अपने प्रतिद्वंद्वियों के पास जाएगा।
मेरे अनुभव से: ऊपर, मैंने लिखा कि मैं परियोजना की समय सीमा पर कैसे विचार करूं। इसलिए, मैं मूल्य टैग इस प्रकार मानता हूं: सबसे पहले: मैं समय को भुगतान किए गए और अवैतनिक दो भागों में विभाजित करता हूं। चौथे भाग के पैराग्राफ 5 में वर्णित तीन भागों में से, मैं केवल पहले तीसरे, यानी विकास के लिए पैसे लेता हूं। एकीकरण और बग फिक्सिंग सभी मुफ्त हैं। बग फिक्सिंग समझ में आता है, ग्राहक को हमारे जाम के लिए भुगतान करने की आवश्यकता नहीं है। एकीकरण एक अलग बिंदु है। अधिक मनोविज्ञान है, इस अवधि में जब सब कुछ ठीक है, सिस्टम काम करता है और आप और आपके ग्राहक इसे क्लाइंट मशीनों में एकीकृत करते हैं, अक्सर आप अमूर्त विषयों पर बात करना शुरू करते हैं जो आपको और आपके क्लाइंट को संचार के अधिक भरोसेमंद स्तर पर लाते हैं। अब, आप एक दूर के अज्ञात देश से सिर्फ एक फेसलेस डेवलपर नहीं हैं, आप एक वास्तविक व्यक्ति हैं। इस अवधि के दौरान, ग्राहक अक्सर कहता है कि वह एक और प्रणाली रखना चाहता है या वह चाहता है कि आप मौजूदा प्रणाली और इसकी समस्याओं पर एक नज़र डालें। यही है, वह आपकी दृष्टि खोना नहीं चाहता है। चूंकि ग्राहक डेवलपर्स को बदलना पसंद नहीं करते हैं, वे चाहते हैं कि आप एक नियमित निष्पादक बनें। ठीक है। आइए लागत की गणना करने के लिए वापस जाएं।
उदाहरण के लिए: एक परियोजना को विकसित करने के लिए 100 मानव-घंटे की आवश्यकता होती है। आप एक परियोजना के लिए एक विशेषज्ञ को बाहर कर सकते हैं। ऐसे विशेषज्ञ की प्रति घंटे की दर, $ 20 का कहना है। आप विशेषज्ञ के घंटे की लागत पर एक मार्जिन रख रहे हैं, अर्थात्, कंपनी का लाभ, उदाहरण के लिए, $ 5। नतीजतन, हमें प्रति घंटे $ 25 मिलता है, और परियोजना के लिए कुल $ 2500 है। ये केवल अनुमानित आंकड़े हैं। लेकिन हम जिस तरह से मूल्य टैग पर विचार करते हैं उसका सार वास्तविक है। स्वाभाविक रूप से, इन भुगतान किए गए घंटों में परीक्षण और एकीकरण शामिल नहीं हैं।

3. लालची मत बनो।

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

4. एक साथी को एक दोस्त के रूप में नहीं, बल्कि एक साथी के रूप में चुनें।

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

5. कर्मचारियों को काम पर रखना।

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

6. अपने सहयोगियों और कर्मचारियों की बात सुनें।

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

7.

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

8.

. , , . , . , , . , , . .
: , . . , , , , , . , . , , , .

एक निष्कर्ष के बजाय

, - . , . , – .

आपका ध्यान देने के लिए धन्यवाद।

निष्ठा से,