민첩한 개발을 (폭포) 고객에게 판매하는 방법

우리의 개발 샵은 더 민첩한 프로젝트를하고 싶지만 고객을 선발하는 데 문제가 있습니다. 많은 고객들이 예산과 마감일을 원합니다. 경쟁 업체가 폭포 기반 고정 마감일과 고정 가격을 제시 할 때 민첩한 프로젝트에서 고객을 판매하는 것은 어렵습니다. 우리는 고정 번호가 잘못되었음을 알고 있지만 고객은 그것을 모른다. 따라서 우리는 가격이나 마감 기한을 고칠 수는 없지만 경쟁 업체는 할 수 있기 때문에 고객에게 좋지 않은 것으로 보입니다.

그렇다면 어떻게 애자일 개발 방법을 사용하는 프로젝트 나 그러한 방법을 사용하여 개발 된 제품을 성공적으로 판매 할 수 있도록 영업 인력을 확보 할 수 있습니까? 내가 찾은 모든 정보는 프로젝트 관리 및 개발자에 중점을 둔 것으로 보입니다.

이를 잘 수행하기위한 핵심은 지원 계약을 사용하는 것입니다.

기본적으로 고객을 처음 판매 할 때는 전문 지식을 기반으로 고객을 판매하고 폭포를 만듭니다. 이는 계약 범위와 확정 기한을 설정하는 계약을 의미합니다. 이것이 고객이 원하는 것입니다. 클라이언트는 그 범위를 어느 정도 알고 있습니다. Waterfall은 고정 및 정의 된 범위 환경에서 매우 잘 작동 하며 그러한 환경에서는 민첩한 것보다 더 효과적 이라고 말합니다 . 그리고이 경우 그것은 전에 당신과 함께 일한 적이 없기 때문에 경향이 긴장 될 때 고객에게 편안함을 제공합니다. 괜찮습니다. 애자일은 항상 폭포보다 나은 것은 아닙니다.

따라서 X 범위에 대한 고정 가격 계약이 있습니다. 그런 다음 고객에게 다음과 같이 말합니다.“ 봐봐, 변경하고 싶을 것입니다. 그리고 포스트 프로덕션을 지원해야합니다. 필요에 따라 사용할 예산을 20 % 따로 설정해 보겠습니다. 지원 계약 수단 "

프로젝트 도중에 변경 사항이 발생하면 간단히 지원 담당자가 처리하도록 변경하십시오. (이 변경으로 인해 프로젝트가 심각하게 중단 될 것이라고 가정)

지원 담당자의 조건은 다음과 같습니다. " 고객이 요청한대로 시간당 수행해야하는 작업은 변경 요청 또는 일반적인 시스템 지원 및 유지 관리에 사용될 수 있습니다 ." BAM! 당신은 애자일에 있습니다.

그런 다음 지원 담당자를 계속 확장하고 지원 담당자를 새 프로젝트를 실행하는 수단으로 사용하면됩니다. 또한이 시간 을 선불 로 구매 하고 지불하면 일반적으로 고객에게 15 % 할인을 제공합니다. 상생입니다.

애자일은 마감일과 예산을 배제하지 않습니다. 내가 클라이언트 였고 개발자에게 갔다가 마감 시간이나 예상 비용을 줄 수 없다고 말하면 그들의 건강에 의문을 갖습니다. 그리고 그들이 이해하지 못한다고 말하는 것은 효과가 없을 것입니다. 예산과 계획을 세울 수 있어야합니다.

그들은 당신의 개발 과정을 알 필요가 없습니다. 기능을 개발하는 데 걸리는 시간과 비용이 얼마나 드는지 알아야합니다. 요구 사항이 100 % 정확하다고 가정 한 (가짜) 가정을 기반으로 숫자를 제공하고 요구 사항이 변경되면 추정값을 변경하십시오.

이를 통해 원하는 예산 광고 항목과 배포 날짜를 제공하고 상황이 변경되면 프로세스를 유연하고 수용 가능하게 만들 수 있습니다.

영업 사원이 개발 팀과 고객간에 잘못된 의사 소통을 일으키는 것처럼 들립니다. IT 시장에서 오랫동안 판매하지 않은 경우, '제품 이동'으로 자신의 역할을 볼 수 있습니다. 즉, '무엇이든지간에'계약서에 서명을 의미합니다. 요컨대, 그들은 유망한 것에 관계없이 닫는 동기가 있습니다. 그러한 상황에서 그들은 고객의 언어를 가능한 한 가깝게 추적 할 것입니다.

나는 이것을 인용 한 기록이 깨졌지만 여기에 간다. 당신은 수술대에 있고 외과 의사가 가면서 '우리는 시간과 예산 내에서 당신을 여기서 꺼내게 할 것이다'라고 말한다. 큰. 내가 살아 있을까?

사업체의 내부 장기에서 작업하는 경우 임의의 지점에서 멈추십니까? 일반적으로 응용 프로그램은 규제, 비즈니스 환경, 경쟁사 행동, 새로운 패러다임의 출현 등과 같은 귀 하나 고객의 통제력에 영향을받지 않습니다. 고객은 3 개월 후에 다시 '잘 ...'이라고 말합니다. 일반적으로 폭포 프로젝트에 동의했을 때 알지 못하는 것을 알고 있음을 의미합니다.

이러한 상황에서 효과가있을 수있는 것은 영업 사원에게 협곡을 통한 드라이브의 모습을 보여줍니다. 모든 차례에 놀라움이 있습니다. 약 3 개월 이상 볼 수 없기 때문에 고객이 18 개월 프로젝트를 요청하는 경우 거의 완료 될 때까지이를 인식 할 수 없습니다. 따라서 영업 담당자는 프로젝트의 재무 성과를 찾아서 시작해야합니다. 이로 인해 매출이 천만 달러 증가할까요? 그렇다면 1,000 만 달러를 추가로 투자 할 가치가 있는가? 고객 및 영업 담당자가 500,000 달러에 대한 약속을 수렴하고 있다면 무언가 잘못되었을 수 있으며 누구도 그 사실을 알 수 없습니다. 기분이 좋지 않습니다. '옳지 않은 느낌'은 ​​쓸모없는 위험에 처한 일을하겠다는 약속입니다.

두 개의 최신 제트 여객기 모델은 snafus의 역사를 가지고 있습니다. Healthcare.gov에는 토론이 필요하지 않습니다. 여객기에 관한 서적이나 보도 기사를 찾을 수 있다면 낙관적 인 것으로 판명되고 프로젝트가 마감일을 반복적으로 놓친 특정 가정이 어떻게 만들어 졌는지 알 수 있습니다. 이것은 종종 복잡성을 과소 평가했기 때문입니다. 코딩을 시작할 때까지 얼마나 복잡한 지 알 수 없다면 실제 문제에 대한 더 나은 아이디어를 얻으려면 '초기 라운드'가 필요합니다. 예산 삭감은 총 추가 이익 (또는 경우에 따라 수익)의 일부가되어야하며,이 숫자는 현재 프로젝트 비용이 생각하는 사람보다 많아야합니다. '지급 한도'를 초과하지 않고 마지막 마일스톤을 전달할 수있는 방법을 보여줄 수 있다면,

소프트웨어 개발 외부에서 Agile-Scrum의 이점을 얻는 데있어 주요 장애물은 기존 제어 메커니즘과 통합하는 것입니다. 이러한 제어 메커니즘은 다양한 조직적 전제 조건으로 인해 규정되며 일반적으로 Linear Waterfall 접근법과 방법론을 사용하여 실현됩니다.

이러한 일반적인 조직 필수 구성 요소 중 4 가지가 아래에 나와 있습니다.

• 세계적 대기업 – 이러한 계층 적 매트릭스 조직에서 하향식 포트폴리오 제어는 오늘날의 규칙입니다. 자유로운 씩씩한 민첩한 접근 방식은 엄격한 컨트롤에 적응하기가 어렵습니다. 특히 고유 한 민첩한 무계획 개념으로 인해 조직이 삼키기가 어려워집니다.

• 규제가 엄격한 산업 – 일부 산업은 규정 준수 및 관리 기관에서 엄격한 구속력있는 제어 메커니즘을 갖추어야합니다. 예를 들어 의료 장비, 항공기 및 제약 연구 및 제품 개발 사업부가 될 수 있습니다. 개별 팀이 Agile-Scrum을 운영 할 수 있지만 개발 프로세스는 추적 성 및 거버넌스를 위해 엄격한 선형 폭포 방식을 따라야합니다.

• 복잡한 사전 정의 된 제품 – 하드웨어, 소프트웨어, 임베딩 등을 포함한 일부 통합 제품은 사전 정의 된 요구 사항에 따라 최종 고객과의 계약으로 개발됩니다. 이러한 경우, 요구되는 유연성의 정도는 작지만 처음에 예상되는 것보다 큽니다. 이러한 경우 Agile-Scrum의 완전 유연한 백 로그 개념은 상당히 어려움을 겪습니다.

• 일반 IT 부서 – 유지 관리 중심 IT 부서의 일일 및 주별 활동은 대부분 특별합니다. 일일 일정 변경은 많고 즉각적입니다. 팀 작업에 지속적인 간섭이 표준입니다. 이러한 상황에서 시간 복싱 및 간섭 없음의 개념을 유지하기는 어렵습니다.

당연히 – 위에서 상세하게 설명 된 4 가지 개별 범주의 여러 배가 실제로 혼합되어 있습니다. 따라서 회사 규정을 준수해야하는 글로벌 대기업에서 복잡한 제품을 찾는 것이 일반적입니다.

실제 경험을 바탕으로 이러한 시나리오 및 기타 시나리오를 해결하기 위해 권장되는 방법은 Agile PMO가 새롭게 부상하는 Agile-Scrum 팀과 Linear Waterfall 요소 사이에서 인 에이 블러, 드라이버 및 번역가 역할을 할 수 있도록하는 것입니다.

구체적인 지침은 아래 표를 참조하십시오

출처 -Michael Nir의 Linear Waterfall과 Agile Approache 간의 인터페이스

우리는 잠재적 인 고객 및 개발자와 함께 2 ~ 3 개의 평가 세션을 설정하여 실제 작업에 대해 논의하고 수용 기준을 설정합니다. 개발자는 회의 중 스토리 포인트에서 작업을 추정합니다.

그 후 우리는 고객에게 많은 이야기 포인트를 판매합니다. 그는 스토리 포인트의 가치를 잘 알고 있기 때문에 가능합니다. 프로젝트 중에 백 로그 / 스코프를 미세 조정할 수 있으며 스토리 포인트를 사용하면 쉬울 것입니다. 또한 진행중인 소프트웨어를 자주 제공하여 진행 상황을 모니터링하고 새로운 통찰력을 얻을 수 있다고 말합니다.

많은 이야기 포인트에 동의함으로써 고객은 자신의 돈으로 가치를 얻을 수 있습니다. 그가 백 로그를 변경하지 않으면 고정 가격 / 고정 범위 프로젝트가 있지만 내 경험은 그가 변경할 것입니다. 잠재 고객이있을 때 추정을 수행함으로써 개방성과 신뢰를 바탕으로 관계를 구축하려고합니다.

"예산과 마감일을 원하는"고객과 같은 고객을 설득 할 수 있었으며 고객은 문서에서 작업하는 대신 필요한 것을 실제로 이해하고 싶었습니다. 우리는이 프로젝트에 투자하고 싶다는 것을 보여주었습니다.

평가 세션 동안 전체 백 로그를 추정했습니다. 이것은 x 이야기 포인트를 주었다. 아직 명확하지 않거나 알려지지 않은 기능에 25 %를 추가 할 것을 제안했습니다. 추정 된 잔고가 계약서에 첨부되면 고정 예산에 대한 모든 것을 얻을 것이라고 확신했습니다.

원래 입찰은 시간과 재료였습니다. 고정 가격 입찰을 원했기 때문에 제공 한 가격으로 일하고 25 %의 추가 스토리 포인트를 우발적으로 사용하도록 제안했습니다. 문제가 해결되지 않으면 25 %의 지연 시간을 극복하기 위해 사용되지 않은 부분이 고객에게 더 많은 기능을 제공하는 데 사용됩니다.

이를 통해 여러 가지 방법으로 자극 할 수있었습니다. 첫째, 개발자가 가능한 한 빨리 작업 할 수 있도록 가능한 한 최선을 다했습니다. 우리는 질문에 대한 답변을 기다릴 필요가 없었습니다. 둘째, 그들은 이야기 요점의 개념을 실제로 이해했습니다. 프로젝트가 시작되기 전에 그들은 이미 일부 스토리를 제거하고 다른 스토리를 추정하도록 요청했습니다. 이를 위해 복잡한 계약 협상이 필요하지 않았습니다.

우리는 그들에게 진행 상황을 알리고 매우 열린 의사 소통을 유지했습니다. 그들은 매 2 주마다 진행 보고서를 받았습니다 : 예상 시간의 y %에서 완료된 스토리 포인트의 x %는 추가 스토리 포인트의 z %를 사용할 수있게합니다. 우리는 시작하기가 다소 어려웠지만 프로젝트가 끝날 때까지 추정치를 따라 잡았으므로 추가 개발 포인트가 100 % 남았습니다. 고객은 실제로 필요한 모든 것을 얻었 기 때문에 기뻤습니다 (처음 요청한 기능과 약간 다르기 때문에 일부를 제거하고 다른 것을 추가했습니다).

고객은 모든 것이 예상 된 시간 안에 전달 되었기 때문에 기뻤습니다 (티켓 추적, 즉각적인 질문에 대한 답변, 매주 분석 회의에 사용자 참여, 기능 테스트에 참여하는 것과 같이 우리를 돕기 위해 가능한 모든 것을 수행함).

우리 회사는 시간과 예산에 맞춰 배송하기 때문에 행복했습니다. 이 프로젝트의 성공으로 더 많은 프로젝트의 문이 열렸 기 때문에 우리 회사도 기뻤습니다. 우리는 전세계 사람들에게 보낸 고객의 월간 잡지에도 언급되었습니다.

좋은 평가는 프로젝트의 가장 어려운 부분 이었지만, 평가 세션을 앞당기는 것은 어려움과 위험을 이해하는 데 도움이되었습니다. 그것은 사실에 근거한 추정치를 제공하고 많은 미지수를 제거했다.

고객이 탑승하지 않은 상태에서 컨설팅 / 입찰 환경에서 민첩한 방법을 사용하는 것은 매우 어렵습니다.

폭포 스타일에 익숙하다면 "여기에 우리의 요구 사항이 얼마나, 얼마나 오래 걸립니까?" 프로젝트를 타이핑하고 입찰하기 위해 애자일이나 다른 방법이 더 낫다는 확신을 줄 시간이 없습니다.

애자일은 장점과 단점이 있지만 솔직히 고객은 종종 배후의 세부 사항을 알거나 신경 쓰지 않습니다.

그들은 비용과 시간 규모의 두 가지를 원합니다. 그리고 일단 당신이 그들에게 말하면, 그들은 더 싸고 더 빨리 그것을 원합니다. 그리고 당신은 무엇을 알고, 우리는 그것을 모두 원합니다. 모든 요구 사항. 아무도 기다리거나 다진 수 없습니다.

대부분의 영업에서 영업 사원을 싫어하는만큼 영업 사원에게 너무 열심히하지 마십시오. 그것은 힘든 일입니다.

그들은 소프트웨어를 구축하지 않으며, 대부분 버즈 단어를 지나서 어떻게 작동하는지 전혀 모른다.

그러나 일부 양모 요구 사항 충족을 기반으로 시간 척도 및 비용을 제시해야합니다. 어쩌면 그들은 그들과 함께 통치 할 기술 인력을 보유하고있을 수도 있지만 일을 계속하려면 판매를해야합니다.

그렇다면 어떻게 애자일 개발 방법을 사용하는 프로젝트 나 그러한 방법을 사용하여 개발 된 제품을 성공적으로 판매 할 수 있도록 영업 인력을 확보 할 수 있습니까?

영업 사원이 고객을 사무실로 데려 오게합니다. 애자일의 전체 요점은 고객이 원하는 것을 생산할 수 있도록 클라이언트로부터 즉각적인 피드백을받는 것입니다. 그들을 데려와 그들이 원하는 것을 물어보십시오. 2 주 후, 그것들을 가져 와서 데모 / 시제품을 보여주십시오. 상호 작용으로 팔아요 진행 상황을 보여주고 이러한 종류의 반복이 원하는 것을 정확하게 얻을 수 있도록하고 싶다고 설명하십시오.

필요한 작업의 양에 대한 추정치를 (즉, 예산이 모든 후 무엇을)주고 있지만 전원을 보자 (읽기 : 책임) 그들이에 맞게 원하는 것을 포함하는 자신의 예산.

답은 대부분의 경우 아마 당신이하지 않을 것이라고 생각합니다. 나는 이것을 초기에 귀하의 비즈니스의 작은 부분으로, 아마도 20 % 정도, 나머지는 전통적인 모델로 시도하려고합니다. 시간이 지남에 따라 애자일 제품과 고객에게 더 집중하고 그 부분을 더 많이 성장 시키려고 노력했습니다.

이것을 다루는 또 다른 부분은 아마도 두 가지 접근법을 시도하고 사용하는 것입니다. 고위 경영진 및 계약 협상 담당자와 함께 폭포 접근 방식을 사용하십시오. 예를 들어 '클라이언트가 브라우저 기반 및 휴대 전화 장치 (Apple 및 Android)를 모두 사용하여 포트폴리오를 유지하고 투자 결정을 내릴 수 있도록하는 시스템'입니다. 또는 그런 것. 그런 다음 홈 페이지 작성, 로그인 페이지 작성, Portolio 관리 히스토리 작성, 모바일 로그인 작성 등과 같은보다 자세한 기능에 대해 개발 팀의 개발에 Agile을 사용하십시오.

또 다른 아이디어는 Agile을 차별화 요소로 만드는 것입니다. 대부분의 대규모 조직은 아니지만 애자일을 수행하지 않는 경우가 많습니다. 그러나 대부분의 (내 경험에서 대다수) 소기업입니다. 애자일이 빠르게 성장하고 있다고 생각합니다. 이 경로의 장점은 이미 알고있는 고객에게 가장하고 싶은 일을하는 것입니다. 이 접근 방식은 시간이 지남에 따라 성공을 보장하지 않는 작업이 필요합니다.

고객이 테스트를 좋아하는 경우 견인을 찾을 수도 있습니다. 테스트를 거친 제품은 일부 고객에게보다 쉽게 ​​판매 할 수 있습니다. 이 분야에서 도움이되는 책은 Adison Wesley Press의 'Agile Testing'입니다.

현재 이벤트를 사용하여 사례를 지원할 수도 있습니다. 예를 들어, 현재 (2012 년 10 월에 작성) 건강 관리 사이트는 운영 2 주 전에 필요한 변경 사항을 처리하지 않는 방법에 대한 훌륭한 사례입니다. 또한 명백한 오버 엔지니어링이 더 민첩한 방법으로 해결되었을 것입니다.

업무에 만족하는 이전 고객에게 문의하십시오. 특히 그들이 폭포에서 민첩한 개종자라면. 최소한 고객이 아닌 개종자입니다.

그들의 고객 평가는 고객이 할 수있는 모든 것보다 중요합니다. 새로운 고객의 우려와 두려움을 그 어느 때보 다 해결해줍니다.

관리 관점에서 예산과 마감일은 프로젝트의 비즈니스 요구입니다. 이러한 요구 사항을 해결하고 있는지 확인해야하며 전환에 대한 비즈니스 평가를 보면 직접 표시됩니다. 전환에 대한 개발자의 평가를 보면 종종 그렇지 않다는 것을 알 수 있습니다.