कमाई के साधन के रूप में फ्रीलांस। भाग २ काम पर लगना

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

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

अब मुख्य बात है, आदेश के मूल्यांकन के बारे में। मंचों और टिप्पणियों में, लागत के मूल्यांकन के लिए यह मानदंड अक्सर मक्खियों:

“आप कोम्प्लेक्टुही की लागत होने का दिखावा करते हैं, इसमें आपके काम के एक घंटे की लागत को खर्च किए गए घंटों की संख्या से गुणा किया जाता है। कुछ ऐसा ही। ”

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

ड्यूटी पर (khe-khe) मुझे इलेक्ट्रॉनिक्स के विकास के साथ, और बहुत कसकर निपटना पड़ा। सब कुछ वहाँ है जैसा कि पोस्ट में वर्णित है, क्योंकि यह उस साइट पर था जिसे मुझे काम करने की पेशकश की गई थी, जो अंत में मैंने खुद को 5 दिनों में किया, 40 tr के लिए ... दो कम अवधि के लिए।

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

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

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

मैं अलग से नोट करना चाहता हूं - मैं यह नहीं कह रहा हूं कि पोस्ट में काम की लागत बहुत अधिक है, इसके विपरीत, यह कुछ स्थानों पर पर्याप्त नहीं है। मैं मूल्य टैग के खिलाफ नहीं हूं, मैं रास्ते के खिलाफ हूं।

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

गीत के बोल, अभ्यास करने के लिए नीचे उतरें।

चलो काम की शुरुआत के बारे में बात करते हैं, और अधिक विशेष रूप से इस बारे में कि हम इसे कैसे प्राप्त करते हैं।

एक ऑफॉप्टिक के रूप में, यहां फिर से एक ही चीज़ के विभिन्न सॉस के साथ बहुत दोहराव होगा। मैं यह नहीं चाहता कि यह पाठ में केवल एक दो पंक्तियाँ हों। सामान्य रूप से पूर्ण की गई परियोजनाओं की लड़ाई में, प्रत्येक विवरण महत्वपूर्ण है, और सभी बिंदुओं का कार्यान्वयन।

विकल्प प्रारंभ करें

मैं सिद्धांत के बारे में बात करना चाहता था, लेकिन यह बहुत जल्दी है। अपने साथ अभ्यास पर बेहतर जाने दें

विकल्प 1. हाँ, समय अभी भी है ...

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

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

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

मेरे हिस्से के लिए, मैं कुछ बिंदु सम्मिलित करूंगा:

परियोजना पूरी नहीं हुई है, आपको दूसरा नहीं लेना चाहिए

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

परियोजना एक समझ से बाहर चरण में है, उत्तर के साथ धीमा करना और अतिरिक्त जानकारी प्राप्त करना बेहतर है

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

आप अगली नौकरी के लिए सहमत हो सकते हैं

• परियोजना को अंतिम मंजूरी का इंतजार है। तकनीकी कार्य 100% पूर्ण होने पर इसे लेने के लिए स्वतंत्र महसूस करें। सभी सुधारों को अतिरिक्त कार्य के रूप में सुरक्षित रूप से रोल आउट किया जा सकता है, और आपको ग्राहक की प्रतीक्षा करने के लिए खुद को कह सकते हैं
• परियोजना में बग की एक अंतिम सूची है, जिनमें से प्रत्येक समझ में आता है। वैसे, समझ से, मेरा मतलब है कि क्रिस्टल स्पष्टता कहाँ से और कैसे आती है, और नहीं "हे, लेकिन यह शायद" वर्ग है! " कचरा, 5 मिनट का काम "

विकल्प दो। आगे बढ़ो! मातृभूमि के लिए! स्टालिन के लिए!

दूसरा विकल्प, जिसमें परियोजना भी ग्रस्त है, और जो पहले के रूप में अक्सर होता है, तुरंत प्रोग्रामिंग शुरू करना है। हाँ, हाँ, और हाँ फिर से! नई परियोजना! ताजा विचार! शांत कार्य! हुर्रे!

वैसे, ऐसे लोगों के लिए एक सरल नियम है - परियोजना पास करने के लिए कुल समय के 5% से पहले परियोजना को करने के लिए मत बैठो। इस समय को समय पर न करें - आपकी समस्या। क्या आपके हाथों में खुजली है? उन्हें व्यापार में ले जाएं। उसी तरह से नहीं, बल्कि परियोजना की भलाई के लिए आवश्यक है। नहीं, नहीं! यह एक नहीं!

हम संभाल लेते हैं / Visio खोलते हैं / एक और सहकर्मी खोलते हैं जो जानता है, और आकर्षित करता है। एक ब्लॉक आरेख बनाएं। सबसे पहले, सबसे सरल। यहां हमारे पास एक क्लाइंट है, यहां एक सर्वर है। और यहाँ एक और ग्राहक है। यदि, बेशक, एप्लिकेशन क्लाइंट-सर्वर है, लेकिन किसी भी अन्य में आप कई सबसे बड़े ब्लॉक पा सकते हैं। बाद में इसे छोटे लोगों में तोड़ दें। सोचें कि यह कैसे काम करेगा। एक तैयार अनुप्रयोग की कल्पना करें।

क्या कुछ है? ...

योजना। कौन सी परियोजना

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

प्रोजेक्ट प्लान कब बनाया जाना चाहिए? फिर, जब परियोजना 3-4 सप्ताह से अधिक रहती है। एक सप्ताह के लिए गंभीर योजना कार्य न करें, और एक बड़ी परियोजना के लिए योजना की उपेक्षा न करें। वास्तव में, एक योजना की कमी अराजकता और परियोजना के अनियंत्रित विकास के लिए एक सीधी सड़क है। फिर भी उम्मीद है कि यह अपने आप सामने आएगा। व्यथित होते हैं। ऊपर मत आना।

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

योजना बहुत कम नहीं होनी चाहिए। "एक क्लाइंट लिखें", "एक सर्वर लिखें", "प्रोजेक्ट सबमिट करना" एक सांकेतिक योजना है, यदि आप इसे लिखने के लिए एक योजना लिखने के लिए एक लक्ष्य निर्धारित करते हैं।

जैसा कि अभ्यास से पता चला है, एक साधारण परियोजना के लिए न्यूनतम 10-15 अंकों की एक योजना है, लेकिन जब सबसे जटिल योजना भी लिखी जाती है, तो मैंने 200 से अधिक बिंदुओं पर नहीं जाने की कोशिश की। जिसके बाद यह अब एक योजना नहीं है - यह एक युद्ध है और किसी प्रकार की शांति है।

एक योजना बनाने के बाद, एक कुर्सी पर वापस बैठें और 5 मिनट के लिए अपनी आँखें बंद करें।
एक नए प्रोजेक्ट के साथ।

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