project management - usuario - Gestión del arrastre de características en las GUI

principios de usabilidad web (28)

¿Alguien tiene alguna sugerencia práctica sobre cómo administrar la función de creep en las GUI?

Recibo una fuerte presión de fuentes internas y externas para agregar, modificar, ajustar, etc. Siempre me estremezco cuando alguien se acerca a mí con las palabras "¿no sería lindo si ...?". No puedo simplemente darme la vuelta y gritar "NO" a ellos, porque a menudo son mis superiores o clientes.

En su lugar, estoy buscando sugerencias para ayudar a explicar por qué es una mala idea agregar constantemente nuevas funciones y, al hacerlo, administrar sus expectativas sobre el producto final.

Debe tener cuidado para equilibrar la reticencia a evitar el deslizamiento de características con una tendencia a ignorar las solicitudes de características y los comentarios.

Cada vez que un usuario acude a usted con comentarios, esa es una oportunidad para mejorar su producto y en lo que está trabajando. Puede terminar agregando algo interesante tanto para el usuario como para sus desarrolladores; en realidad podría ser divertido trabajar en ello. Y sí, puede ser una idea estúpida, como se te plantea . Pero es su trabajo aceptar los comentarios, extraer algo positivo de él y darle forma a algo valioso para sus usuarios, el producto, su empresa y su equipo de desarrollo.

Dicho esto, la característica de fluencia es una cosa muy difícil de manejar. Y qué tan bien lo administre depende de su posición y de quién es el "creep". Si eres un desarrollador de nivel medio a junior, y el CEO está exigiendo una función; bueno, vas a agregar esa característica. Puede tratar de convencer al CEO de que no es una característica valiosa, o no funcionará, o hay cosas más importantes en las que trabajar, o tendrá un impacto negativo en el cronograma. Pero nunca haga nada de eso en el momento en que se solicita la función. Todo lo que terminará con dos personas que defienden su posición en lugar de trabajar juntas hacia un objetivo común.

En su lugar, acepte los comentarios y la solicitud de funciones (o la demanda de características) a su valor nominal de inmediato. Aléjate, piensa en ello abiertamente durante un tiempo por ti mismo. "¿Podría ser esto valioso?" "¿Me estoy perdiendo algo de la forma en que el CEO pidió esto?" "¿Es tan difícil como me imagino?" Hágase este tipo de preguntas y proponga algunas respuestas concretas. Luego siempre vuelve al CEO con preguntas de seguimiento. Demuestre que ha pensado en la función solicitada y que ha presentado algunas ideas, ajustes, mejoras u objeciones, etc. Esto creará una discusión abierta. Uno que el CEO no había anticipado, pero que probablemente no se opondría ya que inicialmente no era una resistencia total a su idea.

Cree mandatos de trabajo que definan el problema que necesita solución. Su trabajo está limitado al solo necesitar implementar lo que es necesario para resolver el problema.

Cualquier refinamiento adicional del problema se convierte en control de cambios.

El truco es definir el proyecto como una secuencia de versiones. Su diseño inicial es para la versión 2.0, pero la primera versión prevista es la versión 1.0. Todas las nuevas ideas (características) son bienvenidas, pero dado que, debido a la programación, la versión 1.0 está congelada, las nuevas ideas deben pasar a la versión 2.0.

Por supuesto, tan pronto como se lanza la versión 1.0, comienzas a corregir errores y codificar una versión de mantenimiento de la versión 1.01 y así sucesivamente ... Tal vez la versión 2.0 nunca se publique, pero se usa como un objetivo esquivo y un lugar de estacionamiento para funciones que son buenas, pero no lo suficientemente buenas como para retrasar el lanzamiento de una versión funcional.

En algún momento, debes enviar algo. Suponiendo que está pasando por algún tipo de proceso de prueba formal, siempre y cuando el producto continúe cambiando, las pruebas nunca podrán cerrar la sesión de un producto en funcionamiento.

Ayuda crear una línea de tiempo que describa qué características se lanzarán y cuándo. De esa forma, las personas que presionan por las nuevas funciones tienen una idea de que se atenderán sus solicitudes. No significa que van a ser manejados ahora, pero debería proporcionarles algunas garantías de que la próxima versión abordará sus inquietudes.

Es posible que no se puedan evitar todas las solicitudes de funciones.

Pero intente asignar un costo por cada solicitud de función. Cuando se produzca la próxima reunión de planificación o se decidan las características para la próxima versión, esto ayudará a eliminar las innecesarias.

Función de bloqueo establecida para un marco de tiempo corto (Scrum / iteration / agile). A medida que el usuario comienza a ver que las cosas funcionan, la necesidad o la falta de características se hará más evidente.

Además, es útil contar con una persona a través de la cual se presenten todos los cambios (en Scrum, un Dueño de Producto realmente bueno).

Guardo una lista priorizada de tareas de trabajo y mis estimaciones sobre lo que estará en construcción X y cuánto tiempo (en términos generales) espero que tome para escribir pruebas, implementar código y hacer todo lo demás relacionado. Siempre tomo sus ideas, hablo de lo que realmente quieren / necesitan e insisto en que determinemos dónde encaja en el gran esquema de las cosas. Hablamos sobre el impacto para programar y otras tareas.

Mantiene la línea de comunicación abierta y clara: no hay sorpresas y las expectativas se gestionan. Al final, no es mi programa, es del cliente (sea quien sea el cliente) y quiero construirlo lo que quiere (y necesita) construir.

Haga que las solicitudes de características se manejen en un proceso formal, normalmente a través del gerente del proyecto y de quien analizó los requisitos originalmente. Siempre es mejor delegar ese tipo de decisiones a alguien que no es el desarrollador, suponiendo que quien sea que haga ese trabajo es realmente capaz de hacerlo.

Si es autónomo, obviamente cobra por los cambios en los requisitos, y si usted es un equipo de desarrollo interno, entonces podría considerar la facturación entre departamentos para asegurarse de que la gente piense en lo que quiere gastar.

Finalmente, espere que los requisitos cambien y que se desarrolle la fluencia. Si codifica sin considerar qué cambios se podrían solicitar, o si su proceso y / o fechas límite son tan inflexibles que no puede ajustarse a esto, entonces verá que el proyecto se convertirá en una pesadilla.

Idealmente, las solicitudes como esta deben ser manejadas por la persona a cargo del Diseño Funcional. Tanto si te gusta como si no, se producirán cambios (desde la primera letra en el diseño funcional hasta el último byte de código y más) y siempre habrá solicitudes de características adicionales. Así que asegúrese de que su diseño esté preparado para un proceso tan dinámico.

Esto probablemente sonará como una solución muy débil (y dudo que sea una buena práctica), pero he estado luchando con los mismos problemas en el pasado. El hecho de que ocurriera en una empresa muy pequeña (falta de "capas" en la administración) lo empeoró, ya que estaba a cargo del desarrollo, diseño funcional, diseño técnico y administración de mis propios proyectos.

Lo que funcionó para mí es desviar el problema a la persona que pregunta (si era un superior o el cliente). Entregue el diseño funcional, una copia impresa del prototipo o lo que sea que describa la situación actual y pídales que averigüen "cómo" y "dónde" debe implementarse esta poderosa característica nueva.

Tanto los superiores como los clientes fueron "forzados" a llevarlo de vuelta a su propia gente, discutirlo en reuniones y demás. Usualmente esto significa que no escuchas por segunda vez. En los casos en que surgió, en realidad fue un concepto que funcionó.

La clave parece estar en la pregunta.

'' Gestión de la función de fluencia'' ... puede hacer esto implementando un proceso de gestión que debe seguirse. No se puede evitar (después de todo, con frecuencia los clientes lo piden y gritar no a ellos todo el tiempo tiende a alejar a las pobres criaturas) ... pero eso no significa que tenga que ser indisciplinado. Con un procedimiento establecido que implica que la persona que hace la solicitud proporcione elementos simples como justificación y una investigación preliminar / caso de uso para el cambio, usted comienza a reducir la cantidad de "no sería agradable". Una vez que tenga esto en su lugar, se gestionará su función de creeping y podrá comenzar a priorizar y proporcionar comentarios más consistentes.

La comunicación es clave. En una relación con un cliente, debe estar claro para ellos que cuando se crea un plan con un conjunto de características, ese es el conjunto de características. Solo es culpa de aquellos que interactúan con el cliente que están engañando al cliente o de alguna manera son intimidados por el cliente.

En cuanto a los desarrolladores que contribuyen a la función de creep, la clave es encontrar un equilibrio entre tomar decisiones sobre la implementación y agregar nuevas características. Nuevamente, la comunicación con el desarrollador de forma regular probablemente reducirá un problema aquí.

La mejor manera en mi humilde opinión es definir claramente exactamente cuál será el costo de implementación de las nuevas características. "Sería bueno si" realmente comienza a disminuir cuando el usuario comienza a ver el costo de tales adiciones.

El desacuerdo con el cliente acerca de una característica generalmente no lo lleva a ninguna parte. Si dices "NO" a ellos, se sentirán alienados y desconectados de ti y de tu equipo. La característica probablemente sea una buena idea en general, ya que tiene todo el tiempo y dinero del mundo y no tiene limitaciones técnicas. En su mundo, poder ver una escena al lado de un bar después de hacer clic en un recorte es una buena idea. Por supuesto, en nuestro mundo significa una exploración completa de la tabla, una vulnerabilidad de seguridad potencial y una noche completa para asegurarse de que esté lista para la próxima versión del punto.

Si se lo explica y explica por qué no es una buena idea en general, generalmente lo entenderá. No olvide todos los diferentes factores (tiempo / dinero / costo de agregar complejidad al proyecto / riesgo de deslizamiento de fechas límite). Una persona razonable entenderá si pinta la imagen lo suficientemente claro, y al menos puede decir "se lo dije" a una persona irracional.

La pregunta correcta es "¿Cómo puedo ofrecerles a los desarrolladores un entorno estable , mientras sigo respondiendo solo a solicitudes de funciones de alto beneficio?". Un enfoque similar a SCRUM sería:

Ambiente estable:

Haga que los desarrolladores trabajen en un pequeño conjunto fijo de características durante un pequeño intervalo de iteración fijo .

Respondiendo solo a solicitudes de características de alto beneficio:

Una persona mantiene una lista de características priorizadas. Siempre se pueden agregar nuevas características (Reduce un montón de política). Sin embargo, las características seleccionadas para la próxima iteración solo son los elementos de alta prioridad .

La respuesta a su pregunta es más amplia que solo las GUI. El deslizamiento de característica / alcance siempre ocurrirá cuando alguien no esté prestando atención a lo estipulado en el contrato y cuando no haya un proceso formal para manejar las solicitudes de cambio.

Si no tiene la capacidad para implementar el proceso formal o influir en su creación, le sugiero que obtenga todas las solicitudes de cambio de funciones documentadas en el correo electrónico, y que notifique a su administración de las posibles consecuencias por correo electrónico. Esto no es para obtener a nadie, sino para protegerse de las consecuencias del fracaso eventual.

Lo que hago es mantener las ideas de las características en las fichas y publicarlas en algún lugar visible. Cuando alguien pregunta: "¿Podría también hacer XXX?" Escribo una nueva tarjeta. Este es un movimiento de construcción de relaciones mejor que gritar "¡NO!" :-) También tiene la ventaja de no perder ideas potencialmente buenas. OTOH, no estoy obligado a implementarlo en ese momento. El que hace la sugerencia sabe que han sido escuchados, sé que no lo olvidaré, puedo volver al trabajo y todos podemos reunirnos para tomar decisiones prioritarias en un momento mejor que cuando mi cerebro está en CodeLand.

Muy bien entonces, seré la voz de ágil aquí. El problema no puede resolverse al final de ese proceso, debe evitarse administrando el proyecto de manera diferente.

Aparte de una metodología específica, el truco es poner esas decisiones en las manos de los clientes. Tienes una lista de cosas que hacer. Cuando quieren cambiar esa lista, les pregunta qué elemento de la lista no se va a hacer para acomodar el nuevo elemento. O, cuánto dinero más le darán para manejarlo.

Además, tienes que hacer el trabajo en iteraciones pequeñas (de una semana a un mes) para que tengan posibilidades de reajustarse en el medio.

Usamos SCRUM y ha sido genial. Después de un par de iteraciones, todos los elementos de nivel empresarial y de nivel de proceso se resuelven y usted está entregando exactamente lo que quiere para el final.

No puede manejar solo la función de creep: necesita organizar todo el proceso de desarrollo de forma adecuada.

Sin embargo, según su descripción, parece que solo codifica lo que otras personas solicitan y no pudo reorganizar el proceso. En este escenario, la mejor manera de administrar las solicitudes de manera efectiva es mediante un sistema de seguimiento / emisión de tickets que le permita recibir solicitudes de otras personas, priorizarlas, estimarlas, acordar el cronograma de implementación y realizar un seguimiento del tiempo que realmente pasa trabajando en ellas.

Cuando pueda probar con las cifras del mundo real que ''este pequeño botón'' tomaría de 2 a 3 días en lugar de 5 segundos, el cliente probablemente crea que debería estar en una mejor posición para negociar.

Si puede mostrar claramente que la fecha de puesta en marcha del proyecto se retrasará dos semanas debido a las nuevas características, es posible que vea esas solicitudes simplemente desapareciendo.

Sin embargo, debe recordar que el "arrastre de características" no siempre es negativo. A medida que la aplicación madura y crece, las prioridades de sus clientes también cambian. Si no lo reconoce, podría significar que su producto final no será lo que quiere. Intente comprobar si aceptarían cambiar una característica nueva por una anterior de la especificación original que aún no se implementó.

Para los gerentes:

cuanto antes se lance al mercado el producto (suponiendo que sea un envoltorio), antes podrá la empresa ganar dinero y mejor será el flujo de caja.
no descarte por completo la nueva característica, sino que la equilibre con el valor que puede obtener al realizar un trabajo alternativo; explicar el costo de oportunidad.

Para todo el mundo:

Si las nuevas características están en su interfaz en la interfaz de usuario, comience a hablar sobre el efecto de la complejidad visual en la usabilidad y, a partir de eso, en el atractivo del producto como un todo. Pero estoy seguro de que ya estás haciendo eso. Intentaré buscar algunas referencias ...

Parece que su empresa no define claramente los requisitos antes de comenzar un proyecto, y esto solo terminará en lágrimas.

Mi política es obtener un desglose claro de todos los requisitos por adelantado y hacer que todas las partes conozcan las implicaciones de introducir estos requisitos.

Tiempos de liberación progresivamente retrasados
Aumento de errores
Funciones incompletas
Estrés del personal
Renuncias de personal.
Cargos adicionales por esperar más del producto final de lo acordado en la declaración de un precio (y esto es REALMENTE MALO)

Si no quieren adherirse a un sistema que sea sostenible y productivo, uno puede querer optar por el # 5 o amenazar con el # 5.

SI usted no es el administrador o el propietario del proyecto, le receto lo siguiente:

Si lo quieren, hazlo. Asegúrese de que le paguen el día de pago. Aprendí que a veces no vale la pena luchar por conseguir que las cosas se ajusten a lo que te gustaría. Disfruta de la vida, después del trabajo y planifica y codifica tus propios proyectos personales que hacen las cosas bien.

Seguimos wireframes en mi oficina. Cualquier cambio después de la firma debe pasar por un procedimiento de Control de cambio.

Sus usuarios tienen muchas necesidades de las que no se ocupan. Ellos están sufriendo. Ellos necesitan atención, y te necesitan. Creo que el deslizamiento de características es algo que sucede cuando ya no implementa las funciones correctas .

Cultive una relación cercana con sus usuarios. Hágales saber que siempre está interesado en su aporte. Periódicamente llame y pregúnteles cómo lo está tratando su software.
Conozca sus hábitos de trabajo, prácticas estándar, cómo usan su software y cómo usan su otro software. A medida que esa información entra, recójala.
Cuando entran solicitudes de funciones, los usuarios realmente no sabrán lo que quieren. Sin embargo, sabes lo que quieren porque tienes experiencia y has estado escuchando. Por lo tanto, trabaje con ellos para aclarar el problema que están teniendo, luego use su conocimiento recopilado para generalizar el problema lo mejor que pueda. Escribe una solución que resuelva ese problema.

Por otro lado, la "característica progresiva" es a menudo la respuesta de un producto de software a un negocio en evolución. Si el negocio de su cliente está creciendo, tiene la suerte de que gastará más dinero en su trabajo. Así que relájate, ¡te pagarán! Solo necesitan comprender que, cuanto más grande sea un sistema, más difícil será cambiarlo, y algunas veces una nueva característica pequeña necesita una gran reescritura, o una interfaz de usuario completamente nueva, para que todo funcione sin problemas.

Muéstreles cómo las GUI simples pueden ser efectivas. Ejemplos: Google Chrome, el software de Apple. También es posible que desee mostrar ejemplos de software inflado, como Eclipse, Netbeans, Visual Studio ... bien, estos son en realidad todos los IDEs de software, pero todos tienen una interfaz desordenada.

Si hay una lección que podemos aprender de Internet y de la Web 2.0, es que la gente adora la personalización. De eso se trata iGoogle y cientos de otros sitios. Si puede crear personalización en su GUI, es probable que sus clientes lo amarán por ello.

Además, observe cómo otros proyectos gestionan con éxito la función de creep. Por ejemplo, Google permite a los usuarios enviar solicitudes de funciones, pero también muestra una lista de funciones ya solicitadas. Los usuarios pueden votar para solicitar esa característica también. No es que sea una mierda, pero eche un vistazo a .uservoice.com . Ellos tienen una política similar.

Es fundamental escuchar a los usuarios y obtener sus comentarios. Espere que se les ocurran nuevas ideas que son mejores que las suyas. Espere que se le ocurran ideas que usted piensa que son tontas. Si suficientes personas lo desean, y parece razonable, déles lo que quieran.

1) Mayor tiempo antes de la publicación.

2) Mayor costo.

3) Costo de mantenimiento exponencial

4) Mayor potencial de errores

Para administrar una solicitud de función, pídales que envíen una orden de cambio. Periódicamente, revise las órdenes de cambio y envíe una declaración sobre cada solicitud, "Esto llevará mucho tiempo en hacerlo, implicando este costo adicional Y. ¿Es esto aceptable?" Una vez que el solicitante ha aceptado el costo adicional, entonces está bien. Tus manos están lavadas. :)

Explica "seguro, es factible, ¿le gustaría obtener una estimación de cuánto va a sacar la fecha de finalización del proyecto? Además, darle ese estimado agregará aproximadamente un día al final del proyecto también".

No hay nada de malo en agregar funciones, siempre y cuando las partes interesadas entiendan que hay un costo asociado al hacerlo.

Uno de nuestros respaldos financieros solicita características todo el tiempo. A veces dice que podemos obtener el software para hacer ''x''. Si es posible, le diremos que sí, y luego pregúntele qué escalas de tiempo tenía en mente. Si vuelve con lo antes posible, entonces le diremos que alguna otra característica tendrá que ceder, o extender nuestros plazos. Afortunadamente, él normalmente cambia su opinión a algún momento en el futuro.

Creo que lo más importante es registrar realmente la idea o solicitud, incluso si la función no se implementa de inmediato.

Usamos Bugzilla para mantener un registro de errores, pero también solicitudes de funciones. Tenemos una lista de trabajo de ''características'' (o versión de destino) ... de esa manera todos pueden ver qué características nos gustaría desarrollar en el futuro y a medida que las personas tienen más ideas sobre una característica, pueden agregar más fácilmente al elemento en bugzilla.

Cada vez que nos sentamos y trabajamos en la lista de trabajo para una versión nos sumergimos en la lista de características para ver si hay algo que podamos incorporar. Intentamos incluir una función cuando podemos y brindar retroalimentación a las personas: esto muestra que las características e ideas no están cayendo en oídos sordos.

Esta retroalimentación ayuda a las personas a saber que estamos reconociendo sus solicitudes de características y nos ponemos a la tarea de implementarlas, en lugar de solo estar sentados en una lista que se hace cada vez más grande.

Supongamos que crea un producto que tiene exactamente una característica y que 100 de sus clientes adoran su producto y lo encuentran fácil de usar. Supongamos ahora que agrega diez características más a su producto que solo usarán diez de sus clientes. Ahora descubrirá que el 90% de sus clientes tiene muchos más problemas para usar su producto porque hay diez veces más opciones que hacer y diez veces más cosas que podría hacer que no lo ayudarán. Lo bueno se ha perdido en el ruido.

Esto es, por supuesto, una simplificación, pero la realidad es que la mayoría de sus usuarios solo usarán una pequeña porción de las características de su producto.

Lea algunos buenos libros sobre diseño de software y diseño de interfaz de usuario, y haga que su gerente los lea también. Los libros de Joel Spolsky son un buen lugar para comenzar: www.joelonsoftware.com