language agnostic - ¿Cómo logras que gente no técnica aprecie un problema que no sea de UI?
language-agnostic communication (11)
Supongamos que está trabajando en un proyecto empresarial en el que debe obtener la aprobación de la administración para que pueda desarrollar un nuevo conjunto de características. Por lo general, su administración no tiene problemas para cerrar sesión en alguna nueva característica de IU brillante y brillante. Desafortunadamente, les resulta difícil apreciar algunos problemas detrás de escena que son cruciales para el bienestar de la aplicación, como transacciones, integridad de datos, enrutamiento del flujo de trabajo, configurabilidad, seguridad, etc. Ya que no son técnicos y estos problemas son no inmediatamente visible, no es obvio para ellos que esto es crucial.
¿Cómo los ha convencido de que estos problemas de infraestructura deben ser tratados y que es importante para su proceso de negocios?
Analogías de automóviles
Todos conocen ese ''sistema'' y es lo suficientemente complejo como para representar la situación extrema.
Cada nave tiene lados antisépticos. Cosas que TIENEN que hacerse, pero nadie las nota directamente. En una tienda de comestibles, alguien tiene que organizar cómo y cuándo llenar los estantes de las tiendas para que siempre luzcan frescos. En una lavandería se necesita a alguien que piense en cómo se deben optimizar los procesos para que el cliente obtenga su ropa a tiempo.
La parte difícil es: el cliente no se dará cuenta cuando estas cosas sutiles se hayan hecho bien ¡HASTA QUE SE COMPRENDA QUE ESTÁN FALTANDO! Como cuando la ropa no está lista a tiempo pero dos días tarde, o las verduras en el supermercado tienen manchas marrones y se ven terribles.
Lo mismo vale para TI. No observa buenas transacciones hasta que su cliente principal llama a su puerta y le dice que un proyecto importante y costoso ha fallado porque las entradas de la base de datos de su producto estaban misteriosamente mezcladas. No se percibe una buena seguridad hasta que aparece la información de la tarjeta de crédito del cliente en Elbonia (y poco después aparece la noticia en los periódicos nacionales que advierten a los clientes de su empresa).
Lo que realmente tienes que decir una y otra vez es que el software NO es estático. Debe ser atendido incluso después de que su fase de desarrollo inicial haya terminado. No es solo un producto que compra una vez y se olvida. Todos los fabricantes de automóviles saben que los servicios son de primordial importancia para los productos que construyen, simplemente porque ocurrirán cosas que deben ser reparadas y mejoradas. Es lo mismo con el software.
Así que haga una presentación, visualice, verbalice, traduzca su información técnica en beneficios. A las personas de negocios no les importa su deseo de estética de código en un proyecto de refactorización, pero entenderán que sus cambios ayudarán a que el producto sea más confiable, gane una mejor reputación y reduzca la cantidad de solicitudes de servicio futuras. Hágales comprender mostrándoles los beneficios!
Desafortunadamente, generalmente se necesita uno o dos desastres antes de que este material reciba la atención que merece.
Realmente depende de cómo sea tu administración, pero he tenido suerte con el buen miedo a la honestidad. Si pasas por un par de escenarios de desastre, y señalas que alguien será culpado si ocurren, eso puede ser suficiente para hacer que sus instintos de descubrimiento de arca funcionen y finalmente presten atención :)
El tipo correcto de pregunta contraria es el secreto.
- ¿Está bien colgar cada 5 páginas web?
- ¿Tenemos que proteger los números de las tarjetas de crédito?
- ¿Está bien tener que pagar a los contratistas para implementar un parche cada fin de semana?
- ¿Lo quería ahora o quería que funcione?
La manera más segura de conseguir que la gerencia de nivel superior pague en el trabajo de desarrollo es presentarla de manera cuantificable. Idealmente, esta medida cuantificable está en $$. Debe explicarles las consecuencias de escatimar en la integridad de los datos, la seguridad, las transacciones, etc., y cómo eso afectará a la comunidad cliente / usuario y, finalmente, a la línea de fondo. Debe tener cuidado en estas situaciones porque a veces la administración espera que estos requisitos no funcionales "simplemente funcionen". Si este es el caso, debe estimar alto y trabajar en estos elementos junto con el trabajo de UI visible (la ignorancia es felicidad) o necesita documentar estas áreas de necesidad a medida que se comunica con la administración, así que si las cosas salen mal como anticipa, no es tu trabajo lo que está en juego.
Lo mismo que la gente ha estado haciendo durante miles de años: dibujar. Diagrame los problemas, use metáforas visuales familiares para su audiencia y arrastre el problema a su territorio.
Suponiendo que no estén siendo intencionalmente obtusos ...
Robustez. Cuando se trata de eso, necesitas hablar en su idioma, que es la forma en que afecta su balance final. Si es un problema de seguridad o corrección, debe informarles que los clientes no querrán productos que funcionen incorrectamente, sin importar lo bien que se vean.
Un gran +1 para analogías y metáforas. Si es posible, encuentre uno que resuene con los intereses personales de su audiencia (si se trata de 1-2 personas). Para las metáforas generales, a menudo me encuentro utilizando el tráfico de cercanías o el metro, por alguna razón.
Por ejemplo, actualmente estamos migrando una aplicación de un OODB a Postgres / Hibernate: la mayor parte de este trabajo se realiza en la Versión ''4''. Muchos expertos de dominio se han preguntado por qué hay tan pocas características de usuario en R4. Regularmente les digo que hemos estado "destrozando la ciudad para poner en el metro". Es muy costoso e innegablemente arriesgado, pero una vez que esté hecho, los beneficios en R5 + serán asombrosos, de verdad ". La verdadera conversación está más involucrada, pero puedo volver a este tema una y otra vez, mucho después de R4. Meses a partir de ahora, espero decir: "Pediste X y ahora es muy fácil, precisamente porque nos permites poner ese metro en R4".
Una imagen descriptiva realmente ayuda a las personas no técnicas a entender de lo que estás hablando. Por ejemplo, a continuación se muestra un ejemplo de Sun que describe cómo se procesa la información en una de sus aplicaciones algo complejas.
diagrama de docs.sun.com http://docs.sun.com/source/816-7152-10/images/wsgoverview3.gif
Tratar de explicar esta aplicación en palabras sería imposible para un no techy. Señalando el diagrama y decir, mira, esta parte es nuestro punto débil, necesitamos mejorarla. Eso tendrá sentido para ellos. Si sienten que comprenden algo de lo que estás haciendo, estarán mucho más dispuestos a apoyar tu pedido.
Me gusta la idea de Deuda técnica , porque permite traducir los problemas técnicos (aunque de manera flexible) en problemas de dinero, y el dinero es algo que la mayoría de los gerentes entienden.
Aunque la idea de la deuda técnica se aplicó originalmente a cuestiones arquitectónicas, se puede usar de manera más amplia para cualquier tipo de situación en la que exista la presión de tomar un atajo, es decir, entrar en una deuda técnica, en lugar de hacerlo bien desde el primer momento. hora. (Hacer las cosas bien es lo mismo que ahorrar para comprar algo, toma tiempo, en lugar de comprarlo a crédito y endeudarse).
Del mismo modo que las deudas pueden ser buenas (por ejemplo, préstamos hipotecarios) y malas (por ejemplo, tarjetas de crédito), la deuda técnica puede ser buena o mala. No trataré de caracterizar las diferencias por completo, pero se puede hacer un seguimiento preciso de la deuda técnica adecuada, para que sepa cuánto está endeudado.
Por lo tanto, intente explicar su problema importante que no es de UI en términos de deuda técnica y el costo de no solucionarlo en términos de pagar intereses sobre esa deuda.
Estoy batallando esencialmente con el mismo tipo de situación. Ya se trate de la aprobación de la gestión o la aceptación por un usuario / patrocinador, el problema sigue siendo uno de diferentes vocabularios, prioridades y perspectivas. Hice una pregunta similar aquí .
También recibí diversas respuestas, tentadoramente cercanas a útiles, pero no lo suficientemente definitivas. Navegar y buscar SO con palabras clave relevantes me llevó a encontrar información útil en varias respuestas repartidas en muchas preguntas no relacionadas. Encontrar y extraer estas gemas me llevó a plantear esta pregunta en la minería del sitio .
Hubiera sido útil poder marcar las distintas respuestas y verlas todas en una sola lista, pero desafortunadamente esa funcionalidad aún no está disponible en SO. Lo sugerí en la voz de usuario .
Espero que encuentres algo que puedas usar de las referencias que di.