Zwolnić pierwszy czy najpierw dokument?

23

Pracuję nad projektem od kilku lat i zaczynam gromadzić porządną bazę użytkowników. Stworzyłem stronę projektu z podstawową dokumentacją, ale w tym momencie to naprawdę niewiele więcej niż FAQ. Wiem, że muszę to poprawić, aby było bardziej pouczające zarówno dla nowych, jak i zaawansowanych użytkowników, i to jest następne na mojej liście rzeczy do zrobienia w następnej wersji.

Jednak następna wersja ma funkcje, których baza użytkowników chce uzyskać. Jestem gotowy na wydanie go teraz, jest zapakowany i gotowy do pracy. Muszę tylko wdrożyć go w odpowiednich usługach dystrybucji.

Do momentu. Funkcje są ważne dla moich użytkowników, ale dokumentacja jest dla mnie ważna. Czy powinienem poczekać na wydanie do momentu przepisania dokumentacji? Moja obecna baza użytkowników jest wystarczająco bystra, aby zrozumieć, jak korzystać z nowych funkcji, więc nie martwię się o to. Dokończenie dokumentacji może potrwać kilka tygodni, ponieważ mam ograniczony czas wolny na pracę nad tym projektem, ale społeczność upiekłaby mnie na rożnie, gdybym kazał im dłużej czekać.

Czy klient ma rację w tym scenariuszu? Czy fantastyczna, prosta funkcja dla obecnych użytkowników powinna mieć pierwszeństwo przed solidną dokumentacją dla nowych użytkowników?


Aktualizacja: Wow, tyle świetnych, wysokiej jakości odpowiedzi! Naprawdę pomogłeś mi lepiej zrozumieć, w jaki sposób powinienem wchodzić w interakcje i wspierać zarówno projekt, jak i jego użytkowników. Stukrotne dzięki!

cyberbit
źródło
14
Tak, klient ma rację. Rozwiń wersję, a następnie spędź dwa tygodnie na przygotowaniu dokumentacji. Powiedziałeś nam już, że brak dokumentacji nie wpłynie negatywnie na bazę użytkowników, a to tylko dwa tygodnie. Gdyby to był prawdziwy koncert, twój klient lub organizacja upiekłaby cię na prawdziwym rożnie, ponieważ dwa tygodnie bez wydania to dwa tygodnie na zdobycie udziału w rynku.
Robert Harvey
3
W zależności od projektu możesz wydać nową wersję w osobnym oddziale jako „beta” lub „podgląd”.
CodesInChaos
2
Jakiego rodzaju dokumentacja - dokumentacja użytkownika końcowego lub dokumentacja kodu źródłowego? A może jest to jakiś projekt, w którym nie ma rozróżnienia?
Dok. Brown
5
Wydaje się, że nie ma tutaj żadnego konfliktu: jeśli jest spakowany i gotowy do pracy, to dlaczego nie możesz go zwolnić i dalej pracować nad dokumentacją, aby zaktualizować tylko dokumenty w ciągu dwóch tygodni? Czy obawiasz się, że wydanie spowoduje wiele pracy (na zgłoszonych błędach itp.), Która uniemożliwi pracę z dokumentami? Powody, dla których nie możesz zrobić obu, należy wziąć pod uwagę w odpowiedziach.
Steve Jessop
@DocBrown W tym przypadku jest to dokumentacja użytkownika. Dokumentacja kodu źródłowego byłaby przydatna tylko dla mnie.
cyberbit

Odpowiedzi:

45

Proste: wypuść wersję beta! Następnie po zakończeniu dokumentacji wykonaj ostateczne wydanie nowej wersji.

Jeśli masz użytkowników chętnych do wypróbowania nowych rzeczy, skorzystaj z nich. Otrzymasz raporty o błędach, prawdopodobnie dostaniesz pytania od społeczności na temat trudnych punktów, więc będziesz wiedział, gdzie skoncentrować się na dokumentacji itp. Możesz również poprawić niektóre rzeczy w oparciu o opinie użytkowników, które mogą mieć wpływ na dokumentację.

Zasadniczo wszyscy wygrywają.


Jednym z powodów, aby nie robić wczesnego wydania, jest to, że jeśli uważasz, że Twoi użytkownicy nie będą otwarci na „wersję beta”, powinieneś pomyśleć dwa razy o zrobieniu tego, ale postępując zgodnie z tym, co piszesz, brzmi, jakby byli z tego zadowoleni.

Innym powodem byłby problem techniczny, jeśli chodzi o wykonanie wersji beta przy użyciu dowolnych kanałów wersji. Może to być bardziej kłopotliwe niż osobne wersje beta i końcowe. Jeśli uważasz, że twoje oprogramowanie jest kompletne, to w tym przypadku oparłbym się na wczesnym wydaniu, zaktualizowałem dokumentację po zakończeniu. W przeciwnym razie istnieje ryzyko, że dokumentacja zostanie opóźniona, a następnie całe wydanie zostanie opóźnione lub w końcu wydasz bez ostatecznej dokumentacji, więc zrób to teraz.

hyde
źródło
1
Robiłem to w przeszłości dla małych narzędzi tak wiele razy ... kod jest gotowy, wszystko wydaje się działać, ale to koniec weekendu i nie mogę się martwić ukończeniem dokumentacji teraz. Po prostu pakuję go jako wersję beta i voila, jeśli bardzo chciałaś nowej wersji, oto ona, w przeciwnym razie będziesz musiał poczekać na następny weekend.
Pimgd
Zastanawiałem się nad wersją beta, zanim o to poprosiłem! Problem z tym pomysłem polega na tym, że kanały, z których korzystam, zmuszają mnie do napisania całkowicie oddzielnej aplikacji z dzielonymi wersjami. Zacząłem pracować nad oddzielną wersją beta, ale jej logistyka jest trudna i na tym etapie projektu nie wydawała się opłacalna.
cyberbit
Zamiast tego zdecydowałem się na tę opcję, aby była to wersja beta opt-in w normalnej wersji. Zapewnia to, że ludzie, którzy chcą stabilnego doświadczenia, zachowają go, a ci, którzy chcą nowej funkcji, będą mogli z niej korzystać, mając świadomość, że czasami może się zepsuć. Następnie, w przyszłej wersji, mogę przenieść tę funkcję z opcjonalnej na zintegrowaną, usunąć oznaczenie wersji beta i wszystko jest dobrze na świecie.
cyberbit
3
Apache używa „Release Candidates” do oznaczenia projektu, który jest funkcjonalnie ukończony, ale właśnie sprawdza, czy pakiet ma wszystkie zasoby i jest naprawdę gotowy na najwyższy czas. Wygląda na to, że jesteś poza wersją beta (funkcjonalność jest dojrzała, ale wciąż nie jest kompletna).
Berin Loritsch
@BerinLoritsch Widziałem to używane wcześniej. Ta etykieta faktycznie pasuje dobrze w tym przypadku. Wydaje mi się, że umieszczenie opcjonalnej opcji w normalnym wydaniu jest (w moim przypadku) czymś w rodzaju kandydata do wydania. Jest stabilny, działa, ale jeszcze nie widział światła.
cyberbit
15

Jeśli dobrze zrozumiałem, robisz ten projekt w wolnym czasie i bez żadnych pieniędzy . W takim przypadku zrób to, co poprawi ci humor (użytkownicy czekają, dokumentuj na swój czas). Nie powinieneś odczuwać presji ze strony „użytkowników”. Wiele osób pisało o tym w Internecie (duzi autorzy i współautorzy FLOSS, którzy odczuwali presję).

Ale jeśli otrzymujesz wynagrodzenie lub otrzymujesz jakąś korzyść, rób to, co chcą Twoi użytkownicy. Oznacza to, że rób wszystko, co najlepsze dla swoich klientów lub użytkowników , w takim przypadku po prostu zwolnij i udokumentuj swój czas. Powiedziałeś, że znajdą drogę, więc to nie powinno być nic wielkiego.

pietromenna
źródło
Masz rację! To jest bezpłatny koncert. Ale mam pewną korzyść, ponieważ jestem jednym z zaawansowanych użytkowników, o których mówiłem. : P To, co mówisz, ma jednak sens i doceniam twoją odpowiedź!
cyberbit
4

Zasadniczo istnieją dwa rodzaje dokumentacji: dokumentacja techniczna twojego kodu (klasy, jednostki itp.) Oraz sposób działania nowych funkcji i implementacji w kodzie i dokumentacji użytkownika. IMO, dokumentacja techniczna jest koniecznością, szczególnie jeśli tworzenie oprogramowania nie jest twoim pełnym etatem. Spędzam na tym dużo czasu, ponieważ mogę mieć duże luki w pisaniu kodu z powodu zobowiązań życiowych.

Uważam, że dokumentacja użytkownika jest dobra, ale nie niezbędna. Oczywiście zależy to od złożoności aplikacji, znajomości bazy użytkowników z wykorzystaniem komputerów i systemów w omawianym obszarze tematycznym - w twoim przypadku wygląda na to, że Twoi klienci mogą zrozumieć, jak działają nowe funkcje. Istnieje szkoła myślenia, która twierdzi, że dobre wrażenia użytkownika i dobry interfejs użytkownika wymagają minimalnej dokumentacji użytkownika.

Ponadto, jeśli masz ograniczony czas i naprawdę odczuwasz presję na tworzenie dokumentacji zgodnie z twoimi sugestiami, możesz zrobić kilka krótkich filmów przedstawiających tylko nowe funkcje. To da ci trochę czasu na napisanie faktycznej dokumentacji, a następnie na wypełnienie mniej ważnych szczegółów.

Niektóre wskazówki marketingowe mogą pozwolić ci zrównoważyć oczekiwania użytkowników i nadal wzmocnić swoją markę. To naprawdę zależy od rodzaju aplikacji i dotychczasowego przepływu pracy, ale możesz mieć ekran powitalny do nowej wersji, aw aplikacji możesz wyświetlać filmy, podając linki lub odtwarzając filmy w aplikacji.

John Kouraklis
źródło
3

Aby dodać coś nie tylko do tego konkretnego przykładu, ale do ogólnego przepływu pracy:

Dokumentacja może być twoja definition of done, ale dokumentacja jest przez większość czasu poza minimalny opłacalny produkt (MVP).

Klient ma zawsze nie tylko rację. Jeśli jest to produkt komercyjny, wydanie może mieć dużą wartość biznesową i jest absolutnym priorytetem.

Właściciel określa wartość biznesową (którą, jak sądzę), więc co jest bardziej wartościowe jako produkt dla Twoich klientów?

Czy są też jakieś ryzyko uwalniające się bez dokumentacji?

Na przykład konkurencja ; Jeśli konkurencja wypuści tę super funkcję przed tobą, możesz po prostu stracić niektórych użytkowników.

Zadaj sobie lub właścicielowi produktu te pytania, a Twoja odpowiedź będzie jasna.

Timmetje
źródło
2

Nowe funkcje sprawiają, że starzy użytkownicy są zadowoleni. Dobra dokumentacja zaprasza nowych użytkowników. Na czym powinieneś się skoncentrować, zależy od tego, czego bardziej potrzebujesz. Wskazałeś, że baza użytkowników jest zdrowa, więc nowe funkcje mogą poczekać. Mówiąc jako stary użytkownik, lubię też dobrą dokumentację. Fajna rzecz w open source: starzy użytkownicy dodają własne funkcje.

candied_orange
źródło
2
Dobra dokumentacja zaprasza nowych użytkowników tylko wtedy, gdy dokumentuje coś, co faktycznie istnieje.
Robert Harvey
@robertharvey Wskazano aktualną bazę użytkowników. Tak więc przypuszczam, że używają jakiejś niewydanej wersji beta.
candied_orange
Istnieje istniejące wydanie, które z brzmienia jest uważane za stabilne, mimo że jest niedokumentowane.
jpmc26
2

Nie wyjaśniłeś w swoim pytaniu i prawdopodobnie nie Twoim użytkownikom konsekwencje tych wyborów. Ile czasu spędzasz na obsłudze użytkowników? Czy dodatkowa dokumentacja skróci czas poświęcony na wsparcie lub zwiększy sprzedaż? Jaka jest twoja korzyść z robienia dokumentacji?

Twoi użytkownicy chcą nowych funkcji w stosunku do dokumentacji, ale czy zdają sobie sprawę, że może nastąpić spadek twojej dostępności w celu zapewnienia wsparcia, naprawiania błędów, poprawek wydań itp.?

Jeśli nie zadałbym sobie trudu przeczytania instrukcji, gdy wszystko, co muszę zrobić, to wysłać Ci wiadomość e-mail z moim pytaniem, dlaczego miałbym kiedykolwiek chcieć dokumentacji dotyczącej nowych funkcji?

JeffO
źródło
-1

Jeśli pakiet jest gotowy do wydania, zwolnij klienta / klienta i rozpocznij pracę nad dokumentacją. Dobrze jest komunikować się z klientem, gdy udostępnisz dokumentację, która pomoże mu zrozumieć wdrożone funkcje.

Sairamys
źródło