Я работаю над проектом уже пару лет, и я начинаю собирать приличную базу пользователей. Я создал страницу проекта с некоторой базовой документацией, но на данный момент это не намного больше, чем FAQ. Я знаю, что мне нужно улучшить его, чтобы он был более информативным как для новых, так и для опытных пользователей, и это будет следующим в моем списке дел для следующего выпуска.
Однако в следующем выпуске есть функции, которые пользовательская база стремится получить. Я готов выпустить его прямо сейчас, он упакован и готов к работе. Мне просто нужно развернуть его в соответствующих службах распространения.
К точке. Функции важны для моих пользователей, но документация важна для меня. Должен ли я ждать релиза до того, как переписать документацию? Моя нынешняя база пользователей достаточно подкована, чтобы понять, как использовать новые функции, так что это не то, что меня беспокоит. Может потребоваться пара недель, чтобы закончить документы, так как у меня было ограниченное свободное время для работы над этим проектом, но сообщество жарило бы меня на вертеле, если бы я заставил их ждать дольше.
Прав ли клиент в этом сценарии? Должна ли фантастическая, простая функция для существующих пользователей иметь приоритет над надежной документацией для новых пользователей?
Обновление: Ух, так много отличных, качественных ответов! Вы действительно помогли мне лучше понять, как я должен взаимодействовать и поддерживать проект и его пользователей. Бесконечно благодарен!
источник
Ответы:
Просто: выпустите бета-версию! Затем, когда документация будет завершена, сделайте окончательный выпуск новой версии.
Если у вас есть пользователи, желающие опробовать новинку, то обязательно воспользуйтесь этим. Вы будете получать отчеты об ошибках, вы, вероятно, будете получать вопросы сообщества о сложных моментах, чтобы вы знали, где сосредоточиться на документации и т. Д. Вы также можете настроить некоторые вещи на основе отзывов пользователей, которые могут повлиять на документацию.
В основном все выигрывают.
Одна из причин не делать ранний выпуск заключается в том, что если вы думаете, что ваши пользователи не будут воспринимать «бета-версию», то вам следует дважды подумать о том, чтобы сделать это, но, исходя из того, что вы пишете, звучит так, как будто они были бы рады этому.
Другой причиной может быть, если есть технические трудности с выпуском бета-версии с использованием любых каналов выпуска, которые вы используете. Тогда это может быть больше хлопот, чем стоит делать отдельные бета и финальные версии. Если вы думаете, что ваше программное обеспечение завершено, то в этом случае я бы положился на ранний выпуск, обновлю документацию, когда это будет сделано. В противном случае есть риск, что документация будет задержана, а затем весь выпуск будет задержан, или вы в конечном итоге выпустите без окончательной документации, так что просто сделайте это сейчас.
источник
Если я вас правильно понял, вы делаете этот проект в свободное время и без денег . Если это так, то, пожалуйста, делайте то, что заставляет вас чувствовать себя лучше (пользователи ждут, документируйте свое время). Вы не должны чувствовать давление со стороны ваших «пользователей». Многие люди писали об этом в Интернете (крупные авторы и участники FLOSS, которые чувствовали давление).
Но, если вам платят или вы получаете какую-то выгоду, делайте то, что хотят ваши пользователи. Это означает, что делайте все, что лучше для ваших клиентов или пользователей , в этом случае просто выпустите это и зарегистрируйте свое время. Вы сказали, что они найдут дорогу, так что это не должно иметь большого значения.
источник
В целом, существует два типа документации: техническая, которая документирует ваш код (классы, блоки и т. Д.) И как новые функции могут работать и реализовываться в коде и пользовательской документации. ИМО, техническая документация обязательна, особенно если разработка программного обеспечения не является вашей постоянной работой. Я трачу много времени на это, поскольку у меня могут быть большие промежутки между написанием кода из-за жизненных обязательств.
Пользовательская документация хороша, но я не считаю ее необходимой. Конечно, это зависит от сложности приложения, от знакомства пользователя с использованием компьютеров и систем в обсуждаемой предметной области - в вашем случае, похоже, ваши клиенты могут понять, как работают новые функции. Существует школа мысли, утверждающая, что хороший пользовательский опыт и хороший пользовательский интерфейс требуют минимальной пользовательской документации.
Кроме того, если ваше время ограничено, и вы действительно чувствуете необходимость разработки документации, как вы предлагаете, вы можете сделать пару коротких видеороликов, представляющих только новые функции. Это даст вам некоторое время, чтобы написать актуальную документацию, а затем вы сможете заполнить менее важные детали.
Некоторые маркетинговые советы могут помочь вам сбалансировать ожидания пользователей и при этом повысить ваш бренд. Это действительно зависит от типа приложения и созданного вами рабочего процесса, но у вас может быть экран приветствия для вашей новой версии, и в приложении вы можете показывать видео либо путем предоставления ссылок, либо путем воспроизведения видео внутри приложения.
источник
Просто чтобы добавить что-то не только для этого конкретного примера, но и для общего рабочего процесса:
Документация может быть вашей
definition of done
, но в большинстве случаев документация выходит за рамки минимально жизнеспособного продукта (MVP).Клиент не только всегда прав. Если это коммерческий продукт, выпуск может иметь большую деловую ценность и является абсолютным приоритетом.
Владелец определяет бизнес-ценность (которую я считаю), так что же является более ценным продуктом для ваших клиентов?
Также есть какие-либо риски выпуска без документации?
Например соревнование ; Если соревнование выпустит эту суперфункцию перед вами, вы можете просто потерять некоторых пользователей.
Задайте себе или владельцу продукта эти вопросы, и ваш ответ будет ясен.
источник
Новые функции делают старых пользователей счастливыми. Хорошая документация приглашает новых пользователей. То, на чем вы должны сконцентрироваться, зависит от того, в чем вы больше нуждаетесь. Вы указали, что база пользователей работоспособна, поэтому новые функции могут подождать. Говоря как старый пользователь, я также люблю хорошую документацию. Хорошая вещь об открытом исходном коде: старые пользователи добавляют свои функции.
источник
Вы не разъяснили в своем вопросе и, вероятно, не для своих пользователей последствия этого выбора. Сколько времени вы тратите на поддержку пользователей? Уменьшит ли дополнительная документация количество времени, которое вы тратите на поддержку, или увеличите продажи? В чем вам преимущество делать документацию?
Вашим пользователям нужны новые функции, а не документация, но понимают ли они, что ваша доступность может снизиться, чтобы обеспечить поддержку, исправлять ошибки, выпускать исправления и т. Д.?
Если я не удосужился прочитать инструкции, когда все, что мне нужно сделать, это отправить вам электронное письмо со своим вопросом, зачем мне когда-либо требовать документацию по новым функциям?
источник
Если пакет готов к выпуску, выпустите его для клиента / клиента и начните работу над документацией. Хорошо пообщаться с клиентом, когда вы поделитесь документацией, которая поможет им понять развернутые функции.
источник