La ética en llevar un proyecto de software hecho para fracasar

Cristian Alejandro Parra Virgen

A00343783

En los proyectos de ingeniería de software, y en general en la administración de proyectos, existe un tipo de específico que son los de “marcha muerta” o Death March Projects. Estos proyectos tienen ciertas características y son llamados así porque en teoría no son alcanzables, ya sea por el tiempo en el que se están esperando, por los recursos que se le están dedicando o por el alcance que se pretende que tenga. Sin embargo, con todo y que en teoría no son desarrollables, se ponen a la ejecución con la misión imposible de que sean completados de manera exitosa en tiempo y forma. Hay algunos casos en los que sí pueden ser el recurso para salvar una empresa, o un área de la empresa o que son completamente necesarios para que un proyecto más grande y de vital importancia siga vivo y pueda ser terminado de buena manera.

En este ensayo se explicarán las diferentes razones de por qué un proyecto es considerado de marcha muerta, así como las razones de por qué se crean estos planes, se expondrán las partes clave de la administración de proyectos, así como la ética en ellos; la ética de la sobrecarga de trabajo, la ética de los proyectos en general y la ética de la ingeniería.

Este tema es importante en la dignidad humana pues cuando te ves envuelto en un proyecto de este tipo, generalmente significa poner más presión en ti y en las personas que están a tu alrededor en cuestión de trabajo, muchas veces se traduce en largas jornadas de trabajo durante ciertos periodos de tiempo y mucho estrés en todas las personas involucradas en el proyecto, lo que puede dar pie a problemas de salud, incluso la muerte, si se llega a un caso extremo.

Palabras clave: Software, equipo, desarrollo, proyecto, líder, ética, marcha muerta, administración de proyectos, gerencia, políticas empresariales, fracaso, tiempo, recursos, dignidad, desarrollo sostenible, felicidad.

Se plantea que al conjuntar, analizar y planear un proyecto de software, el mismo debe ser viable y feasible para que pueda ser puesto en marcha, de otra manera el proyecto debiera ser revisado y corregido en cuanto a recursos o tiempo antes de ser autorizado para ser ejecutado, pues el fallar en hacer esto haría que el proyecto caiga en faltas a la ética de las personas involucradas, desde el cliente, el líder del proyecto o el equipo de desarrollo.

En un proyecto de software siempre tendremos distintas partes involucradas. En general, se tiene la parte del cliente, al equipo de desarrollo y al líder del proyecto como mínimo, pero podría haber más actores involucrados dependiendo del tamaño del proyecto, como por ejemplo equipo de pruebas, equipo de QA (Quality Assurance) y el equipo de soporte y de infraestructura.

Cada actor tiene una cierta inferencia dentro de los proyectos, pues tienen un propósito distinto. El equipo de desarrollo es el encargado de diseñar, construir e implementar el software que se vaya a crear. Por su parte, el líder del proyecto es quien se encarga de mantener el control del proyecto en cuanto a tiempos, recursos, entregables, documentación y los generales del equipo. El cliente es quien contrata los servicios, no necesariamente será el usuario del sistema, sin embargo es quien paga por el software que será creado.

Dependiendo del proyecto, se tienen los otros actores como el equipo de pruebas, de soporte y de QA. Estos actores sí se requieren dentro de un proyecto de software formal, sin embargo, cuando el proyecto es chico y no necesita de muchos recursos, o la empresa es pequeña y no tiene los recursos, estas funciones y tareas las ejecuta el mismo equipo de desarrollo, por lo que dependerá de la empresa y del proyecto el quien personifique estos actores en cada caso específico.

Hay distintos aspectos a considerar cuando hablamos de un proyecto que está diseñado para fracasar. Comúnmente, pensaríamos que si vamos a diseñar o planear un proyecto es porque este se va a materializar, o al menos esa es la intención normalmente. Pero, ¿qué sucede cuando luego de analizar el proyecto nos damos cuenta que no sería realizable con los recursos y el tiempo que se está presupuestando? La respuesta que quizá sería más obvia es modificar las variables del proyecto de tal forma que se convierte en un proyecto feasible y no en una misión imposible.

Una situación a revisar es cuando la intención de realizar el proyecto de marcha muerta sea que se quiera hacer ver mal a la persona que lo estará manejando, debido a que hay una gran probabilidad de que falle, de más del 50% (Klucznik, 2010), eso normalmente haría ver mal al líder del proyecto al no poder sacar el trabajo encargado en el tiempo y con los recursos acordados. Esto se traduce en atentar contra la dignidad humana pues se le quieren restar méritos al trabajo hecho por otra persona o a las cualidades de esa persona, se intenta reducir la dignidad del líder del proyecto y hacerlo fallar en su trabajo de manera deliberada.

En este caso, estaríamos atentando directamente contra la felicidad, la dignidad humana y el desarrollo sostenible, pues estamos haciendo deliberadamente fallar a una persona en su trabajo, causando infelicidad cuando la meta no se logre. Disminuye la dignidad humana al tratar a la persona como un mero medio, y se lastima el desarrollo sostenible pues estamos dejando que se ponga en marcha un proyecto con la idea de que no se termine, lo que no es sostenible si todos los proyectos fueran de esta naturaleza.

Por otro lado está la situación cuando los proyectos como tal, por situaciones políticas, se vuelven más complicados de lo que inicialmente eran. Por situaciones políticas me refiero a formas de relacionarse los diferentes actores involucrados, así como políticas de la empresa que desarrolla el sistema. Ya sea porque se quiere obtener un beneficio personal, o porque se quiere crear una separación dentro del equipo de la parte gerencial, o incluso porque se crean chismes o secretos personales de otros actores con tal de crear inestabilidad en el equipo. (Alexander, 2017)

En estos casos vemos cómo se afectan varias partes de las personas desde el punto de vista ético, pues se atenta contra el bienestar imparcial cuando se inicia algún rumor contra alguien o se toman decisiones con miras a que se obtenga un beneficio personal. Por otro lado se lastima la libertad humana pues el hecho de que otros busquen aprovecharse del conocimiento de otros, provoca que la libertad de expresión se vea cuestionada, ya que al existir la amenaza de que se roben las ideas, muchas veces se cae en la opción de callar y no decir nada para evitar que la idea sea apropiada por alguien más, lo que atenta directamente contra una forma de libertad del ser humano.

También podemos observar que la igualdad no se respeta en estos casos, pues si se trata de manera distinta a los diferentes miembros del equipo con base en lo que ellos saben o son capaces de lograr, estamos violando la igualdad.

Todo esto en conjunto viola los derechos humanos, pues al atacar alguna de estas formas éticas, estamos afectando el conjunto de derechos a los cuáles eres acreedor por el hecho de ser una persona (Naciones Unidas, s.f.)

Viendo estrictamente las partes éticas de los proyectos, nos podemos dar cuenta que hay diversos documentos que sostienen que hay principios éticos universalizables que pueden ser aplicados a proyectos de ingeniería de software. Tal como lo mencionan los autores Dinsmore y Cabanis-Brewin en su libro The AMA handbook of Project Management. En él se menciona que la ética en la administración ayuda a controlar los riesgos y proteger tanto a los directivos, a los administradores de proyectos, a las empresas y a su imagen pública. También se dice que hay diferentes formas de abordar la ética en la administración de proyectos, desde códigos de conducta hasta principios éticos universalizables. (Dinsmore, 2014) De esta forma, nos damos cuenta que el mantener estándares éticos universalizables en todos los proyectos nos ayuda a llevar un proyecto de manera digna, responsable y satisfactoria para todas las partes, aunque no es garantía de ello, sin embargo, es un buen punto de partida para evitar caer en errores.

Por otra parte, es importante revisar que el proyecto como tal no atente contra los principios éticos y analizar desde la parte ética las intenciones del proyecto como tal, además de estar al tanto de los posibles resultados si no se tiene una ética clara en todos los niveles. “La ética de los proyectos puede ser vista en términos de riesgos y oportunidades, y se reduce a preguntas como ‘¿Deberíamos hacerlo o no?’, ‘¿Qué exactamente deberíamos hacer?’, ‘¿Cómo deberíamos hacerlo?’, ‘¿Cómo deberíamos comunicarlo?’. Consideramos la ética en cinco niveles: el individual, en equipo, la organización, la sociedad y desde la perspectiva de las generaciones futuras. De última, los proyectos pueden fallar, a pesar de una buena planeación y ejecución, simplemente porque son, o aparentan ser, poco éticos en algún nivel.” (Jonasson, 2013) Con esto podemos decir que si en cada paso del proyecto, nos preocupamos por mantener y tomar en cuenta las respuestas a estas preguntas, y hacemos que las respuestas mantengan estándares éticos altos, es decir, principios universalizables, podemos afirmar que difícilmente se llegará a faltar a fines éticos durante el desarrollo del proyecto.

Un factor detonante para que casos en los que las políticas se ven involucradas dentro del desarrollo del proyecto es cuando no se tienen alineados los ideales de la empresa con los del proyecto, o también cuando los objetivos no son claros o no se enlistan tareas específicas para los miembros del equipo, así lo maneja José Linares en su documento de Administración de proyectos de ingeniería del software: "Entre las razones determinantes para proponer un proyecto de sistemas se lista: integrar las áreas de la empresa, el desarrollo de nuevos productos y el aumento en la competitividad de la organización. Para lograr una eficiente planificación de proyectos, la gerencia debe definir los productos a ser obtenidos, la estructura de trabajo del proyecto, el calendario de actividades y los costos directos e indirectos. La organización del mismo debe girar alrededor de la experiencia laboral de cada integrante y la optimización de su productividad." (Linares, 2007) Entonces, si los lineamientos del proyecto se salen de lo que es realizable de acuerdo a experiencias previas y estándares de calidad, o afectan directa o indirectamente los ideales de la empresa, podemos decir que lo que se está pidiendo hacer no es ético, pues atenta contra principios antes mencionados en este texto como la dignidad y la felicidad humana.

Es necesario medir de alguna manera la productividad y tener mediciones e indicadores que permitan hacer acercamientos y proyecciones más acertadas cuando se está realizando un proyecto de software, por ello se requiere de algo como los procesos de PSP y TSP, que pueden dar las bases para desarrollar indicadores claros para cada proyecto. Pero es necesario tener cuidado al medir los mismos, pues mucho tiempo en estas mediciones puede ser contraproducente, ya que ocupa tiempo de los ingenieros y se vuelve una carga para ellos en vez de algo positivo, lo cual puede afectar el desarrollo del proyecto como tal. (Lugo, 2009) Cuando contamos con este tipo de datos, nos podemos dar cuenta fácilmente de si un proyecto se vuelve inviable o fuera de lo razonable, pues no se puede pensar que un proyecto que requiere 2000 horas de trabajo, puede ser completado por un ingeniero que invierte 40 horas semanales por 2 meses, pues sería ilógico; y tratar de hacerlo funcionar caería en atentar contra el desarrollo sostenible, lo cual lo hace un problema ético, pues no se actúa de manera universalizable.

También se requiere revisar de manera general la profesión del ingeniero como tal y su ambiente en el cual se desempeña y sus creaciones, con la idea de analizar la ética de todo eso. Así como lo maneja Cortina: "El ingeniero debe ‘procurar por encima de todo, la seguridad, la salud y el bienestar del público’. Las condiciones laborales influyen en el trabajo del ingeniero. Demasiadas veces las prisas llevan a trabajos de escasa calidad. Un ingeniero que actúa así no adopta el comportamiento ético que le corresponde. Los códigos deontológicos de los ingenieros recogen esta idea: cada ingeniero o empresa de ingeniería debe llevar a cabo sus trabajos con una competencia, un esmero y una diligencia razonables. Cuando el ingeniero proyecta un artefacto es moralmente responsable de lo que hace. No puede excusarse diciendo que las condiciones de trabajo no eran adecuadas. Debería prestar sus servicios únicamente a empresas dignas.” (Cortina, 2005)

Cambiando un poco la perspectiva inicial, podemos decir que cuando un proyecto cae en la categoría de marcha muerta, puede que no sea por falta de planeación o por una mala intención en el proyecto necesariamente, también puede ser por la forma en que se ejecuta o por algunas prácticas mientras se lleva a cabo el mismo, sin embargo, esto no quiere decir que ya no falte o no atente contra principios éticos porque aún cuando en un principio no se sabía que podría causar problemas, en el momento en el que se cae en cuenta, ya sea por indicadores o modificaciones por cualquier causa, medidas necesarias deberán ser tomadas para que las probabilidades de éxito del proyecto sean de más del 50%. De no ser así, el proyecto dejará de ser ético pues se atenta contra la felicidad y la dignidad humana porque causa estŕes y trabajo excesivo en los integrantes del equipo y los diferentes actores involucrados en el proyecto.

Al analizar distintos casos, podemos decir que los proyectos deben seguir principios éticos universalizables tanto en su medición, planeación, ejecución y terminación, es decir, en todas sus etapas deberán mantener un nivel ético sostenible que permita ser ejemplo para otros proyectos.

Desde la perspectiva de la ejecución, la falta de ética de los ingenieros como tales, puede llevar a casos en los que la política lleve al proyecto a convertirse en uno de marcha muerta, pues el atentar contra la dignidad de otros integrantes del equipo e iniciar chismes o tomar ventaja de información privilegiada, así como otras conductas faltantes de ética, pueden llevar a causar problemas internos en el equipo, que se puede transformar en retrasos y problemas creados a partir de la interacción de los miembros del equipo y no por la naturaleza del proyecto como tal o por fallas en la planeación del mismo.

Para evitar llegar a casos en los que el proyecto se vuelve uno de marcha muerta, se puede mantener un código normativo estricto que no permita faltas éticas o atentar contra la dignidad, felicidad, igualdad, bienestar o el desarrollo sostenible de las personas involucradas y del proyecto como tal. El conservar el ambiente de trabajo con estas normas evitará problemas futuros que puedan causar conflictos con el desarrollo del proyecto.

Para casos en los que desde un inicio se detecta que el proyecto tiene altas probabilidades de fallar, se pueden tomar acciones para que la presión sobre los responsables del mismo, pueda disminuir, ya sea incrementando el número de recursos asignados al mismo, o cambiando los tiempos dedicados para el desarrollo y terminación del proyecto, de otra manera el proyecto no debería permitirse ser puesto en marcha.

El tener un código más estricto entre los integrantes de los equipos puede llegar a ser molesto en el sentido que puede que haya cosas que normalmente serían permitidas si el equipo tiene una buena relación, pues no causarían problemas, sin embargo, con la idea de evitar conflictos futuros, puede que no se fomente una relación positiva como se podría tener sin el código propuesto.

Por otra parte, hay proyectos que es necesario que se pongan en marcha aún sabiendo que son muy complicados, debido a la naturaleza del mismo, pues algunas veces son necesarios para conservar el negocio, o para cumplir con normas impuestas o con certificaciones que se deseen obtener. Teniendo esto en mente, podemos decir que una vez que se identifica este tipo de proyectos en los que aumentar el tiempo o los recursos no es posible, se debe considerar la cancelación del mismo, pues no se debería poner en riesgo la ética de las personas, del proyecto o de la empresa. Esto puede traer un costo alto dependiendo del proyecto del que se trate, sin embargo difícilmente será un costo más alto que atentar contra la ética de alguno de los actores involucrados en el proyecto.

Con todo lo anterior podemos concluir que los proyectos de ingeniería de software pueden llegar a ser de marcha muerta por distintas razones, y que algunas de ellas implican decisiones conscientes desde un principio, pero otras veces son causas que se dan durante el desarrollo del proyecto, por lo que no pueden ser previstas como tal.

Podemos decir que sí carece de ética el iniciar un proyecto de software cuando se sabe que hay altas probabilidades de que éste fracase, pues sería incluso ilógico no tratar de cambiar la situación desde un principio, aunque esto no siempre es fácil, tratar de mantener un proyecto que implica lastimar la dignidad, felicidad y bienestar de los involucrados no es ético. En este caso, la responsabilidad más grande recae sobre el líder del proyecto y la parte gerencial del mismo.

Por otra parte, no podemos decir que un proyecto de marcha muerta dejó de ser ético cuando cayó en esta categoría por razones políticas entre los involucrados. En este caso la responsabilidad es compartida, pues aunque puede ser que los integrantes del equipo hayan sido los que llevaron a crear los problemas, también es trabajo del líder del equipo y de la gerencia manejar los conflictos que puedan surgir a causa de la carga de trabajo, así como supervisar que la ética de las personas a su cargo es de un alto nivel y no se verá comprometida en situaciones adversas ni pondrán en riesgo al equipo o al proyecto.

Referencias básicas

Cortina, A., Martínez, E. y Siurana, J.C. (2005). Ética de las profesiones. Monterrey: ITESM

Dinsmore, P. C., & Cabanis-Brewin, J. (2014). The ama handbook of project management. Obtenido de: http://0-ebookcentral.proquest.com.millenium.itesm.mx/lib/itesm-ebooks/reader.action?docID=1068886

Jonasson, H. I., & Ingason, H. T. (2013). Project ethics. Obtenido de: https://0-search.proquest.com.millenium.itesm.mx/docview/220235181?pq-origsite=summon

Linares Morales, José Alexander; Geizzelez Luzardo, María Lourdes; (2007). Administración de proyectos en ingeniería del software. Telos, Sin mes, 26-41. Obtenido de: http://www.redalyc.org/articulo.oa?id=99314566002

Lugo García, José Alejandro; García Pérez, Ana María; Delgado Martínez, Ramsés; (2009). Gestión de indicadores en proyectos de software. Perspectivas actuales y futuras. Revista Cubana de Ciencias Informáticas, Julio-Diciembre, 19-25. Obtenido de: http://www.redalyc.org/articulo.oa?id=378343637002

Referencias complementarias

Alexander, Moira. (2017). 9 ways company politics can thwart your projects. 18 de octubre de 2017, de CIO Sitio web: https://www.cio.com/article/3161889/project-management/11-ways-company-politics-can-thwart-your-projects.html

Klucznik, Frank. (2010). Death March Project. 18 de octubre de 2017, de WikiWikiWeb Sitio web: http://wiki.c2.com/?DeathMarchProject

Naciones Unidas. (s.f.). ¿Qué son los derechos humanos?. 18 de octubre de 2017, de Oficina del Alto Comisionado Sitio web: http://www.ohchr.org/SP/Issues/Pages/WhatareHumanRights.aspx