¿Deberías exportar datos a Excel y Word?

Exportar a Excel es una solución, no un requisito. Debe volver a los propietarios y pedirles que detallen sus requisitos funcionales para los datos. Una vez hecho esto, entréguelo a los desarrolladores y déjelos proponer una solución. Puede terminar siendo Excel porque, como escribió, ya está allí, o puede ser otra solución que cumpla con los requisitos.

Tienes que comparar cada solución con sus beneficios, costos, riesgos y otras sanciones. El hecho de que Excel ya esté allí y sepan cómo usarlo es sin duda un beneficio, pero es posible que los propietarios no sepan o estén subestimando los impactos de algunas de las penalizaciones que tendrán al usar Excel y terminen insatisfechos a largo plazo. . Por el contrario, construir una nueva solución costará dinero y tomará tiempo y tendrán que aprenderla (costos y penalizaciones), pero puede curar los impactos de Excel y, a la larga, hacerlos felices.

Nada de esto lo sabes todavía; esto tiene que ser analizado y construido un caso para cada solución. Pero todo comienza con la obtención de los requisitos adecuados de los propietarios.

Como principio, si tener un Excel "vale la pena" (desde el punto de vista comercial) o no, no depende del equipo de desarrollo decidirlo. Deben ser capaces de decir si es factible y decir objetivamente cuáles son los pros y los contras (es decir, no funcionará cuando tenga más de 1.000.000 de filas de datos), también pueden asesorar al cliente sobre si esto realmente resuelve su problema o no (y si no, ser capaz de proponer constructivamente otra solución válida), pero no pueden negarse a implementar una característica solo porque piensan que no vale la pena.

Dicho esto, tal vez el problema no se haya analizado lo suficiente, y el equipo de desarrollo y el cliente claramente aún no están en la misma página; así que personalmente los pondría juntos para que puedan entender mejor el problema y colaborar para encontrar la mejor solución. Es posible que el cliente no haya expresado completamente su necesidad real, y el equipo de desarrollo puede tener una idea diferente...

Cambiaría mi mentalidad de "¿Cómo puedo convencerlos?" a "¿El usuario realmente quiere exportar a Excel?" y "¿Qué solución sería hacer más feliz a mi cliente mientras gana dinero?"

1. Hable con las partes interesadas. Podrían pensar en Excel como una forma familiar de describir la funcionalidad. (Una solución, no el requisito). Pero es posible que prefieran Excel de todos modos (un requisito directo). En este caso:
2. Busque alternativas. Por ejemplo, los archivos CSV se pueden abrir con Excel y son más fáciles de comparar. Son usables en Linux y Mac y debería ser más fácil de desarrollar.
3. Deja claro al cliente que harás cualquier solución que él quiera. A estas alturas no te preocupa trabajar más horas. Le preocupa desarrollar una solución que podría no funcionar para ellos. Después, puede hablar sobre los costos si es un problema.
4. Asegúrese de que el cliente entienda los problemas. Por ejemplo, podría crear dos archivos de Excel ficticios y contarles. "¿Cómo los compararías?"
5. Compruebe si los datos son demasiado grandes para Excel y algunas métricas de rendimiento conservadoras (puede llevar una hora exportar a Excel en un proceso por lotes nocturno)
6. Pregunte "¿Qué planea hacer con este Excels?". ¿Una copia de seguridad? Debería poder hacer una copia de seguridad de la base de datos. ¿Un informe? ¿Podría generar el informe automáticamente?
7. Una vez que el cliente tome una decisión, envíe el acta para tener una prueba escrita de que aceptó las consecuencias. Asegúrese de mantener el correo electrónico fácil de encontrar.
8. Explique al equipo de desarrollo que este es un requisito directo del cliente. No de ti mismo y de tus esfuerzos por buscar una mejor solución. Gracias por su aporte. Incluso si el cliente fue inflexible, será mejor que le hayas explicado los problemas potenciales de antemano.

Trabajo en una oficina muy pequeña y tengo que realizar muchos de los roles de Scrum yo mismo, por lo que tengo que equilibrar los lados y los argumentos en mi cabeza para tales decisiones, esta fue una decisión simple para mí, a pesar de que el Backend guy no pudo hacer la tarea (yo hago la mía ahora).

Creé hojas de cálculo xml para Excel basadas en lo que realmente se muestra en un Actionscript DataTable (una cadena enorme colocada en un bloc de notas guardada como .xml), además de una copia CSV de Flash Datatables.

La creación de hojas de cálculo de Excel en el back-end es trivial. No puedo concebir un escenario que haga que valga la pena discutir sobre hacerlo en lugar de simplemente hacer la solicitud. Incluso convertir la tabla de datos 1 en un Excel de 3 hojas con fechas de parámetros y descargos de responsabilidad no fue particularmente difícil.

Trabajo muy de cerca con los clientes, pero nunca estoy 100 % seguro de cuáles son todos sus requisitos finales. Darles resultados de Excel significa que pueden hacer el 80 % de todos los usos e interpretaciones posibles de los datos por el 20 % del esfuerzo.

Lo importante no era conseguir el excel en el software sino sacar el verdadero problema del equipo.

Pensar como una persona técnica Si la información se almacena en una base de datos de alguna descripción, generalmente no es demasiado difícil otorgar acceso de solo lectura a las tablas que los usuarios desean ver y luego hacer que importen los datos directamente desde Excel sin pasar por el frente de la aplicación. -fin (los desarrolladores no tienen que hacer nada) ya sea usando funciones de importación de datos de Excel o usando scripts VBA personalizados.

Pensar como gerente Hable con su Analista comercial para agregar el requisito de una forma significativa o, alternativamente, solicite al Propietario del producto / Patrocinador del proyecto / persona similar al jefe que priorice el trabajo. Suena como si estuvieras en un 'estado mental de solución', que no es el trabajo de un PM. El hecho de que a las personas les encante Excel no significa que realmente necesiten una función de exportación a Excel; a veces, esto puede generar riesgos de seguridad.

Simplemente puede poner su pie en el suelo y darle al cliente lo que quiere, pero mientras los desarrolladores no entiendan por qué la función es útil, es poco probable que la implementen de una manera útil. Te darán una exportación de Excel sin sentido, que no se usará, y te dirán "mira, te lo dije".

Creo que lo mejor que se puede hacer es cerrar la brecha entre los usuarios y los desarrolladores. Tome algunos desarrolladores, preferiblemente los más cercanos al front-end, y los que son más 'amigables con las personas', y pídales que sigan a los usuarios por un día. Deje que los usuarios les muestren lo que quieren lograr y por qué les resulta útil. En el peor de los casos, se asegurará de que la función realmente haga lo que los usuarios quieren (en lugar de lo que dicen que quieren) y, en el mejor de los casos, los usuarios y desarrolladores llegarán a una solución más creativa que realmente resuelve el problema.

Después de todo, no es trabajo del usuario diseñar el software, y no es trabajo del desarrollador elegir los requisitos. Tienen que trabajar juntos para crear algo de valor.

Luego, si realmente quiere hacerlo bien, haga que los usuarios y los desarrolladores creen algunos bocetos juntos. Pruebe estas maquetas con otros usuarios para asegurarse de que las entiendan y luego discútalas con el equipo antes de implementarlas.

En última instancia, este es el tipo de cosas que debe hacer su diseñador de interacción/administrador de ux. Es comprensible si no tienes uno de esos, pero te recomiendo trabajar para tener uno. Toma esto como un ejercicio. Envíe tres desarrolladores para interactuar con los usuarios. Elija el que los usuarios respondieron mejor y al que pareció gustarle más el ejercicio, y comience a darle más responsabilidades de diseño. No diseñe como en Photoshop cómo deberían verse los botones, pero diseñe como en la recopilación de historias de usuarios, maquetas y pruebas de usuarios de funciones potenciales, y trabaje con los otros desarrolladores para descubrir los detalles de implementación.

Exportar grandes conjuntos de datos a Excel puede ser muy poderoso y hacer que su aplicación sea mucho más valiosa para muchos más usuarios. Excel tiene un conjunto de funciones tan rico que intentar duplicarlo sería una pérdida del conocimiento de la industria de sus desarrolladores.

Los usuarios pueden filtrar, ordenar, graficar y pivotar en Excel de casi cualquier forma que elijan. ¿Puede definir todos los flujos de trabajo posibles que necesitan los usuarios y agregarlos a su aplicación? ¿Qué pasa con el usuario que quiere hacer un poco de espeleología de datos y probar algunos pivotes no obvios?

En cuanto a los grandes conjuntos de datos, la pregunta es ¿qué tan grandes? Exportar a una base de datos para Business Analytics puede ser una mejor opción si el conjunto de datos es lo suficientemente grande como para ahogar a Excel. Más datos me dan un tamaño de muestra más grande y confianza, así que no veo esto como algo negativo.

En cuanto a los usuarios de dispositivos móviles, no sé si estoy haciendo un análisis pesado en mi iPhone. Si puedo obtener informes en mi teléfono, adelante. ¡No dejes que esto te detenga!

Finalmente, estoy 100% de acuerdo con Grimm the Opiner, "el equipo de scrum no puede decidir qué es o no es un requisito del usuario". Esto depende claramente del propietario del producto.