project-management - presenta - como exponer un proyecto

¿Existen buenas metáforas para explicar la complejidad del proyecto a un no programador? (30)

Algunas metáforas ...

En cuanto a la complejidad, es como construir un auto , o un bote, desde cero, solo. Los proyectos de software que requieren un equipo de ingenieros son como construir el transbordador espacial . La única diferencia es que si te equivocas, la gente no suele morir. Si las vidas de las personas están en juego, es más como el transbordador espacial. (Sin embargo, el software casi nunca es tan genial como los cohetes).
Es cierto que su proyecto de software no es la Capilla Sixtina (¿qué es?), Pero es como construir un sistema de gestión de carga, que es increíblemente complejo. Puede dibujar algunos diagramas en una pizarra o llevar a cabo el diseño del sistema y los diagramas de flujo de datos. Ayúdalos a ver.
Pregunte, "¿alguna vez has construido una computadora ?" La selección y el pedido de todos los componentes, la construcción de la computadora, la selección e instalación del software operativo, los controladores de dispositivos y la configuración del resultado final llevarán menos tiempo y serán mucho menos complicados que este proyecto de administración de fletes.

El consejo sobre cómo relacionarlo con algo que hacen es bueno, pero asegúrese de que comprende lo suficiente sobre lo que hace para hacer una analogía adecuada . Si son un mecánico capacitado y usted dice que es comparable a la reconstrucción de un carburador (en lugar de, digamos, una transmisión automática), podrían pensar "está bien, así que no es muy complicado".

Neil Ernst habla un poco sobre las metáforas de software , la aplicabilidad de la metáfora de contratación doméstica y también señala que la ingeniería de software es intrínsecamente difícil de explicar porque es un trabajo abstracto .

Neil se enlaza con un ensayo de Jim Waldo, Ingeniería de software y Arte del diseño , en el que señala

De esta manera, lo que llamamos ingeniería de software se parece más a la arquitectura (arquitectura real que produce edificios) que a otros tipos de ingeniería. Hay un elemento de la ciencia (un edificio tiene que obedecer las leyes de la física) pero también hay un gran elemento del arte. Dependiendo del tipo de software que produzcas, la combinación de ambos puede diferir, pero siempre hay una combinación.

Entonces, tal vez las grandes hazañas arquitectónicas y de construcción son una metáfora adecuada. (No es que lo que hacemos se acerque a la Capilla Sixtina, pero deberíamos enfocarnos en lo que hacemos con eso en mente).

Desafortunadamente, la persona que desestima su proyecto como trivial es poco probable que lo entienda. Es posible que no puedan pensar lo suficientemente abstracto como para obtenerlo . Lo mejor que puede esperar es que capten el tipo de analogía del auto o el bote o la casa, o tal vez les ayuden a verlo con diagramas.

Edición: hizo hincapié en la complejidad relativa entre su proyecto y los "controles de dibujo en un formulario". Tal vez podría responder al comentario de la Capilla Sixtina diciendo que "eso es cierto. Sin embargo, si un proyecto web de tres meses es el pequeño cobertizo detrás de su casa, este sistema de gestión de carga es Rogers Centre .

Se acaba de mencionar que "no estoy construyendo exactamente la Capilla Sixtina". Esto es cierto, pero estoy creando una aplicación de administración de carga, que no es exactamente tan simple como dibujar controles en un formulario (aunque los proveedores le hagan creer que lo es).

No sostengo esto contra la persona que lo dijo, pero siento que la complejidad de lo que estoy haciendo es un poco mal entendida, o esa declaración no se habría hecho.

¿Hay alguna buena metáfora que pueda ilustrar la complejidad de un proyecto para los no programadores?

Creo que es común que las personas que carecen de experiencia técnica simplifiquen lo que hacemos (es decir, programadores). Dicho esto, creo que muchos programadores complican en exceso lo que hacemos, o al menos hacen una gran parte de lo que realmente es.

Me atrevería a decir que el software que la mayoría de nosotros escribimos no hace nada tan complicado (antes de que te enojes, admito que hay muchas, muchas excepciones). Nos encanta lanzar metáforas para construir una casa u oficina, donde el cliente cambia constantemente sus requisitos o tiene otros que están completamente en desacuerdo, como si eso fuera exclusivo de nuestra disciplina. Bueno, si le contara esa historia a la mayoría de los contratistas, sospecho que se reirían en su cara. No son más inmunes a los requisitos contradictorios, a las peticiones no sensatas y a las demandas cambiantes que nosotros. Un enfoque puro de "cascada" no tiene menos problema con él que para nosotros.

De modo que, de lejos, creo que la mejor manera de ayudar a un no programador a entender por qué una tarea o proyecto en particular es difícil no es crear una metáfora. Es para involucrarlos. Muéstrales un ejemplo de algo trivial y dales una idea de cuánto trabajo realmente tiene que hacer para ese cambio "trivial".

Si tiene pruebas unitarias, tal vez haga una prueba de una línea y luego muéstreles los resultados de sus pruebas antes (que deberían pasar) y luego con una barra roja después de una barra roja. "Allí, puedes apuntar. Mira todo lo que se rompió en una línea de código. Tengo que arreglarlo todo allí". Por supuesto, ese es un ejemplo inventado.

No creo que una analogía le dé a un no programador una verdadera apreciación de la complejidad de lo que hacemos (con la advertencia de que realmente, no es tan complejo). Debe realmente darles una idea del trabajo real que está haciendo, lo que en realidad requiere un pensamiento mucho más crítico que una simple analogía inteligente.

Cuando entrega el proyecto tarde debido a que la gestión del proyecto es escasa y produce estimaciones poco realistas ...

"Si agregamos algunos programadores más al proyecto, ¿crees que lo haremos a tiempo?"

Puedes responder con

"Mi esposa está teniendo un bebé, el médico dijo que tomará 9 meses, pregunté si usamos otras 2 mujeres y podríamos hacerlo en 3".

Rico

Deje que la otra persona hable y haga preguntas difíciles. También podría ser una estrategia válida. ¿En qué figuras se basa su opinión?

Las figuras son más fáciles de entender.

¿Tienes un número de

Elemento de lista
casos de uso
requisitos
desarrolladores involucrados en proyectos similares
Compañías o productos de terceros necesarios.
usuario
sitios
...

¿Necesita sincronización? También es un buen punto para encontrar metaphers.

¿Existe una gestión del riesgo? ¿Cuál es el impacto de las fallas? Un programa de PC estándar no es crítico, pero ¿qué sucede si su programa calcula valores incorrectos o ya no funciona?

¿Cuál es la dificultad de programar un sistema operativo? Sé cómo usarlo :) No es una respuesta válida, ¿verdad?

Buena suerte

Desplácese por las miles de líneas de código realmente rápido para ellos. Diga "Si un personaje está equivocado, todo esto no funcionará".

Otro:

Es como escribir una novela, excepto si hay un solo error tipográfico o gramatical, todo esto no tiene sentido.

El objetivo principal de la aplicación empresarial a menudo es ayudar a la comunicación dentro de una organización. Entonces, cuando trato de describir la complejidad de una aplicación comercial, a menudo tiendo a desglosar la comunicación comercial diaria entre la persona X y la Y. ¡Y pulverizarla!

Esto hace que sea más fácil para la persona sin experiencia en programación transmitir la complejidad. Porque no solo tienes que hacer que X e Y hablen, también tienes que inventar su lenguaje. etcétera etcétera.

Espero que esto ayude =)

El orador casi ciertamente significa " pintar la Capilla Sixtina [techo]". ¿Hay algún paralelo significativo?

Michelangelo tuvo algunos problemas con los andamios sugeridos por el arquitecto original. Terminó construyendo su propio marco.

Miguel Ángel era escultor y tuvo que aprender a pintar frescos para completar el encargo.

El papa Julio II originalmente quiso pintar 12 figuras, de los apóstoles. Miguel Ángel negoció una mano libre en la elección del tema y entregó escenas del Antiguo Testamento que representan más de 300 figuras. Él hizo toda la pintura a sí mismo.

El proyecto continuamente se quedó sin dinero (porque el Papa siguió librando una guerra con los estados circundantes).

Así que veamos. Gran dependencia de una prima donna técnica, problemas de flujo de efectivo, no entrega según las especificaciones del cliente ... Tiene razón, parece que no hay ningún proyecto de software del que haya oído hablar.

El problema que encontré es que a veces las cosas simples son mucho más complejas de lo imaginado. Por ejemplo, simplemente podrían decir: "Cada vez que esto sucede, haz que haga esto". Y son cambios simples, pero terminan requiriendo muchos códigos o comportamientos complejos / con errores.

Para explicarlo, es un poco complejo. Si su jefe de proyecto le está dando un mal momento porque es simple para él, entonces lo que tiene que suceder le da tiempo. Di que no está listo, entonces muestra lo que tienes. Eventualmente, aprenderán que cuando dices que va a tomar X cantidad de tiempo, que realmente quieres decir que va a tomar X cantidad de tiempo.

En 1982, estaba diseñando una nueva máquina de prueba de electrónica principal para Intel. Fue para la prueba de chips de microcontroladores (familia de microcontroladores 8X4X). Me preguntaron por qué demoraba tanto un técnico en ingeniería de productos (estaba en ingeniería de pruebas). Pero la pregunta tenía una actitud detrás. Estaba solo un año fuera de la universidad en ese momento.

Le pregunté: "¿Alguna vez has diseñado una máquina de prueba?"

Rápidamente se dio cuenta del problema con su pregunta.

Espero que esto ayude.

En algunos proyectos tengo ganas de tratar de colocar un pulpo en una caja pequeña. Y con algunos proyectos siento que estoy armando un rompecabezas hecho de una película en ejecución. Probablemente no sea la metáfora para explicar algo a un cliente, sin embargo :)

En una entrevista, recuerdo que Moby dijo algo al efecto de ...

A veces pienso que debería reformular "Todo está mal" a "Todo es complicado".

Eso es software.

O realmente leen , dales:

I Sing the Body Electronic: un año con Microsoft en Multimedia Frontier , que es probablemente el mejor libro que he leído que podría brindar a los legos una perspectiva del desarrollo de software. (De hecho, como estudiante que no es de CS, fue uno de los libros que me llevó a quedarme con el software).

Escribir un sistema de software es como escribir una historia. Es un esfuerzo creativo cuya coherencia depende directamente del escritor. A medida que la historia avanza, los puntos (requisitos) de la trama cambian y los personajes se introducen, se forman y se cortan según sea necesario (refactorización). La comprensión de la historia (dominio) está en constante evolución, y ciertos detalles simplemente no se pueden conocer hasta que se escriban partes relevantes de la historia.

El código es una expresión de ideas; por lo tanto, un desarrollador tiene más en común con ser un autor que ser un ingeniero. Como se ha mencionado en otras respuestas, la analogía de construir una casa (o automóvil o puente) no está a la altura de la tarea. Nosotros como pueblo hemos estado elaborando esos patrones durante siglos; solo hemos estado desarrollando software durante ~ 60 años (como industria para ~ 25). Si la ingeniería mecánica fuera una analogía sólida para el desarrollo de software, no tendríamos los problemas que hacemos con las estimaciones.

Esta es una de mis metáforas favoritas para describir la ingeniería de software:

Imagina que estás construyendo una casa. Tendría que tener planes para la casa y decidir qué materiales construir y cómo organizar el proceso de construcción. (La mayoría de las personas han realizado trabajos en su casa, por lo que tienen un concepto aproximado de lo que implica esto).
Ahora imagine que no está construyendo una casa, está construyendo un rascacielos con 100 pisos de oficinas. ¿Cómo serían los planes diferentes a los planes para la casa? ¿Cómo deberían ser diferentes los materiales? ¿Qué factores deberían ser considerados cuidadosamente?
Ahora imagina que no estás construyendo el rascacielos tú mismo, estás construyendo un robot que volará a la Luna y construirá el rascacielos allí. Ahora, ¿cómo tendrían que ser diferentes los planes? ¿Cómo deberían ser diferentes los materiales? ¿Ves por qué las ramificaciones de cada decisión deberían analizarse cuidadosamente?

Podría reemplazar "skyscraper" por "sistema de gestión de fletes" si quisiera, y creo que la metáfora aún sería útil.

Hábleles a través de toda la lógica que tuvo que programar para los escenarios de casos de borde.

Por ejemplo, piensan que el informe sobre Número de Contenidos Enviados es bastante simple, porque simplemente seleccionan un rango de fechas y aparece un número. Dígales acerca de cómo el código debe buscar los contenedores que aún no han llegado a su destino, debe verificar que los contenedores no se devolvieron al remitente, si el contenedor fue retenido por la Aduana porque parecía sospechoso, entonces tiene que conéctese a un servicio web de la Oficina de Aduanas para verificar el estado del contenedor, debe ignorar los contenedores que se cancelaron, los que se perdieron en el mar debido a que un barco se hundió como parte del envío, pero solo si el barco se hundió más de 120 náuticos millas de la costa de los EE. UU., Reino Unido, Francia, Japón o China, o 30 millas náuticas de la costa de cualquier otro país, los contenedores destruidos durante un incidente de tráfico se cuentan siempre que el conductor del camión no haya tenido la culpa, los contenedores que solo los objetos desaparecidos no se cuentan hasta que se pierden durante al menos 6 meses, y así sucesivamente.

Esto le da a la gente una idea de la abrumadora cantidad de "detalles menores" que debe tener en cuenta un programador, incluso en programas aparentemente simples.

La primera pregunta que tendría es quién es tu audiencia? ¿Es esta gestión? ¿Por qué importa que esta persona entienda la complejidad?

Suponiendo que es crítico para el negocio que esta persona tenga una comprensión moderada de la complejidad del sistema, puede tomar la decisión de mostrar una visión general del sistema, entrar en los detalles de un aspecto y luego preguntar qué aportará sobre dónde podría ser simplificado También es posible que esta persona realmente tenga una aptitud única para comprender su complejo sistema, por lo que para ellos realmente no es complicado. En cualquier caso, involucrándolos e invirtiendo en el desarrollo del sistema, pueden pasar de ser sus críticos más duros a convertirse en su campeón.

La programación involucra una plétora de condiciones y acciones superpuestas. Si una condición no es 100% correcta, entonces el programa puede realizar la acción incorrecta. Y las computadoras no perdonan.

Al igual que un maestro de ajedrez que anticipa los movimientos de sus oponentes, el trabajo del programador es anticipar cada escenario y tenerlo en cuenta en el código.

A medida que el proyecto crece, el tablero de ajedrez crece y la necesidad de perfección se vuelve exponencialmente más difícil de manejar para un solo programador.

Me gusta comparar los proyectos de programación con los aviones. Hay una amplia gama de complejidad en los aviones. Una aplicación de bajo nivel, simple pero funcional puede ser un biplano de la Segunda Guerra Mundial. Tiene un uso limitado, pero en el contexto correcto es la herramienta adecuada. Por otro lado, cuando empiezas a mirar un avión comercial y el nivel de detalle / complejidad necesario para construir uno, tienes una historia completamente diferente. No solo tiene que ser capaz de volar, las personas que lo usan deben estar seguras y cómodas mientras lo usan. Si el avión (aplicación) se estrella o tiene retrasos excesivos, el pasajero (usuario) se siente frustrado / insatisfecho. Si sucede lo suficiente, encontrarán una nueva aerolínea. Puedes correr con las complejidades del avión a lo largo del camino que necesites.

La otra gran diferencia en los aviones es el nivel de habilidad y la cantidad de personas necesarias para volar / mantener el avión. Un hombre puede volar / mantener un biplano, pero necesita un equipo más grande con más entrenamiento / horas de trabajo para tratar con un avión comercial.

No es cirugía de cohetes.

No puedo ayudarme a mí mismo, pero solo debo publicar este video de That Mitchell & Webb Look:

Cirujano del cerebro - That Mitchell & Webb Look, Serie 3 - BBC Two

De este modo, podría ayudar a demostrar que la planificación de un proyecto de software implica muchos de los mismos problemas que la planificación de la construcción de una capilla. Tienes muchos aspectos muy diferentes que gestionar y si alguien comete un error en la base, todo se rompería.

No.

Sinceramente, no hay.

Lo mejor que puede hacer es hacer que el usuario final realice un juego de roles en la computadora, de modo que tengan que pensar en cada caso de uso hasta que se den cuenta de lo complejo que es el proceso.

Podría evitar la metáfora de la casa. Cuando construimos nuestra casa hace 3 años, estábamos horrorizados por lo diferente que era un proyecto de ingeniería. Te juro que el fontanero y uno de los carpinteros adiestrados debían de estar borrachos.

Muéstrale a este chico tus especificaciones funcionales. Comenzará a tener una idea de la cantidad de detalles involucrados en la creación de la aplicación.

Programar es como enseñar a un bebé . Tenga en cuenta esto: imagínese que quiere explicar a un bebé cómo ir a comprar zanahorias. Harás lo mismo que enseñar a un robot.

Primero tiene que aprender a caminar. Caminando la subrutina. No voy a entrar en detalles, pero él debe colocar un pie delante del otro y equilibrar su peso. Tienes que gestionar la excepción cuando se cae o se enfrenta a un obstáculo.

Entonces él necesita especificación geográfica en la ubicación del supermercado.

Se le debe decir que use la subrutina para caminar hasta que encuentre el mercado. Si no encuentra el mercado en un tiempo razonable (debe definirse), debe iniciar la rutina de regreso a casa.

Si encuentra el supermercado, debe ubicar las zanahorias utilizando el algoritmo de reconocimiento de zanahorias. Debe comparar cada objeto con el modelo 3D de zanahoria de su banco de datos. Razonable de nuevo el tiempo (o timeout).

Luego, debe evaluar un lugar para intercambiar estas zanahorias con dinero para obtener acceso permanente a las zanahorias. Esta parte podría ser realmente complicada.

Luego, debe evaluar el precio según los precios internacionales de las zanahorias actuales en comparación con los recursos necesarios para obtener zanahorias de menor precio en otra ubicación.

Estoy a la mitad del proceso y captas mi deriva. Y omití MUCHAS comprobaciones y excepciones, evaluaciones, reconocimientos, etc. Tomaría meses, quizás años, para que un equipo completo de desarrolladores programara esto. Y solo va comprando zanahorias.

Lo que estoy tratando de decir es que cuando estás desarrollando una aplicación, tienes que "decirle" todo, literalmente todo. Por cada detalle que no esté claramente especificado, tendrá sorpresas: comportamientos "aleatorios", errores o un simple apagado. Tiene que decirle al programa qué hacer en situaciones generales y cómo adaptarse cuando la situación cambia. Programar es como enseñarle a un bebé una tarea muy compleja.

Luego viene la peor parte. No puedes sostener la mano del bebé durante todo el proceso. Asegúrate de que lo tiene todo y déjalo ir. 2 posibles resultados: todo funciona bien de principio a fin como se esperaba (nunca sucede) o el bebé está sentado en algún lugar en medio de su tarea, llorando, y no puede preguntarle qué salió mal. Solo está llorando y no se detendrá. Y entonces comienza la depuración.

¡Ahora puede imaginar mejor cuánto esfuerzo es necesario para construir un software que gestione la bolsa de valores, o una cortadora de césped automatizada, o un avión! ¿Cuánto tiempo necesitarías para enseñarle a un bebé cómo pilotar un avión?

Recordaría una vieja anécdota que una vez escuché:

Un mecánico de automóviles le pregunta a un cirujano: "¿Por qué ganas tanto? ¿Qué podrías estar haciendo tan complicado? Mi trabajo con los motores me parece muy complejo y desafiante, y soy muy bueno en eso. Puedo arreglar cualquier cosa que está mal con un motor! "
El cirujano luego pasa, gira el encendido y arranca un automóvil. Luego mira al mecánico: "Bueno, ahora arréglalo".

Se puede comparar con proyectos de software anteriores.

¿Recuerdas ese viejo proyecto X, y que tardaron unos 6 meses? Bueno, el nuevo proyecto Y es más o menos ese complejo.

Si esto falla, compara tu proyecto con otros proyectos que requieren ingeniería física del mundo real. Algunos proyectos son como diseñar y construir una casa, otros son más como un puente.

Es incluso mejor si puede encontrar proyectos de ingeniería que su empresa haya realizado como base de comparación, por supuesto, esto depende de su industria.

Si no es como construir la Capilla Sixtina, tal vez es más como construir una casa. Se construyen muchas cosas diferentes para construir una casa, con diferentes personas involucradas en diferentes especialidades. ¡Nada es demasiado complicado, pero hay mucho trabajo involucrado!

El problema es que realmente no es como construir una casa; es más como construir una casa que cambia todo el tiempo . Sin embargo, para propósitos de complejidad, esto podría ilustrar su punto de manera más efectiva.

Todo el mundo entiende McDonalds. Si tienes un montón de dinero en efectivo, obtienes una franquicia y alguien entra y establece todo para ti. El software es como obtener la franquicia y luego tener que hacer todo por ti mismo ...

Encontrar propiedad
Oferta en la propiedad
Comprar una propiedad
Consigue un equipo de construcción para construir un edificio de concha que se parezca a otros McD''s
Encuentra y compra el equipo necesario.
Instalar equipo
Conseguir computadoras
Escribir software de punto de venta
Coloque la computadora en la ventana del vehículo y escriba el código para enviar las órdenes a las aletas de hamburguesas
Escribir software de tarjeta de tiempo
Escribir software de nómina.
Instalar e informatizar el sistema de seguridad.
Contratar tripulación competente
Tripulación del tren
Comprar acciones
Escribir software para rastrear stock
Escribir software para anticipar órdenes de stock.
Etc.

Tienes la idea Hay muchas cosas que van en desarrollo que el promedio de Joe no se da cuenta. McDonalds aparece como magia. Pero hay mucho que se necesita para conseguir (y mantener) una ejecución.

Una metáfora no le hará ningún bien si la persona tampoco lo entiende. Debe intentar explicar la complejidad a la persona en términos que pueda entender. Si es posible, intente relacionarlo con una situación de trabajo compleja que puedan experimentar.

Para un contador, usted podría decir algo como: "Esto es como tomar una calculadora y auditar la Reserva Federal de los Estados Unidos por su cuenta"

Una metáfora que a menudo uso con los laicos es que construir software no es como construir un puente:

Si está construyendo un puente, puede comprar vigas en I y remaches, y puede verter concreto estándar. Si está creando software, tiene que hacer sus propias vigas en I y remaches, y es posible que tenga que inventar concreto no estándar.
Cuando el puente está medio completado, nadie le dice que debería funcionar por la noche como un drive-in cine. Pero en el software, las solicitudes de cambio de última hora son comunes.
Se puede decir cuando un puente está medio completado. No se puede decir cuando el software está medio completado.
Al usar rayos X, ultrasonido y otras herramientas, puede estar seguro de que un puente está libre de fallas estructurales, antes de que se use el puente. Pero incluso con las mejores prácticas en pruebas, muchos errores en el software no se pueden descubrir hasta que se utiliza el software. Y es muy difícil saber cuánto tiempo tomará corregir una falla en particular o cuándo se ha descubierto la última falla importante.

Todos estos factores ayudan a explicar por qué es difícil predecir cuánto tiempo tomará un proyecto de software y por qué los proyectos de software suelen llegar tarde.

acaba de ser de piel más gruesa. A menos que sea el jefe, no tienes que explicar nada. y, por cierto, nunca lo conseguirás a través de las personas que piensan que pasas todo el día en Internet (cómo, irónico). Esto va para los programadores, la gente del servidor, y así sucesivamente.

¿No sabías que no hacías nada para vivir?

Edición: Tengo un voto negativo sin razón ...

tal vez no pueda decir por qué es complejo, pero puede hacer referencia al trabajo en la complejidad.

¿Se puede decir que es tan complejo que 10 personas deberían trabajar en este proyecto 2 años?