archivo

Archivo de la etiqueta: Factoría de software

Puedes trabajar con factorías de software siguiendo el modelo que más pueda convenir: Offshore, Nearshore, Onshore y conforme exista más distancia entre los equipos que tratan las especificaciones y el equipo que las desarrolla más mecánico se convierte el trabajo del equipo de programadores: “toma las especificaciones, te las modelo y desarrolla según la arquitectura y framework pactado”.

Es posible que esa distancia la puedan reducir los equipos de trabajo aplicando distintos tipos de técnicas y herramientas porque como he dicho en otras ocasiones el impacto de la distancia depende mucho de la actitud de todas las partes. Sin embargo cuando por encima de los técnicos, hay jefes de proyecto o gerentes “contables” la actitud (si existe) queda difuminada y se entra en un peligroso modelo de trabajo basado en el antipatrón “arrojar al otro lado del muro”.

Como bien dice un amigo, no hacen falta factorías de software para caer en ese antipatrón, te puede pasar perfectamente con el proveedor incluso compartiendo oficina.

En el momento en que se entra en ese juego la programación desgraciadamente se convierte en una actividad mecánica: el programador se limita a ejecutar tareas, conociendo solo el sistema que se desarrolla a bajo nivel. Con esto perdemos el feedback del programador tanto a nivel técnico: tal vez sean recomendables ciertos cambios en la arquitectura o el framework para adaptarlos mejor a la naturaleza del software que se desarrolla, como funcional: Esto no termina de ser coherente con otros módulos del sistema y es necesario que las especificiones sean más claras o que se estudie esa falta de consistencia con el usuario.

En un proyecto todos suman, los programadores por supuesto también (y mucho). Todas las personas que están en el proyecto están capacitadas para aportar ideas y soluciones, tengan el rol que tengan, a veces estarán acertadas y otras se equivocarán pero lo que no podemos hacer es dejar de escuchar sus opiniones porque estaremos despreciando toda la capacidad y talento de los componentes de nuestro equipo.

No hace mucho tuve una charla con un amigo que es totalmente partidario de los procesos de industrialización del software y que entiende el proceso de desarrollo, una vez elaborado el análisis, como si fuera una cadena de montaje.

Me comentaba que conseguir eso implicaba trabajar, hablando en términos muy generales, de la siguiente manera:

– Los analistas discutirían el diseño del sistema con los arquitectos (en el caso de que hubiera alguna contingencia que hiciera necesario esto).

– Los analistas entregarían el diseño a uno de los responsables de recepción de trabajo de la factoría que se encargaría de distribuir el trabajo en el equipo.

– Dentro del equipo de la factoría habría un perfil asignado al proyecto que se encargaría de ensamblar los componentes y de verificar si el sistema cumple las especificaciones del diseño y del análisis.

– Una vez construido el proyecto (o en diversas iteraciones) el mismo pasaría a ser revisado por un departamento de calidad que haría las verificaciones finales del producto previas a la entrega.

La visión de mi amigo no es ni mucho menos mala, es simplemente otra opción en el proceso de desarrollo de software, es otra manera de hacer las cosas y que puede ser muy rentable si se dan las condiciones necesarias (o se reunen muchas de ellas para trabajar de esa manera).

Algunas de esas condiciones pueden ser las siguientes:

– El proceso de desarrollo de software desde su concepción hasta su entrega está regido por procesos, de manera que en cada fase cada cual conozca su rol y las tareas que debe realizar. Existirían personas encargadas de velar por el cumplimiento y mejora continua de los procesos.

– Los requisitos se encuentran cerrados en el momento en que se entrega el diseño a la factoría. Todos sabemos que eso es bastante complicado de conseguir ya que muchos usuarios terminan por afinar el concepto que tienen de aplicación conforme van viendo plasmada su construcción y a veces estos detalles son los que marcan las diferencias entre una buena terminación y otra no tan adecuada. Esto se complica sobre todo si el proyecto es de gran magnitud.

Pese a que es complicado y yo personalmente soy partidario de ser lo suficientemente flexible con el usuario y dar la posibilidad de introducir cambios menores en los requisitos más allá del análisis (con el coste y riesgos que ello conlleva), si el analista funcional hace un buen trabajo y/o se prevén fases de mantenimiento evolutivo posteriores y/o se opta por un desarrollo incremental del sistema sí que sería posible un escenario donde los requisitos estuvieran debidamente cerrados (no necesariamente al 100% pero sí muy aproximado a ese límite) en la fase de construcción.

Un inconveniente que se puede plantear con esta dinámica de trabajo es la separación entre el equipo funcional y el equipo que realiza la construcción del sistema de información. Esa frontera puede ser causa de problemas salvo que se establezcan mecanismos adecuados de interlocución entre el equipo de personas que construyen y los analistas funcionales, supuestamente si todo estuviera bien especificado en el diseño y en el análisis la comunicación no debería ser necesaria, pero eso es un modelo teórico a mi juicio ya que requeriría que no quedasen resquicios en el diseño y en el análisis, algo que resulta muy complicado y que se complica todavía más conforme se incrementa la complejidad y tamaño del sistema.

Si los mecanismos de interlocución funcionan y todos reman en la misma dirección, estos problemas pueden minimizarse, pero si no es así el equipo de construcción tenderá a rellenar los huecos del análisis y el diseño, algo que es muy arriesgado ya que ellos no han participado en la etapa de definición funcional de la aplicación y no han trabajado con quienes van a utilizar finalmente la aplicación.

Podría pensarse que la colaboración entre los equipos de trabajo debería ser algo fluido, pero no necesariamente va a ser así, sobre todo si los responsables funcionales y los del proceso de construcción son distintos y pertenecen a departamentos diferentes, lo que implicaría que el jefe común entre ambos equipos estaría situado bastante por encima en la jerarquía de la organización, lo que dificultaría las tareas de coordinación en caso de conflicto (cuanto más arriba esté quien realiza estas tareas, pierde la visión del día a día, este tipo de problemáticas no les resulta de interés, en función de otras que suelen tener (principalmente de carácter económico de los proyectos o departamentos a su carga) y además asusta más requerir su participación porque se piensa que su intervención puede ser semajante a la de un elefante cuando entra en una cacharrería).

– La construcción tiene que ser lo más homogénea posible. Es decir, en la medida de lo posible los desarrollos deben estar construidos siguiendo el mismo framework y automatizándose en lo posible el proceso de construcción mediante la utilización de generadores de código e incluso con la posibilidad de utilizar frameworks gráficos. Esto será posible cuando los clientes planteen libertad en cuanto a framework o arquitectura o exista un alto grado de compatibilidad entre la solución que requiere el cliente y aquella con la que se trabaja, en otros casos tales como aplicaciones desarrolladas siguiendo otra estrategia (y en las que se va a realizar mantenimiento evolutivo) o nuevos desarrollos que sigan otro framework habrá que aplicar otro tipo de estrategias para hacerse cargo de ellos.

Cuando el desarrollo sigue una línea diferente a la utilizada en la factoría lo ideal sería especializar un grupo de trabajo en el desarrollo con esa arquitectura, framework o tecnología, pero eso requeriría una vinculación a medio o largo plazo con el cliente y/o tener expectativas más o menos ciertas de negocio. ¿Por qué especializar? Pues porque la productividad va a ser mayor, no ya solo por el dominio que este equipo puede tener de la tecnología, sino porque se pueden adoptar soluciones (aunque sea paulatinamente) para mejorar el rendimiento en el desarrollo. Si el proyecto no es lo suficientemente grande, duradero o las expectativas de trabajar en otros proyectos similares no están claras, lo mismo hay que plantearse que la solución más adecuada no pasa porque el contrato (en el que caso de que se quiera o pueda asumir) lo realice la factoría, lo mismo resulta mucho más adecuado formar un equipo de proyecto tradicional para llevarlo a cabo.

En la charla, mi amigo tenía muy claro que había que invertir en el framework, en la generación de código y en la reutilización de módulos y componentes y que es absolutamente necesario tener a personas dedicadas exclusivamente a mejorarlo, a corregir incidencias y a asesorar y que había que perder el miedo a tener estas personas haciendo estas funciones, ya que aunque sean perfiles altos (deben serlo para que el resultado de sus trabajos sea el más óptimo posible debido al impacto que tendrá en el conjunto de proyectos) el retorno de la inversión está asegurado.

Hace bastante tiempo escribí un conjunto de articulos dedicados a la producción industrializada de software, si queréis echarle un vistazo os dejo a continuación sus enlaces:

Producción industrializada de software I
Producción industrializada de software II
Producción industrializada de software III
Producción industrializada de software IV
Producción industrializada de software V
Producción industrializada de software VI

He tenido la oportunidad de leer mucho últimamente sobre las factorías de software. Mi opinión sobre la producción industrializada de software, la podéis consultar en este mismo blog en una serie de artículos que dediqué al tema.

Como comentaba en dichos artículos, para mi la producción industrializada de software no existe, simplemente lo que se ha hecho es aplicar una serie de buenas prácticas (en algunos centros) y aplicar una serie de fórmulas para reducir en la medida de lo posible los costes de desarrollo (casi todas ellas basadas en la búsqueda de soluciones que impliquen un menor coste por mano de obra y el apoyo de las instituciones).

Los lectores de mi blog, también saben de mi opinión sobre el mercado TIC y en los últimos tiempos, también he tenido la oportunidad de comprobar que no me equivocaba. En esta época de crisis, las empresas de desarrollo de software van a por todas, utilizando unas políticas muy agresivas de precios.

Si las cosas no cambian o se está muy bien posicionado en el negocio o esto será la ley de la selva, donde sólo los más fuertes sobrevivirán (y aquellos aliados de los más fuertes). No todas las empresas pueden asumir esa guerra de precios sin una pérdida considerable de la calidad de los servicios que se ofrecen. Por este motivo yo que siempre he tenido un gran recelo de las factorías de software, veo que en las circunstancias actuales las empresas que tienen este tipo de recursos están bien posicionadas (siempre y cuando las factorías estén bien gestionadas) para poder competir.

Cuando se habla de factorías de software, se utilizan a menudos los términos Nearshore y Offshore. El primer caso se corresponde a aquellas factorías que se encuentran próximas geográficamente (o que tienen algún rasgo común, como por ejemplo, una franja horaria próxima, el idioma, etc…) a las organizaciones para la cual prestan sus servicios (en algunos casos proyectos concretos, en otros casos outsourcing), el segundo caso se corresponde a factorías más alejadas geográficamente y que en la mayoría de los casos no presenta rasgos comunes con las organizaciones a la que prestan servicio. Como habréis podido ver, existirán casos donde las factorías se puedan considerar Nearshore u Offshore en función de la persona que la defina.

Por regla general, se suele relacionar el Nearshore con soluciones de mayor calidad (y con un mayor coste de producción) y el Offshore con soluciones de menor calidad (y con un menor coste de producción). También hay que tener en cuenta que el Offshore en muchos casos es bastante complicado. Supongamos que situamos una factoría de software en Laos y que a ella desviamos carga de trabajo de programación. Si el análisis funcional está hecho en español, existirán serias dificultades para su interpretación por parte de los programadores del centro.

También hay quien utiliza el término de Inshore, para referirse a factorías de software situadas muy próximas geográficamente (100 kilómetros como mucho) de las organizaciones a las que prestan servicio.

En cualquier caso: Inshore, Nearshore y Offshore, lo importante es que el centro esté bien gestionado, que se utilice un framework de desarrollo común (y que pueda ser lo suficientemente flexible para poder adaptarse en situaciones concretas a especificaciones técnicas de clientes concretos) y que el personal que trabaja en los mismos esté lo más formado posible (y existan unos procesos de formación continua). De esta manera más o menos la calidad de los productos no debería ser tan significativa, ni ser tan distintas (aunque la barrera del idioma, en muchos casos, puede afectar notablemente el resultado del producto). Si la gestión es buena, el framework es común y flexible y se poseen buenos técnicos, los costes de producción se reducirán, dejando prácticamente como aspecto diferencial el nivel adquisitivo de los países donde se encuentre la factoría de software, lo que permitiría pagar sueldos más bajos y por tanto permitir ofertar en los proyectos un mayor número de horas a un menor coste.

Aunque la solución que más me guste sea la Inshore o en su defecto la Nearshore, más que nada porque no me gusta por qué se realiza la deslocalización, ni que se aproveche el nivel de vida de un país para ofrecer salarios varias veces más reducidos que los de nuestro país, no tengo más remedio que reconocer que quien posea la infraestructura y la organización para ofrecer productos con un nivel de calidad aceptable y a unos precios rompedores, tienen todas la de ganar en un mercado tan competitivo como es el del desarrollo de software.