릴리스 날짜가 기술적 인 내용을 기준으로 설정되지 않았지만 영업 담당자가 그때까지 고객에게 약속했기 때문에 반복적으로 멈춰있는 것 같습니다. 다른 회사에서 개발중인 친구들과의 토론을 바탕으로 같은 일이 일어난 것 같습니다.

"커밋 된 기능 세트가 있고 여기에 커밋 된 릴리스 날짜가 있습니다".이 시점에서 돈을 싣고 있기 때문에 논쟁하기가 어렵고 모든 것이 우선합니다.

일반적으로 이것을 되돌릴 수있는 방법이 있습니까? 이 릴리스가 아닌 경우 향후는 어떻습니까? 내가 가진 문제는 내가 한 가지 방법으로 볼 수있는 유일한 방법이며, 가능한 한 최선을 다하고 있지만 소프트웨어를 '있는 그대로'출시한다는 것입니다.

내 이름이 첨부되어 있기 때문에 버그 리딩 소프트웨어를 출시하고 싶지 않지만 한 번에 몇 달 동안 80 시간 동안 몇 주 동안 작업하면 임의로 설정된 릴리스 날짜가 입증됩니다.

편집 : 기록을 위해, 지금은 80 시간을하지 않고 있습니다. 출시 날짜에 설정된 예상 기능을 다루는 데 필요한 것만 생각하면됩니다.

80 시간 주를 그만두십시오. 이것은 긍정적 인 강화 입니다. 그들은 예상 비용으로 제 시간에 제품을 구입하고 있기 때문에, 당신이하는 일에 관계없이 계속 제품을 생산할 것입니다.

그들이 시간을 제대로 책정 할 수 없다면, 그것은 경영진의 잘못입니다. 당신이 아닙니다.

그들이 몇 가지 마감일을 놓치게하십시오.

일반적으로 이것을 되돌릴 수있는 방법이 있습니까? 이 릴리스가 아닌 경우 향후는 어떻습니까?

물론,이 : 그들을 보자 실패 이 방법으로 심하게. 아무것도 가르치고 실패하지 않습니다.

확인 추정 이 시작하기 전에 자신을 보여 그들에게. 그런 다음 최선을 다하고 좋은 코드를 작성 하고 자유 시간으로 어리 석음을 보상 하지 말고 나중에 불평 할 때 엔지니어링 원칙에 따라 자신이 보여준 시간 추정을 상기시킵니다 .

그리고 현재 프로젝트 에서 이것을 시작하는 것이 좋습니다 .

그들이 문제에 대해 당신을 계속 비난한다면, 새로운 직업을 찾기 시작하는 것이 좋을 것입니다.

나중에 생각할 때,이 질문은 실제로 Joel의 저서 중 하나 인 EA : The Human Story에 실린 유명한 EA 이야기에 대한 링크를 보증한다고 생각합니다 .

이는 일반적으로 인센티브로 인해 발생합니다. 영업 사원은 커미션으로 지불하고 생산 직원은 급여로 지불합니다. 영업 사원은 기능, 비용 및 배달 날짜와 같은 여러 가지 레버리지 작업을 수행 할 수 있습니다. 그들은 일반적으로 커미션을 낮추기 때문에 비용을 낮추는 데 강한 인센티브를 갖지 않기 때문에 기능과 배송 날짜를 앞당기는 경향이 있습니다. 그들은 거래를 성사시키기 위해 사람들을 최대한 높게 밀어 붙일 것입니다.

잠시 그들의 관점에서 시도하십시오. 그들은 가족들에게도 먹이를주었습니다. 제가 몇 달 동안 일한 판매를 마감하는 것의 차이가 일정의 몇 주일을 끝내는 것이라면, 특히 유혹을 느끼지 않으면 놀라운 유혹입니다 그게 무슨 뜻인지 이해합니다

유혹은 "항상 그렇게되었고 항상 그렇게 될 것이다"라고 말하는 것입니다. 그러나 내가 일한 곳 중 적어도 한 곳은 해결책을 제안했지만 구현하지 않으면 ... 한 관리자가 마침내 손을 내밀어 말했다. "프로그래머의 초과 근무가 판매를 마치는 데 사용되면 위원회. " 그것은 구현되지는 않았지만 모든 사람의 인센티브를 더 밀접하게 조정했을 것입니다 ... 프로그래머는 커미션을 기대하고 있기 때문에 곧 나올 새로운 기능에 대해 듣고 기뻐했을 것입니다. 영업 사원은 이러한 환경을 만들기가 쉽지 않을 것입니다. 왜냐하면 그들이 유리하게 일할 가능성이 적기 때문입니다.

이러한 결정에 대해서는 개발 팀에 문의해야합니다. 그렇지 않으면 해당주기에서 벗어날 수 없습니다. 팀을 관리하지 않는 경우 라인 관리자 중 하나가 개발 팀을 옹호해야합니다. 이들이 문제의 일부라면 다른 고용 옵션을 고려할 수도 있습니다.

일반적으로 Sales는 제품 관리 팀의 승인 없이는 어떠한 것도 약속하지 않아야합니다. 제품 관리 부서는 타임 라인에 대해 개발 팀과상의해야합니다. 궁극적으로 영업팀은 미달 게재 (품질 또는 범위에 관계없이)하기 위해 약간의 열이 필요하기 때문에 대기업이나 소기업에서이를 우회 할 좋은 변명이 없습니다.

거래를 성사시켜야 할 필요성이 더 큰 소규모 회사에서는 거의 보편적 인 일입니다. 회사에서 영업 회의를 시작할 때까지 나는 이것에 대해 몹시 괴로웠지만, 그것이 어떻게 그리고 왜 조금 더 발생하는지 이해할 수있었습니다.

고객은 빠른 속도를 원하며 많은 사람들이 열심히 게임을합니다. 이를 통해 세일즈는 서명 된 것을 얻기 위해 정시 ​​약속을 구부릴 수 있습니다. 서명 된 계약은 금 또는 금을 사용하여 자본 또는 신용을 취득 할 수 있기 때문에 금입니다. 때로는 아무 일도하지 않는 것보다 마감 기한을 지키는 것이 더 나은 경우도 있습니다.

다른 경우에 그것은 뜨거운 시장이고 많은 경쟁자가 있다면 회사는 다른 사람들보다 더 빨리 제품을 출시해야 할 절박한 필요성이 있습니다. 더 큰 회사 나 더 많은 자본을 가진 회사는 항상 더 많은 자원을 고용 할 수 있지만 더 작은 회사는 더 많은 자원을 고용 할 수 없습니다.

어리석은 곳은 마감일이 실제로 인위적인 것이며 영업 및 경영진에 의해 큰 보너스를 확보하기 위해 추진됩니다.

일주일에 45 시간 이상 일하는 습관을 들이지 마십시오. 건강에 해롭고 우선입니다.

나는 집 양쪽에서 일했다. 영업 사원이 없으면 다운 스트림 작업이나 프로젝트가 없다는 것을 기억하십시오.

판매 초과 커밋에 대처하는 방법 : 추정 한 다음 최소 130 % 배수를 취하십시오 (항상 최소 30 %의 비상 사태 계획). 상기 견적을 제공하고 문서화하십시오. 영업 프로세스에서 노력 견적이 줄어 듭니다. 즉, 괜찮습니다, 단지 관리가 개척을 라이센스 / 판매 / 수수료 계약 그 시간의 감소. 당신이 가진 까다로운 도착 공기업 경우 VSOE ,하지만 당신은 계약 책임과 판매 사람들을 명중 할 때까지 선행 그들의 판매 과정에서, 그것은 될 것입니다 귀하의 나중에 책임.

사용할 수있는 전략은 많지만 일반적으로 경영진의 승인 또는 바이 인이 필요합니다.

1. 개발자에게 초과 근무 수당을 더 높은 비율로 지불하십시오. 여분의 시간을 일하는 것이 그렇게 많은 돈을 벌 때 그리 나쁘지 않습니다. 그리고 회사의 수익성에 영향을 미치기 시작하면 더 나은 일자리를 추정하기 위해 영업에 압력을 가할 것입니다.

2. 매출 총액 대신 이익을 기준으로 영업 사원에게 지불합니다. 그들이 추정에 포함시키지 않은 매 시간의 작업은 커미션에 부정적인 영향을 미칩니다.

3. 개발자가 작업 할 수있는 시간을 40 개로 제한하십시오 (또는 표준 근무 주간이 전 세계 어디에서든지).

4. 매시간 영업 담당자가 개발자가 일하는 시간마다 일하도록하십시오. 그들이 당신의 프로젝트를 완수하기 위해 더 많은 시간을 일하기를 원한다면 그들은 거기에 있어야합니다. 문서 작성 또는 손으로 쓴 디자인 패턴의 사본 및 C ++ 표준 템플릿 라이브러리 제작과 같이 유용한 정보를 찾으십시오 .

5. 개발자가 영업 사원에게 맡기지 않고 각 작업을 예측하도록합니다. 최소한이 방법으로 일정을보다 합리적으로 만들 수 있습니다. 그러나 이것은 훌륭한 해결책은 아닙니다. 개발자는 종종 필요한 작업을 추정하는 데 끔찍합니다. 추정치가 합리적 일지라도 예상치 못한 사건으로 인해 목표를 달성하지 못할 수 있습니다. 또한 마감일이 다가올 때와 같은 긴박한 긴 프로젝트를 시작할 때 우리 모두는 일하지 않는 경향이 있습니다. 이것이 애자일 지지자들이 추구하는 짧은 개발주기에 동기를 부여하는 요소들입니다.

6. "민첩한"접근 방식을 취하고 커밋을 거부하십시오. 민첩가는 것은 더 많은 고객의 참여가 필요하지만 때문에 그것은 또한 고객에게 더 많은 유연성을 제공 할 수 있습니다 그들이 필요하거나 프로젝트의 최종 형태에 앞을 투입 할 필요가 없습니다. 판매는 처음에는 그 점에 만족하지 않을 수 있지만, 더 많은 작업을 판매 할 수있는 많은 기회를 제공 할 수 있다는 사실을 알게되면 조정이 바뀔 수 있습니다.

가장 매력적인 솔루션은 잠재 고객의 입장에서 영업 팀이보기에 좋지 않은 것으로 생각합니다. 영업 팀은 회사의 얼굴입니다. 고객이 나쁜 것처럼 보이게 만들면 회사 전체가 해를 입을 수 있으며 문제를 해결하지 못할 수도 있습니다. 신뢰를 되찾기 위해 고객을 위해 더 나은 거래를해야한다고 생각할 수도 있습니다.

떠나다

이미 답변에 많은 현명한 제안이 있으며,이 기능 장애 관계를 해결하는 데 도움이되기를 바랍니다. 그러나 결국, 당신은 당신이 일하고 싶은 금액을 결정합니다.

동료들에게 압력을 가해 쉽게 일을 처리 할 수 ​​있습니다. 그러나 당신은 그렇게 할 때 당신 의 개인적인 삶을 희생하고 있습니다 .

수행 할 수있는 작업은 다음과 같습니다.

• 상사에게 "여기서 원하는 것보다 더 많은 초과 근무를해야했습니다. 지금부터는 한 달에 X 시간 이상 일하지 않을 것입니다."
• 다른 사람들이 제안한 것처럼 일이 몇 시간이나 걸리는지 추정하십시오. "한 달에 X 시간 제한으로 마감일까지이 과정을 마치지 못할 것입니다." 나중에 참조 할 수 있도록 이메일에 넣으십시오.
• 마감 기한이 지났을 때 그 이메일을 참조하십시오. "참조? 예상대로 합리적 근무 시간 내에이 마감 시간을 맞출 수 없었습니다."
• 그들이 당신에게 초과 근무를 계속하도록 압력을 가하고 모든 의사 소통 노력이 실패한다면, 그만두십시오.

개인적인 경험

나는 항상 초과 근무를하고 더 많은 일을하도록 요청 받았기 때문에 마지막 직장을 그만 두었습니다. 나는 출구 인터뷰에서 그들이 그 일에 대해 많은 것을 좋아 했지만 분명히 초과 근무가 끝나는 것을 보지 못했다고 분명히 말했다 .

나는 또한 나의 새로운 직업에 대한 인터뷰에서 그 욕망을 분명히 표현했으며 열렬한 반응을 얻었습니다. 그들은 그들의 말에 충실했다 : 나는 여기서 초과 근무를 거의 요구받지 않았다.

저의 전 고용주는 개발자 이직률이 높으며, 현재는 오버 워킹으로 유명하기 때문에 채용하기가 더 어려워지고 있습니다. 어쩌면 보충과 훈련의 추가 비용이 그들에게 교훈을 줄 것입니다. 그러나 그렇지 않다면 그것은 내 문제가 아닙니다.

먼저 우리 모두는 기술적으로 완벽한 프로그래밍 기술을 구축하기보다는 영업 사원이하는 거래를 지원할 직업이 있다는 사실을 기억하십시오. 그들이 거래를하지 않으면 당신은 직업이 없습니다.

즉, 모든 사람이 좋아 보이도록 판매와 협력하는 방법을 찾는 것이 요령입니다. 기술 팀이 제안을 마치기 전에 최소한 의견을 제시 할 수있는 프로세스가 핵심입니다. 엔지니어링이 막대한 초과 근무를 할 때 엔지니어링에 "종료"해야하는 경우 비현실적인 일정 작업을 수행하면 죽음의 행진 프로젝트의 빈도가 크게 줄어드는 것처럼 보입니다.

이것은 관리자에게 가져 가고 (개발 관리자가 있습니까?) 문제를 설명해야합니다. 그것은 조직 차원에서 일어나야하는 변화입니다. 판매는 약속을하기 전에 개발로부터 구매를 받아야하고, 그 전에 일어나려면 상사로부터 그 방향을 얻어야합니다.

실제로 변경을 수행하기 위해 할 수있는 일은 없지만, 반드시 관리자에게 가져와야합니다.

문화를 바꾸려고 노력하는 것 외에도 (행운), 그들이 만날 수없는 마감일을 맞이할 때마다, 숫자로 되돌아 가십시오. 프로젝트를 세분화하고 예상 시간을 표시하십시오. 6 주간의 프로젝트라면 그들에게 알려주십시오. 4 주 후에 고객에게 약속 한 경우,이를 수행 할 수 없으며 가능한 한 빨리 해당 정보를 배포해야합니다. 영업 사원이 고객에게 돌아가서 더 나은 기대치를 설정하거나 약속 된 타임 라인 내에 제공 할 수있는 더 작은 수용 가능한 기능 세트와 함께 추가 기능을 나중에 추가 할 수 있기를 바랍니다.

추가 편집 : 그들이 당신의 견적을 말하게하지 마십시오. 그것이 정확하다는 것을 확신하고 고수하십시오. 그들은 것입니다 당신과 함께 협상하려고 노력하지만, 그들을하지 않습니다.

아직 나오지 않은 한 가지 제안 : 회고 .

"아니요, 초과 근무를하지 않습니다."라고 말하지 마십시오. 다른 개발자가 항상 스 와이프하여 기분이 나빠 보이게합니다.

그러나 일을 끝내기 위해 일주일에 40 시간 이상을해야 할 때마다 프로젝트에 관련된 모든 사람 은 제품이 인도 된 후 방안에 앉아 있어야하며 , 무엇이 잘못되었는지 파악하고 다시 발생하는 것을 막기 위해 할 수있는 일. 또는 더 나은 방법으로, 모든 프로젝트는 무엇이 잘 되었고 무엇이 잘못되었는지 에 대해 회고해야합니다 .

당신이 옳고 세일즈맨이 과다 커밋하면 이것은 매우 빨리 분명해질 것입니다. 그러나 결론을 선포하지 말고 사실보다 앞서 나가지 마십시오. 초과 근무없이 제 시간에 제공하기 위해 팀이 할 수있는 일에 대해 이야기하십시오.

영업 사원의 견적을보다 실현 가능하게 만들 수있는 자체 프로세스가 개선 될 수도 있습니다.

이 문제를 완전히 해결할 방법은 없습니다. 판매의 본질은 과도하게 커밋됩니다. 영업 담당자는 잠재 고객의 문제를 마술처럼 사라지게합니다. 좋은 영업 담당자는 약간 과장 될 뿐이고 나쁜 영업 담당자는 자신을 크게 당황하게 할 것입니다.

당신이하는 일은 제품 직원과 영업 사원 사이에 악화되거나 긴장을 유발할뿐입니다. 당신은 당신의 영업 담당자의 부분에서 정말 나쁜 개프를 방지하기 위해 열심히 노력할 수 있지만, 하루가 끝날 때 개발자와 영업 담당자는 동일한 은행 계좌에서 지불됩니다. 회사는 하나의 단위로 성공 또는 실패하므로 판매와의 내전을 시작해도 도움이되지 않습니다.

습관적으로 자신을 당황스럽게하는 영업 담당자가 한 명 이상 있으면 영업 관리에서 문제를 처리합니다. 개발자로서, 당신은 그것에 대해 아무것도 할 수있는 영향력을 가지지 않을 것이므로 그들이 제공하는 시간과 자원으로 최상의 제품을 제공하는 데 집중해야합니다.

회사 구조를 모른 채 대답하기가 어렵습니다.

도움이되는 몇 가지 일반적인 도구는 다음과 같습니다.

• 품질 관리에 동의 (하지만 판매 담당자가 아닌 담당자)
• 제품 로드맵 보유 (내부 및 외부)

품질 관리에 동의하면 버그가있는 소프트웨어를 출시 할 수없는 비즈니스 중심 이유가 있습니다. 왜 상사에게 이것이 중요한지를 설득해야 할 수도 있지만 (권장하지는 않음),이를 돕기 위해 많은 문헌이 있습니다.

함으로써 제품 로드맵을 , 영업은 고객에게 약속 할 수는 없습니다 것을 알고있다. 로드맵을 변경하려면 제품 관리자 / 프로젝트 관리자 / 개발 관리자 또는 다른 사람이 로드맵을 사용하여 로드맵을 높여야합니다.

그들이 아직 동의하지 않은 고객에게 무언가를 약속한다면, 행운을 빕니다. 로드맵이 고객 요구에 대한 시장 데이터 를 기반으로하기를 바랍니다 . "고객 기반 요구에 대한 증거가있는이 8 가지 우선 순위가 높은 기능에서 무엇을 제거하라고 제안합니까?"

마지막으로, 이미 예상 한대로 80 시간 동안 작동하지 않습니다. 더 깊은 구멍을 파는 데 도움을주기 때문에 회사를 돕는 것도 아닙니다.

아니

나는 이것을 두 글자로 만들려고 노력했지만 스택은 나를 못하게 할 것이지만 대답은

아니

물론 당신이 회사를 소유하고 운영한다면 완전히 사실이 아닙니다. 당신이 그 위치 에 있다면, 당신은 귀에 의해 영업 팀을 끌어와 "말을 할 수 있습니다. 그러나, 그리고 내가 생각 하듯이, 당신이 단지 "낮은"기술적 인 사람이라면, 유일한 명령은 "사령부"에 "사슬"을 호소하는 것입니다. 즉, 내 경험은 이런 일이 발생하는 회사에서 경영진이 상황을 인식하고 신경 쓰지 않는다는 것입니다.

이 이미지 (또는 this )를 보여주고 불가능한 삼각형으로 작업하고 있다고 말하십시오.

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

모든 프로젝트에서이 세 모서리 중 두 모서리를 수정하면

• 시각
• 범위
• 품질

... 세 번째는 유일하게 유연한 것입니다. 불가능한 것은 기대입니다. 시간이 너무 짧고 범위가 너무 큰 경우 항상 품질이 저하됩니다. 민첩한 프로젝트에서는 세 구석이 모두 융통성이 있습니다.

(면책 조항 : 기존 프로젝트 삼각형 에서 비용 요소를 제외하고 품질을 모퉁이로 만듭니다. 시간은 소프트웨어 프로젝트의 비용입니다.)

보다 민첩한 프로젝트 관리에 성공하기를 바랍니다.

여기에 아주 좋은 답변이 있습니다. 나는 단지 당신이 자신의 마감 시간을 당신의 손해에 맞추기 위해 운전해서는 안된다고 덧붙일 것입니다. 또한, 나는 영업 사원과 확실히 한 마디로 약속을 이행 할 수없고 회사가 약속을 이행 할 수 없다면 미래에 신뢰하지 않고 미래의 커미션을 잃게된다는 사실을 상기시킵니다. 자신의 직무와 관련이있을 수 있으므로 회사에 대한 신뢰를 얻을 수 있도록 현실적으로 만드는 것이 가장 좋습니다 (예 : 프로그래밍 담당자와상의). 단기적으로는 비현실적이어서 얻을 수 있지만 장기적으로는 나쁜 언급을 통해 고객, 고용주 및 미래 고용주에 대한 명성을 손상시킴으로써 상실 할 것입니다.

영업 사원이 다른 무엇보다 돈을 이해하면 그와 관련하여 그와 대화하십시오.

애자일 개발을 통해 컨설턴트는 각각 ~ 1000-1500 포인트를 판매합니다. 포인트 규모에 따라 판매 프로세스를 판매처로 변경할 수있는 경우 영업 팀은 개발 팀과 협력하여 합리적인 견적을 내야합니다.

그것은 모두 하나의 중요한 포인트로 귀결됩니다. 판매 약속 일정을 충족하는 데 필요한 속도를 유지할 수 없다고 생각되면 업무에 전념하지 마십시오. 판매가 과도하게 약속되면 작업에 동의 할 때까지 문제가 아닙니다. 그렇다면 그것은 당신의 문제입니다. 상사에게 모든 영업 사원이해야 할 일은 '예'라고 말하면 수표를받습니다. 당신은 실제로 약속을 이행하는 사람이므로, 그것이 효과가 없다고 말하면 상사는 듣고 있어야합니다. 가능하고 불가능한 것에 대해 그의 개발 인력보다 영업 인력의 의견을 경청하는 관리자가있는 경우, Dilbert-esque PHB가 있으며 이력서를 업데이트해야합니다.

이것이 내가 애자일을 좋아하는 이유 중 하나입니다. 개발 팀은 초기 설계 토론에서 프로세스에 참여합니다. 양쪽 끝에서 "포인트"를 교정 할 수 있습니다. 개발팀은 대략 1 시간의 개발 인력이 어느 정도 내재되어 있는지 대략적으로 (명시 적으로나 경험적으로) 결정합니다. 경영진은 주당 포인트, 월당 포인트 등을 계산하여 달러 수치로 이끄는 데 사용할 수 있습니다. 이 시점에서 영업 팀은 현재 직원 수준이 현재 범위를 달성하는 데 필요한 비용 및 시간과 관련된 수치를 갖습니다. 그들이 그 숫자를 가지고 나면 과다 약속하면, 그들은 엉덩이에 있습니다.

그들이 당신에게 그것을 준 후에 작업을 지정하고 얼마나 오래 걸릴지 알려주십시오. 그리고 그들이 울부 짖을 때 그들에게 말합니다.

"저는 그 약속을 한 것이 유감이지만 내 자원으로 자원을 제공하면 완료하는 데 X 시간이 걸립니다"

매번 이것을하십시오 ... 그것은 나를 위해 일했습니다.

기본적으로 그들이 빠르고, 저렴하고, 좋은 것을 가질 수 있다고 말하십시오.

실제로는 방법이 있습니다-빈 방법이 아니라 실제 방법이지만, 마음에 들지 않을 수 있습니다.

개발 프로세스 담당자가 영업 프로세스에 참여하도록하십시오 .

지금 당신은 좋은 사람들 기술을 가진 사람이 필요합니다. 그리고이 사람은 당신이하는 일의 종류를 광범위하게 이해해야합니다. 그들은 하지 않습니다 그들은 단지 가벼운 일반적으로 코딩의 이해와 특히 개발 과정이 필요, 코드 닌자해야하고, 일을 추정 합리적으로 잘.

이것은 실제로 비즈니스 분석가 또는 프로젝트 관리자를위한 직업입니다. 이러한 일자리가 많은 회사에서 돈을 많이 지불하는 이유가 있습니다. 그들은 두 가지 매우 중요하고 뚜렷한 기술을 결합합니다. 실제 BA 또는 PM은 없지만 사회 기술을 갖춘 선임 개발자 또는 건축가가있는 경우에도 그렇게 할 수 있습니다.

또한 영업 사원에게 명확한 지침을 제공해야합니다. 효과적으로 (개발팀에서와 같이) 귀하를 대신하여 협상 할 사람을 보내고 있습니다. 매개 변수를 제공하지 않으면 매개 변수가 좋은 것만 협상합니다. 그렇기 때문에 항상 매개 변수를 제공해야합니다.

프로젝트 범위를 이해하면, 당신은 얼마나 많은 시간을 운동을 좋아 구축, 테스트, 범위 변경에 대해 갖고, 등, 플러스 버퍼의 일정 금액은 다음 "권한이 최소"와 함께 그들에게 그 번호를 알려 - 프로젝트를 심각하게 위험에 빠뜨리기 전에 가야 할 가능성 이 가장 낮습니다 . 그들도 특정 숫자만큼 그 숫자 를 삭감 할 것으로 예상 되므로, 최소값을 실제로 필요한 것보다 조금 높게 만드십시오.

그들의 경영진이 같은 일을하고 있다는 것을 확신 하십시오. 영업 관리자는 영업 사원이 수익성없는 거래를 판매하는 것을 원하지 않습니다. 그들은 목표 수익성과 최소 수익성에 해당하는 범위의 숫자로 각 협상에 참여하고 있습니다.

관리자가 아닐 수도 있지만 협상을 시작 하기 전에이 모든 것을 서면으로 문서화 하면 사람들이 프로젝트 일정이 왜 뒤처 졌는지에 대한 질문을 시작할 때 고위 경영진에게 훨씬 확고한 입장에있게됩니다. 그러나 그것은 단지 CYA에 관한 것이 아닙니다. 영업팀은 솔직히 특정 일이 얼마나 오래 걸릴지 알지 못하며 포괄적 인 정보를 제공하여 호의적 인 일을하고 있습니다.

다른 한 가지 : 영업 팀이 팀을 지옥에 몰입시킬 것으로 기대하지 마십시오. 영업 관리자 및 임원의 바이 인도 필요합니다. 당신이 위험 관점에서 접근한다면, 그렇게하기가 너무 어렵지 않아야합니다. 실패를 팔고 싶지 않습니까? 회사의 명성에 대한 비용을 생각하십시오. 소송 비용을 생각하십시오 . 거래에 서명하기 전에 누군가 기술 협상에 참여 해야합니다 .

솔직히 아이디어에 대한 경영진을 팔 수 없다면 새로운 고용주를 찾는 것이 좋을까요? 어쨌든 당신의 것이 훨씬 길지 않기 때문입니다.

이와 같은 의견 불일치는 일반적으로 의사 소통이 없기 때문에 발생합니다. 그들이 당신에게 가하는 압력을 이해하지 못하거나 그들이 실제로 요구하는 것을 이해하지 못합니다. 어느 쪽이든, 문제를 해결하려면 다른 관점에서 상황을 이해해야합니다.

소프트웨어 판매를 시도한 적이 있습니까? 많은 개발자에게 가장 적합한 답변은 아니지만 시도하기 전까지는 영업 측면에서 비즈니스를보기가 어려울 것입니다. 훌륭한 개발자라면 실제로 작성하고 판매하려는 것을 작성하십시오. 당신은 그들이 유효한 포인트를 가지고 있거나 그렇지 않은 것을 볼 수 있습니다!