¿Cómo logras que gente no técnica aprecie un problema que no sea de UI?

Question

Supongamos que estás trabajando en un proyecto de empresa en la que usted tiene que conseguir signoff gestión con el fin de que usted 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 tienen un tiempo difícil apreciar algunos problemas detrás de las escenas que son cruciales para la aplicación de bienestar, tales como transacciones, integridad de datos, enrutamiento de flujo de trabajo, capacidad de configuración, seguridad, etc. Ya que están no técnica y estos temas son no inmediatamente visible, no es obvio para ellos que esto es crucial.

¿Cómo se ha convencido de que ellos estos temas de infraestructura tienen que ser tratado y que es importante para su proceso de negocio?

Answer 1

Todas las embarcaciones tienen lados inoxidables. 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 engañosa 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 observa una buena seguridad hasta que la información de la tarjeta de crédito del cliente aparezca en Elbonia (y poco después, los periódicos nacionales advierten a los clientes de su empresa).

Lo que realmente hay 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.

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!

Answer 2

mismo que la gente ha estado haciendo durante miles de años: hacer dibujos. Diagrame los problemas, use metáforas visuales familiares para su audiencia, arrastre el problema a su territorio.

Suponiendo que no está siendo deliberadamente obtuso ...

Answer 3

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.

Answer 4

Una gran 1 de 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.

p. Ej. 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".

Answer 5

La manera más segura de conseguir la gestión de nivel superior para comprar apagado en el trabajo de desarrollo es presentar de una 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.

Answer 6

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 su administración, pero he tenido suerte con los buenos y antiguos tejedores honestos. Si usted va a través de un par de escenarios de desastre, y señalar a alguien 's que van a ser culpados si se producen, que puede ser suficiente para hacer que sus instintos arsecovering entran en juego y, finalmente, presten atención :)

Answer 7

estoy luchando 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. I asked a simmilar question here.

También recibí diversas respuestas, tentadoramente cerca de útiles, pero no del todo 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 posar this question on site-mining.

Habría sido útil marcar varias respuestas y verlas todas en una sola lista, pero desafortunadamente, esa funcionalidad aún no está disponible en SO. I suggested it on uservoice.

Espero que encuentres algo que puedas usar de las referencias que di.

Answer 8

analogías de automóviles.

Todo el mundo conoce ese "sistema" y es lo suficientemente complejo como para describir la situación extrema.

Answer 9

El tipo correcto de pregunta contraria es el secreto.

• ¿Está bien colgar cada 5 páginas web?
• ¿Tenemos que proteger los números de la tarjeta de crédito?
• ¿Está bien tener que pagar a los contratistas para implementar un parche cada fin de semana?
• ¿Lo quería ahora o deseaba que funcionara?

Answer 10

Una imagen descriptiva realmente ayuda a las personas sin conocimientos técnicos a entender de lo que está 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.

diagram from 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 un no-irritable. 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.

Answer 11

Me gusta la idea de Technical Debt, porque permite que los problemas técnicos se traduzcan (aunque poco) en cuestiones 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 utilizar de manera más amplia para cualquier tipo de situación en la que exista la presión de tomar un atajo, es decir, endeudarse técnicamente, en lugar de correcto la primera vez. (Hacer las cosas bien es lo mismo que ahorrar para comprar algo, lleva 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), por lo que la deuda técnica puede ser buena y 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, no relacionado con la UI en términos de deuda técnica, y el costo de no solucionarlo en términos de pagar intereses sobre esa deuda.