कमाई के साधन के रूप में फ्रीलांस। भाग 1। प्रोजेक्ट शुरू

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

शुरुआत हो रही है

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

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

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

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

यदि आप अपने सबसे महंगे प्रोजेक्ट की लागत के दोगुने से अधिक के साथ एक परियोजना का मूल्यांकन करते हैं, तो आप बेशर्मी से, बेशर्मी से झूठ बोल रहे हैं

यदि हम सब कुछ सूचीबद्ध करते हैं, तो आप स्वयं, ग्राहक और इस दुनिया के कानूनों से झूठ बोल रहे हैं।

अच्छी तरह से गर्म होने के लिए, मुझे लगता है कि हर कोई सब कुछ समझ गया था, हम वास्तव में इसके साथ क्या करना चाहते हैं।

दवा

दवाएं दो प्रकार की जानी जाती हैं। एक गंभीर बीमारी के लिए कोल्ड पिल और दवाओं का एक जटिल। अतिरिक्त समय और बजट किस प्रकार का है? क्या आपको अभी भी इस पर संदेह है?

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

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

आइए समय और बजट निर्धारित करके शुरू करें। यदि परियोजना छोटी है, 20 हजार के लिए, और 5 दिनों के लिए, तो हमें कोई समस्या नहीं है, है ना? और क्यों? क्योंकि एक तरफ, हमारी सभी मिसाइलें परियोजना मापदंडों के प्रतिशत के रूप में प्रदर्शित की जाती हैं। और अगर ऊपर के लिए, 30-40% का विचलन 1.5-2 दिन और 6-8 ट्र है, जो बलिदान किया जा सकता है, तो एक बड़े क्रम में वे पहले से ही अलग हैं। वास्तविकता यह है कि मैंने जिन विचलन को इंगित किया है वे बहुत अच्छे संकेतक हैं। क्यों? हम और आगे जा रहे हैं। दूसरा कारण यह है कि शर्तों को अधिक या कम मज़बूती से कहा जाता है, यह परियोजना शारीरिक रूप से विशुद्ध रूप से मूल्यांकन और समीक्षा करने में आसान है। बड़ी परियोजनाओं पर, काम की जटिलता की दृष्टि बहुत अस्पष्ट है।

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

क्या आप नोटिस करते हैं कि समस्याओं का वर्णन अनिवार्य रूप से उन्हें कैसे उत्तर देता है? आइए अधिक विस्तार से विचार करें।

सबसे पहले, TK विनाशकारी रूप से बहुत कम समय है। हां, ऐसी स्थितियां हैं जब आप इसके बिना काम कर सकते हैं। उदाहरण के लिए, मेरे पास एक ग्राहक है जिसके साथ हम टीके के बिना काम करते हैं, और प्रारंभिक समझौतों को बदलने के बाद शर्तों और लागत को बदलने का कोई सवाल ही नहीं है। लेकिन सौ परियोजनाओं के लिए, मेरे पास केवल एक ही सकारात्मक उदाहरण है।

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

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

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

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

कुछ मैंने हस्ताक्षर किए ... मुझे लगता है कि आज के लिए पर्याप्त है, अगले भाग में हम परियोजना पर सीधे काम शुरू करने की समस्याओं पर विचार करेंगे।

भाग दो