Hacer que los no programadores entiendan el proceso de desarrollo

Al comenzar un proyecto para una empresa que no es principalmente una empresa de programación, una de las expectativas es que al final haya un producto terminado libre de errores y que haga todo lo necesario de inmediato. Sin embargo, rara vez es el caso.

¿Cuáles son algunas formas de gestionar las expectativas y explicar a los no programadores cómo el desarrollo de software difiere de otros tipos de desarrollo de productos?

Casi todos los que tienen una computadora han encontrado el concepto de "errores" en estos días, por lo que puede comenzar allí. "¿Cuál es la forma más molesta que una aplicación le ha fallado? Multiplique eso por diez y obtendrá la experiencia de nuestros usuarios si no dedicamos suficientes recursos a las pruebas y el mantenimiento".

Y no subestime el valor de establecer una buena relación de trabajo con los no programadores. Si puede establecer que su juicio puede ser confiable, lo tomarán en serio cuando haga sonar la alarma de que X va a fallar espectacularmente si no lo hace pronto, incluso si no entienden completamente su razonamiento.

Un enfoque que he encontrado exitoso es este:

Todos sabemos que una computadora solo hace y exactamente lo que se le dice que haga.

La programación es la forma en que le decimos a una computadora ahora qué hacemos después .

Esto significa que la forma en que se comporta su comportamiento ahora se debe a las intenciones combinadas de todos los que escribieron el código que se ejecuta en su máquina. Cuando considera la complejidad del sistema operativo, los controladores, el entorno de programación, las bibliotecas, etc., es fácil ver que en la mayoría de los sistemas debe haber más de 20 mil personas involucradas y que podría haber más de 100 mil.

El código escrito por cada persona refleja su propia comprensión, motivación, intención y capacidad. Dado que el funcionamiento impecable del sistema requiere que todo el código escrito por estas 20k personas interactúe sin error, que todo el código debe estar de acuerdo con el significado y la interpretación del comportamiento requerido, el hecho sorprendente no es que tengamos errores, sino que tenemos tan pocos de ellos.

En mi opinión, descubrí que la transparencia ofrecida por los procesos ágiles (por ejemplo, Scrum, Crystal, etc.) ayuda mucho a mostrar cómo funciona el desarrollo para la parte interesada promedio.

La explicación por metáfora es una abstracción permeable, pero aquí hay algunas ideas que a menudo funcionan para mí:

Tenga en cuenta que ninguna de estas explicaciones excusa el trabajo descuidado.

Piense en un programa de computadora como máquina, donde cada variable es una parte móvil. Eso hace que incluso un programa trivial sea una máquina compuesta por cientos de partes móviles.

Cuando eso falla, recurro al hecho de que, si bien es matemáticamente posible demostrar que un programa no tiene errores, lleva mucho tiempo y no valdrá la pena el esfuerzo.

Finalmente, pregunto si Intel y Microsoft no pueden evitar errores, ¿cómo esperan que lo hagamos?

He respondido una pregunta similar con más detalle , pero la esencia es: "La programación es como construir una fábrica o una línea de montaje".

La forma tradicional de expresarlo es el Triángulo de gestión de proyectos: los tres criterios competitivos de alcance, costo y cronograma; típicamente expresado como "barato, rápido, bueno, elige dos".

Al final de un proceso de diseño, desarrollo e implementación, la expectativa de que un producto esté relativamente libre de defectos de diseño y funcione con una funcionalidad específica es perfectamente razonable. La misma expectativa es completamente irracional con respecto a un proyecto, proceso o profesión.

Lo profesional basado en las ciencias, duro o blando, no pasa por un proceso de exploración, formando conceptualizaciones inexactas e imprecisas, siguiendo tácticas menos que óptimas (o simplemente erróneas), descubriendo lo que funciona a través de prueba y error, y repitiendo ¿Procesar una y otra vez hasta que se agoten los recursos o se alcance un nivel suficiente de rendimiento?

Ningún proceso está libre de fallas, aunque puede acercarse asintóticamente a niveles de calidad más altos.

Eso es cierto para la profesión médica, donde las tácticas a menudo implican conjeturas y protocolos, y gran parte de la actividad consiste básicamente en depurar una máquina principalmente de software. Es cierto en el caso de la ingeniería civil y la arquitectura, donde las aplicaciones de nuevos materiales de ingeniería deben validarse en el campo y pueden fallar abruptamente después de años de servicio a pesar del estricto cumplimiento de las normas. Es cierto en el campo automotriz donde la edad y los cambios en las condiciones de operación comúnmente afectan el rendimiento hasta el punto de falla, sin culpa de los servicios de ingeniería o reparación aplicados. El desarrollo de software no es fundamentalmente diferente de estas profesiones en tales aspectos, solo tiene una mayor parte de su enfoque involucrado en inventar máquinas novedosas y útiles.

Si está familiarizado con el desarrollo de software de alta resolución, como para el control de reactores nucleares, comunicaciones en el espacio profundo o dispositivos de implantes médicos (etc.), puede explicar cómo se estructuran el costo y el tiempo de entrega para ese nivel de gestión de proyectos y control de calidad podrían ser magnitudes mayores de lo que las empresas típicas pueden pagar por sus proyectos de software.

Puede compararlo con algo que puedan ver y, si es posible, usar todos los días.

Por ejemplo, el automóvil. Los autos comenzaron con dispositivos mucho menos refinados y confiables que los que tenemos hoy. Si bien los automóviles se han fabricado durante más de 100 años, el software probablemente sea la mitad de ese tiempo. Los automóviles están disponibles con una personalización significativa, algunos incluidos en el precio (como la elección del color), otros como el tamaño del motor, el tipo de transmisión, la rueda / el neumático, el nivel de equipamiento son los conductores de costos significativos.

Hay muchos controladores de características, calidad y costo para automóviles y para software. Luego, puede discutir cómo la tecnología de software, la disponibilidad de experiencia, tal vez incluso donde se construye, harán una gran diferencia. Los ciclos de desarrollo apropiados (por ejemplo, modelos anuales con pequeños cambios, cambios en la carrocería / motor / plataforma cada tres años aproximadamente) están impulsados ​​por una combinación de las necesidades del cliente y un proceso de diseño complejo. Algunos productos comienzan con un aspecto pequeño y rechoncho (piense en el Honda Accord), pero mejoran cada año hasta que obtienen la mejor calificación.

Los automóviles tienen retiros (a menudo mucho más costosos que las actualizaciones de software) y mejoras incrementales en la forma de ejecutar cambios en sus listas de partes (piense en las correcciones de errores), y a menudo necesitan soporte a largo plazo (piense en la compatibilidad hacia atrás / adelante). Gran parte del costo de su automóvil viene después de conducirlo a casa. Gran parte del costo del software viene después del lanzamiento inicial del producto a medida que actualiza y actualiza a los clientes.

En algunos casos, puede hacer referencia a productos conocidos que incluyen software u otros productos de software. Por ejemplo, los teléfonos tienen un ciclo de lanzamiento y actualizaciones y métodos para agregar funcionalidad después de la venta inicial para generar más ingresos. Los teléfonos son una excelente ilustración de la compatibilidad hacia adelante / hacia atrás. Demasiado, y la gente no va a tirar el viejo para comprar uno nuevo. Demasiado poco, y los clientes se desesperan por tener un teléfono que no odiarán antes de que termine su contrato.

Productos como Windows, Microsoft Office, navegadores web y páginas web son todos software que se pueden usar en debates. Se han actualizado en ciclos anuales o de tres años, pero pueden tener actualizaciones automáticas con más frecuencia. Tienen errores y agujeros de seguridad que afectan a los clientes en diversos grados, pero son parte del panorama a pesar de nuestros mejores esfuerzos. Los clientes pueden obtener arreglos gratis, pero generalmente pagan por mejoras, a menudo como un paquete, a veces como un módulo individual o mediante una clave de licencia.

Los líderes de la industria como Microsoft, Apple, Google y Amazon ofrecen clientes relativamente baratos a los usuarios. Pero tienen enormes gastos que permitieron esos productos. Su experiencia muestra que el software es costoso, pero valioso y rentable. A menudo comprometen la calidad, tienen todas las características que desean y entran en los mercados cuando es el momento adecuado. No todos los productos que fabrican son un éxito, y a veces convierten a los perros en ganadores al renombrar, mejorar el marketing y las ventas, o reducir sus pérdidas y usar lo que aprendieron en productos posteriores.

Quizás intente guiarlos, uno a uno o en grupos pequeños, idealmente, use casos de software que tenga que desarrollar. A medida que describen los casos de uso, identifique los puntos en el caso en que podrían suceder cosas diferentes (casos inesperados pero no irrazonables). Comience a enumerarlos, solicite algunas aclaraciones e ilustre todas las decisiones y direcciones que deben tomarse o resolverse, y las compensaciones que se hacen al hacerlo. Continúe hasta que estén perplejos y no puedan darle una respuesta. Haz que entiendan que, lo que estás haciendo ahora con ellos, es exactamente lo que haces todo el día, probablemente solo, probablemente con una dirección mucho menos clara, tanto para decidir el curso como para escribir el código, para cientos o miles de use casos que pueden o no ser presentados por nadie. Y cuando hay En caso de que no haya pensado en usted mismo, no puede garantizar lo que hará el programa. Tal vez hace lo "correcto", tal vez tenga en cuenta. Y eso es un error. Y es por eso que escribir software lleva tiempo. Mientras menos tiempo tenga, menos casos tendrá la oportunidad de considerar y acomodar, y es más probable que el programa no haga lo "correcto" en una circunstancia desconocida.

Costo y tiempo.

Hora

Establezca expectativas de que entregará X en Y cantidad de tiempo. No tendrá nada más, nada menos. Luego dígales cuál será la próxima versión y a qué hora. Al principio, podrían sorprenderse al creer que construir X requiere una cantidad de tiempo Y, aquí es donde se explica el tiempo y la complejidad de construir un software. Si no están sorprendidos, o estimaste mucho menos tiempo o sabían mejor de lo que piensas sobre la creación de software.

Costo

Esto es del libro Code Compete de Steve McConnel (citando de memoria, así que discúlpeme si no pudiera transmitirlo con el mismo efecto). Es fácil para los clientes solicitar nuevas características. Como gerente de producto, no debe decir a lo que el cliente pregunta. Debe estimar cuánto esfuerzo y costo toma construir esta nueva característica. Poco a poco comprenderán que la nueva característica realmente no vale la pena el dinero / tiempo o tal vez que ni siquiera la requieren. No estoy sugiriendo que use este arma para asustarlos, pero hágalo honestamente y podría ayudar a conducir el punto a casa.

Las metáforas son abstracciones permeables, pero son pequeños pasos que lo acercan a la comprensión.

Mi favorito es que el software de construcción a menudo es un proceso similar a la arquitectura de una casa. Sin embargo, es más preciso pensar que se trata de un sistema que imprime un modelo de arquitectura personalizada basado en algunos parámetros y crea uno diferente para cada uno de sus usuarios. En la conversación geek que sea meta-arquitectura.

He descubierto que en realidad podría ayudar cuando les muestras lo que significa escribir código. Muestre a las partes interesadas la base de código con la que está trabajando. Incluso cuando haya elegido buenos nombres de variables y métodos, la mayoría de la gente pensará que está usando algún tipo de magia negra. Tal vez ellos entiendan por qué necesita más que "unos días" para implementar una nueva función para su software.