패치는 고객에게 나쁜 신호입니까? [닫은]

사무실에서 우리는 패치를 너무 자주 발표하는 오랜 시간이 걸렸습니다. 그 기간이 끝날 무렵 우리는 일주일에 거의 3 개의 패치를 수행했습니다.

이것이 개발자에게 큰 동기를 부여한 것 외에도 고객이 이에 대해 어떻게 생각하는지 궁금했습니다. 나는 스스로 질문을했고 자주 업데이트되는 소프트웨어를 모른다는 결론을 내렸다. 그러나 가장 가까운 경우 패치가 매우 빨리 적용되므로 실제로 신경 쓰지 않습니다.

이 패치를받은 고객은 서로 많이 다릅니다. 일부는 다른 사람들이 실제로 신경 쓰지 않은 패치를 실제로 기다리고 있었지만 모두 동일한 패치를 얻었습니다. 고객 소프트웨어를 업데이트하는 데 걸리는 시간은 30 초 미만이므로 시간과 관련된 문제는 없습니다. 그래도 로그 아웃해야합니다.

그래서 내 질문에 더 자세하게 : 업데이트를받는 것이 수신자에게 '부정적'메시지를 자주 주는가?

물론 고객에게 물어볼 수는 있지만 그 자리에 있지 않고 '수면 견을 깨우고'싶지도 않습니다.

추신 : 내 질문을 개선하기 위해 할 수있는 일이 있으면 의견을 남겨주십시오.

컴퓨팅의 많은 것들과 마찬가지로, 그것은 달려 있습니다. 패치가 새로운 기능이나 개선 사항에 대한 고객 요청에 대한 응답 인 경우 회사는 반응 형으로 간주됩니다. 반면에 패치가 버그 보고서에 대한 응답 인 경우 회사는 무능한 것으로 간주됩니다.

고객의 소프트웨어 테스트는 다른 사람의 말에 상관없이 버그를 감지하는 가장 비싼 방법입니다. 거짓 경제입니다. 고객 서비스 노력, 소프트웨어 개발 수명주기 중단, 고객 신뢰 상실 등으로 인해 무료 노동력을 상쇄 할 수 있습니다.

가까운 곳에 여러 패치를 배포하는 것이 회사에 제대로 반영되지 않는 것 같습니다. 그것은 항상 그들이 충분히 사전에 테스트하지 않았거나 개발자가 무능하거나 경영진이 무엇을하고 있는지 전혀 모른다고 느끼게합니다.

즉, 토큰의 다른 측면은 서로 가까이에 여러 패치를 발표하면 회사가 제품에 적극적으로 접근하고 소비자를 위해 제품을 지속적으로 개선하고 있음을 보여줍니다.

전자가 소비자의 입장에서 가장 많이 볼 수있는 방법이라고 생각하지만, 그들과 직접 대화하는 것이 최선의 선택이 될 것이지만, 고객층 내에서 문제를 제기 할 것입니다. 처음에는 알지 못했습니다.

점점 더 많은 회사들이 크롬의 발자취를 따르고 있으며 점점 더 빈번한 고객 출시가 있습니다.

짧은 릴리스주기를 구현하기위한 전제 조건은 번거 로움이없는 업그레이드입니다. 예를 들어 크롬에서 업그레이드는 응용 프로그램 시작시 사용자 개입없이 수행되며 사용자가 항상 응용 프로그램을 계속 사용하는 경우 부 플래그를받습니다. 편리한 시간에 응용 프로그램을 다시 시작하도록 조언 한 다음 응용 프로그램은 다시 시작한 후 이전 상태로 되돌리려 고합니다.

이 방법을 사용하면 모든 업데이트를 인식 할 필요가 없으므로 고객을 만족시킬 수 있으며 기능 릴리스가 자주 제공되므로 버그 수정 릴리스를 환영합니다.

반면에 패치가 show-stopper 버그를 낸 후 패치가 나오고 이전 패치가 버그를 수정하지 못했거나 더 큰 버그를 생성했기 때문에 클러스터로 제공되는 경우 고객이 냄새를 맡을 수 있으므로 안심하십시오. 이는 공급 업체의 전문 평판에 제대로 반영되지 않으며 공급 업체의 인식 된 소프트웨어 표준을 낮 춥니 다. 지속적인 배송 은 효과적인 단위 테스트 및 통합 테스트에 크게 의존하여 성공을 보장합니다.

고객에게 '잠자는 개를 눕히도록'말하지 않는 문제에 대해서는 이것이 잘못된 전략이라고 생각합니다. 고객은 맹인이 아니며 바보가 아닙니다. 고객과의 원활한 의사 소통은 고객이 고객의 우선 순위이며 고객의 비판을 받아들이는 것만 보장 할 수 있다고 생각합니다. 불량 릴리스를 두 번 전달 했는데도 불만이 들리지 않으면 걱정할 필요가 없습니다. 알지 못했을 것입니다. 대신 대체 제품을 찾는 데 바쁠 것입니다 ...

문제를 발견 한 고객을위한 패치는 가능한 빨리 나가야합니다.

대기업의 소프트웨어를 본 후 다른 고객이 정기적으로 예약 된 간격으로 해당 패치를 서비스 팩으로받을 수있는 접근 방식을 취했습니다. 일반적으로 패치는 고객 환경에서 설치 및 테스트하기 위해 약간의 노력이 필요하기 때문에 귀하의 경우에는 해당 효과의 영향을 줄일 수 있습니다.

또한 사람들이 리포지토리 나 고객이 원하는 패치를 다운로드하여 설치할 수있는 웹 사이트에 패치를 올리는 것을지지하는 사람들을 보았습니다. 이는 고객이 어떤 패치를 가지고 있는지 아는 데 문제를 일으킬 수 있으므로 문제가 발생했을 때 어떤 코드를 실행하고 있는지 정확히 파악해야하지만 추적 할 수있는주의를 기울여야합니다. 그런 다음 많은 패치를 묶는 패키지가 출시 될 때 사람들이 더 큰 '팩'중 하나로 업그레이드하도록 할 수 있습니다.

보안 패치는 예외입니다. 워싱턴의 한 대형 소프트웨어 회사는 이달 3 일 목요일까지 중요한 보안 패치와 해킹에 대한 정보가 유출되어 손을 더 크게 당황하게 만들었습니다.

Google 크롬은 자동 업데이트를 자주 수행하여 문제를 해결하므로 프로그램을 다시 시작해야합니다 (크롬을 다시 시작하거나 로그 아웃). 그들은 이제 브라우저에 대한 일반적인 관행을 만들었고 사람들은 더 이상 그것에 대해 생각조차하지 않습니다. 그러나 모든 사람이 Google이 될 수있는 것은 아닙니다.

SaaS 애플리케이션은 백그라운드에서 업데이트를 수행하여 전체 문제를 해결합니다.

그러나 무엇보다도 지속적인 통합을 수행하거나 새로운 사용자 요청 기능으로 매우 자주 업데이트하지 않는 한, 사람들이 출시 전에 적절한 양의 테스트를 수행 할 것으로 예상하는 시점에 있다고 생각합니다. 고객을 만나고 당황하여 버그 수정 빈도에 대해 이야기한다면 충분한 테스트를 수행하지 않은 것입니다. 코드를 공개하기 전에 얼마나 위험을 감수 했습니까? 그것이 무엇인지 아는 한 초창기 버그 코드를 발표한다는 주장이 있지만, 알려진 품질을 잘 이해해야한다고 생각합니다. 이는 품질을 알기 위해 시간을 이해하고 통제하는 것을 의미합니다.