우리는 종종 비즈니스가 고객에게 새로운 기능을 약속 할 여러 시나리오에서 실행되었습니다. 비즈니스는 특정 방식으로 기능을 구현할 것을 약속합니다. 비즈니스에서 약속 한 이러한 기술적 세부 사항은 일반적으로 좋지 않습니다. 불행하게도, 클라이언트는 이제 설정되었으며이 기능이 비즈니스에서 설명 된 방식으로 구현되기를 원합니다.
결국, 비즈니스는 품질 및 유지 보수성에 관계없이이 기능이 완료되기를 원합니다. 되돌릴 수있는 좋은 방법이 있습니까? 요구 사항을 수집하기 전에 기술적 세부 정보를 제공하는 것이 나쁜 생각이라고 어떻게 비즈니스에 설명 할 수 있습니까?
답변:
그것은 조직의 문제입니다. 상급자가 이것을 이해하지 못하면 할 수있는 일이별로 없습니다. 비 기술적 인 상사에게 문제를 설명하려고 노력하지만 아무데도 갈 때 놀라지 마십시오.
어떤 이유에서든 소프트웨어를 판매하는 비 개발 회사에서 일하는 개발자에게는 일반적인 문제입니다.
유쾌한 전술은 아니지만 증거로 그들을 욕설 할 수 있습니다. 프로젝트를 시작할 때 실패한 이유 (기술 세부 정보가 열악했기 때문에)를 정확히 적어 관련 담당자에게 전자 메일로 보냅니다. 계속해서 이메일을 보내십시오. 프로젝트가 결국 고객을 화나게하여 재난이 발생하면 기회가있을 때마다 보낸 이메일을 인용하십시오. 그것은 악의를 불러 일으킬 수 있지만 실제로 그러한 시스템 문제를 해결하려고 시도하는 좋은 방법은 없습니다 .
개발자의 관점에서 볼 때 이것은 스펙 작성과 관련하여 두 가지 실패 유형 중 하나입니다. 발생할 수있는 또 다른 일은 영업이 큰 약속을 한 다음 IT 부서에서 프로젝트를 지정하고 견적을 제출할 수있는 글쓰기를 제공 할 때입니다.
문제는 종종 그 작업의 대부분입니다. 실제 코드는 잘 설계된 사양으로 제시된 접근 방식의 세부 사항을 구현하고있을 것입니다.
동시에 판매는 사양 개발과 같은 예비 비용을 청구하기가 어렵다는 것을 알게되었습니다. 우리는 아직 고객과 잘 지내지 않았으며 돈을 벌기 위해 얼마나 많은 돈을 벌 수 있는지 알아내는 것이 이상합니다.
그렇기 때문에 새로운 고객을 대상으로 한 대부분의 "처음"프로젝트가 손실 리더가되는 이유입니다. LUCKY 인 경우 첫 번째 프로젝트를 사용하여 클라이언트가되는 방법에 대해 클라이언트를 교육하고 두 번째 프로젝트에서 엉덩이를 돌려 받거나 첫 번째 프로젝트에서 유지 보수 계약을 얻을 수 있습니다.