परियोजना में पैसे बचाने के बारे में

एक बार जब मैं एक अध्ययन के बारे में आया कि हमारे प्रतियोगी समान सेवाओं के लिए किस कीमत की पेशकश करते हैं और जैसा हम करते हैं वैसा ही काम करते हैं। और यह डेटा अप्रिय था: हम काफी महंगे थे। आदेश रखने और पदों को रखने के लिए, हमें परिवर्तनों की आवश्यकता है।



आगे देखते हुए, मैं कहता हूँ कि अंत में हमने अपने काम का पुनर्गठन किया। इसके अलावा, न केवल लागत को कम कर रहा है, बल्कि प्रोग्रामर के लिए वेतन भी बढ़ा रहा है। कैसे - कट के नीचे पढ़ें।

अध्ययन

आंतरिक विश्लेषण

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

डेवलपर	"स्पीड"
1	1.61
2	1.55
...	...
N-1	0.31
एन	0.26

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

बाहरी स्रोतों से डेटा

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

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

परियोजना	औसत	कम से कम	अधिकतम।	विचलन
COMPRESS00	33.83	11.58	77,00	14.51
COMPRESS99	27.47	6.67	69.50	13.62
TEX00	21,22	6.00	75,00	12.11

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

विधि

इसलिए, हमारे कार्य पर वापस जाएं: परियोजनाओं का संचालन करते समय लागत को कम करना। मेरे पहले टैबलेट से यह इस प्रकार है कि गति का प्रसार छह गुना था। और इस टीम के भीतर वेतन का बिखराव (न्यूनतम करने के लिए अधिकतम दर का अनुपात) लगभग 2 था। इस प्रकार, यदि हम प्रोग्रामर एन को काम देते हैं, तो हम इसके लिए 3 गुना अधिक भुगतान करेंगे जब हम प्रोग्रामर # 1 को एक ही काम देंगे।

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

हालाँकि, यह एक तालिका बनाने और अपने लिए निष्कर्ष निकालने के लिए एक बात है। एक और बात यह है कि इस विचार को नेतृत्व तक पहुंचाया जाए और उसे उसकी बेगुनाही का दोषी ठहराया जाए।

अधिक महंगे प्रोग्रामर के साथ काम करने के लिए प्रबंधन को समझाना क्यों मुश्किल है?

मनोवैज्ञानिक बाधा

जैसा कि मैंने लेख की शुरुआत में कहा था, कार्रवाई प्रतिस्पर्धा और लागत में कमी (बचत) की पृष्ठभूमि के खिलाफ हुई। आमतौर पर, ऐसी स्थिति में, कार्यालय वेतन बढ़ाने के बारे में बात नहीं कर रहा है - कुल बचत शुरू होती है (ठीक है, किसी तरह कीमत कम करना आवश्यक है!)।



इसलिए नौकरी की रिक्ति में वेतन बार बढ़ाने की दर + को बढ़ाने के विचार ने, इसे अप्रत्याशित रूप से, हल्के ढंग से रखा।

समस्या पर एक सतही नज़र

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



यह डिफ़ॉल्ट दृष्टिकोण कई लोगों के दिमाग में बैठता है, न कि केवल प्रबंधकों के लिए। इसलिए, जब एक पीएम गैर-आईटी व्यक्ति देखता है कि नौकरानी की तुलना में मध्य वेतन K% अधिक है, तो वह सोचता है कि मध्य K% तेजी से काम करता है। इसका मतलब यह है कि प्रणाली रैखिक है: 2000 के लिए $ 1000 = 1 लोगों के लिए 2 लोग। और यह पूरी तरह से स्पष्ट नहीं है कि हमें "मजबूत कर्मचारियों" पर ध्यान क्यों देना चाहिए। इसके अलावा, उनके साथ काम करने में कुछ "असुविधाएँ" हैं।

स्टार रोग

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



कभी-कभी, गलती से, इस व्यवहार को "स्टार रोग" के रूप में वर्गीकृत किया जाता है। और इस सूत्रीकरण के साथ, अनुभवी प्रोग्रामर के साथ शुरुआती लोगों के साथ काम करना वास्तव में बेहतर है।

आखिर में क्या हुआ?

अंत में, जानकारी को नेतृत्व को अवगत कराया गया था, और प्रस्तावित सुधार किए गए थे: हम लगभग विशेष रूप से मजबूत प्रोग्रामर के साथ काम करते हैं। परिणामस्वरूप, हमें निम्नलिखित मिला:

• टीम में मजबूत प्रोग्रामर का औसत वेतन 50% से अधिक बढ़ गया;
• कार्य की प्रति यूनिट औसत लागत में 50% की कमी हुई।

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