El saber-como poder y el saber-hacer como aprendizaje: juegos y consensos, conflictos y resistencias en el proceso de trabajo
| Autor | José Guadalupe Rodríguez Gutiérrez |
| Páginas | 247-288 |
Page 247
En el proceso de trabajo del software a la medida del cliente es fundamental especificar la lista de requerimientos que el líder de proyecto, gerente o pro-gramador de la empresa transformará en un diseño modularizado. Baldissera señala que la consideración del cliente y/o del usuario final en el diseño y desarrollo de programas de software se presenta como una "revolución del usuario"1 (Baldissera, 1988; en Castillo, J. J. 1993). En última instancia, un tercer jugador en el proceso de trabajo en la industria del software es el cliente quien participa en mayor o menor medida como un agente activo en el proceso de trabajo, desde el inicio del proceso e incluso en algunos módulos considerados como "complicados" el cliente está presente. La participación del cliente en el proceso de trabajo del software a la medida es importante para convenir sus necesidades (requisitos de diseño) y desarrollar una interfaz gráfica que refleje dichas necesidades. En esta interacción social deben observarse: a) comprensión de las necesidades del cliente y proyectarlas en un diseño; b) diseñar dispositivos gráficos (interfaz) y procesos sencillos, prácticos; c) una interfaz gráfica con símbolos usables; d) facilidad para corregir errores, acceder información a través de iconos y ventanas, sin complejidades para el usuario; e) crear iconos alternativos al texto escrito, por ejemplo en lugar de "enviar por correo electrónico" utilizar el icono: V*, para que el software desarrollado represente, ejecute y
Page 248
procese la mayor información posible solicitada por el cliente. En este proceso se pone en juego un conjunto de símbolos del saber-hacer y el saber como poder, se involucra una serie de configuraciones subjetivas que intervienen en el proceso de trabajo, como los conocimientos formales e informales, habilidades y destrezas, autoa-prendizaje y disposición en la búsqueda de información; consensos y alianzas, resistencias y desobediencias; entre aquellos agentes que intervienen en el proceso de desarrollo del software a la medida.
En el proceso de trabajo del software se pone en juego una serie de conocimientos formales e informales, un conjunto de habilidades y destrezas en torno al significado de apreciar, discernir o descifrar soluciones informáticas, proceso que podemos señalar como rutinas y juegos específicos de relaciones de poder, entendiendo por poder el sentido que señala Foucault (1993) que es un conjunto de relaciones de poder, el cual no se adquiere mediante el despojo o la expoliación, no es que se arrebate o comparta; sino que existe en el momento que se ejerce, que entra en conflicto el saber y el poder.2 Foucault (1993, 1976 [2005]) señala que el poder sólo existe en el momento de su ejercicio, cuando se busca algo y es conseguido, obtenido, logrado, las relaciones de poder desaparecen, es decir el poder sólo existe en el acto, en las interacciones transitorias y continuas entre los individuos. El poder no se posee, no es monolítico, consiste en una serie de interjuegos específicos en el que todos los participantes actúan en diferentes niveles, con distintas intensidades e intenciones.
Para el caso del software, consideramos que cuando el cliente hace contacto el agente-desarrollador (sea el gerente, líder de proyecto, ingeniero de software o el programador experto) indaga quién y bajo qué costo desarrollarán un software, que solucione los problemas empresariales en el menor tiempo y costo posibles. Al agente-desarrollador le interesa primero retener al cliente como tal, y ajustarse a sus necesidades, obviando una serie de contingencias, por ejemplo ¿existen posibilidades reales para desarrollar el software que plantea el cliente?, ¿posee la empresa la experiencia, recursos humanos y técnicos para el desarrollo del software que se solicita?, ¿es viable el proyecto, tanto económica como técnicamente? ¿los requerimientos del cliente, son realmente lo que necesita? Consideraciones que están implícitas en el proceso de trabajo y, en conducir a buen término el proyecto.
Page 249
Si bien es cierto en el capítulo anterior y en lo que va del presente, hemos situado al proceso de trabajo del software como si estuviesen separadas las fases de diseño del software y la creación cognitiva de los algoritmos, es decir por un lado las entrevistas entre el administrador del proyecto y el cliente y, por otro, la transformación de los requisitos en líneas de código (LDC); dicha separación no es tal,3 por el contrario, coexiste un proceso fluido (Castillo, 2007) entre un proceso y el otro; al respecto el programador JO3 señala que existe un ir y venir entre el administrador del proyecto y el cliente, entre el administrador y los programadores; entre programado-res y tester de calidad; proceso fluido, ágil que implica una serie de interacciones simbólicas entre el administrador del proyecto y los programadores:
El cliente se podría decir que participa en todo el proceso, pero no directamente con el programador, sino que participa con el arquitecto y con el administrador del proyecto... el arquitecto es el que.. .va a solucionar las necesidades, el administrador es el que tiene que ver con el cliente...juntas, reuniones, entregables, ver si hay alguna modificación, —los proyectos a veces se extienden y pueden producir modificaciones en cualquier momento— para ajustarse a la realidad... (programador JO3, MIXE).
La participación del cliente viene a marcar una ruptura con el tradicional proceso de trabajo de la economía fordista-taylorista, el espacio cerrado en que se convertía el proceso de trabajo, zona exclusiva entre patrón y trabajador es irrumpida por el cliente, como actor clave que participa en mayor o menor medida en el proceso de trabajo. Sin embargo, debemos aclarar que en la industria del software a la medida la participación del cliente es heterogénea, con diferentes grados de implicación. Por ejemplo, en las fábricas de software empaquetado, de uso masivo el cliente es considerado como usuario final del producto, lapráctica social mas común entre este tipo de empresas es el testeo masivo o debbuging free que consiste en la liberación del software que se está desarrollando en formatos beta (software en fase de prueba), éste es probado (testeado) tanto por otros programadores (en búsqueda de vulnerabilidades, bugs, fallas, etc.) como por usuarios invitados, para que comprueben la usabilidad o no de la interfaz gráfica, así como la operabilidad interna del sistema4
Page 250
y otros posibles errores en el producto desarrollado por las fábricas de software. Sin embargo, en el software a la medida, la participación del cliente ocurre desde el inicio del diseño de los requerimientos del diseño y es quien evalúa y aprueba el interfaz gráfica del software. Al respecto, el líder de proyecto y dueño de una pequeña empresa con menos de 35 empleados, cuatro programadores y seis consultores en tecnologías, pero líder en el mercado de los erp administrativos en Latinoamérica, señala que el diseño de interfaz gráfica es elemental en el éxito de un sistema informático: ".. .ves interfaces de usuario, que están concebidas pensando en el dato, no en el usuario; pensando en la información, no en el proceso... llega el usuario se sienta enfrente de la computadora y para registrar un tipo de transacción tiene que navegar por dos, tres, cinco o siete pantallas para registrar una sola cosa" (líder dyya, RF1).
El líder RF1 desaprueba que las empresas desarrolladoras de software no profundicen en torno a las necesidades gráficas del usuario (interfaz gráfica) por estar concentrados en el desarrollo del código, es decir no contemplan el desarrollo del software en todo su conjunto. Al respecto Hammer y Champy (1994: 35)5 señalan que el proceso de desarrollo de un software "es una colección de actividades que toman uno o más tipos de entradas y crea una salida que es de valor para el cliente". La colección de actividades en el argot de la industria del software es la participación de distintos actores en el ciclo de vida del proyecto6 que hemos denominado con el nombre de constelación de relaciones subjetivas y un conjunto de prácticas sociales de aprendizaje, que en la mayoría de los ciclos de vida coinciden en las etapas de conceptualiza-ción-formalización y procesamiento-implementación del sistema. Lo cual no significa, según Hammer y Champy (1994), que todas las empresas de negocios de software implementen todas fases de: a) análisis de requisitos; b) diseño basado en un proceso c) desarrollo de los módulos; d) implementación, sino que pueden utilizar diversos enfoques, como orientado a tareas, a personas, a estructuras entre otros enfoques como el método ágil, donde la comunicación entre agentes es fluida, horizontal, sin jerarquías, sin divisiones rígidas o formales. Para el caso de las empresas del valle de México observamos en las entrevistas realizadas que en el discurso se plantean tres etapas de trabajo yuxtapuestos: 1) análisis de requisitos y diseño del proyecto, inte-
Page 251
grado por el cliente y el agente desarrollado^ 2) proceso de programación y verificación de la calidad, interactúan el diseñador, programador, tester, documentador, entre otros trabajadores cognitivos; 3) implementación del software desarrollado, participan el diseñador, programador responsable, el cliente y usuarios finales del programa. Sin embargo, en términos informales el proceso no está dividido, es fluido, dinámico, ágil, sin fronteras rígidas entre cada uno de las tres etapas del proceso de trabajo.
[VER PDF ADJUNTO]
En el esquema 9 se identifican tres espacios de poder en el proceso de trabajo, que ya definimos en el...
Para continuar leyendo
Solicita tu prueba