deployment - temas - tecnicas para capacitar al personal
¿Cuál es una buena forma de capacitar a los empleados sobre cómo usar el software que acaba de crear? (7)
Crea una página wiki para describir el uso de tu sistema. Dar derechos de edición a los usuarios de tu sistema permite a los usuarios:
- actualizar la documentación para corregir cualquier error en la versión inicial de la documentación,
- comparte cualquier consejo sobre el uso que puedan haber encontrado.
- compartir usos inusuales para el sistema que quizás no haya pensado.
- funciones de solicitud
- proporcione las soluciones provisionales que hayan encontrado mientras esperan que se implemente la nueva funcionalidad.
Estoy trabajando en una empresa pequeña y faltan semanas para implementar una aplicación web que se usará mucho. Todos en un lugar tendrán que aprender a usarlo, y aunque creo que es bastante fácil e intuitivo, puedo ser parcial.
He escrito una guía de ayuda con muchas capturas de pantalla que están disponibles en cada página, pero aún así tendré que entrenar a todos. ¿Cuál es la mejor manera? ¿Cómo das un paso atrás y explicas el código en el que has estado trabajando durante semanas?
Pocas ideas:
¿Tiene algunos escenarios de recorrido enlatados? No sé si es aplicable a su producto, pero construí un producto bastante sustancial hace un par de años y desarrollé algunos módulos de capacitación que trabajarían para ellos: nada largo, tal vez 15 minutos como máximo para cada uno.
Arreglé una presentación de diapositivas que resalta los aspectos más destacados para hablar sobre lo que hace. Pasaría unos 10 minutos revisando los aspectos más destacados de la aplicación para familiarizarlos con ella antes de hacer las cosas prácticas.
La gente no tiende a leer cosas, desafortunadamente. Puede incluir horas y horas en un documento de ayuda, y aún así descubrir que la gente simplemente no lo lee ni lo hojea. Eso puede ser frustrante. Espere que las respuestas que están en su guía sean el tema de las preguntas que tendrán sus usuarios.
Rompe cualquier entrenamiento que hagas en trozos manejables. He estado en un ejercicio de entrenamiento de un día completo y el capacitador lo dividió en trozos cortos y me facilitó el tema de la capacitación en mi cabeza. No desea volcar datos en ellos porque sus ojos se desvanecerán y los perderá.
En última instancia, si tu aplicación es muy útil, debería ser pan comido. Si no es así, lo descubrirás. Es posible que desee contar con algunas personas que conozca que realicen su capacitación con anticipación y que le den críticas constructivas al respecto. Es mejor arreglarlo antes de que el gran grupo esté entrenado. Tendrá más confianza en el producto y los materiales de capacitación (sean lo que sean) y probablemente tenga una mejor experiencia de capacitación.
Si corresponde, proporcione una ayuda en línea / wiki / faq para ellos. A veces eso es útil.
¡La mejor de las suertes!
Pruebe primero con algunos usuarios, uno o dos en una empresa pequeña. Sobre todo mira, ayuda lo menos posible. Esto le indica qué debe solucionarse y crea una base de usuarios experimentados, por lo que ya no es el "cuello de botella del entrenamiento".
Convierta los requisitos principales / casos de uso / historiales en HowTo / tutoriales para su documentación.
Para una capacitación pública, prepare una presentación de 10.15 minutos (¡solo eso, no más!) Que cubra los conceptos clave que los usuarios deben comprender absolutamente, que mostrar sus recorridos principales. Reserve tiempo extra para preguntas sobre cómo resolver varias tareas.
Piense como usuario, no como técnico: a nadie le importa si se trata de una base de datos SQL y usted pasó mucho tiempo para tener los mecanismos de bloqueo correctos. Se preocupan por "¿me frena?" Y "¿algo malo sucede cuando dos personas hacen eso al mismo tiempo?". Nuestro trabajo es hacer que las cosas complicadas parezcan fáciles.
Puede ser útil colocar la documentación en la intranet de forma editable: página "comentarios" o wiki tal vez. Y / o ponga un "wiki de errores" para los mensajes de error y los avisos - donde usted o sus usuarios pueden agregar rápidamente recomendaciones, soluciones y razones para cualquier cosa que no vaya como se esperaba.
Realmente debería haber abordado este problema mucho antes en el ciclo de desarrollo de lo que está haciendo.
En mi opinión, el escenario ideal para el software corporativo es aquel en el que los usuarios diseñan su propia aplicación y escriben su propia documentación, y siempre intento esforzarme por lograrlo. Debes haber identificado a los usuarios clave desde el principio y diseñar el sistema con ellos (intento que mis usuarios hagan diseños de pantalla básicos y diseños de menú en Excel o similar, luego implemento eso como páginas estáticas y reviso antes de escribir una línea de código significativo , obviamente no obtendrán el diseño correcto la primera vez, pero es su trabajo guiarlos , e idealmente de una manera en la que crean que tuvieron las decisiones de diseño correctas, no usted :-)).
Estos usuarios deben escribir la documentación del usuario de este diseño en paralelo con el desarrollo del sistema. Nunca he visto la documentación de ayuda entregada por un departamento de TI / empresa de software utilizada significativamente en un entorno corporativo. En cambio, lo que ocurre es que los usuarios crearán su propia carpeta de notas y soluciones alternativas y se refieren a esto (de hecho, si alguna vez haces un análisis del sistema para reemplazar un sistema existente, encontrar la ''user-bible'' para el sistema anterior es estrategia clave). Hacer que los usuarios escriban su propia documentación por adelantado simplemente aprovecha lo que sucederá de todos modos, pero esto es mucho más fácil si los usuarios sienten que tienen la propiedad del sistema porque lo diseñaron ellos mismos en primer lugar.
Por supuesto, este enfoque requiere compromiso y tiempo de sus usuarios, pero en general no es tan difícil de vender. Es trillado, pero trabajar como facilitador para que los usuarios puedan desarrollar su propio sistema en lugar de un tercero para darles un sistema garantiza la aceptación del usuario.
Como está donde está, ya es demasiado tarde para implementar todo esto, pero si puede identificar a un par de usuarios interesados y clave y obtener tiempo de ellos para escribir su propia documentación, sería una buena decisión. Si no puedes obtener eso, entonces necesitas identificar a un evangelista a quien puedas entrenar para que sea el experto ''departamental'' y darles un 110% de tu energía para apoyarlos.
La conclusión es que la aceptación del usuario se basa en la percepción, y esto no se correlaciona necesariamente con la utilidad real de un sistema. Debes enfocarte tanto en la psicología grupal como en la realidad del sistema, lo que tiende a ser complicado para los desarrolladores, ya que estamos mucho más basados en hechos que la mayoría de las personas.
También estaré investigando algo como esto en los próximos meses.
En su caso, es de esperar que la interfaz de usuario ya se haya sometido a las pruebas de aceptación del usuario. Dices que trabajas en una empresa pequeña. ¿Es posible conseguir que la persona menos conocedora de la tecnología esté allí para probarlo? De hecho, haz que lo prueben sin ninguna guía tuya, excepto por las preguntas que hacen. Documente las preguntas y asegúrese de que su guía de usuario las responda.
Lo principal para mí sería la lógica y la coherencia. Si el flujo de trabajo de la aplicación se relaciona lógicamente con la tarea para la que se diseñó y la interfaz de usuario es consistente, debería estar bien.
Primero intente evitar el entrenamiento:
Realice pruebas de usabilidad para garantizar que su aplicación web sea intuitiva. Las pruebas de usabilidad son un aspecto muy importante de las pruebas y, a menudo, se ignoran. La forma en que ve su sistema probablemente será muy diferente a como ve un nuevo usuario su sistema.
También agregue ayuda contextual tan a menudo como sea posible. Por ejemplo, cuando sobrevivo una etiqueta en desbordamiento de pila, sé exactamente qué hará clic, porque me dice.
También esto puede parecer obvio, pero asegúrese de vincular su documentación con el sitio mismo. La gente puede no pensar en buscar en su documentación a menos que esté justo frente a sus ojos.
Acerca de la documentación de capacitación:
Intente dividir su material en cómo usarían sus usuarios el sistema. Personalmente me gusta la opción "senderos" que Sun creó para sus tutoriales de Java . En este tutorial puede hacer varias cosas, y puede elegir a qué sendero le gustaría ir.
Admita lecturas aleatorias en su documentación de ayuda. Si tienen una tarea que hacer en su aplicación web, entonces deberían poder obtener ayuda sin leer un montón de contenido no relacionado.
Asegúrese de que su documentación se pueda buscar.
Acerca de las sesiones de entrenamiento reales:
Si realmente está realizando sesiones de capacitación, evite explicar todo lo relacionado con su código. No necesita saber sobre el motor para conducir un automóvil.
Intenta dividir tus sesiones de entrenamiento en aspectos muy específicos de tu sistema. Si solo tiene 1 sesión de capacitación disponible, solo haga un caso de uso especializado de su sistema + la descripción general del sistema. Consulte las diferentes partes de la documentación donde pueden obtener ayuda.
Dejar que la comunidad se ayude a sí misma:
No importa cuán extensa sea su documentación, siempre tendrá casos que no cubrió. Es por eso que es una buena idea tener un foro disponible para todos los usuarios del sistema. Permitir que se hagan preguntas unos a otros.
Puede revisar este foro y agregar contenido a su documentación según sea necesario.
También podría abrir una wiki para la documentación en sí misma, pero esto probablemente no sea deseable si su base de usuarios no es muy grande.
En lugar de entrenar a todas esas personas, he elegido a algunos superusuarios (al menos una persona de cada departamento) y los he capacitado para enseñar al resto de los empleados. Por supuesto, es vital que esos superusuarios sean
- muy respetado en sus departamentos
- capaz de enseñar
- como la aplicación
La manera fácil de asegurarse de que les gusta la aplicación es hacer que definan la forma en que debería funcionar :-). Dado que deben trabajar con esta aplicación todos los días, son los principales interesados, sin importar qué estados de gestión