마감일에 대한 현실적인 기대치 설정

저는 소규모 팀의 기술 책임자입니다. 내 접시의 주요 작업 중 하나는 클라이언트와 통신하는 것입니다. 특히 어려운 점은 마감일을 처리하는 것이 클라이언트가 지시하고 마감일이 자주 있기 때문에 마감일을 처리하는 것입니다.

일반적으로 상호 작용은 다음 패턴을 따릅니다. 클라이언트는 추가하려는 기능인 기능 X를 제공합니다. 기능 X는 영업일 기준 약 6 일 후에 다음 주에 출시 될 예정입니다. 이 시점에서 기능 요청은 승인을 거쳐야하며 처리해야 할 다른 종속성이 자주 있습니다. 결국 N 일 후에 기능 요청이 내 팀으로 흘러 들어갑니다. 개발자가 아닌 관리자가 설정 한 원래 최종 기한을 달성하더라도 더 이상 달성 할 수 없습니다. 우리 팀은 비난을 받고 낙담 한 느낌 이 들었고 전반적으로 패배의 분위기 가 있습니다.

분명히 전체 프로세스가 중단되었습니다. 불행히도, 내가 권력의 위치에 있지 않기 때문에 내가 할 수있는 일은 많지 않습니다. 내 현재 접근 방식은 고객에게 시작 날짜 대 마감일, 기능 범위 등을 부드럽게 상기시키는 것입니다. 그래도 변명하는 것처럼 느껴집니다.

비슷한 상황에 있었습니까? 무엇이 당신을 위해 일하지 않았습니까?

당신은 정말로 이것에 대해 상사와 이야기하고 몇 가지 기본 규칙을 설정해야합니다.

• 커밋하지 않는 한 마감일은 마감일이 아닙니다.
• 견적은 귀하가 제공하지 않는 한 추정치가 아니며, 이는 어려운 마감일이 아닌 "추정"입니다.

Robert Martin의 Clean Coder 에는이 내용을 상사에게 전달하는 방법에 대한 장이 있습니다. 영업팀이 불가능한 약속을하고있는 것은 당신의 잘못이 아닙니다.

새로운 기능을 얻으면 기능을 추정하고 PERT를 사용하여 확률 분포를 갖습니다. "4 일 안에 처리해야하지만 최대 8 일이 소요될 수 있습니다." 당신의 입장을 고수. 세일즈맨과 견적을 협상하지 마십시오. 결국 불가능한 일에 봉착하게됩니다.

이 작업을 몇 번 반복하면 영업 사원이 바보 같은 짓을하게 될 것이며, "개발팀에 문의하여 언제 끝낼 수 있는지 확인할 것"으로 행동을 조정할 것입니다. 파괴.

비슷한 상황에 있었습니까? 무엇이 당신을 위해 일하지 않았습니까?

대부분 작동하는 것은 진실을 힘으로 말하는 것입니다.

사실을 모으십시오. 사실을 제시하십시오. 고객이 자신의 속도에 따라 배우거나 배우지 않도록하십시오.

우리 팀은 비난을 받고 낙담을 느끼며 전반적인 패배 분위기가 있습니다.

왜 팀이 책임을 알고 있습니까? 고객이 귀하를 우회하고 팀과 직접 대화하는 경우 효과가 없어지고 이유를 파악해야합니다.

당신의 팀은 "비난"이나 비난에 대해 무지해야합니다. 이들은 단순히 소프트웨어를 구축해야하며 고객이 현재하고있는 작업과 수행중인 시간을 커뮤니케이션해야합니다.

고객은 결국 프로세스를 이해하기 위해 성장해야합니다. 나쁜 습관을 없애려면 많은 반복이 필요합니다. 아주 더.

나는이 정확한 상황에 있었고 즐겁지 않았습니다. 그러나 내가 한 접근법은 현재 개발중인 작업 기록을 세 심하게 유지하는 것이 었습니다. 작업이 진행되면 클라이언트, 관리 또는 프로젝트 관리자에게 다른 작업이 우선 순위가됨에 따라 다른 작업이 진행될 것임을 상기시킵니다.

그렇지 않으면 고객을 다루고 이러한 마감일에 동의하는 프로젝트 관리자 / 고객 연락 담당자 / 관리 / 영업 사원 인 돌담에 그 끌을 계속 망치려고 노력해야한다고 생각합니다. 나는 그들이 어떤 일을하는 데 5 일이 걸린다는 데 동의한다면, 그들은 분명히 5 일의 개발에 대해 이야기하고 있다는 것을 깨달았습니다. 다음 이틀 동안 멋진 단어 doc을 작성).

그러나, 귀하는 개발을 주도하므로 처음부터 귀하와상의하지 않으면 이와 같은 결정은 무의미합니다.

또한 가능한 한 많이 팀을 보호해야합니다. 어렵지만 고객 / 관리 정치에서 최대한 멀리 떨어져 있어야합니다. 그렇지 않은 경우 더 많은 헤드 해머가 필요합니다.

기본적으로, 나는 그것을 즐기지 않았고 아무리 힘들어도 그 과정이 완벽하지는 않았습니다. 그러나 나는 일을 다소 개선했습니다.

당신이 할 수있는 유일한 일은 고객과 대화하는 것입니다. 당신이 볼 때 일어나는 일을 설명하고 모든 위험 등을 설명하십시오. 나는 비슷한 상황을 겪었고 정말 화가났다. 지금도 모든 기술적 인 평가에 대한 책임이있을 때 종종 들었습니다. 우리는 월요일까지 그것을 원합니다. 나는 단지 말한다-당신은 그것을 얻지 못할 것이고, 월요일까지 정확히 당신이 원하는 것을 토론하고, 종종 모든 중요한 기능들이 구현하기 쉽고 월요일이 절대적으로 괜찮은 것처럼 보입니다. 그런 다음 다른 모든 기능은 이후 릴리스로 예약됩니다.

문제는 고객이 대부분 해당 기능의 비즈니스 가치를 알고 있지만 그 복잡성을 깨닫지 못한다는 것입니다. 논의하고 명확히하십시오. 항상.

고객에게 시작 날짜가 기능을 요청한 날짜보다 늦다는 것을 상기시키는 것이 좋습니다. 당신은 또한 클라이언트 말할 수 있도록 기능에 대한 세부 정보를 얻기 위해 고객과의 초기 대화를하지 누구든지 할 얘기가 시간에 더 나은 마감이 될 것입니다. 이미 고객과 의사 소통을하고 있기 때문에 "이 마감일에 동의 한 Y 부서의 담당자는 누구입니까?"라고 말할 수 있습니다.

그들이 대화에 참여하지 못하게하거나 조용히하고 그들이 동의 한 마감 시간을 갖도록 지시하면, 팀이 제 시간에 온다면 회사 전체가 더 나아질 것임을 상기시킬 수 있습니다. 이를 달성하기 위해 마감일에 입력을 받고 있습니다 .

정보 흐름을 수정하십시오.

• 고객과 의사 소통해야한다면, 모든 프로젝트 이해 관계자 (고객 포함)가 항상 귀하와 직접 연락하도록하십시오 .

슬프게도, 권력은 대부분 다른 사람들이 당신에게 부여하는 것이 아니라 자신이 취하는 것입니다.

내 접시의 주요 작업 중 하나는 클라이언트와 통신하는 것입니다. 특히 어려운 점은 마감일을 다루는 것이 클라이언트가 지시하고 마감일이 종종 있기 때문에 마감일을 처리하는 것입니다.

고객과의 커뮤니케이션에 책임이있는 경우, 조직 내에서 담당 직원과 고객 측 담당자간에이 정보를 전달할 수 있도록 스케줄링 (및 예산)에 대해상의하지 않는 이유는 무엇입니까? 이 문제를 해결하는 것이 귀하, 팀 및 프로젝트에 큰 도움이 될 것이라고 생각합니다.

클라이언트는 추가하려는 기능인 기능 X를 제공합니다. 기능 X는 영업일 기준 약 6 일 후에 다음 주에 출시 될 예정입니다. 이 시점에서 기능 요청은 승인을 거쳐야하며 처리해야 할 다른 종속성이 자주 있습니다. 결국 N 일 후에 기능 요청이 내 팀으로 흘러 들어갑니다. 개발자가 아닌 관리자가 설정 한 원래 최종 기한을 달성하더라도 더 이상 달성 할 수 없습니다.

스케줄링을위한이 시스템은 가장 이상하게도 이상하게 보인다.

내 경험상 고객은 특정 릴리스에 서명합니다. 원하는 기능 및 변경 사항 목록과 원하는시기를 제출 한 다음 소프트웨어를 구축하는 팀과 협상 할 수 있습니다. 또는 개발 팀에 우선 순위가 지정된 기능 목록을 제공 할 수 있으며, 개발 팀은 다양한 기능 세트를 제공 할 수있는시기에 대한 견적을 제공합니다. 다른 변형도 있습니다.

그러나 내가 허용 한 적이없는 것은 고객이 게임 출시 후반에 출시를 변경할 수 있다는 것입니다. 디자이너, 개발자 및 테스터가 그런 압력을 가하는 것은 옳지 않은 것 같습니다. 반복 개발을 수행하는 경우 우선 순위가 높은 기능인 경우이를 백 로그 양식에 추가하고 가능한 빨리 가져 가십시오. 우선 순위가 높은 기능이 아닌 경우에는이 릴리스에서 반드시 필요하지 않으며 다음 릴리스까지 기다릴 수 있습니다.

설계, 개발, 테스트 및 제공 팀과 고객이 동결, 코드 동결 및 전달 기능을 제공 할 수 있도록 기본 규칙을 설정하는 것이 좋습니다. 이것들을 서면으로 작성하고 모든 사람의 헌신을 얻고 그것을 고수하십시오. 한 번 버지 않으면 더 구부릴 것으로 예상되며 프로세스를 제어 할 수 없게됩니다.

불행히도, 내가 권력의 위치에 있지 않기 때문에 내가 할 수있는 일은 많지 않습니다.

혼자가 아닐 수도 있습니다. 그러나 디자이너 및 / 또는 개발자 및 / 또는 테스터가 일정을 충족해야하는 압력이 큰 것처럼 들립니다. 당신은 팀으로서 상사와 함께 앉아서 상황을 설명해야합니다. 먼저, 조직이 프로세스 개선에 전념하도록 한 다음 고객과 협력하여 일이 어떻게 진행 될지 고객에게 문의하십시오.

그래도 변명하는 것처럼 느껴집니다.

변명하기 시작하면 어려운 대화 나 결정적인 대화 를해야 할 때 입니다. 그 두 권의 책 중 하나를 추천합니다. 그것들을 읽으면 나의 의사 소통 능력을 향상시키는 데 도움이되었으며, 특히 모든면에서 긴장이 높은 어려운 상황에 직면해야 할 때.

다른 답변 중 일부를 해결합니다.

슬프게도, 권력은 대부분 다른 사람들이 당신에게 부여하는 것이 아니라 자신이 취하는 것입니다.

안드레아 가 어디로 가고 있는지 모르겠습니다 . 예, 정보 흐름을 수정해야합니다. 그러나 PM 및 고객과 함께 프로젝트 시작시 동의 한 사항을 모두가 알 수 있도록해야합니다. 어떤 이유에서든 합의가 이루어지지 않으면 재 방문하여 자신에게 더 적합한 사람들에게 업무와 역할을 재분배하십시오.

당신은 권력을 얻거나 권력과 싸우지 않지만 힘을 다해 길들여 모든 사람을 위해 일하게 만듭니다.

문제는 고객이 대부분 해당 기능의 비즈니스 가치를 알고 있지만 그 복잡성을 깨닫지 못한다는 것입니다. 논의하고 명확히하십시오. 항상.

loki2302의 인용문 은 꽤 많이 등장 했습니다. 소프트웨어 엔지니어로서의 직무 중 하나는 올바른 사람들이 작업이 얼마나 어려우며, 시간이 오래 걸리며, 어떤 일을 할 때 어떤 종류의 옵션과 위험이 있는지 알고 있어야합니다. 팀의 수석 의사 소통 자로서이 정보를 조직에서 고객에게 전달하는 것은 이론적으로는 직무입니다.

마감일을 정하는 사람에게 다가 갈 포럼을 찾으십시오. 그들이 당신과상의하고 더 현실적인 것을 제시해야한다는 것을 알려주십시오. 대안은 다음과 같습니다. 클라이언트에게 발생하지 않을 것을 알리거나 클라이언트에게 알릴 수 있습니다.

팀이 작업을 시작하면 X 일 이내에 할 수있는대로 제시 할 수 있습니다. 어쩌면 그것은 혼란입니까? 반복해서 발생하지 않는 한 정직한 실수입니다. 그런 다음 방치합니다.

귀하의 팀이 과거에이 기한을 충족했다고 생각합니다.

불행히도 업계에서 고유 한 특성을 지니고 있기 때문에 많은 디지털 / 소프트웨어 대행사는 회사의 내부 작업이나 요구 사항에 대해 전혀 모릅니다. 많은 사람들은 빠른 현금에만 관심이 있습니다. 많은 사람들이 견적이나 마감일을 제공하지 않으면 이전에 말했듯이 경영진에게 알리십시오. 개발 팀의 일정을 알고있는 기술 담당자의 추정없이 x 시간으로 기술 작업을 제공하는 방법은 무엇입니까?

다른 모든 것이 실패하면 떠나십시오.

프로젝트 관리자 / 보스 / 클라이언트에게 달성 가능한 견적 및 일정을 알려주고, 계획을 확인하도록 요청하거나, 그가 먼저 작업하고 싶은 것을 해결 한 다음 떠나십시오.
그가 당신의 견적을 반영하지 않는 프로젝트 계획으로 돌아 오면, "나는 견적을 협상하지 않습니다."라는 진술과 함께 그에게 다시 발사하십시오. 걸어가

CYA 문서가 많이 있는지 확인하십시오. 이 문서를 보관하고 있다는 사실을 모든 사람들에게 분명히하십시오. 본인의 개인 이메일 주소로 이러한 기록을 이메일로 보냈으며 CC가 내 상사에게 CC를 보냈는데, 이는 매우 성공적이었습니다.

다음은 손가락 포인팅 대신 건설적인 방법으로 접근해야합니다. 나는 당신을 비난하지 않고 단지 고발의 진실에 관계없이 잘못한 누군가와 변명하는 것이 좋지 않다고 말하고 있습니다.

이 문제가 발생한 후 사후 관리를 수행하여 실제로 프로젝트를 완료하는 데 걸린 시간 또는 완료 한 시간을 계산하십시오. 그런 다음 충분한 정보가있을 때부터 사용 가능한 리소스 시간과 이에 대한 녹색 표시등을 계산하십시오. 이 숫자를 마감 시한을 맞추기 위해 몇 명의 프로그래머를 추가 할 수 있는지로 변환하십시오.

이제 다음 라인을 따라 상사와 대화하십시오.

프로젝트 시작 날짜 Y와 마감일 Z 사이에 X 사용 가능 시간이있었습니다.
프로젝트를 완료하려면 X + C 시간이 필요했습니다.
다른 프로젝트에서도 비슷한 처리 요구 사항이 있습니다.
기대에 부응하는 데 필요한 용량에 도달하려면 Q 추가 프로그래머가 필요합니다.
예산이 부족한 경우 프로젝트 관리자와 협력하여 예상보다 더 많은 시간을 투자하여 약속을 지키지 못하고 과도하게 전달할 수 있습니다.