Wydawaj często/wcześnie wersję komercyjną oprogramowania?

Question

Czy jest ktoś, kto ma doświadczenia/przykłady na temat wczesnego wydawania/wydawania oprogramowania komercyjnego? Czy to działa?

Myślałem o VMware, gdzie ma wiele wersji wydania między każdą główną wersją. Instalacja była straszna, czasami łamali istniejące maszyny wirtualne, a inne narzędzia VMware Tools w systemach-gościach nie działały/nie instalowały. To po prostu okropne.

Myślałem także o wdrożeniach ClickOnce, ponieważ dzięki ClickOnce przy aktualizacji oprogramowania wszyscy klienci automatycznie otrzymują powiadomienie o wydaniu, a za pomocą jednego kliknięcia są aktualizowani do nowej wersji. Jeśli twoje oprogramowanie zawiera błędy, to automatycznie zostaną "uaktualnione", aby również uzyskać te błędy.

Czy masz doświadczenie \ przykład \ sugestia stosowania zasady wczesnego wydania/wydania często do komercyjnego oprogramowania?

Chciałbym zastosować go do jednego.

Answer 1

Kenny ma rację: to zależy.

Pracujemy na oprogramowaniu Enterprise, w którym klient może uruchomić wewnętrzny 3-miesięczny projekt w celu uaktualnienia do nowej wersji. W tym środowisku często pojawiają się wydania , a nie. Klienci pozostaną w starym wydaniu od lat i musimy je nadal wspierać, więc im więcej aktywnych wydań, tym więcej wsparcia.

Z drugiej strony korzystałem z przeglądarki Google Chrome i przeczytałem o odświeżaniu wersji beta. Poszedłem sprawdzić, jak to uzyskać i odkryłem, że Chrome już się zaktualizował. Jeśli było jakieś powiadomienie, przegapiłem to i to jest w porządku ze mną.

Głównym pytaniem jest, jak bardzo uciążliwe jest nowe wydanie:.Na przykład, jeśli MS wypuściło nowe wersje Visual Studio co 3 miesiące z nową wersją .NET, środowiskiem wykonawczym C itd., Wówczas spędzalibyśmy sporą część naszego czasu, zajmując się tylko aktualizacją, która nie byłaby dobra. Ale jeśli chcą wydać nowe wersje odtwarzacza multimedialnego Windows z nowym widżetem, który jest dla mnie w porządku - po prostu spraw, aby proces pobierania/instalowania był jak najbardziej bezproblemowy.

Answer 2

Myślę, że zawsze będzie zależeć od rynku lub bazy klientów. Zmiana/aktualizacja oprogramowania jest zawsze bolesna i jeszcze bardziej bolesna w niektórych środowiskach i firmach. Szybkie cykle zwalniania mogą być uciążliwe. Te zakłócenia często obejmują także operacje wewnętrzne, w zależności od tego, w jakim stopniu zarządzanie pełnią funkcje.

Tak więc klasyczna, prawdziwa odpowiedź "to zależy" dzwoni ponownie.

Jeśli naprawdę dodajesz wartość do produktu, klienci, którzy szczególnie będą chcieli, będą tego chcieli. Najlepszym rozwiązaniem jest usunięcie bodźca zmiany uaktualnienia, ponieważ działa on tak samo, ale lepiej w oczywisty sposób. Wspaniały.

Answer 3

To zależy od zasobów. Jeśli korzystasz z MicroSoft, możesz wcześniej wydać POS, który rymuje się z SISTA, i polegać na swojej mocy marketingowej, aby ludzie zapomnieli o swoich wczesnych doświadczeniach z produktem.

Jeśli masz nadzieję na dobrą reklamę, wypuszczenie wczesnej wersji nie jest dobrym pomysłem (chyba że zamierzasz zmienić nazwę lub coś przed ostatecznym wydaniem).

Answer 4

Jeśli masz zamiar to zrobić, upewnij się, że gdy ludzie kupią twój produkt, otrzymają bezpłatne uaktualnienia do nowych wersji na rok lub jakiś inny okres czasu, aby nie poczuli się oszukani wyłączone, gdy pojawi się nowa wersja 2 miesiące po zakupie kopii. Upewnij się także, że obsługujesz stare wersje, aby ci, którzy nie chcą uaktualniać, po prostu chcą, aby poprawki błędów mogły to zrobić, nie ryzykując przerwania obecnych instalacji nowymi wersjami oprogramowania. Osobiście uważam, że będzie to więcej pracy, ale otrzymasz lepszy produkt, a pozwolisz, aby osoby korzystające z Twojego oprogramowania szybciej korzystały z nowszych funkcji, jeśli zdecydują się na to.

Answer 5

Zwróć uwagę na człowieka za zasłoną.: Rzeczą, którą wydaje się, że wczesne wydawanie jest często praktykowane, polega na wczesnym i szybkim niepowodzeniu zamiast na końcu projektu, gdy jest za późno. Daje to więcej możliwości pokazania, co budujesz dla klienta końcowego, uzyskania cennych informacji zwrotnych i dostosowania przy niższych kosztach. Osoba w roli "klienta" musi mieć możliwość łatwego uzyskania najnowszego wydania; baw się z nim i reaguj na konstruktywne opinie tak regularnie, jak to tylko możliwe.

Jeśli budujesz coś krytycznego, np. coś, co monitoruje lub kontroluje elektrownię, prawdopodobnie zechcesz zachować ostrożność w tej praktyce. Nie chcesz, aby ludzie z pochodniami byli opiniami o Twoim nowym wydaniu. W takich przypadkach warto regularnie umieszczać na łóżku testowym, oglądać przez X dni (zgodnie z poziomem pewności siebie), a następnie przejść NA ŻYWO! Możesz dać klientowi dostęp do tego stanowiska testowego, aby zagrać i zbudować jego miernik zaufania.
Jeśli jest to aplikacja niekrytyczna i masz dobrą historyczną dokumentację dobrych wydań, zrób coś takiego jak ClickOnce ... ale również upewnij się, że jest równie łatwo wycofać klienta.

Answer 6

Prowadzimy aplikację SaaS, więc w zasadzie może być aktualizowana tak często, jak nam się podoba.

Z drugiej strony, w praktyce dostaje tylko kilka głównych wydań rocznie (mniejsze wydania są wydawane co kilka tygodni).

Powodem tego jest to, że wydania powodują zakłócenia dla personelu operacji; czasami część aplikacji musi zostać usunięta. W przypadku zmian niezwiązanych z klientem jest dużo pracy, która w rzeczywistości wchodzi w zakres , wydając wersję, w przeciwieństwie do inżynierii.

Podczas gdy StackOverflow wydaje się aktualizowany co kilka dni, nie robimy czegoś takiego. Kilka błędów można naprawić w jeden dzień, ale są one ustalane w kolejnym wydaniu, które wychodzi jako "wielki wybuch". Lub coś.