위험 회피 환경에서 준 엄격한 출시 일정을 어떻게 옹호 할 수 있습니까?

최근에 나는 점점 내가이 직업에있는 나의 가장 실망과 사기 살해 경험 중 하나로 설명 할 것입니다 무엇에 의해 시달려했습니다하는 데 릴리스에 앉아 테스트되었습니다, 재 테스트, 무대, 그리고 모든 의도에 대한 그리고 목적은 선적 / 배포 할 준비가되었습니다 .

하드 코어 코더뿐만 아니라 모든 주변 솔루션 사용자로서, 나는 적절한 변경 제어의 필요성을 이해하고 심지어 옹호했습니다. 그러나 최근에 우리의 기지를 덮는 것과 제 시간에 맞춰 선적하는 것 사이의 잔고 한 균형이 사라졌고 나는 그것을 제정신으로 복원하는 데 거의 성공하지 못했습니다.

위험 회피 경영진에게 다음과 같은 사실을 확신시키는 데 도움이 되는 강력한 주장을 찾고 있습니다 .

1. 개발팀은 당연히 자체 출시 일정을 세울 수 있어야합니다 (또는 1 ~ 3 개월은 포춘지 선정 500 대 기업을 제외한 모든 회사를 위해 충분히 보수적이어야합니다).

2. 소프트웨어 릴리스는 중요한 이정표이며 신중하게 취급해서는 안됩니다. 다시 말해서 불필요한 지연 / 정지가 매우 파괴적이며 일부 중요한 비즈니스 문제에 대한 최후의 수단으로 만 고려해야합니다. 과

3. 이해 관계자로서 참여하기를 원하는 (또는 수요가 아닌) 외부 (비 개발 / 비 IT) 실체는 특히 예정된 선박의 지난 주 또는 그 이전에 출시 일정을 달성하기 위해 개발팀과 협력 할 책임이 있습니다. 날짜 (예 : 사용자 테스트 / 스테이징).

위의 내용은 경험을 바탕으로 나에게 맞는 주장 이지만, 지금 그것을 증명해야 할 입장에있는 것처럼 보입니다 . 따라서 그러한 것이 존재하는 경우 여기에서 조금 더 강력한 것을 요구하고 있습니다.

경영진에게 고정 된 (또는 반 유연한) 릴리스주기에 대한 아이디어를 "판매"해야했던 사람이라면 어떤 주장 / 전략이 효과적이거나 설득력 있고 어떤 것이 아닌지에 대한 몇 가지 지침을 제시 할 수 있습니까? 명백한 일정 경합 및 가라 앉은 비용 외에도 "기업"환경에서도 운송이 실제로 중요한 경우를 만드는 데 유용한 하드 데이터 / 증거가 있습니까?

대안으로, 일정에 맞춰 배송하는 것보다 일정 유연성 (주 / 월에 걸쳐)이 왜 중요한지에 대한 건설적인 주장을들을 수 있습니다. 지금은 믿기가 어렵지만 아마도 내가 모르는 것을 알고있을 것입니다.

_{출시를 준비했으며 프로덕션을 제외한 모든 단계를 거쳤습니다. 상용 버그 추적기를 사용하여 문제를 추적하고이 릴리스에 할당 된 모든 문제 (100 %)가 마감되었습니다. 나는 믿기가 어렵고 그것이 정확히 요점이라는 것을 알고 있습니다. 100 %, 기능이 완전하고, 완전히 테스트되고, 승인 된 이해 관계자 별 릴리스가 설명되지 않은 이유로 경영진에 의해 지연 될 것이라는 것은 말이되지 않습니다. 그것이 일어나고있는 일이며, 해결해야 할 문제입니다.}

Joel Spolsky는 소프트웨어 개발 팀은 자본 (돈)을 작동하는 소프트웨어로 전환하기위한 계획이라고 말합니다. 솔직히, 귀하의 질문에 따르면, 귀하의 팀이 그것을 잘하는 것처럼 들립니다. 합리적인 금액의 돈을 투자하면 괜찮은 소프트웨어를 얻게됩니다.

물론 다음 단계는 소프트웨어를 서비스하는 것입니다. 귀사가 그렇게하기로 결정하기 전까지는 자본 투자 수익을 거둘 방법이 없습니다. 배포 준비가 완료된 선반에있는 소프트웨어는 재고 실의 재고와 비슷합니다. 기회 비용도 있습니다 : 여러분의 그룹은 다른 것보다는이 프로젝트를하기로 선택했습니다.

또한 선반에 앉아 새로 개발 된 소프트웨어의 가치는 식당의 냉장고에 앉아있는 치즈 상자의 가치와 비슷합니다. 천천히 썩습니다. 경쟁사가 따라 잡기 때문에 가치가 떨어집니다. 또한 개발자가 다른 일을 진행함에 따라 새로운 소프트웨어를 서비스에 도입하는 것이 점점 더 어려워지고 위험 해지기 때문에 거부합니다. 선반에서 몇 년이 지난 후에는 실제로 가치가 없을 수 있습니다. 이 경우 회사는 개발에 투자 한 자본을 폐기하기로 결정했습니다. 회사의 소유자 인 주주가 이에 대해 불쾌감을 줄 수 있습니다.

개발자로서 알아 두어야 할 것이 있습니다. 제안한 릴리스주기가 끝나면 소프트웨어를 실제로 배포 할 준비가 되었습니까? 준비가 되었습니까, 아니면 회사가 생산에 투입 할 때해야 할 일과 돈이 더 많습니까? 회사에서 소프트웨어를 배포하는 데 필요한 서버 및 소프트웨어 라이센스를 보유하고 있습니까? 작업 제품에 배포 계획이 포함되어 있습니까? 최종 사용자 교육을 받았습니까? 생산 데이터가 변환 되었습니까? 새 소프트웨어에 회사의 비즈니스 방식 변경이 포함 된 경우 회사에서 해당 변경을 수행 할 준비가 되었습니까? 새로운 것들과 오래된 것들이 작동하는지 확인하기 위해 병렬로 작업을 수행하기위한 계획을 세웠습니까?

이러한 모든 롤아웃 비용은 소프트웨어 개발 비용을 쉽게 뒤흔들 수 있습니다. 현명한 프로젝트 관리 팀은 모든 것을 계획하고 예산을 세우고 일정을 잡기 위해 최선을 다합니다. 그 일을 했습니까? 경영진에게 명확하게 설명했습니까? 그렇지 않은 경우 롤아웃 속도가 느려질 수 있습니다.

최신 민첩한 소프트웨어 롤아웃 일정이 회사의 다른 부분에서 예상하는 변화 속도와 일치하지 않을 수 있습니다. 최종 사용자 (이해 관계자)는 팀이 만들 수있는 속도로 변화를 흡수하지 못할 수 있습니다.

관리 팀이 제대로 작동하지 않을 수도 있습니다. 팀이 회사의 다른 곳에서 원하지 않는 것을 개발 했습니까? 새로운 물건이 영업 또는 생산 팀의 도발을 위협합니까? 그렇다면 일부 임원은 출시하기에는 너무 위험하다고 말함으로써 어뢰를 공격 할 수 있습니다. CEO가 아닌 이상 할 수있는 일은 없습니다.

적시에 소프트웨어 롤아웃에 대한 강력한 주장을 요구했습니다. 투자 수익이라는 정말 매력적인 주장이 있습니다. 회사는이 소프트웨어에 투자하기로 결정했으며, 이제 소프트웨어가 선반에서 천천히 썩어 가면서 투자를 낭비하고 있습니다.

시기 적절한 출시에 대한 두 번째 주장은 팀의 사기입니다. 서두르는 것은 창의적인 개발자가 좋은 일을하도록 동기를 부여하는 좋은 방법이 아닙니다. 업무 수행에 만족하지 않으면 팀을 잃을 수 있습니다.

먼저,이 비디오를보십시오 :

http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain

행정상 개요 :

시간과 예산에 맞춰 배송하는 방법은 다음과 같습니다. 시간이 없거나 돈이 부족하면 배송합니다. 그게 다야.

대부분의 프로젝트가 제 시간에 출시되지 않는 이유는 누군가가 리소스를 제공 할 때 개발주기에서 한 번에 출시 준비 직전에 릴리스에 삽입 할 "하나 이상의 기능 또는 수정 사항"을 제공하기 때문입니다. 가장 드물고 이제는 출격해야합니다. 이것을 스레 싱 (thrashing)이라고하며, 배송하지 않는 한 사람들이 제품을 빨아들이라고 말하는 사람들에 대해 걱정할 필요가 없기 때문에 발생합니다.

스 래싱을 치료하는 방법은 사람들 이 제품 개발주기가 시작될 때가 아니라 시작 하도록 강제 하는 것입니다.

출시일 바로 몇 주 전에 제품을 변경하는 것은 명백한 이유로 매우 파괴적입니다. 변경 사항이 새로운 기능이든, 소프트웨어 개발 프로세스 변경이든, 또는 개발 일정에없는 오래된 버그를 수정하려는 시도이든 마찬가지입니다.

누군가가 늦게 개발주기의 수정 또는 변경 나에게 올 때, 나는 항상이 질문 : "당신은 제가 당신의 일을 끝낼 수 있도록 수행되지 원하는 작업?"

돈 동기 부여가 필요한 경우 이는 다음과 같습니다. 연구 결과에 따르면 소프트웨어 라이프 사이클에서 기능 또는 수정을 구현하기 위해 기다릴수록 더 비쌉니다. 기하 급수적으로. 이것을 증명하는 것은 어렵지 않습니다.

직면 한 문제에 대해 명확하게 설명했지만 관리자가 왜 이런 식으로 행동하는지 확실하지 않습니다. 당신은 명확히 할 수 있습니까? 예를 들어, 배포 할 준비가되었다고 생각하고 누군가 동의하지 않으면 누구와 왜 그렇게합니까? 그들은 전직 관리인입니까?

이것은 능력 대 욕구 정렬 문제와 비슷하게 들리지만, 권한을 가진 사람들은 욕구가없는 능력 (권한)이 아니라, 욕망을 풀기를 원합니다.

왜 그들이 욕구가 부족한지 알아야합니다. 마케팅 이유입니다 (이전 버전을 조금 더 젖을 짜는 동안 1 년 동안 유지하십시오), 두려움 / 자신감입니까 (버그가있는 경우 우리를 나쁘게 보일 것입니다) , 우리에게 돈을 지불 ...., 자원 부족 (배송 / 포장 / PR 물건의 비용을 감당할 수 없다), 당신의 불분명 한 초과 수익으로 가라 앉는 싱크대에서 돈을 버는 것을 원하지 않는 상업적입니까? 소리만큼 바보가 아닙니다).

또한 관련 당사자들 사이에 약간의 존중이 있다고 의심되므로 합리적인 성인 토론이 이루어지지 않습니다.

죄송합니다. 요청한 특정 답변이 아니라 몇 가지 생각할 사항이 있습니다.

가장 먼저 고려해야 할 것은 릴리스가 위험하지 않은지 확인하는 것 입니다.

이상적으로 변경 요청에는 위험 완화 와 같은 섹션이 있어야하며 , 문제가 발생할 경우 이전 버전으로 롤백하는 방법에 대한 지침이 포함되어 있어야합니다 . 리스크 측면에서, 사전 테스트의 양은 변경을 롤백하기위한 간단한 옵션을 대체 할 수 없습니다.

• ^{위험 회피 환경에서는 돌이킬 수 없는 변화를 고통없이 만드는 방법을 상상할 수 없습니다 .
  많은 / 대부분의 릴리스가이 범주에 속하는 경우 아키텍처를 다시 고려할 수 있습니다.}

방출하지의 위험은 당신이 dev에 팀 일정이 심각하게 취급 할 경우, 노출 될 것입니다.

릴리스가 프로덕션 / 지원 문제 및 중단에 대한 수정 사항을 제공하는 경우,이를 나열하고 업그레이드하지 않는 한 프로덕션이이를 반복 할 위험이 있음을 지적하면 쉽게 수행 할 수 있습니다.

개발 팀이 출시 전표에 맞서 싸울 수있는 효과적인 방법으로 시간이 지남에 따라 릴리스되지 않을 위험이 증가합니다 . 내부 릴리스가 일정대로 실행되어 생산 문제에 대한 "누적"솔루션 목록을 제공하여이를 달성 할 수 있습니다.

• 간단히 말해서, 릴리스를 차단 XX하는 사람들 N은 해결되지 않은 상태로 생산 문제가 발생할 위험이 있을뿐만 아니라 그 주 (또는 한 달) 후에 XX+1승인 대기열에 릴리스 되어 차단 될 것임을 알아야합니다. N+M생산 문제 의 종류에 대한 위험은 여전히 해결되지 않은 상태로 남아 있으며 이는 XX+2개발팀이 제공 한 "내부"릴리스 의 경우도 마찬가지입니다 .

위에서 설명한 방식은 본질적으로 응용 프로그램 업데이트와 프로덕션 문제 사이를 더 강력하고 명시 적으로 연결합니다.

따라서 생산 문제 에스컬레이션에 더 많은 참여가 필요할 수 있습니다 . 보다 엄격한 예약 업데이트 비전을 홍보 할 수있는 기회로 사용할 수 있습니다. 원하는 접근 방식을 채택하는 프로세스 속도를 높이기 위해 직접 에스컬레이션을 트리거 할 수도 있습니다.

• ^{"... 응용 프로그램을 최신 버전 ( XX또는 그 이상)으로 업그레이드하는 것이 좋습니다 . 현재 환경에 배포 된 XX-2버전 ( )은 현재 코드베이스 뒤의 두 가지 주요 릴리스보다 심각하게 오래되었습니다. 결과적으로 이러한 간단한 실패에 대한 세부 사항은 다음과 같습니다. 로그에 깊게 숨겨져 있으며 해독 할 수없는 가비지가 명확한 오류 설명 대신 클라이언트에보고됩니다. 사용자와 지원이 실제로 매우 간단한 문제를 조사하는 데 시간을 낭비하게합니다. "
   
  위의 티켓 지원 문제 추적기에서 몇 시간 전에 추가 한 주석 특정 생산 사고와 관련이 있습니다. 그 후 얼마 지나지 않아 "이해 관계자"는 개발자 팀에 연락하여 릴리스를 추적하는 방법과 환경에 배포하는 데 도움이되는 방법을 묻습니다. 아 그리고 그들은 또한XX-2버전도. :)}

프로덕션 에스컬레이션이 발생하면 비전을 신속하고 명확하게 제시 할 수 있도록 준비하는 것이 좋습니다.

유용한 릴리스 중 하나 는 특정 릴리스 미끄러짐을 담당 하는 사람 을 선택하고 추적하는 것 입니다. 기본적으로 "계획된 릴리스가 발생하지 않았다는 사실에 대한 책임은 누구에게 있습니까?"와 같은 질문에 빠르고 명확하게 대답 할 수 있어야합니다. 준비가되지 않았다면 저항이 가장 적은 경로를 선택하여 책임을 물을 수 있습니다. 다른 답변에 대한 의견 에서 지적했듯이 "경영진이 당신을 보호하려는 뜨거운 물에 빠질 수 있습니다."

마지막은 아니지만 최소한

시간이 걸릴거야

(아마도 이미 알고 있지만 명시 적으로 언급 할 가치가있는 것으로 보입니다)

당신이 찾는 것은 "방치하는 것이 위험 하다 "에서 "방치 하지 않는 것이 위험하다" 까지의 태도 변화로 설명 할 수 있습니다 . 태도 변화는 하룻밤 사이에 거의 일어나지 않으며, 교대를 완료하기 위해 인내심이 필요할 수 있습니다.

귀하의 질문에 큰 물음표가 붙어 있으므로 귀하의 회사가 소프트웨어를 공개하지 않기를 바랍니다. 항상 위험 회피의 단순한 사례는 아닙니다. 종종 높은 경영상의 높이에서 넘어지지 않는 다른 원인이 종종 있습니다. 제 질문은 "상사와 함께 앉아서 왜 제품 출시가 진행되고 있는지 물었습니까?"입니다.

위험 관리와 피하는 것에는 큰 차이가 있습니다. 제품 출시가 지연되는 법적 또는 마케팅 이유가있을 수 있습니다. 경영진과 개발 팀 간의 신뢰 문제 일 수 있습니다. 고객이 몇 달 전에 요청한 것과 똑같더라도 제품이 고객의 요구에 맞지 않을 수 있습니다. 다른 곳에서 지연에 대한 책임을 바꾸려고 노력하거나 제품이 배송되기 전에 무언가를 완료 해야하는 제 3 자에 의한 지연까지 심각하게 다루는 경영진의 누군가 일 수도 있습니다. 수십 가지 시나리오를 생각해 낼 수있었습니다. 종종 개발자는 명백하지 않은 방정식의 다른 측면을 이해하지 않고 위험 회피를 가정합니다. 반대로, 그것은 단순히 안주, 회사 내 개인 간의 갈등,

모든 경우에, 제품 출시 지연 이유에 대한 자세한 정보를 확보하고 해당 정보를 사용하여 가능한 빨리 제품을 출시 할 수있는 사례를 구축하는 것이 중요합니다. 그렇습니다. 매우 실망 스러울 수 있지만 상사와의 대립이나 소진의 위험없이 이러한 상황을 처리 할 수있는 다른 방법이 있습니다. 비슷한 상황에서, 나는 나 자신이 정보를 수집하고 내가 한 진보를 문서화했다. 그리고 나빠진 상황이 나빠지면 프로젝트를 중단하고 다른 것으로 넘어 갔다. 출시를 위해 프로젝트를 다시 진행할 수 있었던 곳은 대개 내가 제기 한 질문에 대한 피드백으로받은 정보를 바탕으로 건전한 비즈니스 사례를 만든 결과였습니다. 제품을 배송해야한다는 경영진을 설득 할 수 없었던 경우, 나는 단순히 프로젝트가 끝나고 경영진의 릴리스 승인을 기다리는 것처럼 배송을 꺼려한다고 문서화했습니다. 그런 다음 관리자가 내 문서를 관리자가 승인하고 이해 한 것으로 서명하여 나중에 미발표로 나를 비난하려고 할 경우 내 엉덩이를 덮도록해야합니다.

배송 지연이 나중에 당신에게 탓하는 것을 피하기 위해 항상 당신의 I와 T를 교차시켜야합니다. 특정 전문가와의 분리를 통해 자신의 상황을 살펴보면 문제와는 달리 더 큰 "거리"에 효과적으로 도달했기 때문에 해결책이 제시 될 수 있습니다. 사례를 만들 수없는 경우 잠시 슬라이드해야하지만 처음부터 사례를 만들려면 전문적으로 분리 된 것으로 보이며 친밀하게 연결된 정보를 바탕으로 논쟁을해야합니다. 회사와 내부 활동.

내가 방금 생각한 것 중 일부는 Lean Software Development를 읽고 회사의 상황과 관련된 귀중한 것이 있는지, 특히 처음 몇 장에서 확인하는 것입니다. 최대한 빨리 제공하는 문제를 다루고 지연 비용과 관련이있는 것은 4 장이라고 생각합니다.

릴리스를 판매하는 가장 쉽고 효과적인 방법은 준비가되었을 때 잠시 동안 도구를 다운시키는 것입니다. 다른 작업을하고, 새로운 프로젝트를 시작하고, 기존 프로젝트의 버그를 해결하십시오. 문을 보낼 때까지이 작업을 더 이상하지 마십시오. 결국 준비가되지 않았을 때 전혀 방해하지 않는 이유는 무엇입니까?

그러나 실제 환경에서는 실제 릴리스가 다른 사람의 문제이므로,이를 릴리스하여 릴리스로 취급해야합니다. 문 밖으로 나가면 배송됩니다. 그들이 단지 그것에 앉아 있다면, 그것은 당신의 문제가 아닙니다 (사실, 그것의 위대한 버그 가보고되지 않습니다! w00t! 모든 버그없이 출시되는 보너스;))

어쨌든 변경 제어 시스템과 릴리스 관리자가 필요합니다. 변경 관리를 관리 할 필요가 없다는 점을 제외하고는 소스 제어와 배포 빌드가 매우 필요합니다. 조직이 필요하지만 조직이 구성되어 있으면 간단합니다.

비즈니스를 담당하는 데브 팀을 설명하는 것이 "좋은 일"이라고 상상할 수 없습니다. 실제 문제를 숨길 수도 있지만, 데브 팀이 영업, 마케팅의 입력을 평가할 올바른 위치에 있지 않는 한 등으로 인해 귀하는 잘못된 (및 잠재적으로 나쁜) 이유로 릴리스 할 위험이 있습니다.

문제를 이해하면 프로젝트를 완료했으며 결과물을 회사 외부의 사람에게 보여줄 수 없습니다. (이 내용이 요약되기를 바랍니다. 전체 스레드를 읽고 손가락을 올리는 데 어려움이 있습니다.)

시도해 보셨습니까?

1. 개발 과정에서 이해 관계자 역할을하도록 고객 또는 고객 집합을 경영진에게 요청합니까? 일반적으로 중간 릴리스를 수행하고 피드백을 제공 할 고객을 찾을 수 있습니다. 그들은 석방 될 때 큰 옹호자가 될 수 있습니다. 한 고객에 대한 "제한된 릴리스"조차도 경영진을 돕도록 충분할 수 있습니다.
2. 포인트 릴리즈를 포함한 릴리즈 계획 수립. 즉, 3.4.1 릴리스는 오늘 + 1 개월로 예정되어 있으므로 오늘 3.4를 릴리스 할 수 있습니다. 이것은 릴리스 케이던스가이 메시지에 도움이된다고 이미 언급 한 좋은 아이디어입니다.
3. 지원, 판매 또는 마케팅을 받으십시오. 상위 3 개의 지원 요청을 해결하는 수정 프로그램을 빌드하면 다른 부서에서 동맹을 얻을 수 있습니다. # 1과 같이 고객 이해 관계자를 확보 할 수없는 경우 소수의 영업 담당자와 함께 사용해보십시오. 영업 회의에 사용할 수 있도록 제안하고 제품을 가져 오십시오. 당신이 도로에있을 때, 당신이 제품을 가지고있는 판매원 (있는 상태에 상관없이)이 당신을 끌어 당기도록하십시오.

"경영진이 왜 출시 될까?"에 대한 다른 질문에 대답하기 위해 회사는 항상 SW 이외의 분야 에서이 작업을 수행하며 전례가 없다고 생각합니다. 예를 들어, 테스트 준비가 완료된 새로운 릴리스가 있습니다. 그러나 이전 버전은 아직 경쟁사에 의해 대체되지 않았습니다. 경쟁 업체가 경쟁 제품을 이전 버전으로 출시하면 경영진은 선반에서 대기중인 버전을 출시하고 시장을 혼란 시키며 경쟁을 다시 설정하고 판매 및 시장 리더로서의 명성을 유지합니다. 너무 빨리 출시하면 로드맵에 대해 더 잘 알고 있고 최종 게임으로 이길 수있는 경쟁자에게 손을 내밀 수 있습니다.

모든 말과 함께 ... Hanlon의 면도기는 아마도 정답 일 것입니다 :-)

그 회사를 떠나 소프트웨어를 이해하지 못합니다. 그러나 진지하게, 소프트웨어는 시스템을 작동시키는 요소입니다. 자동차를 만드는 중이라면 자동차 공장이 느리다는 것을 상상하십시오. 그들은 자동차 출시를 기다 립니까? 그들은 점증적이고 관료적인가? 아니요, 그들은 가능한 가장 빠르고 깨끗한 방법으로 일하려고합니다. 관리 문제가 있으며 관리 충돌로 문제를 해결하고 해당 용어를 말로 표현하십시오. 그들에게 어떤 위험이 있는지 물어보고 최소화하려고 노력하십시오. 당신의 개발자들의 감정은 또한 당신의 개입에 의해 내려 질 결정에 대처해야하기 때문에 중요합니다. 모든 야간 근무자들이 정시에 배송을하게되어 기쁠까요? 상금 / 벌칙은 무엇입니까? 이제 나는이 문제에 대한 실용적인 접근법을 조금 극단적으로 제공하지만 감사를 요청합니다.