고객의“업데이트 이후…”질문에 어떻게 응답합니까? [닫은]

업데이트 이후로 사람들은 계속해서 전화를 걸어 "업데이트 X, Y 및 Z가 느리고 나쁘고 충돌하는 이래로"

이것은 업데이트가 시작된 이래로 계속 발생했습니다.

사람들은 무엇을 기대합니까? 감마는 베타 버전으로 제공되며 감마 테스트는 항상 사용자를 인크레더블 헐크로 전환합니다.

아마도 당신은 클라이언트로부터 이것을들은 적이 없을 것입니다. 아마도 당신은 대학이나 FLOSS Dev에서 5-6 명 이상을 비난 할 수 있습니다. 아마도 코드를 단위로 테스트 할 것입니다. 아마도 흥미로운 상황에 있지 않을 것입니다. 고객이 실제로 오늘의 패치를 발표 할 정확한 시간을 요구하는 고객에게 전화를 걸거나 (Microsoft에이 작업을 수행하고 싶습니다) 새 제품을 출시 한 저와 같은 미안합니다. 업데이트하고 집에 갔다가 내일 다시 일하는 것을 두려워합니다.

어쨌든 나중에 나보다 똑똑해 "소프트웨어를 더 나쁘게 만들기 때문에 나쁜 프로그래머가되어야합니다."에서 틀린 비판을 어떻게 받습니까?

배포 할 때마다이 문제가 발생하면 개발 프로세스에 심각한 결함이있을 수 있습니다. 문제를 일으키는 몇 가지가 의심됩니다.

1. 프로덕션과 동일한 크기 (대략)의 데이터베이스에 대해 개발합니까? 그렇지 않은 경우 작은 데이터 세트에 적합한 쿼리는 종종 큰 쿼리가있는 개이기 때문에 항상 이러한 문제가 발생합니다.
2. 품질 관리에서 테스트를로드합니까? 한 번의 사용자 테스트에서 제대로 작동하는 것은 1000 명의 사용자가 동시에 작업을 수행하려고하는 방식과는 매우 다릅니다.
3. 사용자의 인식이 잘못되었다고 가정하고 불만에 대해 바보처럼 취급합니까? 그렇다면 귀하의 태도는 불만을 줄이지 않고 더 많은 불만을 제기합니다.
4. 테스트를 잘하고 있습니까? 변경 사항에 영향을 받는지 확인하기 위해 변경되지 않은 회귀 테스트 기능이 있습니까? 당신은 그들이 찌를 때까지 시간이 얼마나 걸리는지 걱정합니까?
5. 급여 지급이 실시되는 당일 회계 시스템에 변경 사항을 배포하거나 배포 할 때 사용자에게 좋은 시간에주의를 기울이고 왜 사용자가 느리게 화를 내는지 궁금하십니까?
6. 개발자와 제품 사이에 환경 적 차이가 있습니까? 때때로 운영 체제 또는 데이터베이스 버전의 성가신 차이점으로 인해 이와 같은 문제가 발생할 수도 있습니다. prod와 동일한 스테이징 환경, 일부 장비는 동일한 운영 체제, 가능한 데이터베이스 데이터에 가까운 dat가있는 동일한 데이터베이스를 갖는 것이 좋습니다. 배포를 테스트하는 데 사용됩니다. 이 서버에서 먼저 실행하면 일부 사용자 또는 테스터가 해당 서버로 이동하여 일부 테스트를 수행하게됩니다.
7. 배포 과정이 얼마나 좋습니까? 배포하려는 지점에 어떤 코드가 있는지 분명하기 때문에 개발자 이외의 사람이 실행할 수 있습니까? 구성 관리 팀이 생겼을 때 코드를 배포하는 데 훨씬 능숙 해졌으며 아무도 "oopsie"변경을 수행하는 데 도움이 될만한 권리가 없었습니다. 빌드를 자동화하면 큰 도움이 될 수 있습니다. QA로 가서 먼저 준비를해야하고 딥 문제가 해결 되었기 때문에 찌르기 위해 무엇이 필요한지 추측해서는 안됩니다. 스크립팅 데이터베이스 변경도 중요합니다. 그것들은 스크립트와 소스 제어에 있어야하므로 빌드 프로세스는 누군가가 기억할 필요없이 그것들을 선택할 수 있습니다. 그렇습니다. 우리는 B 열의 길이를 50에서 241로 변경해야합니다.

"소프트웨어를 더 나쁘게 만들기 때문에 나쁜 프로그래머가되어야합니다."에서 틀린 비판을 어떻게 받습니까?

그러나 그러한 비판은 대부분 정당화됩니다. 새로운 릴리스는 이전 릴리스보다 나빠서는 안되지만 실제로 알다시피 실제로 릴리스가 되었기 때문에 우리의 잘못입니다.

실수를하는 것은 인간이며, 누군가를 "나쁜 프로그래머"로 만들지 않기 때문에 개인적으로 비판을받지 마십시오. 고객에게 문제를보고 해 주셔서 감사하며 가능한 빨리 해결하십시오. 좋은 프로그래머로서 당신의 직업입니다.

직장에서 우리는 고객과 직접 상호 작용하지 않으므로 개인 프로젝트 작업 에서이 질문에 대답해야합니다. 사람들이 자신의 게임을 만드는 데 사용할 수있는 게임 엔진을 작성하고 있습니다. 아직 사전 알파 상태이지만 관심이 많은 사용자가 있으며 때로는 버그가 있습니다.

사용자로부터 이와 같은 보고서를 받으면 개인 터치를 사용하려고합니다. 나는 버그를 도입하려고하지 않았으며, 내 엔진에 대해 좋은 경험을 갖기를 원하기 때문에 그것들을 믿어야한다. 먼저 대화 할 수 있도록 IM 핸들을 가져옵니다. 사용자에게 프로젝트에 대해 물어보고 사본을 얻으려고합니다. 이것은 훨씬 쉽게 재생산합니다. 결함이 발생했을 때 그들이 무엇을하고 있는지 물어보십시오. 한편, 나는 디버거에 엔진이 열려 있고 우리가 이야기하는 동안이 문제를 원하고 있습니다.

예외 인 경우 일반적으로 매우 간단합니다. 문제를 재현하면 디버거가 문제를 파악하여 전체 스택 추적으로 오류 위치로 바로 이동합니다. 진행 상황은 분명합니다. 성능이 느리거나 잘못된 동작 인 경우 시간이 조금 더 걸릴 수 있습니다. 그러나 대부분의 경우 처음 20 분 이내에 수정 사항을 준비 할 수 있습니다. 나는 그것을 압축하고 테스트를 위해 그들에게 보냅니다. "좋아요, 알았어요.이게 당신의 끝에서 작동하는지보세요?"

대부분의 개발자 (읽기 : 소프트웨어 회사)는 버그를 수정하지 않고 빠르게 다시 릴리스하기 때문에 응답은 거의 보편적으로 놀라움과 감사의 혼합입니다. 그리고 실제로 고정되어 있다면 잠재적 인 비평가를 팬으로 바꿨습니다. 정말 좋은 기술입니다. 더 많은 개발자가 채택하기를 바랍니다.

나는 개인적으로 문제를 긍정적으로 받아들입니다. 나는 많은 고객과 항상 상호 작용하고 여전히 코드를 작성합니다.

그들이 새 릴리스를 다운로드하고 그와 같은 것을 말해 줄 때, 나는 항상 다음과 같이 말합니다.

그 버그를 알려 주셔서 감사합니다. 어쩌면 우리가 추가 한 모든 새로운 기능들이 함께 소개되었을 것입니다. 최대한 빨리 해결하겠습니다.

실제로 고객은 당신의 진정한 상사입니다. 당신과의 경험이 나쁘면 나도 나쁘다.

그가 옳지 않더라도 회사의 일원으로서 다음과 같은 기회를 가져야합니다.

• 제품의 개선 가능성을 모아 그에게서 배우십시오.
• 행복하지 않은 고객을 행복한 고객으로 전환하여 너무 행복해 (상사 포함)
• 하고있는 일을 자랑스러워하다

세부 사항, 세부 사항, 세부 사항. 나는 그들이 무엇을하고 있었는지, 언제 구체적인지 묻습니다. 저스틴 비버 (Justin Beaber) 비디오가 유튜브에 방금 출시 된 것일 수도 있습니다. 로그 파일은 두 경우 모두 친구입니다.

또한 그들이 알아 차린 날짜도 묻습니다. 때로는 특히 엔터프라이즈 상점에서 사용자는 릴리스가 언제 나오는지 알지 못하고 무언가를 완료하는 데 오랜 시간이 걸리고 지금 불만을 제기하고 있음을 알고 있습니다.

직업 그림자. 이것을 충분히 강조 할 수 없습니다. 운이 좋으면 근처에 사용자가있을 수 있습니다. 나는 종종 눈부신 문제를 무시하고보고하지 않습니다. 그들은 종종 새로운 것을 알고 있거나 처음에 문제를 발견했을 때만 불평합니다.

1 단계는이 업데이트 (다른 ​​업데이트가 중단됨)가 정상이 아니라는 사고 방식에서 나온 것입니다. 업데이트가 앱의 다른 부분을 깨뜨 리거나 느리게하지 않아야합니다. 그것은 괜찮지 않고 예상되지 않으며 사용자가 그것에 대해 불평 할 때 사용자의 잘못이 아닙니다. 이를 방지하기 위해 가능한 한 많은 테스트를 수행해야합니다. 그것이 일어날 때, 당신은 문제와 긴급한 문제가 있습니다.

2 단계는 자신이 한 일을 알아야한다는 것입니다. 소스 제어 시스템이 도움이 될 수도 있고 어떤 종류의 작업 추적 시스템이 도움이 될 수도 있지만 이러한 불만 사항 중 하나가 발생하는 순간 "확인,이 표에 열을 추가하고이 표를 변경하여 계산 새 세금, 그 두 가지 새로운 보고서를 추가했습니다 ... "등.

3 단계는 성능 문제를 발견하고 빠르게 충돌하는 경험이 있어야하므로 어떤 종류의 문제가 발생할 가능성이 있는지 알고 즉시 문제를 해결할 수 있습니다. 이 일은 생겨 났고 문제를 빨리 찾아 패치를 얻어야합니다. 보고서를 변경해도 보고서를 사용하지 않는 앱의 일부가 느려질 수는 없습니다. 현재 비상 모드에 있으며 프로세스에서 앱의 다른 부분을 중단하지 않고 실수의 위치와 해결 방법을 파악해야합니다.

4 단계는이 시리즈 각각에 대해 다음에 테스트 할 레슨을 배워야합니다. "만일 레코드가있을 때 끔찍할 것"이기 때문에 특정 구성에 반대하는 "그 사람"이 될 것입니다.

"이것은 정상입니다"앞에서 조금 더. 외부 고객을 위해 민첩한 프로젝트를 실행합니다 (우리가 진행중인 다른 모든 것들 중에서). 우리는 지금 2 ~ 3 년 동안 대략 6 주마다 릴리스를 해왔습니다. 그리고 네, 출시 예정입니다. 우리는 방금 어제 오전 8시에 하나했습니다. 그리고 대략 4 년 또는 5 일마다 (연 1 회 또는 2 년마다) 무언가가 생겨나 고, 우리는 가능한 한 빨리 행동을 취하고 올바르게 만듭니다. 릴리스 전에 테스트하고 테스트하고 테스트하더라도. 그런 다음 무슨 일이 있었는지 알려줍니다. "6 월 배포에는이 필드를 비워 두는 약간의 버그가 있었지만 그 당시에는 값을 사용하지 않았기 때문에 눈치 채지 못했습니다. 그런 다음이 배포에서는 필드를 사용하기 시작했을 때 비었을 수 있습니다. 그 오류 메시지를 보았습니다. v 버그를 수정하여 비워 둘 수 없도록하고 잘못된 레코드에 값을 입력하고 더 이상 폭파되지 않음을 확인했습니다. "죄송합니다."또는 "출시 이틀 전에 긴급 변경을 요청한 결과, 우리가 생각하지 않았고 테스트하지 않은 결과가있었습니다. 우리가 왜 긴급한 변화에 저항하는지 기억하십니까? "나는 업데이트를 통해 악화시키는 데 나쁜 프로그래머는 아니지만, 반드시 나쁜 일을 했으므로 올바르게해야합니다. 나는 업데이트로 더 나쁘게 만드는 나쁜 프로그래머는 아니지만 분명히 나쁜 일을했다. 그리고 나는 그것을 올바르게 만들어야합니다. 나는 업데이트로 더 나쁘게 만드는 나쁜 프로그래머는 아니지만 분명히 나쁜 일을했다. 그리고 나는 그것을 올바르게 만들어야합니다.

다른 측면을 다루기 위해 :

우리는 그렇지 않은 것으로 밝혀 졌을 때이를 주장하는 고객 목록을 유지합니다. 소프트웨어는 버그가 많고 종종 버그가 많지만 많은 고객이 "업데이트 시작"이라고 말하면 즉각적인 관심을 끌기 때문에 문제를 찾는 표시된 기능에 대한 델타를 걸을 때 모든 사람이 시간을 낭비한다는 사실을 깨닫지 못합니다. 고객이 진실을 말하면 이것이 빨리 발견되는 경향이 있습니다. 고객이 허위 목록에 너무 많은 경우 시간 낭비를 좋아하지 않으므로 걱정하지 않습니다.

거짓말을하면 프로세스 속도가 빨라진다 고 생각하기 위해 어떤 사고 방식이 필요한지 상상할 수 없습니다. 이 사람들은 의사이거나 의사와 함께 일하며 사람들이 의사에게 거짓말을 할 때 어떤 일이 발생하는지 잘 알고 있어야합니다. 동일한 원칙이 적용됩니다.