5 dilemas éticos de la ingeniería en

sistemas
– Mea culpa. Ocurre cuando el equipo debe entregar un producto software, este tiene algún
problema que ellos conocen o aún le faltan importantes funcionalidades y, aún así, es entregado.
Ocurre por la presión del mercado, las penalizaciones de los contratos, etc.

– Trabajo realizado de manera apresurada. Ocurre cuando el software funciona pero su calidad es
muy baja, se ha desarrollado demasiado rápido, normalmente como consecuencia de la presión
del calendario, de ofertas con tiempos por debajo de lo necesario, etc.

– Ese no es mi problema. Ocurre cuando el equipo de proyecto se centra en el día a día, sin
mostrar proactividad, tendencia a mejorar la productividad o la calidad, esos “no son mis
problemas”.

– Mentir. Ocurre en reuniones con el cliente o con la dirección del proyecto, cuando se dicen
cosas que no son verdad, como, por ejemplo, que la entrega del software se ajustará al
calendario… a sabiendas de que es imposible.

– Software inviable. Ocurre cuando una organización promete a un cliente un software con
características inviables de implementar, muchas veces por presiones de mercado, por cumplir
objetivos de venta, obtener comisiones a corto plazo y luego gestionar qué realmente se podrá
entregar… pero una vez conseguido el proyecto.

– Falta de revisión. Ocurre cuando cierta documentación importante no se revisa lo suficiente.

Cuando las propuestas, las especificaciones de requisitos, contratos, etc., no son examinados a
fondo. Esto suele provocar problemas a la hora de cerrar el proyecto, de conseguir la aceptación
por el cliente, de evitar penalizaciones o incluso de poder cobrar.

– Cancelación de vacaciones. Ocurre cuando la dirección del proyecto presiona a los miembros del
equipo con la amenaza de cancelar sus vacaciones, para así poder cumplir cierto hito del proyecto
(ay, que recuerdos me trae esto, recuerdo cierto proyecto que se presentó al cliente diciendo que
éramos la oferta con menores tiempos de desarrollo… eso sí, marcando en el Gantt, de manera
consciente, los sábados y domingos como día en el que se trabajaría desarrollando software)

– Barrer bajo la alfombra. Ocurre cuando aparecen imprevistos, que potencialmente pueden
afectar al proyecto, y estos son conscientemente ignorados, con la falsa esperanza de que
desaparezcan solos. Ejemplo, alguien del equipo de pruebas detecta un fallo, lo comunica al jefe
de proyecto y este decide “olvidarlo” porque ese error es muy raro que se dé en el cliente