El Negocio del Software

Así se llama un libro de Michael Cusumano. Profesor distinguido del MIT. Asesor de multinacionales como Toyota y otras empresas en Estados Unidos y Japón.

En este libro hay una guía corta muy buena que puede servir como anticipación a problemas en el crecimiento de cualquier organización. Si se lee con atención, se puede aprender mucho en un instante. Traduciendo literalmente el libro:

"(...) los mismos problemas que fueron comunes en los 60, han reaparecido con turbadora regularidad en los 80, 90 y 2000. De hecho, una de mis listas favoritas de problemas típicos en desarrollo de software, vienen de una lista compilada en la conferencia de ingeniería de software de la OTAN en 1968 (...)"

The Business of Software de Michael A. Cusumano

Reporte de problemas de ingeniería de software. Comité de ciencias de la OTAN. Bruselas. 1968.

En la Página 131, encontramos la Tabla 4-1 con este listado de interesantes consejos orientados a mejorar el desarrollo de software:

  • Falta de entendimiento en requerimientos en la parte de usuarios y diseñadores.
  • Grandes diferencias entre costos estimados y tiempo con gastos debidos a pobres técnicas de estimación.
  • Errores a la hora de reservar tiempo para realizar cambios en requerimientos.
  • División en tareas de programación dentro de equipos antes de que la necesidad se haya comprendido lo suficientemente bien cómo para hacerlo debidamente.
  • Largas variaciones –de hasta 26 a 1 según un estudio– en los niveles de productividad de los programadores.
  • Dificultad para dividir trabajos entre el diseño y la producción (código fuente), dado que las decisiones de diseño deben aún ser tomadas mientras se escribe el código.
  • Dificultad para monitorizar los progresos en un proyecto de software, dado que "la construcción del programa no es siempre una simple progresión, en la cual cada acto de ensamblaje represente necesariamente un paso hacia adelante".
  • Rápido crecimiento en el tamaño de los sistemas de software.
  • Pobre comunicación entre grupos trabajando en el mismo proyecto: exacerbada por demasiada descoordinación o innecesaria información
  • Ausencia de automatización para manejar información necesaria.
  • Excesivo gasto en desarrollo de herramientas online de control de producción.
  • Dificultad para medir aspectos clave del programador y del rendimiento del sistema.
  • Programadores que no escriben sistemas "para uso práctico" que tratan de escribir nuevos y mejores sistemas, por lo que siempre están combinando investigación, desarrollo y producción en un mismo proyecto, lo que lo hace difícil de predecir y controlar el resultado.
  • Rápido crecimiento en la necesidad de programadores e insuficiente número de programadores adecuadamente entrenados y capacitados.
  • Dificultad de alcanzar fiabilidad, entendida como reducción y tolerancia a errores, en grandes sistemas de software.
  • Dependencia del software en el hardware, lo que hace la estandarización mucho más compleja entre diferentes máquinas.
  • Ausencia de inventarios de componentes de software reutilizable para asistir en la construcción de nuevos programas.
  • Costes de mantenimiento de software con frecuencia excediendo el coste del desarrollo del sistema original.

Cómo presentar y vender software

Si os ha gustado este artículo y queréis continuar profundizando en el negocio del software, el siguiente paso una vez se dispone de un producto, es aprender a valorar, presentar y vender el software. En el enlace anterior disponéis de una interesante guía con consejos prácticos para ello.

Anterior
Anterior

Lo que no nos enseñaron en clase de matemáticas

Siguiente
Siguiente

¿Qué es el sistema OKR?