¿Cómo logran que personas no técnicas aprecien un problema que no es de UI? [cerrado]

Question

Suponga que está trabajando en un proyecto empresarial en el que debe obtener la aprobación de la administración para poder desarrollar un nuevo conjunto de características. Por lo general, su administración no tiene problemas para cerrar sesión en alguna nueva función de interfaz de usuario 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 las transacciones, la integridad de los datos, el enrutamiento del flujo de trabajo, la configurabilidad, la seguridad, etc. Dado que no son técnicos y estos problemas son no visible de inmediato, no les resulta obvio que esto es crucial.

¿Cómo los ha convencido de que estos problemas de infraestructura deben abordarse y que es importante para su proceso comercial?

Answer 1

Cada nave tiene sus lados poco atractivos. Cosas que DEBEN hacerse, pero nadie las nota directamente. En una tienda de comestibles, alguien tiene que organizar cómo y cuándo llenar los estantes para que siempre se vean frescos. En una lavandería, necesita a alguien que piense en cómo deben optimizarse los procesos para que el cliente reciba 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 dé cuenta de que se están perdiendo! 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 nota 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 se mezclaron misteriosamente. 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 de la palabra está en los periódicos nacionales advirtiendo a los clientes de su empresa).

Lo que realmente tiene que introducir una y otra vez es que el software NO es estático. Debe cuidarse incluso después de que termine su fase de desarrollo inicial. No es solo un producto que compra una vez y se olvida. Todos los fabricantes de automóviles saben que los servicios son de importancia primordial para los productos que fabrican, simplemente porque sucederán cosas que deben repararse y mejorarse. Es lo mismo con el software.

Haga una presentación, visualice, verbalice, traduzca su información técnica en beneficios. Los empresarios no se preocupan por su deseo de una estética de código en un proyecto de refactorización, pero comprenderán que sus cambios ayudarán a que el producto sea más confiable, gane una mejor reputación y reduzca la cantidad de futuras solicitudes de servicio. ¡Haz que entiendan mostrándoles los beneficios!

Answer 2

Lo mismo que la gente ha estado haciendo durante miles de años: hacer dibujos. Diagrama los problemas, usa metáforas visuales familiares para tu audiencia, arrastra el problema a su territorio.

Asumiendo que no están siendo intencionalmente obtusos ...

Answer 3

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 metáforas generales, a menudo me encuentro usando tráfico de cercanías o metro, por alguna razón.

p. 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 en dominios se han preguntado por qué hay tan pocas funciones orientadas al usuario en R4. Regularmente les digo que hemos estado destrozando la ciudad para poner un metro. Es muy costoso e indudablemente arriesgado, pero una vez que esté hecho, los beneficios en R5 + serán realmente asombrosos '. La verdadera conversación es más complicada, pero puedo volver a este tema una y otra vez, mucho después de R4. Meses a partir de ahora, espero decir "Solicitaste X y ahora es muy fácil, precisamente porque nos permitiste poner ese metro en R4".

Answer 4

La forma más segura de lograr que la administración de nivel superior compre el trabajo de desarrollo es presentarlo 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, al resultado final. Debe tener cuidado en estas situaciones porque a veces la gerencia 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 visible de la interfaz de usuario (la ignorancia es una bendición) o debe documentar estas áreas de necesidad a medida que se comunica con la administración, de modo que si las cosas van mal como anticipaba, no es tu trabajo lo que está en juego.

Answer 5

Desafortunadamente, usualmente toma un desastre o dos antes de que esto reciba la atención que merece.

Realmente depende de cómo sea su gestión, pero he tenido suerte con los viejos y honestos temores de honestidad. Si atraviesa un par de escenarios de desastre y señala que se culpará a alguien si ocurre, eso puede ser suficiente para que sus instintos de descubrimiento se activen y finalmente presten atención:)

Answer 6

Analogías de automóviles.

Todos conocen ese 'sistema' y es lo suficientemente complejo como para representar la grave situación.

Answer 7

Estoy luchando esencialmente con el mismo tipo de situación. Ya sea que sea aprobado por la administración o aceptado por un usuario / patrocinador, el problema sigue siendo uno de diferentes vocabularios, prioridades y perspectivas. Hice una pregunta similar aquí .

También obtuve diversas respuestas, tentadoramente cercanas a útiles, pero no lo suficientemente definitivas. Navegar y buscar SO usando 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 sobre minería de sitios .

Hubiera sido útil poder marcar las diversas respuestas y verlas todas en una sola lista, pero lamentablemente, esa funcionalidad aún no está disponible en SO. lo sugerí en uservoice .

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

Answer 8

El tipo correcto de pregunta de respuesta es el secreto.

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

Answer 9

Robustez. Cuando se trata de eso, debes hablar su idioma, que es cómo afecta a sus resultados. Si se trata de un problema de seguridad o corrección, debe decirles que los clientes no van a querer productos que actúen incorrectamente, sin importar cuán bonitos se vean.

Answer 10

Me gusta la idea de Deuda técnica , porque permite traducir problemas técnicos ( aunque vagamente) en cuestiones de dinero, y el dinero es algo que la mayoría de los gerentes sí 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 presión para tomar un atajo, es decir, endeudarse técnicamente, en lugar de hacerlo bien la primera vez. (Hacerlo bien es el equivalente a ahorrar para comprar algo, lleva tiempo, en lugar de comprarlo a crédito y endeudarse).

Así como las deudas pueden ser buenas (p. ej., préstamos para la vivienda) y malas (p. ej., tarjetas de crédito), la deuda técnica puede ser buena o mala. No intentaré caracterizar las diferencias por completo, pero una buena deuda técnica se puede rastrear con precisión, para que sepa cuánto tiene deudas.

Por lo tanto, trate de explicar su importante problema no relacionado con la IU en términos de deuda técnica, y el costo de no solucionarlo en términos de pagar intereses sobre esa deuda.

Answer 11

Una imagen descriptiva realmente ayuda a las personas no técnicas a comprender de qué 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.

_{(fuente: sun.com )}

Intentar 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 mejorarlo. Eso tendrá sentido para ellos. Si sienten que comprenden algo de lo que está haciendo, estarán mucho más dispuestos a respaldar su solicitud.