Propozycja: testowanie nowych funkcjonalności Coyote przez wybranych użytkowników na 4programmers.net

@Adam Boduch, co byś powiedział na to, żeby testować nowe feature'y Coyote na kształt testów A/B? Wyglądałoby to tak:

1. Planujemy, że feature zostanie wprowadzony.
2. Implementujemy go.
3. Testujemy go: (1) udostępniasz go wybranym użytkownikom na 4programmers.net, (2) jeśli będzie potrzeba, udostępniasz go również na 4programmers.dev.
4. Jeśli zostanie dobrze przyjęty, w szczególności przez tych "wybranych użytkowników", którym został udostępniony na 4programmers.net, to wdrażasz go.

Którzy użytkownicy będą owymi "wybranymi"? Ci, z którymi uzgodni się. Oczywiście dobrze, żeby taki wybrany użytkownik miał jakieś oznaczenie w profilu, że wersja 4p, z której on korzysta, trochę różni się od wersji innych użytkowników. Myślę, że wystarczy, jak takie oznaczenie będzie widoczne tylko dla niego. Myślę, że najlepiej, jak będzie widoczne w głównym menu, między przyciskiem prywatnych wiadomości a przyciskiem z awatarem.

Skąd mi się ten pomysł wziął? Moim zdaniem są pewne problemy z testowaniem nowych feature'ów Coyote. Jako jedną z przyczyn postrzegam to, że mało komu się chce wchodzić specjalnie na 4programmers.dev w celu przetestowania jednej rzeczy (myślę głównie o sobie). Szczególnie jest to niewygodne, że tam jest trochę inna perspektywa, brakuje postów, wpisów na mikroblogu i tak dalej.

Testy A/B mają sporo sensu przy stronach z dużym ruchem / częstymi zmianami ficzerów / eksperymentami, stad nie jestem pewien czy tutaj jest to gra warta świeczki - imo prościej wrzucić na produkcję i zebrać feedback od wszystkich naraz; a i przy okazji nie ma wtedy problemu z ikonką ten użytkownik korzysta z innej wersji serwisu :-)

Patryk27 napisał(a):

Testy A/B mają sporo sensu przy stronach z dużym ruchem / częstymi zmianami ficzerów / eksperymentami, stad nie jestem pewien czy tutaj jest to gra warta świeczki (…)

No, chciałem jedynie porównać koncepcję. Nie wiem, być może u nas taka funkcjonalność udostępniania feature'ów wybranym użytkownikom miałaby sens ze względu na jakieś inne cechy niż wymienione przez Ciebie.

Nie wiem czy mamy bazę ludzi, którzy byliby skłonni się zgodzić na coś takiego. Myślę że 99% użytkowników jak im zaproponować dwie opcje, to będzie ich walić która z nich zostanie wybrana i wdrożona. Oczywiście są tacy userzy np jak @furious programming, którzy potrafią znaleźć wady i zalety jakiegoś rozwiązania, i potem walczą o jego wprowadzenie, ale to jest raczej mniejszość.

Wiesz jak ciężko jest przekonać kogokolwiek na forum żeby sprawdzić jakiś feature na choćby na 4programmers.dev? Jak wchodził nowy edytor, to był na .dev przez chyba miesiąc, i jedynymi osobami które go widziały zanim wszedł to chyba tylko ja i @Adam Boduch, bo nikomu innemu się nie chciało wejść na .dev.

Idea zacna, ja bym był chętny na coś takiego, ale nie sądzę że uzbieramy więcej niż 3-5 osób, a dla takich testów 4programmers.dev spokojnie by wystarczyło.

TomRiddle napisał(a):

Nie wiem czy mamy bazę ludzi, którzy byliby skłonni się zgodzić na coś takiego. Myślę że 99% użytkowników jak im zaproponować dwie opcje, to będzie ich walić która z nich zostanie wybrana i wdrożona.

Ja wychodzę z założenia, że takie testy będą przeprowadzane tylko z tymi, którzy będą chcieć. :) Inaczej mówiąc: albo Ty czy Adam widzicie, że ktoś jest chętny, więc proponujecie mu przy okazji, albo on sam się zgłasza (nawet bez okazji). "Status testera" może być albo tymczasowy, albo stały. Ja byłbym za stałym, bo to prościej, i nie trzeba dwa razy pytać. Tak jak funkcja Moderatora, tylko bez uprawnień moderatorskich, za to z nowymi feature'ami.

Idea zacna, ja bym był chętny na coś takiego, ale nie sądzę że uzbieramy więcej niż 3-5 osób, a dla takich testów 4programmers.dev spokojnie by wystarczyło.

Inaczej mówiąc, zakładasz, że każdemu, kto chce testować, będzie się chcieć robić to na 4programmers.dev? (Pomińmy mnie w tej chwili, bo już pisałem, że mnie się nie chce).

@Silv: pomysł fajny, ale totalnie nie pasuje tutaj. Za mały ruch i jeszcze mniejsza liczba userów, którzy się zaangażują w wystawianie opinii. Ja bym nie udziwniał, wrzucać (po testach na .dev) na produkcje i potem zbierać feedback.

cerrato napisał(a):

@Silv: pomysł fajny, ale totalnie nie pasuje tutaj. Za mały ruch i jeszcze mniejsza liczba userów, którzy się zaangażują w wystawianie opinii. Ja bym nie udziwniał, wrzucać (po testach na .dev) na produkcje i potem zbierać feedback.

Tak właśnie teraz (nie)stety robimy :) Nie ma to jak feedback po wdrożeniu na produkcję :)

Nie powiem jednak, że nie myślałem o tym, co proponuje @Silv. Można użyć tego narzędzia (https://launchdarkly.com/) aby w miarę prosty sposób włączyć niektóre funkcje wybranym użytkownikom.

Jeszcze raz napiszę: chodzi mi tylko o tych użytkowników, którzy będą chcieć. :) Ale masz rację, @cerrato, być może niedokładnie opisałem zalety. W takim razie zalety widzę takie:

1. Więcej feature'ów przetestowanych przez większą liczbę użytkowników. Oczywiście to przy założeniu, że jest u nas poza mną ktokolwiek, kto chciałby testować, ale komu nie chce się wchodzić na 4programmers.dev.
2. Feedback bardziej real-time niż w przypadku 4programmers.dev. Skoro testujący użytkownik na bieżąco korzysta z testowanych feature'ów, to bardziej będzie chcieć, by działały niezawodnie. Skoro tak, to w przypadku problemów będzie chcieć, by te zostały szybko naprawione. Myślę, że to go skłoni do szybszego stworzenia wątku w kategorii "Coyote", lub choćby napisania prywatnej wiadomości do osoby odpowiedzialnej za implementację tego feature'a. Nawet bym dodał: w ogóle będzie większa szansa, że ktokolwiek cokolwiek zgłosi.
3. Ograniczenie testów na produkcji. Nie powinno ich być, więc nawet najmniejsze ograniczenie ich występowania zawsze jest na plus.

Zaadresuję też niektóre obiekcje, które padły w tym wątku:

Patryk27 napisał(a):

(…) przy okazji nie ma wtedy problemu z ikonką ten użytkownik korzysta z innej wersji serwisu :-)

Oczywiście, ikonka wymaga jakiegoś dodatkowego kodu w Coyote (i zapewne jej pobierania z Font Awesome), ale moim zdaniem to nie jest problem zważywszy na wyżej wymienione zalety. Czy chodzi Ci o jakiś inny problem?

cerrato napisał(a):

Za mały ruch i jeszcze mniejsza liczba userów, którzy się zaangażują w wystawianie opinii.

Jeśli chodzi o ruch, to nie widzę problemu. Jak napisałem, testować będą Ci, którzy będą chcieć, a nie losowa próba wszystkich użytkowników. Może analogia z testami A/B nie jest najlepsza. Jeśli chodzi o wystawianie opinii, to zakładam, że opinii jako takich nie będziemy oczekiwać (tj. nie tylko nie będziemy oczekiwać, że będzie ich więcej, ale że w ogóle będą). Natomiast domyślam się, że będzie po prostu większe prawdopodobieństwo otrzymania opinii. W szczególności, jak napisałem wyżej w zaletach, oczekuję, że liczba opinii będzie większa, kiedy coś nie będzie działać.

@Adam Boduch: co do tego narzędzia, nie znam go, nie wiem, może Ty zdecyduj, czy to ma sens. :)

To by miało sens w przypadku np. jakiś dużych zmian jak to było w przypadku edytora. Można by utworzyć grupę "Testerzy" i włączać im wybrane nowe funkcje.

Myślę że jest za mało użytkowników do czegoś takiego.
Więcej sensu by miało żeby było coś takiego jak 4programmers.dev ale z bazą produkcyjną, tak żeby każdy mógł włączyć sobie 4p w wersji preview i go normalnie używać. Ciężko było na przykład dobrze przetestować nowy edytor skoro na tym 4p.dev niczego się nie pisze

@obscurity: nie bardzo rozumiem, mógłbyś rozwinąć ten pomysł? Jak on się różni od mojego?

Silv napisał(a):

@obscurity: nie bardzo rozumiem, mógłbyś rozwinąć ten pomysł? Jak on się różni od mojego?

Twój pomysł jeśli dobrze rozumiem to połączenie dwóch wersji 4p w jedną. Część userów dostaje feature a w wersji 1, część w wersji 2, część userów dostaje feature b w różnych wersjach (jak np na youtube). Masa implementacji, dodatkowe opcje w panelu admina itp.
Mój pomysł to po prostu podpięcie żywej bazy do 4p.dev (lub jego kolejnej kopii w innej domenie) tak żeby można było sobie korzystać jednocześnie normalnie z 4p i testować nowe zmiany. Każdy sam może zdecydować czy i kiedy chce oglądać wersję preview serwisu, gdyby coś nie działało może wrócić na zwykłe bez proszenia się admina.
Zerowy koszt implementacji, być może nawet większość użytkowników zdecydowałaby się na korzystanie z tej wersji jako głównej (tak jak ja przykładowo używam głównie wersji preview IDE i innych programów bo mimo zapisków że nie powinno się tego robić do rzeczywistej pracy to zazwyczaj jednak wszystko działa bez zarzutu i mam dostęp do nowych opcji trochę wcześniej)

Nie jestem przekonany z uwagi na to, że baza danych live wymaga jakiegoś poziomu bezpieczeństwa. Chodzi mi głównie o podejście administratora. Domyślam się, że w przypadku serwera deweloperskiego administrator ma podejście "a, dobra, jak coś, to się bazę przywróci", a w przypadku produkcyjnego "póki działa, nie dotykaj".

W tym, co ja zaproponowałem, przynajmniej jak ja to widzę, to od początku operujemy na serwerze produkcyjnym. Nawet jeśli wprowadzi się jakieś funkcje "unstable", to są one nadal częścią produkcji – przynajmniej wyobrażam sobie, ze dla mnie by były, gdybym był administratorem. W tym duchu administrator zachowuje podejście "póki działa, nie dotykaj" (pomijając feature'y testowe). Zaś w przypadku Twojej propozycji wydaje się, że sytuacja jest odwrócona, jesteśmy na serwerze deweloperskim, a "tylko podpinamy bazę". W tym duchu administrator zachowuje wspomniane podejście "to się przywróci".

Przepraszam, że nie rozważam głębiej tego, co napisałeś, ale ta kwestia jest dla mnie way more important od pozostałych.

Fakt, moja propozycja się nadaje tylko do testowania zmian client-side i wymaga użycia tego samego backendu i struktury bazy (albo nowe wersje muszą być w pełni kompatybilne wstecz). Przy zmianach js/html/css nie powinno być żadnego problemu z bezpieczeństwem ani uszkodzeniem integralności bazy - a przynajmniej nie powinno być bo to by oznaczało że i w obecnej wersji aplikacji jest dziura.
Nie wiem jak często są wprowadzane zmiany od strony backendu w porównaniu do frontu, ale pomogłoby to przynajmniej przetestować rzeczy które się wizualnie zmieniają dla userów (jak na przykład ten nowy edytor).