Zwolnić pierwszy czy najpierw dokument?

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!

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.

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.

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.

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.

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.

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?

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.