상용 소프트웨어에 대한 초기 릴리스/출시에 경험이있는 사람이 있습니까? 작동합니까?상용 소프트웨어의 출시/출시를 자주 시작 하시겠습니까?
나는 각 주요 버전 사이에 많은 개정판이있는 VMware를 생각하고있었습니다. 설치 경험이 끔찍했기 때문에 게스트 OS 내의 VMware Tools가 오작동/설치되지 않는 기존 VM을 차단할 수도있었습니다. 그것은 단지 끔찍한 일입니다.
ClickOnce를 사용하여 소프트웨어를 업데이트하면 모든 클라이언트가 자동으로 릴리스에 대한 알림을 받고 한 번 클릭하면 새 버전으로 업데이트되므로 ClickOnce 배포도 고려하고있었습니다. 소프트웨어에 버그가있는 경우 버그를 자동으로 "업그레이드"합니다.
상업용 소프트웨어에 출시 초기/릴리스 자주 원칙을 적용한 경험이 있으십니까?
나는 그것을 하나에 적용하려고합니다.
케니가 맞습니다.
우리는 고객이 내부 3 개월 프로젝트를 실행하여 새 릴리스로 업그레이드 할 수있는 엔터프라이즈 소프트웨어를 작업합니다. 그 환경에서 자주 출시 하지 작동합니다. 고객은 수년 동안 이전 버전을 유지할 것이며 지원을 계속해야하므로 더 많은 지원이 활성화되면 더 많은 지원이 이루어집니다.
다른 극단에서 Google 크롬을 실행하고 베타 업데이트에 대해 읽었습니다. Chrome을 가져 오는 방법을 살펴본 후 Chrome이 이미 업데이트 된 것을 발견했습니다. 어떤 알림이 있다면 나는 그것을 놓쳤다. 그리고 그것은 나와 잘있다.
주요 질문은 새로운 릴리스가 얼마나 불쾌한 지입니다.예를 들어, MS가 새로운 .NET 버전, C 런타임 등으로 매 3 개월마다 Visual Studio의 새 버전을 출시 한 경우 우리는 업그레이드를 처리하는 데 많은 시간을 할애하여 좋지 않을 것입니다. 그러나 나와 함께 괜찮은 새로운 위젯으로 Windows Media Player의 새 버전을 출시하려는 경우 다운로드/설치 프로세스를 최대한 원활하게 진행하십시오.
나는 그것이 항상 귀하의 시장이나 고객 기반에 달려 있다고 생각합니다. 소프트웨어를 변경/업그레이드하는 것은 항상 고통스럽고 일부 환경 및 회사에서는 더욱 고통 스럽습니다. 빠른 릴리스주기는 방해가 될 수 있습니다. 이러한 혼란은 마케팅/관리가 얼마나 잘 작동하는지에 따라 내부 작업까지 확장됩니다.
그래서 클래식은 '이제는 달라집니다'라는 응답이 다시 울립니다.
제품에 실제로 가치를 추가하는 고객은 특히 새로운 고객이 원할 것입니다. 가장 좋은 경우는 업그레이 드 변경 통증을 제거하는 것인데, 이는 동일하게 작동하지만 분명한 방법으로 더 좋습니다. 큰.
리소스에 따라 다릅니다. 당신이 MicroSoft라면 Sista와 유사한 버그에 휩싸인 POS를 일찍 출시 할 수 있으며 마케팅 능력을 통해 제품에 대한 초기 경험을 잊어 버릴 수 있습니다.
좋은 입소문을 원하면 초기 버전을 출시하는 것이 좋지 않습니다 (최종 출시 전에 이름이나 무언가를 변경하지 않는 한).
이렇게하려면 사람들이 제품을 구입할 때 1 년 동안 새로운 버전으로 무료 업그레이드를 받거나 다른 기간 동안 찢어진 느낌이 들지 않도록해야합니다 새 버전이 사본을 구입 한 후 2 개월 후에 나오게됩니다. 또한 이전 버전을 지원하여 업그레이드를 원하지 않는 사용자는 버그 수정을 통해 소프트웨어의 새 버전으로 현재 설치를 중단하지 않고도 그렇게 할 수 있습니다. 필자는 개인적으로 더 많은 일이 될 것이라고 생각하지만, 더 나은 제품으로 끝나게 될 것이며, 소프트웨어를 사용하는 사람들이 더 새로운 기능을 더 빨리 이용할 수있게됩니다.
커튼 뒤에있는 사람에게주의하십시오. :
종종 Early Practice를 발표하는 것은 너무 늦을 때 프로젝트가 끝날 때가 아니라 빨리 실패하는 것입니다. 최종 고객에게 제공하는 것을 보여주고 귀중한 피드백을 얻고 저렴한 비용으로 적응할 수있는 기회를 더 많이 제공합니다. '고객'역할의 사람은 최신 릴리스를 쉽게 얻을 수 있어야합니다. 가능한 한 정기적으로 건설적인 피드백으로 대응하십시오.
중요한 경우를 대비하여 예를 들어 발전소를 감시하거나 통제하는 것이 있다면,이 관행에 조심하고 싶을 것입니다. 당신은 횃불로 사람들을 당신의 새 릴리스에 대한 피드백으로 보내지 않을 것입니다. 이러한 경우 테스트 베드에 정기적으로 배포하고 X 일 동안 (자신감 수준에 따라) 시청 한 다음 LIVE로 이동하십시오! 고객에게이 테스트 베드에 대한 액세스 권한을 부여하여 자신감 측정기를 구성하고 재생할 수 있습니다.
중요하지 않은 응용 프로그램과 좋은 릴리스에 대한 좋은 기록이있는 경우 ClickOnce ..와 유사하게 수행하고 고객에게 롤백하기도 쉽습니다.
SaaS 애플리케이션을 실행하므로 원칙적으로 원하는만큼 자주 업데이트 할 수 있습니다.
한편, 실제로는 연간 주요 릴리스가 거의 없습니다 (작은 패치 릴리스는 일반적으로 몇 주에 한 번씩).
이유는 릴리스가 운영 요원에게 혼란을 야기하기 때문입니다. 때로는 응용 프로그램의 일부를 제거해야합니다. 비 고객 지향적 인 변화에 대해서는 엔지니어링을하는 것 말고는이라는 릴리스를 실제로 수행하는 많은 작업이 있습니다. .
그래서 StackOverflow가 며칠마다 업데이트되는 것처럼 보이지만 그렇게하지는 않습니다. 하루에 몇 가지 버그가 수정 될 수 있지만 "빅뱅"으로 나가는 후속 릴리스에서 수정되었습니다. 또는 뭔가.
좋은 설명입니다. – chakrit
마크가있는 권리. 또 다른 포인트 : - 출시 전략이 비즈니스 및 마케팅으로 확장 : 잦은 릴리스에는 고객이 다음 달 N 개월 이내에 모든 업데이트를 미리 지불해야하는 "유지 관리 계약"이 필요합니다. 고객은 비용을 미리 계획 할 수 있지만 그가 얻는 것이 무엇인지 알지 못합니다. OTOH, 업데이트 가격으로 개별 버전을 판매 할 경우 출시 빈도가 적어 출시 가능성이 높은 기능으로 끝납니다. 고객은 그가 지불하는 것을 알고 있지만 예산으로 인해 구매가 지연 될 수 있습니다. – peterchen