최종 사용자가 불행하게도 가상이 아닌 상황을 처리하는 방법은 무엇입니까?

나는 중소 기업에서 일하지만 IT 인력은 매우 적습니다.

작년 (2011), 나는 많은 최종 사용자 그룹에게 매우 인기있는 응용 프로그램을 작성했습니다. 작년 말에 마감 시한이 지났고 일부 기능 (지금부터 funcA라고 부름)이 마지막에 원하는 응용 프로그램에 추가되지 않았습니다. 따라서이 응용 프로그램은 2011 년 말부터 라이브 / 프로덕션에서 실행되었습니다. 문제없이 추가 할 수 있습니다.

어제 전체 최종 사용자 그룹이 애플리케이션에없는 funcA가 더 이상 작동하지 않는다고 불평하기 시작했습니다. 이 회사의 우선 순위는 응용 프로그램이 손상된 경우 우선 순위가 지정된 프로젝트보다 먼저 수정해야한다는 것입니다.

코드와 쿼리를 비교 한 결과 2011 년 이후에는 차이가 없습니다. 이는 proofA입니다. 그런 다음 최종 사용자 중 한 명에게 증거 B가 작동하지 않는다는 것을 인정할 수 있었지만 그 이후로 최종 사용자가 돌아와 이전에 작동하고 있다고 말했습니다 ... 최종 사용자의 무리가 동화되었다고 생각합니다 그녀. 또한 "시간 제한으로 인해 funcA를 달성 할 수 없음"(proofC) 인 프로젝트에 대한 요구 사항과 일일 업데이트가있는이 프로젝트에 대한 메모를 검토했습니다.

나는 그들 중 많은 사람들과 이야기를 나누었으며 프로그래밍 배경과는 거리가 멀어 혼란 스러울 수있는 곳을 알 수 있지만 프로젝트 우선 순위를 무시하기 위해 그룹에서 행동 할만 큼 지능적이라는 것도 알고 있습니다. 작업을보다 쉽게하기 위해 원하는 기능.

최악의 부분은 이제 그룹 생각이 시작되고 내 상사와 IT 책임자가 실제로 코드 또는 쿼리 변경이 없어도 실제로 그것을 믿기 시작한다는 것입니다. 논리 상태를 검토하는 한 1 = 1 인 경우 funcA가 작동하지 않을 정도로 매우 잘 건조됩니다.

따라서 이것은 시나리오 설명의 끝이지만 필연적으로 인계 할 수없는 생산 문제를 해결하기 위해 움직일 수 있기 때문에 성능 지표에 여러 가지 영향을 미치지 않으려 고합니다. 1 개월.

쉽게 관찰 할 수있는 사실에 대한 분쟁은 실제로 해결하기가 매우 쉽습니다 . 사실 만 관찰하십시오. "집 밖에 보라색 나무가있는 나무가있다"고 말하면 내 집에 올 수있는 사람이라면 누구나 내 진술의 진실 또는 허위를 확인할 수 있습니다.

FuncA가 제품에 있었으며 이전 버전에서 작동 하던데 현재 작동하지 않는다고 불평하고 있고 제품에 포함되어 있지 않다고 생각되면이를 증명하도록 요청하십시오. (또는 더 부드러운 말로 "우리는 문제를 재현하는 데 문제가 있습니다. 여기서 도와 주실 수 있습니까?"와 같은 말을하십시오.)

이전 버전이없는 경우 이전 버전의 사본을 제공하고 LiveMeeting으로 가져 와서 FuncA 사용 방법을 보여줍니다. 그들이 그것을 할 수 없다면, (희망적으로) 그들은 그것이 거기에 없었다는 것을 깨닫고 그것에 대해 귀하의 사례를 벗어나거나 적어도 다른 전술을 시도하여 구현하십시오. (그리고 LiveMeeting에서 관리 또는 PM으로부터 누군가를 데려 와야합니다.)

사실을 다룰 수있는 문제는 아닙니다. 시도하면 신뢰성이 떨어집니다.

먼저, 사용자가 원하는 것을하지 않기 때문에 소프트웨어가 "손상"되었다는 사실을 받아들입니다. 이제 사용자에게 소프트웨어가 원하는 작업을 수행 할 수있는 권한이 있음을 인정하십시오. 우리가 가진 것은 결함이있는 소프트웨어와 엔지니어가 그것을 고치기를 거부하는 것입니다 .....

결과적으로 우선 순위를 설정하기 위해 실행하는 시스템 인 경우, 이러한 사용자는 일반 채널을 통해 소프트웨어를 고정시킬 수 없으므로 사이드 채널을 사용하고 시스템 조작을 시도하기 위해 사이드 체인을 사용하여 먹이의 절반을 높이십시오. 그 동안 KPI가 나빠 보이게 만드는 것 (주요 관심사는 KPI가 아닌 고객이어야 함)-KPI는 자신이 좋아하는 경우 "담보 손상"으로 간주되거나 그렇지 않은 경우 유익한 부작용으로 간주됩니다. 그러나 그들은 당신이 가장 좋아하는 일을 얼마나 잘 통제 할 수 있습니다.

그래서 일어나고있는 일은 시스템이 망가졌고 모두가 원하는 것을 얻기 위해 물건을 조작하려고 노력하고 있습니다. 그들은 기능을 원하며 흠없는 KPI를 유지하려고합니다.

시스템을 고치거나 사무실 정치를 정말 빨리 배우는 법을 배우지 않는 한 게임 오버 : 패배.

참고 :이 토론에는 데드 라인, 버그 대 기능 토론, 지불하는 사람 등이 포함되지 않습니다. 이들은 사실입니다-사실은 중요하지 않습니다 (그들은 일종의 일이지만 많은 방법으로 조작 할 수 있습니다 ...) ) 사무실 정치에서.

조직적으로는 문제가 있습니다.

IT 책임자와 상사를 포함하는 계층 구조가 있습니다. 조직이 전통적 (민첩한 것처럼 들리지 않음) 인 경우 귀하는 자원이며 자원 관리자입니다. 소프트웨어 개발이라는 정규직이 있습니다. 최종 사용자가 기능을 직접 요청하고 우선 순위를 설정하며 시간을 관리하려고하는 경우 관리자가 중복됩니다. 최종 사용자에게는 책임이있을 수 있지만, 업무를 수행하는 경우 사용자에게 책임이 있으며 집중된 개발자 모드에서 방어 개발자 모드 로 전환 되지 않도록 보호해야 합니다.

내 대답의 맥락을 설정하기위한 몇 가지 사항 :

• 소프트웨어 개발자는 시간 여행자가 아니므로 결과는 현재 상태가 아닌 현재 상태에 대한 판단이 필요합니다.
• 기능이 요구 사항 사양, 일정 및 완료된 작업보다 우선 순위가 높은 경우 합법적 인 불만이있을 수 있습니다. 그렇지 않으면, 당신이 책임을 져야 할 정당성은 무엇입니까?
• 당신의 형벌은 공로를받는다면 당신의 지휘 체계에서 나올 필요가 있습니다. 제품 개발이 고객을 꾸짖었을 경우 마케팅 및 영업에서 원하지 않는 것처럼, 대부분의 조직에는 제품 관리자가 고객 분노를 받고 채널을 통해 전달해야합니다.
• 제품 관리자는 프로젝트의 성공한 부분을 따뜻하게 받아 들일 경우 매우 어려운 관계를 만들 수 있지만 개발자를 향한 채로 만있을 수 있습니다.
• 1 년 분량의 기능을 갖춘 기능성 제품을 제공했는데 업계에서 내가 본 것에서 원하는 기능을 추가하는 데 1 개월 (2 개월)이 걸린다면 귀하의 추정치는 평균 이상이었습니다.
• 문제를 공정하고 생산적으로 해결하려면 사람들이 책임의 손가락을 주머니에 넣고 앞으로 계획을 세워야합니다.

IT 책임자가 소유해야하는 프로세스에서 염소가 아니라고 평가되면 더 나은 동기 부여로 훨씬 더 우수한 품질의 작업을 수행 할 수 있습니다. 공정하고 생산적인 방법입니다. 나는 당신이 그런 식으로 관리되기를 바랍니다. 그리고 언젠가는 다른 사람들도 그렇게 관리하기를 바랍니다.

이와 같은 현실 실패의 경우 가장 좋은 것은 앞으로 나아가는 것입니다. 과거에 대해 논쟁하는 대신, 그것이 효과를 발휘하게하는 것과 그것이 얼마나 쉬운 지 또는 어려운지를 이야기하십시오. 문제가 문제를 해결하거나 처음으로 구현하는지 여부는 실제로 중요하지 않습니다. 경영진이 B보다 먼저 A를 원한다면 그렇게하십시오.

이 프로젝트에서 일한 유일한 개발자입니까? 프로젝트를 만드는 동안 누군가에게 대답 한 것처럼 들립니다. 이 모든 사람이 어디에 있습니까? 프로젝트에 대한 문서는 무엇을 전달 했는가?

문서 용지 흔적이 있어야합니다. 응용 프로그램 사용 방법을 보여주는 교육 문서 개발 된 기능을 설명하는 기능 사양. 기능이 포함되지 않은 경우 해당 기능에 대한 설명서도 있어야합니다. 누군가는 그것을 받아들이겠다고 서명해야했습니다.

그들에 대한 당신의 말이 아니어야하며, 문서에 모두 있어야합니다.

이 문서가 없다면 ...이 문서를 물어야 할 것 같습니다. 인생의 교훈으로 생각하십시오. 하루가 끝나면 사용자는 고객이며, 계속 말하면 고객은 항상 옳습니다. 이 기능을 추가하는 방법과 시간이 얼마나 걸리는지 작성하십시오. 회의를 열고 '우리의 기록에 따르면이 기능은 구현되지 않았지만 x 주 후에는 그 기능을 사용할 수 있습니다. 우리는 머리를 갈까? '

그리고 거룩하신 모든 것의 사랑을 위해 .... 승인을 받았다는 것을 증명하는 서류를 얻으십시오.