Errores comunes en desarrollo software (IV y final)

Por parte del producto como objetivo final nos encontramos con los siguientes problemas:

Requisitos de “placa dorada”. Requisitos no tan importantes para el usuario como nosotros pensamos, obsesión por el desempeño y otros factores que como informáticos puedan parecernos clave pero que un usuario no valorará tanto. Alargan la calendarización, y si les damos demasiada importancia, restaremos valor a otros requerimientos clave para el cliente.

Inestabilidad de los requisitos. Algo presente siempre, por lo tanto es fundamental vigilar y controlar los cambios en los requisitos. Alarga la calendarización.

Desarrolladores de “placa dorada”. Los programadores suelen estar ansiosos por utilizar una nueva tecnología, herramienta o técnica que ha aparecido en el mercado, aunque no sea necesaria para el proyecto. La investigación en nuevos campos conlleva gran incertidumbre, y esto alarga la calendarización, además de aumentar riesgos.

Negociaciones de tira y afloja. Es extraño que cuando se negocia un deslizamiento en la estimación de un producto automáticamente alguien añade nuevas funcionalidades, lo cual invalida la nueva estimación…

Desarrollo orientado a investigación. Si quieres desarrollar proyectos, no te sumerjas demasiado en investigar nuevos algoritmos, técnicas, etc. El riesgo de fracasar o ralentizar el proyecto es muy elevado. Desde luego que, si no te queda más remedio hazlo, pero cuenta con el riesgo que ello conlleva y desde luego no esperes terminar el proyecto en un tiempo récord, precisamente.

Finalmente, en cuanto al factor tecnológico:

Síndrome de la bala de plata. No dejes que los equipos confíen demasiado en una nueva técnica, herramienta, etc. como si fuera la solución de todos los problemas. Las balas de plata no existen en informática; no creas lo que te venden los comerciales…😛

Ahorros sobreestimados de nuevas herramientas o métodos. Las organizaciones no mejoran su productividad a grandes saltos, sino en pequeños avances; entre los inconvenientes de utilizar nuevas tecnologías están: riesgos de utilizar algo tan novedoso que pueda no tener soporte para el cliente, adecuación, curva de aprendizaje, etc. Otro ejemplo de esto podría considerarse el reutilizar software. Nuevamente, el ahorro no es tan grande como se podría prever en un primer momento.

Cambiar las herramientas a mitad de proyecto. Casi nunca funciona bien. La curva de aprendizaje, rehacer el trabajo ya hecho, errores inevitables cometidos por el desconocimiento de la herramienta… ralentizan el proyecto.

Falta de control automático del código fuente. Expone al proyecto a riesgos innecesarios. Es fundamental utilizar un buen software de control de versiones, junto con una buena política de gestión de configuraciones. Muchas empresas se conforman con adquirir buenas herramientas de control, pero se olvidan de que sin una buena política de gestión de configuraciones la herramienta no es más que un soporte, algo que puede considerarse incluso como un elemento lelo si se utiliza sin cabeza.

Es posible que redacte en próximas entregas lo que bajo mi punto de vista sería una solución a todos estos problemas. No quiero decir con ello que tenga la solución a todos los problemas, que sea un gran consultor ni nada parecido; simplemente reflejaré lo que los autores aconsejan sobre esto y expondré qué cosas se podrían hacer para paliar estas situaciones. Y desde luego que exponer una solución no es el final de todo. No existen balas de plata, recordemos, y la aplicación de tales soluciones será unas veces más sencillo y otras más complicado, requiriendo en algunos casos de la implicacion de todo el equipo para alcanzar el éxito. Tampoco existen garantías absolutas, pero sí podemos aumentar nuestras posibilidades, y  por esto bien puede merecer la pena el esfuerzo.

3 pensamientos en “Errores comunes en desarrollo software (IV y final)

  1. Muy interesante el post. Cuanta razón tienes.
    Con toda humildad, quisiera comentarte que hemos creado un sitio web para facilitar las relaciones de negocio entre los profesionales del sector de las Tecnologias y las Empresas. Puedes vernos en http://www.softauction.es y los sitios asociados (te recomiendo el blog en especial).
    Si te hemos hecho perder el tiempo, nuestras disculpas por adelantado.

  2. Por cierto, incluiria una opinión constructiva (sic):
    – No disponer de un interlocutor valido en el cliente ni en la gestión del proyecto. En la finalización de un proyecto de desarrollo sw se producen momentos donde hay que decidir; si no tienes a nadie que pueda ayudarte a tomar esas decisiones de forma coherente, el proyecto puede naufragar.

  3. Hola, estoy buscando un software libre de la escuela que debe tener toda la funcionalidad necesaria para ejecutar un trabajo de gestión de la escuela. Las cosas básicas principales que debe incluir la gestión de bibliotecas relacionadas con el alquiler libro o su envío a los estudiantes asignados.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s