Share
Soy parte del equipo que recientemente lanzó una aplicación web llamada Dunked. Dunked es un portafolio en línea gratuito y fácil de usar para tipos creativos. A partir de mayo de 2013, estamos en beta pública; continuar desarrollando funciones y realizando mejoras incrementales basadas en los comentarios de los usuarios.
En este artículo, voy a discutir algunas de las razones por las que creo que un lanzamiento beta es importante para el desarrollo de su producto. También discutiré cómo nosotros, en Dunked, nos ocupamos del proceso de monitoreo y recopilación de comentarios de los usuarios. Por último, analizaré cómo avanzamos en la implementación de cambios basados en los comentarios de los usuarios a medida que continuamos desarrollando el producto..
Personalmente creo que tener un lanzamiento beta es una gran idea. Por supuesto, no es recomendable lanzar algo que esté plagado de errores. También es una mala idea lanzar un producto que no esté listo para el consumo público. Es mucho mejor lanzar el producto una vez que tenga las características principales necesarias y esté libre de errores.
Google es probablemente una de las compañías más conocidas que inicialmente ofrece productos como una versión beta. Gmail es un gran ejemplo. Gmail estuvo en beta privada desde abril de 2004 hasta febrero de 2007, cuando se puso a disposición del público en general. Incluso entonces, todavía tenía la etiqueta "beta". Gmail no fue oficialmente retirado de la versión beta por otros dos años. Tenerlo como un producto beta permitió a los ingenieros de Google continuar mejorando Gmail basándose en los datos del usuario y probando varias adiciones.
Lo perfecto no existe en el desarrollo de software.
Reconozco que puede ser difícil dejar que los usuarios vean un producto antes de que creas que es perfecto. Pero lo perfecto no existe en el desarrollo de software. Siempre tendrá que recorrer un producto en un esfuerzo constante para realizar mejoras. Creo que al lanzar una versión beta de un producto, se pone en una posición para ofrecer a los usuarios lo mejor que ellos desean. Es posible que tenga suposiciones que son totalmente erróneas. Al operar en beta, puede girar rápidamente para mejorar su producto a las necesidades de sus usuarios.
Al llevar a Dunked al lanzamiento, sentimos que era crucial identificar y establecer las diferencias entre las características imprescindibles y las características agradables de tener. Las características imprescindibles son las características que dan forma, y esencialmente, a su producto. Los elementos imprescindibles son las funciones en las que debes enfocar tu tiempo antes del lanzamiento. Una vez que hayas completado tu lista de must-haves, inicia. Después del lanzamiento, puede hacer frente a los simpáticos, corregir cualquier error que surja y realizar ajustes en función de los comentarios de los usuarios..
A medida que continuamos construyendo, los comentarios de los usuarios son como el oro. Los usuarios nos dicen cuando estamos haciendo las cosas bien; cuando estamos haciendo las cosas mal; y cuando estamos siendo simplemente estúpidos. Debido a que los comentarios de los usuarios son tan valiosos, es importante que tenga un sistema implementado antes del lanzamiento para que pueda monitorear y recopilar comentarios. También debe establecer un sistema para actuar sobre la retroalimentación que reciba.
Monitorear y recopilar comentarios no es una tarea fácil. Los usuarios son todos diferentes, con diferentes preferencias en cuanto a cómo expresan sus opiniones. Por lo tanto, necesita tener un sistema para monitorear activamente una variedad de canales de retroalimentación. Hemos optado por utilizar Desk. Sirve como nuestro centro central de recopilación de todos los tweets dirigidos a nuestra cuenta de Twitter @DunkedHQ, comentarios en nuestra página de Facebook y correos electrónicos enviados a través de nuestro formulario de contacto de soporte (este formulario está vinculado desde la propia aplicación). Me permite iniciar sesión en una única ubicación, donde puedo revisar y responder a los comentarios en el orden en que se enviaron. Esto es un ganar-ganar para nosotros y para los usuarios. Los usuarios pueden expresar sus opiniones como se sientan más cómodos, y podemos acceder fácilmente a todos los comentarios en una única ubicación.
Eso se ocupa de los usuarios actuales, pero ¿qué pasa con las personas que simplemente eliminan sus cuentas sin ofrecer ningún comentario? Sepa que las cuentas se cerrarán y haga todo lo posible para recopilar información de los usuarios que cierran sus cuentas. En Dunked, dirigimos al usuario a una encuesta de "salida" rápida una vez que han completado el proceso de eliminación de la cuenta. La encuesta es completamente opcional y se puede completar en menos de cinco minutos. La mayoría de la gente ha estado dispuesta a completarla, proporcionándonos comentarios adicionales sobre por qué eliminaron su cuenta. Hemos usado Wufoo para manejar las necesidades de nuestra encuesta porque lo hacen realmente fácil.
Ahora que tenemos un método para monitorear y recopilar comentarios, ¿qué debemos hacer con él? Para Dunked, tenemos un enfoque bastante simple. Usamos una lista de tareas dentro de Basecamp para albergar los comentarios que recopilamos. Cuando un usuario escribe con una mejora sugerida o solicita una característica que falta, lo agregamos a nuestra lista de tareas pendientes / sugerencias. Esta lista también contiene nuestras características de "tener bien" que hemos mencionado anteriormente. No todos los elementos que se agregan a la lista se agregarán a Dunked, pero nos ayuda a monitorear las sugerencias. Las solicitudes de características comunes se anotan, se mueven al principio de la lista y, a menudo, se incluyen en nuestros sprints de código, que trataré más adelante..
Desafortunadamente, la plataforma Dunked no ha sido perfecta, por lo que ocasionalmente obtenemos informes de errores. Mantenemos una lista de errores separada también dentro de Basecamp. Cualquier elemento agregado a la lista de errores se considera una prioridad máxima y se arregla lo más rápido posible.
Como mencioné anteriormente, continuamos desarrollando las funciones principales de Dunked, pero creemos que es importante actuar sobre la retroalimentación proporcionada por los primeros usuarios. Debido a que los usuarios han sido tan buenos al proporcionarnos sus comentarios, queremos implementar sus sugerencias cuando el tiempo lo permita. Hacemos esto a través del código diario de sprints. Una o dos veces por semana, revisaremos nuestra lista de Sugerencias / Comentarios, y seleccionaremos algunos elementos que se pueden completar en un solo día de codificación. Completamos esos elementos, los probamos en nuestro servidor de desarrollo y luego los enviamos al servidor de producción una vez que estamos contentos con el código..
Para ilustrar cómo los comentarios de los usuarios han mejorado en Dunked, considere el siguiente ejemplo. Para las cargas de imágenes, creamos un botón simple de hacer clic para subir. Al hacer clic en el botón, se inició el explorador de archivos en la computadora del usuario, lo que les permite buscar y cargar imágenes para sus proyectos. Funcionó perfectamente para nosotros. Los usuarios, sin embargo, tuvieron algunos problemas..
Hay dos opciones básicas sobre cómo manejar las cargas de imágenes: hacer clic para subir o arrastrar y soltar para subirlas. Como resultado, nosotros (Equipo Dunked) cada uno de nosotros preferimos hacer clic para subir. No imaginamos que los usuarios querrían subir y soltar las cargas. Al recopilar comentarios, se hizo evidente que teníamos espacio para mejorar las cargas de imágenes. Agregamos "Cargar arrastrando y soltando" a nuestra lista de sugerencias / sugerencias. Después de varias solicitudes, las cargas de arrastrar y soltar se agregaron a uno de nuestros primeros sprints de código. Ahora, cuando desee cargar imágenes a un proyecto, puede hacer clic para subir o arrastrar y soltar.
Este es un ejemplo bastante simple de cómo los usuarios usaban Dunked de manera diferente a lo que imaginábamos. Nunca consideramos que los usuarios se desanimaran por nuestro método tradicional de carga de imágenes. Sin embargo, al monitorear, recopilar y actuar según los comentarios de los usuarios, pudimos mejorar el Dunked para nuestros usuarios.
Ahora que he explicado un poco sobre nuestro enfoque de una versión beta y por qué creo que las versiones beta son excelentes, debo comentar algunos de los errores y limitaciones que podrían afectar a una versión beta. El mayor error que uno podría cometer en una versión beta es lanzar una versión beta antes de que esté lista. Si encuentra errores en sus propias pruebas o si no ha ejecutado un conjunto completo de pruebas en su aplicación, no tiene nada que ver con la versión beta. Cuando lanza un software que sabe que no está listo para el lanzamiento, está arriesgando la confianza de sus usuarios y la vida de su producto. Si bien la mayoría de los usuarios de la versión beta están dispuestos a perdonar errores menores que aparecen en la versión beta, lanzar un producto que sepa que tiene errores es irresponsable..
Cuando lanza un software que sabe que no está listo para el lanzamiento, está arriesgando la confianza de sus usuarios y la vida de su producto..
El segundo error más grande que podrías cometer en una versión beta es permitir que los usuarios entren demasiado rápido. Si bien puede realizar pruebas de estrés, no sabrá al 100% qué puede manejar su servidor hasta que se haya sometido a una prueba real. Si el servidor se bloquea, desea bloquearse con 1.000 invitaciones beta y no con 10.000 o 100.000 invitaciones pendientes. Además, está en beta, por lo que es posible que se encuentre con uno o dos errores. Con Dunked, por ejemplo, tuvimos un error extraño relacionado con ciertas fallas del proyecto. Todo funcionó bien con el administrador, pero la página en vivo resultó en un error 403. Resultó ser una solución muy simple. Pero como el problema estaba relacionado con las URL, tuvimos que corregir los errores de URL existentes. Ciertamente, fue más fácil buscar y remediar cientos de slugs de proyectos y páginas que lo habría sido para cientos de miles.
Una de las mayores limitaciones de una versión beta está relacionada con los comentarios. El otorgamiento de acceso beta a los usuarios no significa que le proporcionarán comentarios. Los usuarios pueden tener la intención de proporcionar comentarios, pero simplemente no tienen tiempo para expresar sus comentarios en palabras. También pueden sentir que están haciendo algo mal, cuando la aplicación no funciona como lo esperan, y por lo tanto no le escriben con comentarios. Además, si tiene que recorrer un determinado componente dentro de su aplicación, lo más probable es que la calidad y la cantidad de los comentarios vayan a disminuir..
No creo que no sea prudente intentar incluir todas las funciones deseadas al lanzar un producto. Creo que es mejor lanzar una versión beta "completada" y luego continuar recorriendo el producto, agregando funciones adicionales. Al hacerlo, podrá recopilar y utilizar los comentarios de los usuarios para mejorar su producto..
Dicho esto, debe tener un plan establecido en cuanto a cómo va a supervisar, recopilar y actuar sobre la retroalimentación que recopila. Por lo tanto, estará en posición de agregar características que crean un valor real para el usuario, mejorando sus posibilidades de éxito.
Accentsconagua