Випустити перший або спершу документувати?

Я працюю над проектом вже пару років, і я починаю збирати гідну базу користувачів. Я створив сторінку проекту з базовою документацією, але це справді не набагато більше, ніж FAQ на даний момент. Я знаю, що мені потрібно вдосконалити його, щоб він був більш інформативним як для нових, так і для користувачів енергії, і це вже в моєму списку справ для наступного випуску.

Однак наступний випуск має функції, які користувачеві бажання отримати. Я готовий випустити його зараз, він упакований і готовий до роботи. Мені просто потрібно розгорнути його у відповідні служби дистрибуції.

До суті. Функції важливі для моїх користувачів, але для мене важлива документація. Чи варто чекати, коли вийдуть, поки я не перепишу документацію? Моя поточна база користувачів достатньо розумна, щоб зрозуміти, як користуватися новими функціями, тому це не те, що я хвилююся. Щоб закінчити документи, може знадобитися кілька тижнів, оскільки у мене обмежений вільний час для роботи над цим проектом, але громада могла б обсмажити мене на косі, якби я змусив їх більше чекати.

Чи правильно у цьому сценарії замовник? Чи має фантастична, прямолінійна функція для існуючих користувачів віддати перевагу надійній документації для нових користувачів?

Оновлення: Вау, так багато чудових, якісних відповідей! Ви дійсно допомогли мені краще зрозуміти, як я повинен взаємодіяти та підтримувати як проект, так і його користувачів. Завдяки мільйонів!

Просто: випустіть бета-версію! Після завершення документації виконайте остаточний випуск нової версії.

Якщо у вас є користувачі, які бажають спробувати нові речі, то будь-якими способами скористайтеся цим. Ви отримаєте звіти про помилки, ви, ймовірно, отримаєте питання спільноти про складні моменти, щоб ви знали, де зосередитися на документації тощо. Ви також можете налаштувати деякі речі на основі відгуків користувачів, які можуть вплинути на документацію.

В основному, всі виграють.

Однією з причин не робити дострокового випуску є те, що якщо ви думаєте, що ваші користувачі не сприйматимуть "бета-версію", то вам слід подумати над цим двічі, але проходити по тому, що ви пишете, звучить так, що вони будуть із цим задоволені.

Іншою причиною може бути, якщо є технічні труднощі щодо створення бета-версії з використанням будь-яких каналів випуску, якими ви користуєтесь. Тоді це може бути більше клопоту, ніж варто робити окремі бета-версії та остаточні версії. Якщо ви вважаєте, що ваше програмне забезпечення завершено, то в цьому випадку я спершусь на достроковий випуск, оновіть документацію, коли це буде зроблено. Інакше є ризик затримки документації, і тоді весь випуск затягується, або ви все одно випустите без остаточної документації, так що просто зробіть це зараз.

Якщо я маю право на те, ти займаєшся цим проектом у вільний час і без грошей . Якщо це так, то, будь ласка, зробіть те, що відчуває вас краще (користувачі чекають, документуйте про ваш час). Ви не повинні відчувати тиску з боку своїх "користувачів". Багато людей писали про це в Інтернеті (великі автори та автори FLOSS, які відчували тиск).

Але якщо вам платять гроші або ви отримуєте якусь вигоду, будь ласка, робіть те, що хочуть ваші користувачі. Це означає зробити все, що найкраще для ваших клієнтів чи користувачів , у такому випадку просто відпустіть його та задокументуйте свій час. Ви сказали, що вони знайдуть свій шлях, тому це не повинно бути великою справою.

Загалом існує два типи документації: технічна, на яку документи входить ваш код (класи, одиниці тощо), і як нові функції можуть працювати та впроваджуватися в код та документацію користувача. IMO, технічна документація є обов'язковою, особливо якщо розробка програмного забезпечення не є вашим повним робочим часом. Я витрачаю на це багато часу, оскільки у мене можуть бути великі проміжки в написанні коду через життєві зобов’язання.

Документацію для користувача добре мати, але я не важливо, я вважаю. Звичайно, це залежить від складності програми, ознайомлення з базою користувачів із використанням комп’ютерів та систем у обговорюваній тематичній області - у вашому випадку схоже, що ваші клієнти можуть зрозуміти, як працюють нові функції. Існує школа роздумів, яка стверджує, що для хорошого користувальницького досвіду та хорошого користувальницького інтерфейсу потрібна мінімальна документація користувача.

Крім того, якщо ваш час обмежений, і ви дійсно відчуваєте тиск на розробку документації, як ви пропонуєте, ви можете зробити кілька коротких відеороликів, де представлені лише нові функції. Це дозволить вам придбати деякий час, щоб написати фактичну документацію, і тоді ви зможете заповнити менш важливі дані.

Деякі поради щодо маркетингу можуть допомогти вам збалансувати очікування користувачів і все ж підвищити свій бренд. Це дійсно залежить від типу програми та робочого процесу, який ви створили до цих пір, але у вас може бути екран вітання до вашої нової версії, і всередині програми ви зможете показувати відео, надаючи посилання або відтворюючи відео всередині додатка.

Просто додати щось не лише для цього конкретного прикладу, але і для загального робочого процесу:

Документація може бути вашою definition of done, але документація більшу частину часу перевищує мінімальний життєздатний продукт (MVP).

Замовник завжди має рацію. Якщо це комерційний продукт, випуск може бути великою діловою цінністю і є абсолютним пріоритетом.

Власник визначає цінність бізнесу (який ви вважаєте), тож що цінніше як продукт для ваших клієнтів?

Чи є ризики звільнення без документації?

Наприклад конкуренція ; Якщо конкуренція випустить цю суперфункцію перед вами, ви просто можете втратити деяких користувачів.

Задайте собі питання або власнику товару ці питання, і ваша відповідь буде зрозумілою.

Нові функції роблять старих користувачів щасливими. Хороша документація запрошує нових користувачів. На чому слід зосередитися, залежить від того, що вам більше потрібно. Ви вказали, що база користувачів корисна, тому нові функції можуть чекати. Якщо говорити як старий користувач, мені подобається і хороша документація. Приємна річ у відкритому коді: старі користувачі додають свої особливості.

Ви не уточнили у своєму запитанні і, мабуть, не для своїх користувачів наслідки цих виборів. Скільки часу ви витрачаєте на підтримку користувачів? Чи зменшить додаткова документація кількість часу, який ви витрачаєте на підтримку, або збільшить продажі? Яка для вас перевага в документації?

Ваші користувачі хочуть нових функцій над документацією, але чи розуміють вони, що може зменшитися ваша доступність, щоб забезпечити підтримку, виправити помилки, виправити виправлення тощо?

Якщо я не намагався прочитати інструкції, коли все, що мені потрібно зробити, це надіслати вам електронний лист із моїм запитанням, чому я взагалі хочу отримати документацію щодо нових функцій?

Якщо пакет готовий до випуску, відпустіть клієнта / клієнта і починайте роботу над документацією. Добре повідомте клієнту, коли ви поділитесь документацією, яка допоможе їм зрозуміти розгорнуті функції.