क्या बिक्री का मुकाबला करने का एक तरीका हमेशा के लिए खत्म हो गया है? [बन्द है]


120

मुझे बार-बार ऐसी स्थिति में फंसना प्रतीत होता है जहाँ रिलीज़ की तारीखें तकनीकी के आधार पर निर्धारित नहीं की जाती हैं, लेकिन क्योंकि बिक्री में किसी ने तब तक किसी ग्राहक के लिए प्रतिबद्ध किया है। अन्य कंपनियों में विकास में दोस्तों के साथ चर्चा के आधार पर, वही बात होती है।

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

सामान्य तौर पर, क्या इस पर पीछे धकेलने का कोई तरीका है? यदि इस रिलीज के लिए नहीं, तो भविष्य में क्या होगा? मेरे पास समस्या यह है कि एक ही रास्ता मुझे ऐसा करने का एक तरीका दिखाई देता है, और वह यह है कि जो मैं कर सकता हूं वह सबसे अच्छा करूं, लेकिन सॉफ्टवेयर को 'जैसा है' जारी करना है, इसलिए बोलना है।

मैं बग-राइड किए गए सॉफ़्टवेयर को जारी नहीं करना चाहता क्योंकि यह मेरा नाम जुड़ा हुआ है, लेकिन एक बार में महीनों के लिए 80 घंटे का सप्ताह करना सिर्फ मनमाने ढंग से सेट रिलीज की तारीख को इंगित करता है।

संपादित करें: रिकॉर्ड के लिए, मैं अभी 80 घंटे का सप्ताह नहीं कर रहा हूं, बस यह ध्यान में आता है कि रिलीज की तारीख तक निर्धारित अपेक्षित सुविधा को कवर करने के लिए क्या करना होगा।


49
जब आप कमिटमेंट नहीं कर रहे हैं तो आपका नाम प्रोडक्ट से क्यों जुड़ा है? यदि कंपनी घटिया अधूरा सॉफ्टवेयर डालना चाहती है, तो यह उनका अधिकार है, लेकिन आपके पास कोई निर्णय लेने के लिए व्यक्तिगत जिम्मेदारी लेने का कोई कारण नहीं है जो आपने भी नहीं किया है।

4
@Giorgio haha अच्छा :)
पक्ष

3
@ShawnD। गिरोह के लिए!
कलामने

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

3
क्लीन कोडर खरीदें। इसे पढ़ें (मैंने इसे एक सप्ताह के अंत में खा लिया), और अपने कैरियर के लिए सख्ती से विचारों को लागू करें। आपका काम एक ईमानदार "नहीं" देना है अगर नौकरी नहीं की जा सकती है। यदि आप ऐसा नहीं करते हैं, तो आपके पास खुद को दोषी ठहराने वाला कोई नहीं होगा। मुझे पता है कि ईमानदार होने के लिए रोजगार खोने का खतरा काफी कम हो सकता है। लेकिन पूरी तरह से आधारहीन कमिटमेंट को पूरा करने के लिए फ्लिप पक्ष को 80 घंटे के सप्ताह में मजबूर किया जा रहा है।
माइकल ब्राउन

जवाबों:


147

80 घंटे सप्ताह करना बंद करो। यह सकारात्मक सुदृढीकरण है । क्योंकि उन्हें अपेक्षित लागत के साथ समय पर उत्पाद मिल रहा है, वे इसे जारी रखने जा रहे हैं, भले ही यह आपके लिए क्या करे।

यदि वे समय को ठीक से बजट नहीं कर सकते हैं, तो यह प्रबंधन की गलती है। तुम्हारा नहीं।

उन्हें कुछ समय सीमा याद आती है।


60
अपने लिए खड़े होने के लिए +1। डेवलपर्स खुद को सभी पर चलने की अनुमति देते हैं, ठीक इसी तरह से ऐसे स्वेटशोप संस्कृतियों को बनाए रखने की अनुमति देता है।

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

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

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

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

96

सामान्य तौर पर, क्या इस पर पीछे धकेलने का कोई तरीका है? यदि इस रिलीज के लिए नहीं, तो भविष्य में क्या होगा?

बेशक, वहाँ है: उन्हें इस दृष्टिकोण के साथ बुरी तरह से विफल करते हैंअसफल होने के साथ-साथ कुछ भी नहीं सिखाता है।

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

और आप बेहतर वर्तमान परियोजना के साथ ऐसा करना शुरू करते हैं ।

यदि वे आपको समस्या के लिए दोषी ठहराते हैं, तो आप नई नौकरी के लिए शिकार करना शुरू कर देंगे, क्योंकि कुछ भी उन्हें आश्वस्त नहीं करेगा कि वे समस्या हैं।

एक विचार के रूप में, मुझे लगता है कि यह सवाल वास्तव में प्रसिद्ध ईए की कहानी का एक लिंक है, जो जोएल की पुस्तकों में से एक में चित्रित किया गया है: ईए: द ह्यूमन स्टोरी


1
सुनिश्चित करें कि आप एक अनुमान और एक प्रतिबद्धता के बीच अंतर सीखते हैं: blog.mountaingoatsoftware.com/… ऐसा लगता है कि वे दोनों के बारे में परवाह नहीं करते हैं, लेकिन एक बार जब वे अंतर जानते हैं तो यह उपयोगी है।
स्टुपरयूजर

26
उन्हें अनुमान दिखाने के लिए +1 । इस बिंदु पर, मैं इस पोस्ट पर गुल्लक वापस करना चाहता हूं: यहां तक ​​कि मृत्यु-मार्च कंपनी के वातावरण में, ग्राहकों को मुफ्त में काम करना (यानी कि सभी अवैतनिक ओवरटाइम) अत्यधिक हतोत्साहित हैं, क्योंकि कंपनी ऐसा कर सकती थी। यदि वे इसके लिए ग्राहक से शुल्क लेते थे, तो उसी काम से बहुत अधिक पैसा । यह बताते हुए कि बिक्री की अधिकता से कंपनी का पैसा खत्म हो रहा है, इससे सभी फर्क पड़ सकते हैं।

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

2
हाँ। इसलिए जब बिक्री एक युक्ति के बिना आपके पास आती है, तो अनुमान लगाने के लिए सहमत होने से पहले एक पर जोर दें, या उन्हें विवरण के स्तर के आधार पर एक उपयुक्त अनुमान सीमा दें। यह आमतौर पर "एक और तीस सप्ताह के बीच" जैसा कुछ होगा।
पीटरअल्बेनवेब

2
@ मर्क बूथ: यही कारण है कि आपको अवमूल्यन लागतों का मुद्रीकरण करने की आवश्यकता है। निश्चित रूप से, विकास एक आवश्यक खर्च है, लेकिन यह केवल एक ही नहीं है। और सामान्य तौर पर, प्रबंधन यह समझता है कि बिक्री का काम उपरोक्त लागत पर बेचना है; किसी भी बेवकूफ नीचे लागत बेच सकते हैं।
एमएसलटर्स

52

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

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

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


46
+1 यदि प्रोग्रामर्स के ओवरटाइम का उपयोग बिक्री को बंद करने के लिए किया जा रहा है, तो उन्हें कमीशन का एक हिस्सा प्राप्त करना चाहिए।
गिल्बर्ट ले ब्लैंक

12
यह डेवलपर्स को बिना लाइसेंस के बकवास जारी करने के लिए प्रोत्साहित करेगा।
quant_dev

5
मुझे एक बिक्री प्रबंधक द्वारा एक बार दोपहर का भोजन खरीदा गया था, जिसे एक परियोजना पर एक बहु-हजार डॉलर का कमीशन मिला, जिसे वितरित करने के लिए मैं पांच सप्ताह की मृत्यु के समय गहरी थी। मैं यह नहीं कह सकता कि इससे मुझे स्थिति के बारे में बेहतर महसूस हुआ।
दान रे

7
@quant_dev - हर स्थिति डेवलपर्स को परीक्षण को छोड़कर - अप्रयुक्त बकवास जारी करने के लिए प्रोत्साहित करती है। यह एक अलग सवाल है।
क्रिस बी। 17:00

18
प्रोत्साहन को समायोजित करने का आसान तरीका प्रतिशत कमीशन का भुगतान करने से पहले सौदे की राशि से ओवरटाइम की लागत को घटाना है।
रॉबर्ट

26

इन फैसलों पर विकास टीम से बात की जानी चाहिए या आप उस चक्र से बाहर नहीं निकलेंगे। यदि आप टीम का प्रबंधन नहीं कर रहे हैं, तो आपके एक लाइन प्रबंधक को विकास टीम की वकालत करने की आवश्यकता है। यदि वे समस्या का हिस्सा हैं, तो आप अन्य रोजगार विकल्पों पर विचार करना चाह सकते हैं।

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


2
एक सटीक और उच्च स्तर के योग के लिए +1। उत्पाद प्रबंधन शामिल होना चाहिए, लेकिन बाद में कमिटिंग और खराब दिखना कंपनी के निरंतर अस्तित्व के लिए आवश्यक हो सकता है।
मेपल_शफ्ट

इस तरह की बातें कहना अच्छा है लेकिन यह वास्तविक सलाह नहीं है जो ओपी की मौजूदा समस्या को हल करने में मदद कर सकती है। इस बेहतर स्थिति के लिए वे क्या कदम उठा सकते हैं?
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner बिक्री चर्चाओं में बेहतर उत्पाद प्रबंधन इनपुट की आवश्यकता के बारे में प्रबंधन के साथ बात करने के अलावा, अच्छी तरह से ... एक डेवलपर के रूप में कुछ भी नहीं किया जा सकता है। इस प्रकार की कंपनियां अपने तरीके से निर्धारित की जाती हैं और प्रबंधन की कमी के कारण कुछ भी नहीं बदलेगा।
maple_shaft

1
दुर्भाग्य से बहुत सारी कंपनियों में, बिक्री "गुरु / रॉकस्टार" की राय में अक्सर उत्पाद प्रबंधन की तुलना में अधिक वजन होता है, जो कभी-कभी अपने मामले को ऊपरी प्रबंधन के लिए आगे बढ़ाने में बस मजबूत नहीं होते हैं। मैंने पाया है कि कई बिक्री लोगों का मानना ​​है कि डेवलपर्स जो भी समय का अनुमान लगाते हैं, वह बहुत निराशावादी होगा, और कम से कम आसानी से हल किया जा सकता है।
डोडी_कोडर 8

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

21

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

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

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

जहां यह डांट है, जब समय सीमा वास्तव में कृत्रिम होती है और इसे बिक्री और प्रबंधन द्वारा अपने लिए बड़े बोनस को सुरक्षित करने के लिए धक्का दिया जाता है।

सप्ताह में 45 घंटे से अधिक काम करने की आदत न डालें, यह आपके स्वास्थ्य के लिए बुरा है और यह सबसे पहले आता है।


2
मैं मानता हूं कि छोटी कंपनियों के लिए मेज पर रोटी रखना एक संघर्ष है। फिर भी डेवलपर्स के अतिरिक्त प्रयास के लिए कमीशन प्राप्त करने के लिए बिक्री के लिए यह गलत (scummy) है। प्रबंधन को इस स्थिति को पहचानने की आवश्यकता है या वे हमेशा उच्च डेवलपर का कारोबार करेंगे।
अर्ध नज

16
+ 1 "सप्ताह में 45 घंटे से अधिक काम करने की आदत न
डालें

2
45hrs के साथ क्या है? आपने 40hrs अनुबंध नहीं गाया था ??
sbi

14
@ एसएसबी: आप आश्चर्यचकित हो सकते हैं। जहां मैं काम करता हूं, हमें वास्तव में अनुबंध गाना आवश्यक था। वास्तव में, यह पूरी बात गाने के लिए लगभग 40hrs लिया। (बहुत अच्छा प्रिंट था।) अजीब तरह से बुरा था, क्योंकि मेरे पास एक खराब गायन आवाज है।
मैथ्यू स्काउटेन

3
@MatthewScouten आप कितनी भाषाएं बोलते हैं?
जिम

11

मैंने घर के दोनों किनारों पर काम किया है। बिक्री के लोगों के बिना याद रखें कोई डाउनस्ट्रीम नौकरी या परियोजनाएं नहीं होंगी।

विक्रय-प्रतिबद्धता के लिए कैसे लड़ाई करें : अनुमान करें, फिर कम से कम 130% एकाधिक (हमेशा न्यूनतम 30% आकस्मिक योजना) लें। प्रदान करें और दस्तावेज़ ने कहा अनुमान। एहसास करें कि बिक्री प्रक्रिया में आपके प्रयास के अनुमान कम हो जाएंगे। यह ठीक है, बस प्रबंधन तराश लेना लाइसेंस / बिक्री / कमीशन समझौते उन घंटों के किसी भी कमी की। आप एक सार्वजनिक कंपनी इस के साथ मुश्किल हो जाता है कर रहे हैं VSOE , लेकिन जब तक आप अनुबंध जवाबदेही के साथ बिक्री लोगों को मारा सामने उनकी बिक्री की प्रक्रिया के दौरान, यह हो जाएगा अपने बाद में जवाबदेही।


6
यह केवल तभी काम करता है जब ओपी को संभावित सुविधा को देखने की अनुमति दी जाती है और इससे पहले कि बिक्री करने वालों को बेचने की कोशिश करें, एक अनुमान दें । ऐसा लगता है कि ओपी भी एक मौका नहीं मिलता है : "Here is the committed feature set and here is the committed release date"
FrustratedWithFormsDesigner

2
इसके साथ समस्या यह है कि सेल्सपर्सन अक्सर मान लेते हैं कि आपने एक आकस्मिकता जोड़ ली है और इसीलिए वे पहले की समय सीमा के लिए प्रतिबद्ध हैं।
डोडगी_कोडर 8

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

10

ऐसी बहुत सी रणनीतियाँ हैं जिनका आप उपयोग कर सकते हैं, लेकिन आपको आमतौर पर प्रबंधन से अनुमोदन या खरीद-इन की आवश्यकता होगी।

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

  2. सकल बिक्री के बजाय लाभ के आधार पर वेतन प्राप्त करें। हर घंटे काम जो वे अपने अनुमान में शामिल नहीं करते हैं, उनके कमीशन पर प्रतिकूल प्रभाव डालता है।

  3. डेवलपर्स की संख्या को सीमित करें 40 से काम कर सकते हैं (या दुनिया के आपके हिस्से में मानक कार्य सप्ताह जो भी हो)।

  4. डेवलपरों के काम करने के लिए बिक्री लोगों को हर घंटे काम करें। यदि वे चाहते हैं कि आप अपनी परियोजना को पूरा करने के लिए अतिरिक्त घंटे काम कर रहे हैं, तो उन्हें वहां भी होना चाहिए। ऐसा करने के लिए उनके लिए कुछ उपयोगी खोजें, जैसे कि डॉक्यूमेंटेशन लिखना या कॉलिग्राफ का निर्माण करना, डिज़ाइन पैटर्न और द सी ++ स्टैंडर्ड टेम्प्लेट लाइब्रेरी की हाथ से प्रकाशित प्रतियां ।

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

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

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


# 4 नहीं कर सकते, आप स्पष्ट रूप से यह जानते हैं। बिक्री किसी भी सक्रिय अनुबंध की संभावनाओं का 100 गुना पीछा कर रही है।
Jé Queue

2
पुन: ४: मैं एक ऐसी कंपनी में काम करता था जहाँ बिक्री करने वाले लोग १ 1.०० बजे, बाकी सब से १ घंटा पहले निकलते थे। इसने बिक्री और बाकी कर्मचारियों के बीच अच्छी भावनाएं पैदा नहीं कीं।
quant_dev

2
@Xepoch यदि वे प्रोग्रामर की तुलना में पहले घर जा रहे हैं तो वे स्पष्ट रूप से कुछ प्रबुद्ध पांडुलिपियों को खंगालने में व्यस्त नहीं हैं।
ब्रायन गॉर्डन

1
@ ग्राहम, मैंने "ऐसी रणनीतियाँ लिखीं जिनका आप उपयोग कर सकते हैं", लेकिन वास्तव में ये वास्तव में ऐसी रणनीतियाँ हैं जिनका प्रबंधन तब उपयोग कर सकता है जब वे सतत अतिव्यापन को एक समस्या के रूप में देखते हैं जिसे वास्तव में हल करने की आवश्यकता है। # 1, वास्तव में, सबसे उचित हो सकता है। सिर्फ इसलिए कि आप वेतन पर काम करते हैं इसका मतलब यह नहीं है कि आप ओवरटाइम, बोनस या कॉम्प टाइम के लिए पात्र नहीं हैं। मैंने एक वेतनभोगी कर्मचारी होने के दौरान अलग-अलग समय पर तीनों प्राप्त किए हैं। इसी तरह, सेल्सपर्स के लिए मुआवजे के ढांचे को बदलना असंभव नहीं है; कंपनियां अक्सर सेल्सपर्सन के व्यवहार को बदलने के लिए प्रोत्साहन या डिसेंट्राइव प्रदान करती हैं।
कालेब

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

8

छोड़ना

जवाबों में पहले से ही बहुत सारे समझदार सुझाव हैं, जो उम्मीद करते हैं कि इस खराब रिश्ते को खत्म करने में मदद कर सकते हैं। लेकिन अंत में, आप तय करते हैं कि आप कितना काम करना चाहते हैं।

सहकर्मियों द्वारा अधिक काम में दबाव डालना आसान है। लेकिन जब आप ऐसा करते हैं तो आप अपने निजी जीवन का त्याग कर रहे होते हैं।

यहाँ आप क्या कर सकते हैं:

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

निजी अनुभव

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

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

मेरे पूर्व नियोक्ता के पास एक उच्च डेवलपर टर्नओवर दर है, और इन दिनों भर्ती करना कठिन हो रहा है क्योंकि उनके पास ओवरऑल के लिए एक प्रतिष्ठा है। शायद भर्ती और प्रशिक्षण की अतिरिक्त लागत उन्हें सबक सिखाएगी। लेकिन यदि नहीं, तो यह मेरी समस्या नहीं है।


मैंने इस बारे में एक अच्छी किताब पढ़ी है, जिसे एक बार नेक वर्क फॉर ए जर्क कहा जाता है। मुझे आश्चर्य है कि यह प्रिंट से बाहर है, लेकिन अमेज़ॅन
टॉम रिसिंग

6

पहले यह याद रखें कि तकनीकी रूप से परिपूर्ण प्रोग्रामिंग-आर्ट के निर्माण के लिए सेल्स के लोगों द्वारा किए गए सौदों का समर्थन करने के लिए हम सभी के पास आम तौर पर नौकरियां हैं। यदि वे सौदे नहीं करते हैं तो आपके पास नौकरी नहीं है।

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


4
और अगर आप इसे लागू नहीं करते हैं तो उनके पास कोई नौकरी नहीं है। मैं प्रोग्रामर के इस विचार को बिक्री लोगों के समर्थन के रूप में अनुमोदित नहीं कर सकता।
Agos

@ एगो: निष्पक्ष बिंदु। दूसरी ओर, यदि आप काम करने से इंकार करने के लिए निकाल दिए जाते हैं, तो आपको कहीं और काम पर रखने की कितनी संभावना है? और कैसे तैयार करने के लिए सबसे अधिक दुकानें हैं बस अगले आदमी को किराए पर लें जो मृत्यु मार्च पर जाएंगे।
व्याट बार्नेट

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

5

यह कुछ ऐसा है जिसे आपको अपने प्रबंधक (विकास प्रबंधक, सही?) के पास ले जाना होगा और समस्या को समझाना होगा। यह एक बदलाव है जिसे संगठनात्मक स्तर पर होने की आवश्यकता है - प्रतिबद्धताओं को बनाने से पहले बिक्री को विकास से खरीदने की जरूरत है, और इससे पहले कि वे अपने मालिकों से उस दिशा को प्राप्त करें।

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

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

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


8
लेकिन उन्हें दिखाएं कि उनके पास चार सप्ताह में क्या हो सकता है। शायद उनके पास आधे क्षेत्रों के साथ सभी स्क्रीन हो सकते हैं, या कुछ ऐसे। या कुंजी पाँच वर्कफ़्लो में से तीन। यह पूछें कि आपको उन तीनों में से किस पर काम करना चाहिए। इसे "उनकी" समस्या बनाओ।
sdg

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

4

एक सुझाव जो अभी तक नहीं आया है: पूर्वव्यापी

मत कहो "नहीं, मैं ओवरटाइम नहीं कर रहा हूं," जो हमेशा अन्य डेवलपर्स को झपट्टा मारने और आपको बुरा दिखने के लिए प्रोत्साहित करता है।

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

यदि आप सही हैं और यह सेल्समैन ओवरकोमिटिंग है तो यह बहुत जल्दी स्पष्ट हो जाएगा। लेकिन निष्कर्ष से पहले नहीं और तथ्य के आगे प्रतिकूल मत बनो। इसके बारे में उन चीजों के बारे में बात करें जो आपकी टीम ओवरटाइम के बिना समय पर वितरित करने के लिए कर सकती है।

आप कभी नहीं जानते हैं, आप अपनी खुद की प्रक्रियाओं में सुधार भी पा सकते हैं जो विक्रेता के अनुमान को अधिक संभव बना सकता है।


3

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

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

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


एक ठोस वर्कहॉर्स देव दुकान के रूप में एक प्रतिष्ठा विकसित करना असंभव है जो जादू करने का दावा करने के बजाय वास्तविक रूप से बचाता है? मेरा मतलब है, वहाँ ग्राहक नहीं हैं जो बेवकूफ नहीं हैं और यह वास्तव में उन चीजों को समझते हैं जिनके बारे में हम बात कर रहे हैं?
ब्रायन गॉर्डन

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

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

2

आपकी कंपनी संरचना को जाने बिना उत्तर देना कठिन है।

मदद करने के लिए कुछ सामान्य उपकरण हैं:

  • गुणवत्ता नियंत्रणों पर सहमत हैं (लेकिन वे जो प्रभारी हैं, बिक्री नहीं)
  • एक उत्पाद रोडमैप रखें (आंतरिक और बाहरी)

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

उत्पाद रोडमैप होने से , बिक्री को पता चलता है कि वे ग्राहकों से क्या वादा कर सकते हैं और क्या नहीं। यदि वे रोडमैप बदलना चाहते हैं, तो उन्हें उत्पाद प्रबंधक / परियोजना प्रबंधक / विकास प्रबंधक या जो कोई भी इसे बदलना चाहता है, के साथ उठाना होगा।

यदि वे एक ग्राहक से कुछ वादा करते हैं जो पहले से ही कठिन भाग्य के लिए सहमत नहीं है। उम्मीद है कि आपका रोडमैप ग्राहक की जरूरतों पर बाजार के आंकड़ों पर आधारित है । "आप वास्तव में क्या प्रस्ताव करते हैं कि हम इन 8 अन्य उच्च प्राथमिकता वाले फीचर्स से गिरते हैं जो हमारे पास हमारे ग्राहक आधार की जरूरतों का सबूत है?"

सबसे आखिरी में, जैसा कि पहले से ही अपेक्षित था, 80 घंटे के सप्ताह में काम नहीं करते। आप कंपनी को ऐसा करने में मदद भी नहीं कर रहे हैं क्योंकि आप उन्हें एक गहरा छेद खोदने में सहायता कर रहे हैं।


2

नहीं

मैंने इसे दो अक्षर का उत्तर बनाने की कोशिश की और स्टैक ने मुझे नहीं दिया ... लेकिन उत्तर है

नहीं

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


2

उन्हें यह छवि (या यह ) दिखाएं और उन्हें बताएं कि आप एक असंभव त्रिकोण के साथ काम कर रहे हैं।

  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·

किसी भी परियोजना में, यदि आप इन तीन में से दो कोनों को ठीक करते हैं:

  • समय
  • क्षेत्र
  • गुणवत्ता

... तो तीसरा एकमात्र लचीला है। जो चीज असंभव है वह है उम्मीदें। यदि वे समय को बहुत छोटा करते हैं और स्कोप बहुत बड़ा होता है, तो गुणवत्ता हमेशा खराब होगी। एक फुर्तीली परियोजना में, तीनों कोने कमोबेश लचीले होते हैं।

(अस्वीकरण: मैं पारंपरिक परियोजना त्रिभुज से लागत कारक को बाहर करता हूं और गुणवत्ता कोनों को बनाता हूं । सॉफ्टवेयर परियोजनाओं में समय की लागत है।)

मुझे आशा है कि आप एक अधिक चुस्त परियोजना प्रबंधन के लिए अपना रास्ता बनाने में सफल होंगे।


2

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

जैसा कि बिक्री के लोग पैसे को किसी भी चीज़ से अधिक समझते हैं, उन शब्दों में उससे बात करें।


1

फुर्तीली विकास के साथ हम सलाहकारों को प्रत्येक 1000-1500 के अंक बेचते हुए देखते हैं। यदि आप बिक्री प्रक्रिया को बदल सकते हैं जहां उन्हें पॉइंट स्केल के आधार पर बेचना है तो बिक्री टीम को उचित अनुमान के साथ विकास टीम के साथ काम करने के लिए मजबूर किया जाएगा।


वे सिर्फ "बिंदु" प्रति कार्य पैकेज को बढ़ाएंगे (लेकिन एक पुनरावृत्ति में प्रत्येक "बिंदु" की अवधि) उस बिंदु तक नहीं है जहां यह गुंजाइश और बजट / समयरेखा फिट बैठता है जो वे बेच सकते हैं।
8

अंक प्रति कहानी डेवलपर्स द्वारा नहीं बिक्री या व्यवसाय टीम द्वारा निर्दिष्ट किए जाते हैं।
सोयालेंट्रे

1

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

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


आह, लेकिन salespeople बातचीत की कला में कुशल हैं और इंजीनियर नहीं हैं। यही कारण है कि वे बिक्री में हैं और हम इंजीनियरिंग में हैं! मेरे अनुभव में, ज्यादातर तकनीकी लोग सिर्फ अपना सिर हिलाते हैं (यह मदद नहीं करता है कि अनुमान पूर्वाग्रह के लिए अतिसंवेदनशील होते हैं )। तकनीकी लोगों के लिए यह कहना बहुत मुश्किल है कि किसी को यह सोचने में अधिक समय लगेगा क्योंकि उन्हें पता है कि यह आसानी से उनकी क्षमता पर एक प्रतिबिंब में बदल सकता है। "आपको लगता है कि इसमें दो सप्ताह लगेंगे? जो ने कहा कि वह एक से अधिक में कर सकता है।"
स्कॉट व्हिटलॉक

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

चंचल अनुमान का पूरा बिंदु यह है कि कीमत सही है और गति टिकाऊ है। वे चीजें हैं जो एक ग्राहक के लिए मूल्य हैं; यह जानते हुए कि यह वास्तव में कितना खर्च होगा, और वास्तव में कितना समय लगेगा, और यह कि वे उस मूल्य के लिए जो कुछ भी मांगते हैं, वह मिलेगा और "हम किसी भी कीमत को हरा देंगे" के वादे से कहीं अधिक है। ।
14

1

नौकरी को निर्दिष्ट करने के बाद वे इसे आपको देते हैं और उन्हें बताते हैं कि इसमें कितना समय लगेगा। फिर जब वे इसके बारे में कौवा उन्हें बताते हैं।

"मुझे खेद है कि आपने वह प्रतिबद्धता व्यक्त की, लेकिन मेरे निपटान में संसाधनों को देखते हुए इसे पूरा करने में X घंटे लगेंगे"

हर बार ऐसा करो ... यह मेरे लिए काम किया।

मूल रूप से उन्हें बताओ कि वे इसे फास्ट, सस्ता और अच्छा, दो उठा सकते हैं।


फास्ट और सस्ता?
एडेप्टर

तब यह मुझे अच्छा नहीं लगा।
जिम

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

जब तक वे जानते हैं कि ... ऐसा हो।
जिम

2
वे इसके बारे में परवाह करते हैं कि यह अच्छा है, वे आपको केवल उस परियोजना के लिए दोषी ठहराएंगे, जब ग्राहक खुश नहीं है ...
jwenting

-1

वास्तव में एक तरीका है - एक वास्तविक तरीका, एक खाली पठार नहीं - लेकिन आप इसे पसंद नहीं कर सकते हैं।

बिक्री प्रक्रिया में शामिल विकास टीम से कोई है

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

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

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

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

निश्चिंत रहें कि उनका प्रबंधन भी यही काम कर रहा है। बिक्री प्रबंधक नहीं चाहता है कि बिक्री सहयोगी लाभहीन सौदे बेच रहे हैं। वे लक्ष्य लाभ और न्यूनतम लाभप्रदता के अनुरूप संख्या की सीमा के साथ प्रत्येक वार्ता में चल रहे हैं।

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

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

और अगर आप वास्तव में, ईमानदारी से विचार पर प्रबंधन नहीं बेच सकते हैं, तो क्या मैं एक नया नियोक्ता खोजने का सुझाव दे सकता हूं? क्योंकि तुम्हारा अब वैसे भी ज्यादा समय तक नहीं रह सकता है।


-1

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.