상사는 모든 버그 보고서에 "책임자"필드를 추가하기로 결정했습니다. 그것이 나쁜 생각임을 어떻게 확신시킬 수 있습니까?

최신 "WTF"동작 중 하나에서, 상사는 버그 추적 템플릿에 "Person To Blame"필드를 추가하면 책임이 증가 할 것이라고 결정했습니다 (이미 버그를 기능 / 스토리에 묶는 방법이 있지만). 이로 인해 사기가 줄어들고, 손가락 지적이 높아지고, 버그가 알려지지 않은 것으로보고 된 누락 / 오해 된 기능을 설명하지 않을 것이라고 주장합니다.

내가 사용할 수있는이 관행에 대한 다른 강력한 주장은 무엇입니까? 이 주제에 대해 팀 및 상사와 공유 할 수있는 글이 있습니까?

전문가에게 사용되는 근본 원인 필드 의 아마추어 이름 일뿐입니다 (문제 추적기에 전용 필드가없는 경우 주석을 사용할 수 있음).

소프트웨어 버그 근본 원인 분석 과 같은 것을 웹에서 검색하십시오. 이 추론 ^{1 , 2 , 3 , 4 , ...} 를 정당화하기위한 많은 자료가 있습니다.

... 결함의 근본 원인이 항상 단일 개발자 인 것은 아닙니다 (이 분야의 핵심).

그것이 바로 "근본 원인"이 전문가 인 반면 "비난 할 사람"이 아마추어 인 이유입니다. 개인적인 책임은 훌륭하지만 개발자 팀의 "외부"에 놓이는 경우가 있습니다.

책임을 져야 할 단일 개발자 가 있을 때 상사에게 말하십시오 . 근본 원인 필드는이를 분명히 포함 할 것입니다 ( "Job이 검토 567에서 Bob이 놓친 코딩 실수" ). 근본 원인 이라는 용어를 사용하는 요점은 개발자 팀의 범위를 벗어난 사례 와 함께 이와 같은 사례를 포함하는 것입니다.

^{예를 들어, 결함이있는 하드웨어로 인해 버그가 발생한 경우 (팀을 구매하여 테스트 한 팀 외부의 누군가를 비난하는 사람으로 인해) 근본 원인 필드에서이를 해결할 수 있지만 "단일 개발자는 비난 할 수 있습니다" 문제 추적 흐름.}

^{테스터 오류, 요구 사항 변경 및 관리 결정과 같은 개발자 팀 외부의 사람으로 인해 발생하는 다른 버그에도 동일하게 적용됩니다. 예를 들어, 경영진이 재해 복구 하드웨어에 대한 투자를 생략하기로 결정했다면 데이터 센터의 정전으로 인한 "단일 개발자"의 책임은 의미가 없습니다.}

이러한 정책의 또 다른 가능한 결과는 사람들이 자신이 "책임자"라고 생각할 경우 버그를보고하지 않으므로 실제로 팀에서보고 한 버그 수를 줄일 수 있다는 것입니다.

내가 그것에 대해 사용할 주요 논쟁은 그가 해결하려는 문제를 묻는 것입니다. 동일한 문제를 해결하는 더 좋은 방법이 거의 있습니다.

우선, 한 사람 만 탓할 사람이 있습니까? 있다면, 당신은 다른 무언가를하고있는 것입니다. 좋은 프로세스는 분석가, 프로그래머, 검토 자 및 테스터가 프로덕션에 도달하기 전에 작업을 수행합니다. 이 단계를 모두 수행하지 않으면 상사가 해결하려는 문제에 대한 해결책 일 수 있습니다. 그렇다면 어느 쪽이 책임이 있습니까? 그것들 중 어느 것도 아닐 수도 있으며, 비난받을 레거시 코드 일 수도 있습니다.

사람들이 뒤로 물고 손가락을 가리키게하면 일단 설정되면 사라지지 않는 검은 색 표시를 피하려고하는 것은 좋지 않습니다. 아무것도 해결되지 않습니다. 악의적으로 과실 된 사람은 거의 없습니다. 당신은 적절한 회고 를해야 합니다. 무엇이 잘못되었고 다시 잘못되지 않도록하기 위해 무엇을 할 수 있는지보십시오.

이를 통해 한 사람이 정기적으로 잘못 판단하고 처리해야 할 다른 문제가 있는지 분명히 알 수 있습니다.

책임을지는 관리자를 막는 비결은 자유롭게 제공하는 것이지만 실제로는 귀하에게 적합한 방식입니다.

해당 분야에는 3 가지 이상의 문제가 있습니다.

첫 번째는 사람들을 비난하는 것이 사기에 좋지 않다는 것입니다. 승인. 그러나 그는 사기에 신경 쓰지 않고 나쁜 개발자를 해고하려고합니다. 반대하기 어렵다.

두 번째는 해당 필드를 올바르게 얻는 것이 어렵고 시간이 많이 걸리는 것입니다. 누가 나쁜 코드를 작성했는지 알아내는 것보다 더 복잡합니다. 그리고 파악하기 어려운 잠재적 인 정보는 모두 모래가 낀다 / 속일 수 있습니다. 그러나 그는 그 비용을 지불하고 정보를 감사 할 준비가되어있을 것입니다. 좋아.

더 근본적인 문제는이 분야가 조치를 취하기에 좋은 지표가되지 않을 것이라는 점입니다. 물론, 그는 가장 많은 결함을 일으키는 코드의 순위가 좋을 것입니다. 그러나 누가 그 목록의 맨 위에 있을지 추측 해보십시오. 아마도 회사 설립자이거나 결함률이 매우 낮지 만 생산성이 높은 최고의 개발자 일 수 있습니다. 코드의 불균형 부분을 작성합니다. 그래서 그는 최고의 개발자를 해고하거나 더 이상 최고의 개발자가 아닌 것을 느리게 할 것입니다. 그리고 한 달에 한 줄의 코드를 작성하는 사람들-바람직하게는 주석-아마도 그의 낮은 결함 수에 대해 보상받을 것입니다.

또 다른 소프트웨어 메트릭 실패.

현장 결함의 근본 원인은 결코 한 사람이 아닙니다. 완벽하게 양심적 인 사람들은 실수를 범할 것이며, 오류가 없을 것으로 예상하는 과정은 부당합니다. 배포하기 전에 수동 또는 자동 테스트를 통해 프로덕션 시스템의 변경 사항을 확인하지 않으면 버그가 불가피합니다.

잘못된:

Bob은 입력을 확인하는 것을 잊었으며 프로그램이 0으로 나누어 충돌했습니다.

권리:

0으로 나누기 오류에 취약한 코드가 배포 전에 감지되지 않았습니다. 유효하지 않은 입력이 올바르게 처리되는지 확인하기 위해 새로운 테스트 사례가 추가되었습니다. 코드가 수정되었고 모든 새로운 테스트 사례가 통과되었습니다.

"비난 할 사람"을 "칭찬 할 사람"으로 변경

버그를 수정 한 주체는 자신의 이름을 얻습니다.

간단한 대답.

"Blame"필드는 희생양과 지각, 사기가 떨어지고 팀 신뢰가 파괴 될뿐 아니라 무언가를 고치는 대신 자신의 잘못이 아니라는 것을 증명하는 방법을 찾으려고 노력할 것입니다. 또한 동료가 문제를 일으키지 않기를 원하기 때문에 버그를보고하는 대신 버그를 조용히하는 경향이 있습니다. 완전히 역효과를냅니다.

더 중요한 것은, 정직한 실수로 누군가를 희생 시키거나 가능한 빨리 문제를 해결하는 것입니까?

상사는 버그가 게으름이나 둔감의 징후라고 생각하는 것 같습니다. 그들은 아니야. 그들은 인생의 사실입니다. 1 년에 Microsoft는 몇 개의 패치를 발표합니까?

약간의 민사 불복종에 직면했다면 팀이 각 버그에 대해 해당 분야의 모든 개발자 목록을 작성하도록 동의하십시오. 그것이 맞지 않으면 "나는 스파르타쿠스입니다!"라고 쓰십시오. 대신에. 요점은 물론 모든 버그에 대한 책임은 귀하에게 있으며, 하나의 버그를 만든 개인을 지적하지 않아도된다는 것입니다.

또 다른 옵션 : 함께 연주하십시오. 특별히 아무 것도하지 마십시오. 좋은 일을하고 몇 개월 동안 가능한 한 정확하게 현장을 채우십시오. 그런 다음 각 버그에 대해 책임을 부여하면 팀의 모든 사람이 불행하고 불편하게된다고 상사에게 설명하십시오. 생성 된 버그와 다른 것 (기술, 노력, 온전함) 사이에는 상관 관계가 거의 없다고 생각한다고 말하십시오. 실제로 상관 관계가 없음을 나타내는 숫자를 실행할 수 있으면 도움이됩니다.

간디의 시민 불복종 : 다른 분야의 사람들이 자신의 버그를 밝히지 않는 한 모든 분야에 자신의 이름을 기입하고 자신의 버그 여부에 관계없이 모든 버그에 대한 책임을 받아들입니다. 그 분야 나 이보다 더 쓸모없는 사람을 비난한다는 생각은 없습니다. 당신의 상사가 왜 모든 분야에서 당신의 이름을 묻는 지 묻는다면, 당신은 "개발이 비난 게임이라고 생각하지 않기 때문에 사람들이 비난하고 십자가에 못 박 아야 할 필요가 있다면 모든 것을 위해 나를 십자가에 못 박히고 팀이 평화롭게 일하게하십시오. "

나는 한때 상사가 이것과 매우 유사한 시스템을 구현하도록했다. 비록 프로그래밍이 아니었지만 (매일 신문을위한 인쇄 디자인이었다) 개념과 적절한 반응은 동일하다.

그녀가 한 것은 우리의 서류에 '책임자'필드를 추가하는 대신 각 디자이너에게 컬러 스티커 세트를 주었다. 각 디자이너는 서로 다른 색의 스티커를 받았으며 디자인 작업을하거나 만질 때마다 해당 디자인의 서류에 스티커를 추가해야 한다는 지시를 받았습니다 .

"스티커 이니셔티브"에 대한 사장의 목표는 모든 부서 오류의 원인 (서류, 실수, 잘못된 사본, 본질적으로 버그에 해당하는 인쇄물의 실수)을 확립하는 것이 었습니다.

우리가 한 것은 다른 모든 디자이너들에게 스티커의 1/4을 줘서 우리 모두가 모든 색상을 가졌으며, 각 디자인에 색상을 넣는 대신 4 개의 디자이너 색상을 모두 넣었습니다.

[Blame] 상자에 이름을 쓰지 말고 팀 / 프로젝트에있는 모든 사람의 이름을 입력하고 전체 팀이 동일한 것을 수행하도록하십시오.

우리는 그녀의 orwellian bitchiness에 대해 함께 일했고 결과적으로 우리는 실제로 서로의 실수를 잡아서 그것에 대해 이야기하고 결국에는 오류를 크게 줄였습니다. 그녀는 외견 상 관리자였으며, 그녀의 이니셔티브가 우리를 하나로 묶고 생산성을 높이는 것을 인식하는 대신, 모든 꽁초를 내고 스티커 시스템을 해체하여 실패를 선언하고 공식적으로 우리 모두를 견책했습니다.

그의 가장 많은 프로그래머를 처벌 할 것이다. 승률은 대부분의 프로젝트에서 일한 최고의 직원 일 수 있습니다. 10 명 규모의 부서에 출력의 일부에 불과하고 인터페이스 코드의 60 %를 작성한 코더가 있다면 버그의 60 %가 코드에 포함됩니다.

이 시스템은 가장 많은 코드를 작성하는 사람이 최악의 프로그래머이고 가장 적은 코드를 작성하는 사람이 최고 프로그래머 인 것처럼 보이게합니다.

Scott Adams가 Dilbert의 Pointy Haired Boss의 버그 바운티에 대한 실패한 지혜를 지적했을 때와 비슷하게 들립니다. 월리는 자신이 가서 새로운 미니 밴을 쓰겠다고 발표했다.

공식 Dilbert 코믹 스트립 아카이브에서 1995 년 11 월 13 일에 대한 Dilbert 코믹 스트립.

스노우 스키 (Snow Skiing)에서 누군가가 '떨어지지 않는다'는 지적은 스키어의 징조가 아니라 종종 시도하지 않는 (또는 실제로 스키를 타지 않는) 징조의 징조라고 생각합니다.

잘못된 프로그래밍과 나쁜 디자인으로 인해 버그가 코드에 도입 될 수 있습니다. 그러나 많은 어려운 코드를 작성한 결과로 올 수도 있습니다. 버그가 가장 많은 사람을 죽이는 것은 생산성이 높은 개발자만큼 빈약 한 개발자를 죽일 가능성이 높습니다.

당신의 상사가 결함의 수에 좌절하는 것처럼 들립니다. 당신의 그룹에 속한 사람들은 품질에 대해 열정을 가지고 있습니까? 'who'필드 대신 원인에 대한 'what'필드를 작성하는 것이 더 생산적 일 수 있습니다. 예 : 요구 사항 변경, 설계 결함, 구현 결함 등 제품 품질을 향상시키기 위해 그룹이 없다면, 이는 실패 할 것입니다.

어쩌면 "누가 버그를 해결하기에 가장 좋은 위치에 있습니까?" 내 일부도 느끼고, 부러 뜨 렸고, 고쳤다. 약간의 책임이 있어야합니다.

나는 어떤 종류의 점수를 유지하는 것에 동의하지 않습니다. 어떤 사람들은 더 복잡한 코드 부분에서 작업하기 때문에 더 많은 버그를 만듭니다. 코드 줄이 유용한 측정 기준이 아니라면 코드 줄당 버그가 더 나을 것입니다. 코드는 체크인되지 않습니다.

어떤 시점에서 관리자는 누가 자신의 일을하고 있는지, 누가 팀의 나머지 부분 때문에 누가 더 잘하는지뿐만 아니라 누가 잘하는지 알아야합니다.

이전에 아무도 언급하지 않은 것은 이상합니다. 버그 추적기에 이러한 기능을 추가하면 직원들이 시스템 게임을하게됩니다 .

이것은 다른 유사한 아이디어 (코드 라인 수로 지불하고 버그 수로 지불)와 같이 질문이 제시 한 것과 같은 접근법에 공통적 인 문제입니다. 이를 통해 많은 사람들이 작업중인 소프트웨어와 관련된 문제를 해결하는 대신 좋은 점수를 얻는 데 집중할 수 있습니다.

예를 들어, 자신의 비난을 줄이려는 문구가 포함 된 버그 보고서를 제출하고 다른 사람에게 공개하면 개발자가 문제의 원인을 이해하지 못하게 될 수 있습니다. 문제를 해결하기 위해 더 많은 시간과 노력을 이끌어내는 코드를 가장 많이 사용하고 버그의 주요 원인 인 코드만큼 좋은 코드).

당신의 실제 질문은 회사를 떠나기 전에 문화를 바꾸는 방법에 관한 것이 었습니다. 그러나 물론 문화를 바꾸려면 왜 이것이 나쁜 생각 인지 이해해야 합니다.

이것은 큰 주문입니다. 마음을 바꾼 후 얼굴을 구하는 문제 외에도 주로 개인 비난의 관점에서 해결책에 대해 생각하는 사람들이 그 사고 방식에 꽤 기본 설정되는 문제가 있습니다.

이 주제에 대해 글을 쓰라고 요청하면 Peopleware 가 떠 오릅니다. 산출물을 측정하기 어려운 창의적인 작업을 수행하는 사람들을 관리하는 방법에 대해 높이 평가하고 일반적인 용어로 이야기합니다. 문제는 당신이 그것을 읽는 것이별로 도움이되지 않는다는 것입니다. 상사는 그것을 읽으면서 적어도 일부를 믿어야합니다.

이상하게도 여기서 문제는 버그 보고서보다 사람에 관한 것이기 때문에 프로그래머보다 직장에 더 속할 가능성이 큽니다. 그러나 소프트웨어 프로젝트의 성공은 일반적으로 인간의 사회적 상호 작용에서 상당히 추적 가능하므로 실제 대답은 대개 소프트웨어를 능가하는 것에 관한 것입니다.

내 유일한 다른 반 심각한 제안은 그 말 (또는 당신이 떠날 계획 때문에, 말을 동료를 설득)하는 것입니다 당신이 프로젝트의 성공을위한 모든 책임을 감수하고, 이름이해야 항상 현장에서 이동 다른 사람이 직접 실수를 했더라도 팀의 모든 사람이 양질의 작업을 수행 할 책임이 있습니다.

물론 말도 안되는 일이지만, 어떻게 백업 할 수 있을지 모르지만 일부 사람들 (특히 비난을받는 사람들)은 실제로 그 물건을 먹습니다. 로널드 레이건은 자신의 행정부 구성원이 스캔들에 휩싸 일 때마다 개인적 책임을 공개적으로 받아 들였습니다. 당신에게 가장 좋은 부분은 책임은 일반적으로 실제 결과가 없다는 것입니다. 그들은 단지 당신이 책임을지는 일을하는 사람이라고 생각합니다.

아니면 어쩌면 그것이 내려가는 방법이 아닐 수도 있습니다. 그것은 나에게 전혀 이해가되지 않으므로 그것이 언제 작동하는지 예측하기가 어렵지만, 사업이없는 것처럼 보였을 때 (Reagan의 예가 아니라 직장에서) 그것이 효과가 있음을 목격했습니다.

사람들은 실수를 저 지르려고 의도적으로 노력하지 않으며, 착오가 있었을 수도 있고 아닐 수도있는 것에 대한 책임을 구체적으로 비난하기 위해 마련된 전략은 엄청나게 비전문적이라고 말할 수 없습니다.

최소한 문제를 책임지고 해결하기 위해 할당 된 "책임자"또는 유사한 사건의 발생을 추적 및 / 또는 방지하기위한 계획을 세우는 것이 좋습니다. 때로는 솔루션이 추가 교육에 지나지 않습니다. "회사 유급 / 회사 시간"교육을 받기 위해 직업 설명의 일부인 여러 회사에서 근무했습니다. 한 곳은 심지어 지역 기술 대학이 그들의 산업 기술 과정을 위해“빌려주는”전체“훈련 센터”를지었습니다.

지난 20 년 동안 제조 환경에서 일하면서 프로그래밍 실수는 오류를 유발할뿐 아니라 물리적으로 물건을 파괴하거나 사람들을 다치게합니다. 그러나 모든 제조 분야에서 강건한 하나의 상수는 어떤 상황에서도 책임을 져야 할 사람이 없다는 것입니다. - 그것은 평범하고 단순 시스템의 결함이기 때문에 없는 사람들의 결함. 문자 검사의 영역에서 운이 좋지 않은 사람들을 위해, 또는 약간 과도하게 일한 사람들을 위해,이 방법으로-철자 검사기 사용-매우 효과적인 도구를보십시오. 그러나 결코 비난이나 책임의 방법은 아닙니다.

어떤 종류 또는 어떤 목적 으로든 업무 환경은 시스템입니다. 적절하게 "조정 된"경우 개별 구성 요소로 구성된 시스템은 완전히 조화를 이루어 작동합니다.

상사 측에서 제안하는 독서 : 매우 효과적인 사람들의 7 가지 습관

현실 점검이 아니라면 조금 겸손하게 사용할 수있을 것 같습니다. 그는 다른 모든 사람들과 마찬가지로 팀의 일원이며, 깨달아야합니다. 그렇지 않으면 작동하지 않을 것이며 결국에는 가방을 들고있을 것입니다.

귀하가 제안한 읽기 및 / 또는 연구 :

5 가지 원인 분석, 근본 원인 분석 ... 문제가 아닌 솔루션 을 제공 할 수있는 더 나은 위치에있게 하는 것을 살펴보십시오 . 그리고 당신의 상사와의 의견 차이는 단지 해결책이 아니라 문제입니다. 그에게 더 나은 것, 말이되는 것을 제안하고 심지어 그 아이디어를 인정할 수 있도록 준비하십시오.

"I 's the boss"라는 정신 외에 다른 것이 전혀 없다면 깨진 것이 무엇인지에 대해 제대로 이해하지 못하기 때문에 지금은 아무것도 고칠 준비가되어 있지 않은 것 같습니다.

행운을 빕니다! 특히 여러분이 받아 들일 수있는 방식으로이 문제를 해결할 수 있기를 바랍니다.

편집 : 개인적으로, 내 자신의 경험에서 ... "계속 날 비난. 충분히 확신, 그것을 고칠 것입니다 그리고 다시 일어날 때, 하루를 저장하기 위해 누가있을 것인가? "올빼미가 웃었다."

책임 성을 위해 person to blame필드를 원하지 않고 Person who knows the code필드 또는 person who can fix필드를 원하므로 지원 티켓을 보낼 위치를 알 수 있습니다.

이것은 버그 자체를 수정하는 프로세스 속도를 높이고 하나의 돌로 두 마리의 새를 죽이는 것과 같은 책임을 부여합니다. 나는 개인적으로 이것을 그에게 가져오고 이것이 실패한 것처럼 느끼지 않으면 서 사기와 책임감을 높이는 데 도움이 될지 결정하게 해줄 것입니다. 극단적 인 테스트는 모든 버그를 포착하지는 않으며, 그렇지 않으면 버그보고가 없습니다.

그에게 "비난"이 부정적이라고 말하십시오. "수정할 사람"으로 변경 한 후 최소한 긍정적 인 방식으로 프레임을 구성하면 동일한 작업이 계속 수행됩니다. 사람들이 "비난"을 받으면 어떻게 일할 수 있습니까?!

내 상사가 다음과 같은 순서로 발생했을 경우 :

1) 나는 즉시 새로운 일자리를 찾기 시작합니다.

2) 비난 할 사람과 함께 버그가보고 될 때마다 상사의 이름이 나타나고 팀의 나쁜 프로세스가 그 원인에 대한 의견이 표시됩니다. 그리고 그의 상사에게 참조하십시오 (바람직하게는 배치로). 단위 테스트가 있습니까? 그렇지 않으면 개발 프로세스가 중단되어 버그가 발생했음을 의미합니다. 모든 외부 시스템과의 지속적인 자동 통합 테스트가 있습니까? 그런 다음 dev 프로세스가 중단되어 버그가 발생합니다. 인적 오류를 허용하지 않도록 스크립트를 통해 프로덕션 환경에서 모든 환경을 동일하게 만들 수 있습니까? 그런 다음 dev 프로세스가 중단되어 버그가 발생합니다. 한 명의 개발자가 끔찍한가요? 그런 다음 고용 기준이 나빠서 보스의 잘못입니다. 모든 개발자가 하루 12 시간 일하고 있기 때문에 휴식이 부족하여 바보 같은 실수를 저지르고 있습니까? 그런 다음 개발 프로세스가 중단됩니다.

참고로 : 모든 훌륭한 개발 관리자는 위에 쓴 내용을 알고 있습니다. 그리고 민첩한 전략은 개발자가 속도를 늦추는 이유를 상사 나 그 / 그녀의 상사에게 지적하기위한 것입니다. 우리는 버그를 수정하는 데 50 %의 시간을 소비하고 있습니다. 버그를 수정하는 데 소요되는 시간의 40 %를 버그를 수정 한 후 30 %로 끌어 올릴 수 있도록 전략을 줄이는 전략을 살펴 보겠습니다. 기타

불행히도 현장 때문에 좋은 관리자가없는 것 같습니다. 따라서 (1)하고 관리자에게 알리지 말 것을 제안합니다 (탈퇴 인터뷰 제외).

당신의 상사가 소프트웨어에 대해 깊이 이해하지 못하고 아마도 의도하지 않은 것처럼 보입니다. 그래서 그는 다른 언어, 다른 문화를 가지고 있습니다.

솔루션을 위해 앞으로 나아가려고 시도하기 전에 이와 같은 문제에 대한 직업을 끝내는 것은 그냥 끝내주는 것입니다. 종료하는 중입니다. 그는 당신이 서로를 이해할 수 없다는 것을 확신 할 때까지 끊지 마십시오. 이를 확인하려면 먼저 시도해야합니다.

그는 우리의 언어를 모르고 보스이기 때문에 여기서 첫 번째 단계는 그의 언어로 그와 대화하려고 시도하는 것입니다. 언어 란 무엇을 의미합니까? 같이 생각해 보자.

우리는 소프트웨어 사용자이며, 대부분 우리가하는 일을 좋아하며, 우리가하는 일과 깊은 관련이 있습니다. 그렇지 않으면 그것은 작동하지 않으며 그것을 사랑하거나 완전하지 않고 오랫동안이 사업을 계속할 수 없습니다 ... 공백을 채우십시오 ...

그러나 그는 사물을 크게 다르게 본다. 모든 버그 보고서에서 우리 대부분은 일이 더 잘 작동하게되어 기뻐하지만 (아니면 정말 스트레스가 많더라도 문제를 좋아하고 인정합니다!) 그는 실패로 간주합니다. 실패했습니다. 그가 이해하고 싶은 첫 번째 것은 버그가 좋다는 것입니다. 버그는 고객이 회사를 사랑하게합니다. (이것은 그의 언어입니다.) 고객이 버그를보고하거나, 우리가 직접 버그를 발견하면, 해결 된 후에는 결코 발생하지 않은 상황보다 훨씬 낫습니다. 버그는 고객 충성도를 만들어 내고 (진지합니다!), 버그는 소프트웨어 소비자와 생산자 간의 의사 소통에 큰 변명을줍니다.

"버그의 이익을 높이려면"버그 보고서를 더욱 개방적으로 제공해야합니다. 모든 버그 보고서와 빠르고 깨끗하고 좋은 솔루션을 통해 고객은 "와우,이 사람들은 정말 대단합니다! 정말 열심히 일합니다. 해결하고있는 것들을 살펴보십시오. 소프트웨어가 그렇게 복잡하다는 사실조차 알지 못했습니다. 의회!" ㅋㅋ ㅋㅋㅋ

자신의 언어로 대화하십시오. 버그는 문제가 아니라 소프트웨어 회사에 좋습니다. 그들은 우리를 생계로 만듭니다.

팀 윤리, 효율성 또는 대화의 종류가 의도 한 것과 다르게 작동 할 수 있습니다. 당신이 그만두기를 원한다면, 그는 "아하, 내 솔루션은 첫날부터 작동하기 시작했다! 나쁜 링크는 노출되기 전에 이미 스스로 떨어지기 시작했다!"라고 생각할 것이다. 그는 회사에서 나쁜 소년을 찾는 아이디어를 믿고 다른 방법으로 그를 설득하기가 매우 어렵습니다. 특히 당신이 그 나쁜 소년 중 하나 일 때!

따라서 그의 실제 문제인 버그에 집중하십시오. 버그가 매우 유용 할 수 있음을 보여주십시오. 아무 문제없이 관계는 지루합니다. 당신을 죽이지 않는 모든 것이 당신을 강하게 만듭니다. 모든 버그는 고객의 행복을 높이기 위해 사용할 수있는 좋은 기회입니다.

이것은 당신이 말할 수있는 것 중 하나입니다. 그의 관심사에 대해 생각하면 목록에 추가 할 다른 많은 항목을 찾을 수 있습니다. 황금 열쇠는 그의 아이디어와 싸우는 대신 대안을 제공하는 것입니다!

애자일을하고 있다면, 기능 / 스토리 코멘트 에서 나온 것처럼 들립니다 . 비난하는 사람은 버그를 통해 미끄러 수 있도록 품질 보증 사람, 또는에서 버그 완전한 기능 / 이야기를 수락 한 제품 소유자 / 고객이 될 것입니다.

나는 하루에 다시 조판을했다.

이것은 철자가 틀린 철자 나 교정자가 찾아 냈지만 놓친 다른 것들에 대해 조판자를 비난하는 것과 같습니다. 조판자가 틀린 철자를 썼지 만 교정자는 그것을 놓쳤다. 그래서 처음부터 오류를 범한 사람이 아니라 인쇄하는 실수를 탓하는 것은 교정자 이다.

민첩한 환경에서는 오류 (버그)를 포착하는 것은 QA 담당자의 책임이며 올바르지 않은 것을 수락하지 않는 것은 제품 소유자의 책임입니다. 이것은 개발자에게 릴리스되는 것들을 격리시켜야하는 두 가지 수준의 증거 독자입니다. 이것이 애자일 환경에서 버그 로 분류되어야하는 유일한 방법 입니다.

귀하의 관리자가 잘못된 솔루션으로 문제를 해결하려고한다고 생각합니다. 너무 많은 버그가 발표되고 관리자가 개발자가 작성한 코드에 대해 더 많은 소유권과 책임을지기를 원한다는 문제가 있다고 생각합니다.

테스트 중심 개발을 사용하고 Jenkins 와 같은 지속적인 통합 서버를 설정 하면 "비난 게임"을 도입하지 않고도이 문제를 해결하는 데 도움이됩니다. 누군가가 "빌드를 깨뜨리는"코드를 커밋하면 팀원에게 이메일을 보내 사람을 비난하기 때문에 지속적인 통합 서버가 중요합니다. 이 코드는 프로덕션 환경에 공개되지 않았으므로 이러한 유형의 책임은보다 적극적이고 고무적입니다 (그리고 재미 있습니다!).

결과적으로 개발자는 더 많은 소유권을 가지게되고 자신감을 갖게되고 생산 코드에 버그가 줄어 듭니다.

한 사람의 실수로 인해 생산에 버그가 생기면 방법론이나 소프트웨어 개발의 모든 방식에 문제가있는 것입니다. 버그가 발생하는 것을 막는 것은 팀 전체의 책임이라고 지적하십시오.

이 두 가지 주장 중 하나를 사용하여 "선택 책임자"필드를 단일 선택 필드로 사용하는 것이 잘못 될 수 있다고 상사를 설득 할 수 있는지보십시오. 따라서 "탓할 사람"필드가 다중 선택 필드인지 확인해야합니다. 이것을 달성하면 모든 버그에 대해 모든 사람의 이름이 현장에 있는지 확인하십시오. 당신의 상사는 결국 현장에 대한 모든보고가 쓸데없는 것을 보게 될 것입니다.

상사에게 약간의 신용을주기 위해 "비난 배정"이라는 개념은 이미 SVN 과 같은 도구로 구워졌으며 , 디버깅하는 동안 "대화 할 사람 찾기"에서 개발자가 데이터를 적절하게 사용할 수 있습니다. 예 : http : / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

근본 원인 필드가 좋은 것이라는 위의 gnat의 응답에 동의하지만 , 이것은 동일한 정보가 아니며, 영향을받는 소스에 대해 이전 개발자 이름을 할당하기 위해 필드를 "비정규 화"하며 때로는 기술적 설명 (예 : "10000 명의 사용자로 확장하지 않았 음")은 물을 흐릿하게 만듭니다. 근본 원인 을 유지하기 위해 옹호합니다필드는 기술적 인 설명을 명확하게 기술합니다 (예 : 명확한 프로그래머 오류 일 경우에도 "fooData = 999 일 때 IndexOutOfRange 예외"와 같은 세부 사항을 캡처하도록 함). 이것은 전체 검토시 유용한 피드백을 제공 할 수 있으며 일부 수정 조치를 취할 수 있습니다. 아키텍처 또는 프레임 워크 변경과 관련된 전체 문제 클래스를 해결합니다 (예 : 사용자 정의 컨테이너 클래스 개선, 최상위 예외 처리)

즉, Person To Blame 필드 를 추가하면 경영진이 코드를 가장 자주 깨는 개별 개발자를 골라 내고 싶어하는 소프트웨어 팀에 매우 나쁜 메시지와 파괴적인 메시지를 명확하게 보낼 수 있습니다. 관리자는이 공개 조사를 통해 개발자가이 "부끄러운 벽"에 이름을 올리지 않도록보다 신중하고 자율적으로 통제해야한다고 생각하며, 특히 추가 된 경우 개발자가 이에 대한 위협을 느끼는 이유를 이해하지 못합니다 일반적으로 모든 버그 보고서에 적용됩니다.

이것을 버그 필드 / 잠재적 메트릭으로 추가 할 때의 문제점은 열거하기 쉽습니다.

1. 버그는 해결하기 어려운 변수가 많으며 버그 통계 / 개발자의 간단한 통계는이를 반영하지 않습니다.
2. 개발자는 "" "" "" "" "" "기능이 매우 다양합니다.
3. 많은 소프트웨어 시스템에는 리팩토링이 필요한 컴포넌트가 있지만 레거시 컴포넌트 리팩토링 (특히 레거시베이스에 유닛 테스트 기능이 없거나 제한적인 경우)에는 처음에 버그가 발생합니다. 새로운 버그 생성과 관련된 오명 / 두려움이있는 경우 (이러한 버그를 해결하기가 쉽지 않고 결과적으로 시스템이 크게 개선되는 경우에도) 개발자는이 "좋은"활동을 사용하지 않는 것이 좋습니다.
4. 테스터는 동일한 문제와 관련하여 매우 다양한 버그를 제출할 수 있으므로 더 자세한 분석을 수행하지 않으면 버그 수 / 개발자가 치우치게됩니다.

빙산의 일각에 불과합니다. 이를 API 요구 사항, 테스트에서 부정확 한 예상 결과 및 부정확 한 / 결측 요구 사항의 "이전 체인"문제를 예상 한 사람의 지적과 결합하면 이와 같은 메트릭은 무가치 한 것으로 간주됩니다 (단, 그렇지 않은 경우) 목표는 사기를 손상시키고 대량의 탈출을 야기하는 것입니다.)

보스 관점으로 돌아 가면 코드를 반복적으로 위반하는 개발자가 있는지 확인하고 그것에 대해 무언가를 시도하고 (희망적으로 건설적인) 시도하는 것이 좋습니다. 버그 보고서에 필드를 추가하여이 정보를 얻으려고 시도해도 위에 나열된 이유로 의미있는 정보를 제공하지는 않습니다. 내 경험상,이 정보는 팀에 연결하고, 대부분의 팀 회의에 참여하고, 가끔 일대일 회의에서 배운 정보를 팀원과 통합하고 (주의 깊게) 통합하여 하위 시스템에 익숙해지면서 배울 수 있습니다. 코드를 읽을 수없는 경우에도

그냥 내버려둬 상사는 문제가 발생하면 스스로 발견 할 것입니다.

무뚝뚝하게하자, 당신은 의견을 가지고 있으며 그렇게합니다. 그는 당신의 매니저이고 그의 의견은 승리하는 것입니다.

예,이 문제를 놓고 전쟁을 할 수 있지만 그만한 가치가 있습니까? 나는 그것이 사용 중지되기 3 개월 이상 지속될 것으로 의심한다.

그러나 적극적으로 이것을 방해하거나 그것에 대해 비명을 지르면 여분의 시간을 내거나 다음 번 인상, 승진 또는 정말로 중요한 디자인 결정을 내릴 때 더 잘 절약되는 정치적 자본을 사용합니다.

그 순간, 실제로 계산할 때 당신은 보스가 당신이 "사람을 비난하는 사람"에 대한 그의 아이디어를 적극적으로 파괴 한 사람임을 기억하기를 원합니다.

결정을 존중하지 않더라도 사무실을 존중하십시오.

훨씬 더 오래 지속될 의사 결정을 위해 스트레스와 테이블 파운딩을 저장하십시오.

팀에서 개발하려면 사회적 기술이 필요하다고 상사에게 알리십시오. 그는 고개를 끄덕일 수도 있습니다.

그러나 문제는 이것이 개발자가 극도로 나쁜 것입니다. 적절한 문제 분석보다 비난을 시사하는 도구를 추가하는 것은 비생산적입니다.

대신, 당신은 사회적 기술을 향상시키기 위해 인센티브가 필요하며, 당신이 가지고있는 커뮤니케이션 인프라가 그것을 지원해야합니다. 예를 들어, 긍정적으로 동전을 넣으십시오. 티켓을 책임지고 돌보는 사람의 이름을 지정하십시오.

또한 코드 검토부터 시작하여 서로 배울 수 있습니다. 나중에 비난을 피할 수 있습니다.

이 질문을 이메일로 보내십시오. 그가 추론을 할 수 있다면, 여기 주석은 그의 추론에 대한 온전한 점검을 제공 할 것입니다. 그가 합리적이지 않다면, 당신은 그에게 합당한 이유들로 그를 설득하지 못할 것입니다. 또한 대화 외의 이유를 읽을 수도 있습니다 (대화의 열기 속에서 "올바른"동기가 제거되어 더 설득력있는 경우가 있습니다).

당신은 또한 그것을 바꾸려고 노력할 수 있습니다. 이 필드는 "유사한 버그가 발생하는 것을 피할 수있는 단계"이거나 그 영향보다 짧은 것일 수 있습니다. 그런 다음 솔루션을 모아서 업무 환경을 개선하기 위해 구현할 솔루션에 투표 할 수 있습니다. 아마도 솔루션 지향적 접근 방식이 생산적이고 더 잘 받아 들여질 것입니다 (제안을 다시 검토 할 실제적인 방법이 있다면).

나는 두 가지 가능성을 본다 : 그는 실수를 저지른 사람들을 처벌하기를 원하거나 생각하지 않았다. 모든 사람에 대한 인식은 그가 실수를 저지른 사람들을 처벌하려는 것이라는 것을 알게하십시오. 그것이 권장하고 싶은 문화인지 물어보세요.

상사는 버그 추적 템플릿에 "Person To Blame"필드를 추가하면 책임 성이 높아질 것이라고 결정했습니다.

내 경험상, 경영진이 "사람들을보다 책임감있게"하고 싶을 때 그들이 의미하는 바는 실패에 대한 정확한 형벌을 원한다는 것입니다. 실적이 저조한 사람들을 해고하든, 아니면 연봉 검토에서 겁을 먹게하든간에 ( "죄송합니다, 밥, 당신은 17 개의 버그가 당신의 잘못으로 표시되었고, 그것은 15의 한계를 넘었습니다"), 처벌입니다.

그는 아마 "아, 아니, 우리는 그것을 원하지 않는다"고 말할 것이므로, 그 데이터가 어떻게 사용될 것인지 물어보십시오. 데이터 포인트를 사용하지 않는 한 데이터베이스에 데이터 포인트를 추가하지 마십시오. 그는 주어진 기준 ( "보고서 작성기 서브 시스템에서 열려있는 모든 버그 표시")을 선택하여 작업을 수행하거나 집계 데이터를 얻을 수 있도록하려고합니까 ( "서브 시스템이 사후 분석을 수행 할 수 있습니다. 그는 사람들이 공개적으로 굴욕을 당할 수있는 일종의 실패 보드를 구상합니까?

그래서 그는 무엇을 의도합니까? "밥의 잘못 인 모든 버그를 보여줘?"라고 말하고 싶습니까? 왜? 아니면 "대부분 누가 잘못했는지 보여줘?"라고 말하고 싶습니까? 왜? 첫 번째는 의미가 없으며 두 번째는 처벌 적입니다. 또는 세 번째 옵션은 그가 진정한 이유가 없다는 것입니다.

기술 향상에 도움이 필요한 팀의 프로그래머를 찾을 가능성이 있음을 인정합니다. 그렇다면이 정보를 포착하는 더 좋은 방법이 있습니다.

여기서 주목할 점은 팀이 '보스'를 향한 의사 소통 방식과 다른 방식으로 의사 소통이 얼마나 개방되어 있는지 믿습니다. 그러나 손가락으로 가리키는 것은 결코 관리 측면에서 결코 좋지 않습니다. 개발자 중 한 명이 같은 문제에 여러 번 빠지면,이 반복적 인 문제를 극복하도록 도와야 할 때가 될 수 있습니다 (예 : John이 올바르게 테스트하지 않음) 코드 : 지난 3 개월 동안 3 개의 생산 버그. 그에게 코드를 어떻게 테스트 해야하는지 기억하도록 체크리스트를 제공하십시오.

개발 관점에서 볼 때, 'blaming'은 이미 SVN과 같은 주류 도구에 통합되어 있으므로 "John, 작성한 쓴 쓰레기를 고치십시오"라는 이름과 그것. JIRA는 또한 버그를 제출할 때 사람의 이름을 통합합니다 (그러나 그것이 실제로 책임이있는 사람을위한 필드는 아니지만 누군가가 고칠 수있는 부분입니다).

많은 사람들이 위에서 언급했듯이 버그가 발생하면 개발자, 테스터, QA, 관리자에 대한 공동 책임입니다. 어느 시점에서 상사가 전화를 통해 화난 고객을 " 죄송합니다. John이 이걸 제대로 테스트하지 못했습니다 "와 같은 문제를 처리한다면 다른 직업을 찾고있을 것입니다. 좋은 상사는 "우리가 처리 할 것"으로 가야합니다. 이름도없고, 손가락도없고, 해결책도 없습니다.

다시 한 번 나는 그것이 의사 소통에 관한 것이라고 생각합니다. 아마도 상사가 원하는 것은 개발자 팀에서 누가 문제를 겪고 있는지 또는 팀이 어떤 종류의 문제를 겪고 있는지 (아마도 훈련 세션에 대한 것입니까) 알 수있을 것입니다. 상사 나 팀 전체와 이야기하지 않는 한 결정 (또는 포스터 / 리더).