Ciągłe Komunikaty Lub „niedokończone”: Jak Często Warto Wydać Aktualizację Swojego Produktu

Istnieją dwa główne podejścia do wydania nowych wersji produktu. Można gromadzić mnóstwo nowych funkcji i poprawek błędów w dużych wydawnictw, które wychodzą kilka razy w roku, a można wlewać aktualizacji na produkcji jak można częściej — kilka razy w tygodniu lub w ogóle w czasie rzeczywistym. Druga metoda nazywa Continuous integration. W ostatnim czasie staje się coraz bardziej popularne.

Jego nawet prezes Sbierbanku German Gref, który niedawno stał się chętnie ewangelistą agile-podejścia. Niemniej jednak, u dużych wydawnictw ma swoje zalety, i wiele bardzo skutecznych i innowacyjnych firm korzysta właśnie ich. Przypomnę, jak wygląda proces projektowania. W obu przypadkach składa się z niepodzielnych jednostek, które zwykle nazywają lub historie.

może być nowa funkcjonalność lub . W dużym prasowym w całości powstają dziesiątki i setki biletów, po czym następuje całkowite () testowanie produktu. Jeśli testy zakończone pomyślnie, wydanie dostępne na produkcji. Przy ciągłej integracji każdy bilet jest realizowany i testowany w oddzielnym „piaskownicy” — branch.

Po tym, jak przechodzi przeglądy zmian w kodzie, a także ręczne i automatyczne testy, bilet uznaje się za spełniony i wlewa w master branch. W ten sposób, w kreatorze jest zawsze wersja nadaje się do premiery. Można ją ułożyć na produkcji co tydzień, dzień lub nawet automatycznie z każdym nowym . Jesteśmy w „” przeniósł się z dużych wydawnictw do ciągłego wydania aktualizacji.

Spróbuję porównać zalety i wady obu metod, z którymi mamy do czynienia w praktyce. Stabilność. W produkcie dla firm ważna jest stabilność, przy czym mam na myśli nie tylko jakość, ale i brak zmian w interfejsie. Każda aktualizacja istniejącej funkcjonalności — mały szok dla zwykłych użytkowników, z których większość nie chce zmian.

Dla nich łatwiej przetrwać stres kilka razy w roku, niż szereg drobnych zmian zachodzących stale. Prowadzenie. U dużej premiery jest zaplanowana data, do której powinien być wydany. Zaległości od niej pokazuje, jak źle się sprawy mają.

Być może bywa i wyprzedzenie grafika, ale tego jeszcze nie widziałem nigdy w życiu. W razie potrzeby z dużej premiery można wyrzucać poszczególne funkcje, które uniemożliwiają jego gotowości, ale w ogóle sama obecność planowaną datę dyscyplinuje. Z drugiej strony, przetwarzania i pracy w weekendy, które towarzyszą wyścig za harmonogramem — dodatkowy stres dla zespołu, który nie zawsze jest przydatny.

Efekt PR. Duża aktualizacja — to wydarzenie i świetny . Można go pięknie ogłosić, napisz do artykułu, zamówić recenzje, inicjowanie dyskusji w sieciach społecznościowych. Na podstawie wiadomości w 168 aktualizacji za rok możemy trochę poprawić drukowanie faktur” trudno uruchomić na szeroką skalę PR-kampanii.

Opóźnienia. W praktyce mamy stale do czynienia z tym, że realizacja jednej-dwóch skomplikowanych funkcji rozciąga się na nieprzewidywalne czas. Z tego powodu musieli opóźniać pełna wydanie, w którym mogły być dziesiątki gotowych opcji i . To okazało się nieprzyjemne dla poprawek błędów. Czasami musieliśmy wydać szczerze surowe produkty tylko po to, aby wyłożyć od dawna czekają .

Niekontrolowane złożoność. Jednoczesne wydanie kilku nowych funkcji doprowadziły do tego, że zaraz po premierze mamy dużą ilością komunikatów o błędach. Praca nad nimi zatrzymywał normalny proces rozwoju na jeden-dwa tygodnie. Jeszcze gorsze było to, że na pierwszy rzut oka często nie było wiadomo, jakie zmiany spowodowana przez konkretny problem.

Powolna reakcja. Po wydaniu nowej funkcji możemy prawie zawsze dostajemy informacje zwrotne — informacje o tym, co trzeba poprawić w realizacji. Wcześniej krytyczne problemy raz, a ulepszeń, które wypróbowały, zamierza na nowe wydanie. W rezultacie, użytkownicy otrzymywali je tylko przez kilka miesięcy.

Do tego momentu są już przyzwyczaić działać według pewnych wzorów świetlnych, które łamały kolejne ulepszenie. W rezultacie, użytkownicy byli stale niezadowoleni, a produkt rozwijało się powoli. Funkcji nie czekają na siebie nawzajem. Myślę, że to jest główną zaletą ciągłej aktualizacji.

Jak tylko przetestowany nowy wykres do analizy sprzedaży, trafi do produkcji. Mu nie trzeba czekać na gotowość do zarządzania uprawnieniami użytkowników i jeszcze kilkudziesięciu zmian. Szybka reakcja. Jeśli wypuszczamy nową funkcję i od razu wiemy, jak należy ją poprawić, zmiany wychodzą na następny dzień.

Kiedy decydujemy się zmienić kolor przycisku, aby zobaczyć, jak to wpływa na konwersję, nowy wariant pojawia się od razu, a nie w następnym wydaniu przez dwa miesiące. W ogóle ten proces znacznie lepiej nadaje się do modelu lean startup i koncepcji stałych eksperymentów ze zmianą produktu. Aktualizacje są wyraźnie podzielone na ramy i funkcjonalne. Rzecz w tym, że problemy wymagają różnych poprawek.

Na przykład, podczas platformowych zmianie, gdy zmienia się jakaś technologia lub wewnętrzna architektura, trzeba wrócić do poprzedniej wersji, aby potem spokojnie zrozumieć. Błędy w funkcjonalnym prasowym łatwiej korygować szybko. Przy ciągłym aktualizacjach u nas nie występuje zadania zrobić jeden wydanie platform, a drugi — z nowymi funkcjami. Wystarczy publikować gotowe bilety osobno.

Więcej środków na badania i wydanie wersji. Całkiem realne jest w pełni przetestować produkt ręcznie dwa razy w roku, ale robi to na co dzień już nie można. Wydaje się, że dla wydawnictw ciągłych musiał rezygnować z jakości, znacznie zmniejszając testy. Właściwierozwiązanie już dawno znaleziono i świetnie działa — testy automatyczne. Na ich rozwój i wsparcie wymaga dodatkowego czasu, ale od pewnej wielkości projektu, bez nich w każdym razie obejść się nie można.

Oprócz testowania istnieją jeszcze koszty na przeprowadzenie samego premiery. Jeżeli umieszczenie nowego kodu na produkcji serwerach można i trzeba zautomatyzować, to nadal pozostaje zadaniem monitoringu — czy wszystko w porządku u użytkowników z nowej kompilacji. Ten problem już nie da się w pełni przełożyć na skrypty.

Zacinanie się grafiki. Teraz wydań nie planowany, ponieważ w rzeczywistości nie ma i samych wydań. Pozostajemy z kilka ticketów, i każdy z nich ma przybliżony ocena czasu realizacji. Ponieważ stały wzrost tego czasu na dzień, dwa lub tydzień nie wpływa na inne bilety, łatwo go nie zauważyć. Zamiast jednego dużego projektu „wydać komunikat do 25 maja”, otrzymujemy setki mini – i mikroprojektów w postaci pojedynczych biletów.

Zarządzanie nimi wymaga wysiłku i większego doświadczenia w zarządzania projektami. Po tym, jak przeszliśmy na ciągłe wydania, częstotliwość aktualizacji produkcja-systemy wzrosła o porządek. Z pięciu do 54 razy w ciągu tych samych odstępach czasu w 2015 i 2016 roku. Byłoby to logiczne założenie, że użytkownicy teraz mniej czasu czekają na poprawki.

Naprawdę, mediana oczekiwań użytkownika biletów od momentu powstania obsługą do wyjścia fixa na produkcji zmniejszyła się z 17 do pięciu dni (średni czas — z 70 do 34). Myślę, że to bardzo dobry wynik. Mimo, że ma podejść do wydania aktualizacji ma swoje zalety, jesteśmy ogólnie zadowoleni z jego przejściem na ciągły wydanie wersji. Zapewnia on bardziej dynamiczny rozwój produktu, zachęca do automatycznego testowania (co samo w sobie jest o wiele bardziej wiarygodne i skuteczne) i, jak mi się wydaje, lepiej skaluje.

W miarę wzrostu liczby programistów i testerów to ciągłe aktualizacje sprawiają, że proces rozwoju produktu jest bardziej kontrolowany.

Czytaj Więcej: google.co.uk/blog/can-success-failure-fifty-shades-grey-teach-startup-founder/

Dodaj komentarz