Что хороший путь состоит в том, чтобы обучить сотрудников о том, как использовать программное обеспечение, которое Вы только что создали? [закрытый]

Немного идей:

У Вас есть некоторые консервированные сценарии пошаговой демонстрации? Не знайте, применимо ли это для Вашего продукта, но я создал довольно существенный продукт пара несколько лет назад и разработал некоторые учебные модули, что они будут работать через - ничто долго, возможно, вершины 15 минут для каждого.

Я соединил слайдовую презентацию, которые поражают выделения для разговора о том, что она делает. Я провел бы приблизительно 10 минут, проходя выделения приложения для ознакомления их с ним прежде, чем сделать практический материал.

Люди не склонны читать материал, к сожалению. Вы могли поместить часы и часы в документ справки, и все еще найти, что люди просто не читают его или скользят по нему. Это может быть печально. Ожидайте, что отвечает, что находятся в Вашем руководстве, будет тема вопросов, которые будут иметь Ваши пользователи.

Разбейте любое обучение, которое Вы делаете в управляемые блоки. Я был к учебным маневрам полного дня прежде, и тренер повредил их в короткие части и помог мне получить учебную тему в моей голове. Вы не хотите к дампу на них, потому что их глаза замнут, и Вы потеряете их.

В конечном счете, если Ваше приложение очень применимо, это должен быть кусок пирога. Если это не будет, то Вы узнаете. Вы могли бы хотеть иметь несколько человек, которых Вы знаете, пробегает Ваше обучение заранее и дают Вам конструктивную критику на нем. Лучше для фиксации его, прежде чем большая группа обучена. Вы будете более уверены в продукте и учебных материалах (независимо от того, что они), и у Вас, вероятно, будет лучший учебный опыт.

Если применимо предоставьте справку/Wiki/часто задаваемые вопросы онлайн им. Иногда это полезно.

Всего наилучшего

Я буду изучать что-то вроде этого также за следующие несколько месяцев.

В Вашем случае надо надеяться, UI уже подвергся тестированию приемлемости для пользователя. Вы говорите, что работаете в небольшой компании. Действительно ли возможно заставить наименее технически подкованного человека там испытывать его? На самом деле заставьте их испытывать его без любого руководства от себя за исключением вопросов, которые они задают. Зарегистрируйте вопросы и удостоверьтесь, что Ваше руководство пользователя отвечает на них.

Главным для меня была бы логика и непротиворечивость. Если рабочий процесс приложения имеет отношение логически к задаче, это было разработано для выполнения, и UI последователен, необходимо быть в порядке.

Создайте страницу Wiki для описания использования системы. Предоставление прав редактирования пользователям Вашей системы позволяет пользователям:

• обновите документацию для исправления любых ошибок в первоначальной версии документации,
• совместно используйте любые подсказки относительно использования, которое они, возможно, нашли.
• совместно используйте необычное использование для системы, о которой Вы не могли думать.
• функции запроса.
• обеспечьте любые обходные решения, которые они нашли при ожидании новой функциональности, которая будет реализована.

Необходимо было действительно решить эту проблему намного ранее в цикле разработки, чем Вы делаете.

По моему мнению, идеальный сценарий для корпоративного программного обеспечения является тем, где пользователи разрабатывают свое собственное приложение и пишут их собственную документацию, и я всегда пытаюсь бороться за это. Необходимо было идентифицировать ключевых пользователей вначале и разработать систему с ними (я пытаюсь заставить своих пользователей делать основной дизайн экранов и разметки меню в Excel или подобный - затем я реализую это как статические страницы и обзор прежде, чем записать строку значительного кода, очевидно, они не получат право дизайна в первый раз, но это - задание для руководства их - и идеально способом, где они думают, что придумали корректные проектные решения, не Вас :-)).

Эти пользователи должны затем записать пользовательскую документацию из этого дизайна параллельно с Вами разрабатывающий систему. Я никогда не видел документацию справки, поставленную отделом ИТ / компания-разработчик программного обеспечения, используемая значительно в корпоративной установке. Вместо этого то, что происходит, является пользователями, будет создавать их собственную папку примечаний и обходных решений и относиться к этому (на самом деле, если Вы когда-либо сделаете системный анализ для замены существующей системы, находящей, что 'пользовательская библия' для старой системы является ключевой стратегией). Получение пользователей записать их собственную документацию заранее просто использует то, что произойдет так или иначе - но это значительно легче, если пользователи чувствуют, что у них есть владение системы, потому что они разработали его сами во-первых.

Конечно, для этого подхода нужно обязательство и время от Ваших пользователей, но обычно дело не в этом трудно продавание. Это банально, но работающий помощником, таким образом, пользователи могут разработать там собственную систему, а не как третье лицо, чтобы дать им, система в значительной степени гарантирует приемлемость для пользователя.

Поскольку Вы - то, где Вы, Вы слишком опаздываете для реализации все это, но если можно определить несколько сильно желающие, ключевые, пользователи и заставить время от них писать их собственную документацию затем, это было бы хорошим перемещением. Если Вы не можете добраться даже, что затем необходимо идентифицировать евангелиста, которого можно обучить, чтобы быть 'ведомственным' экспертом и дать им 110% энергии поддерживать их.

Нижняя строка - то, что приемлемость для пользователя основана на восприятии, и это не обязательно коррелирует с тем, насколько применимый система на самом деле. Необходимо сфокусироваться на психологии группы этого так же как действительность системы, которая имеет тенденцию быть коварной для разработчиков, поскольку мы являемся намного более фактически базирующимися, чем большинство людей.

Судите несколько пользователей сначала, один или два в небольшой компании. Главным образом смотрите, справка как можно меньше. Это говорит Вам, какие потребности быть зафиксированным, и это закладывает основу опытного пользователя - таким образом, Вы не "учебное узкое место" больше.

Поверните базовые требования/использование cases/storycards в HowTo / пошаговые демонстрации для Вашей документации.

Для общедоступного обучения подготовьте 10.. 15-минутная презентация (просто это, не больше!), который покрывает ключевые понятия, которые пользователи абсолютно должны понять, чем шоу Ваши базовые пошаговые демонстрации. Зарезервируйте дополнительное время для вопросов о том, как решить различные задачи.

Думайте как пользователь, не как техник: - никто не заботится, является ли это база данных SQL, и Вы провели много времени для разбираний в механизмах блокировки. Они действительно заботятся о, "делает это замедляет меня", и "делает что-то, плохо происходят, когда два человека делают это одновременно". Наше задание состоит в том, чтобы заставить сложные вещи выглядеть легкими.

Это может помочь поместить документацию относительно интранет в доступной для редактирования форме - страница "комментарии" или Wiki, возможно. И/или поднятый "ошибка Wiki" для сообщений об ошибках и вспышек - где Вы или Ваши пользователи можете быстро добавить рекомендации, обходные решения и причины чего-либо, что не идет как ожидалось.

Скорее затем обучите всех тех людей, я выбрал несколько суперпользователей (по крайней мере один человек от каждого отдела) и обучил их преподавать остальную часть сотрудников. Конечно, жизненно важно, чтобы те суперпользователи были

• хорошо уважаемый в их отделах
• способный преподавать
• как приложение

Простой способ гарантировать, чтобы им понравилось приложение, состоит в том, чтобы иметь их для определения способа, которым это должно работать :-). Так как они должны работать с этим приложением каждый день, они - главные заинтересованные стороны, независимо от того, что указывает управление