archivo

Archivo de la etiqueta: Nearshore

No me gusta tratar personalmente con empresas subcontratadas por otras, ya que sí se contrata a una empresa para realizar una tarea no me parece de recibo que sean otros los que tengan que dar la cara.

Esto no quiere decir que esté en contra de la subcontratación, lo único que quiero expresar es que no estoy a favor de la subcontratación total o casi total de un servicio ya sea a tiempo completo de la duración de un determinado contrato o un franja de tiempo más pequeña.

No obstante, sí que me parece razonable que una empresa subcontrate a un tercero la realización de determinados paquetes de tareas, siempre y cuando no provoque mermas en el resultado y en la calidad del producto final.

En el mundo del desarrollo de software, lo que veo más subcontratable son las tareas de construcción, pero eso requiere que los análisis y diseños estén debidamente cerrados y eso no es siempre posible en todos los proyectos, aunque sí que se puede conseguir en un buen número de ellos. Muchas empresas de desarrollo de software han tomado la decisión de subcontratar parte de sus desarrollos a terceras empresas, algunas de ellas filiales propias y otras con las que no mantienen ningún tipo de relación más allá de la comercial. Subcontratar no es clave de éxito, ya que como he comentado hay que tener bastante claro lo que se subcontrata, teniendo debidamente cerrado qué es lo que se entrega al subcontratado y qué es lo que se espera recibir del mismo. Las tareas de supervisión siempre serán necesarias, pero conforme se vaya teniendo confianza en un determinado proveedor, el esfuerzo en ese sentido se irá reduciendo.

Subcontratar a terceros siempre provoca mucha incertidumbre y cuando se pregunta a personas que han tenido esa experiencia te cuentan desde rotundos éxitos hasta importantes fracasos. En cualquier caso, creo que es algo en lo que merece mucho la pena pensar y probar primero con fogueo con algún proyecto pequeño y si funciona plantearse extenderlo poco a poco a proyectos de mayor tamaño.

En este artículo me he centrado en el proceso de construcción, pero no es lo único que es subcontratable, dentro de tu país o en el extranjero, por ejemplo, son subcontratables, tareas relacionadas con la revisión de la calidad del software, administración, recursos humanos, marketing, actividad comercial y un larguísimo etc…

El concepto de Inshore, es un concepto que ha venido de la mano de los dos modelos de centros de desarrollo de software tradicionales: Nearshore y Offshore, los cuales como ya he comentado en diferentes posts, se diferencian por motivos geográficos (para unas personas son unos motivos, para otras otros, en mi caso, el criterio es la distancia).

El Inshore maneja también criterios geográficos para diferencias del Nearshore, ya que hace referencia al establecimiento del centro de desarrollo de software en la misma localización geográfica (mismo municipio o misma provincia) que el centro destinatario del producto resultante.

La regla general que se aplica a estos modelos (no siempre se cumple) es que la distancia reduce la calidad del producto final y también los costes de desarrollo. Supuestamente, atendiendo a esta regla, un centro Inshore produciría resultados de gran calidad, pero también a unos costes de producción altos (o por lo menos similares a la competencia).

La calidad del resultado final depende de muchos factores, pero no necesariamente la distancia debería ser un factor decisivo, si se tiene un buen framework, una buena gestión y organización, una buena metodología y un buen equipo de técnicos. Como en todos los casos, no se puede decir qué una solución es óptima para todos los casos, ya que hay proyectos de desarrollo de software para los que puede resultar interesante el empleo de Offshore, otros Nearshore, otros Inshore y otros una combinación de los anteriores.

El Inshore sólo o combinado con el Nearshore o el Offshore, resulta muy adecuado para proyectos que requieren mucho contacto y feedback con el cliente, por lo que no resulta recomendable (entre otra cosa por los costes) estar desplazando continuamente técnicos y tampoco un umbral de latencia en la respuesta al cliente demasiado alto.

Hasta ahora sólo he trabajado con modelos Inshore puros o con el modelo combinado Inshore-Nearshore, con mejores resultados en los primeros casos que en los segundos, aunque también es cierto que se están mejorando las prestaciones en los últimos trabajos entregados utilizando el modelo Inshore-Nearshore.

La logística que se requiere para implantar un centro de desarrollo de software offshore y que funcione adecuadamente no debe ser nada sencilla.

Como ya he comentado en algún artículo, si el desarrollo de software se va a centrar en el mercado español, recomendaría sin duda que el centro Offshore se situase en Sudamérica, ya que de no ser así a las dificultades propias de mantener un centro a miles de kilómetros de distancia habría que sumarle la barrera del idioma, ya que los análisis y diseños llegarían en español.

Un aspecto importante es que los conceptos de Offshore y Nearshore están un tanto solapados, en tanto que hay personas que entienden que la diferencia entre ambos conceptos no es la distancia, sino el idioma y/o la diferencia horaria. En mi caso y porque tengo que decidirme por algo, establezco el criterio de la distancia para diferencias ambos conceptos y para diferenciar también el concepto de Nearshore con el de Inshore.

Pienso también que sería muy conveniente que personal ya especializado en desarrollo de software y en los procedimientos, metodología y framework de la organización estuviera desplazado en la sede del centro offshore, tanto para dirigirlo, coordinar los proyectos y realizar tareas de formación y soporte. Son importantes estas figuras con el objeto de darle a este sucursal de la empresa ese sentimiento corporativo, esa imagen de empresa que no la dan ni los logotipos, ni las guías de estilo, ni siquiera la metodología o el framework. Cuando el centro esté más consolidado, se podría ir sustituyendo personal desplazado por personal local.

Como también he comentado, un centro Offshore aunque tenga como objetivos reducir costes de producción (como resultado de instalarse en un país donde el salario medio es inferior), bajo ningún concepto debería tener un tratamiento distinto al que tendría si el centro tuviera características Nearshore o Inshore. Es decir, es un centro más de la empresa, en el que deberían existir las mismas posibilidades de promoción y las mismas condiciones laborales que en el resto y dar la posibilidad al personal que destaque que solicite ir a trabajar, siempre que existan vacantes, al centro que más convenga a sus intereses.

La apertura de un centro Offshore tiene importantes costes, por lo que entiendo que la apertura de un centro de estas características debería responder a una demanda real o relativamente cierta de trabajo durante un período de tiempo que permita amortizar (evidentemente con los riesgos que siempre acompaña a cualquier negocio relacionado con la informática) la inversión y consolidar el centro de trabajo. Una vez establecido el centro, ya es cuestión de utilizarlo en aquellos proyectos que estratégicamente convenga a la organización.

Otra posibilidad podría ser, en lugar de instalar un centro propio de la organización, contratar los servicios de desarrollo a una empresa de desarrollo de software del país, bajo el marco que establezca un determinado acuerdo de nivel de servicio. Esta posibilidad no requiere ningún tipo de inversión en infraestructuras, aunque requiere tener un importante grado de confianza en el proveedor, con el objeto de que éste entregue un producto acorde a las especificaciones de calidad establecidas.

Los lectores más asiduos de mi blog, se extrañarán por mis últimos guiños al Offshore, mostrados en este artículo y en otros, ya que siempre he dicho que las bases sobre las que se sustenta este tipo de servicios no me gusta (la base de utilizar un país o una región con menor renta per capita y con menores costes de infraestructura), pero vistas las características del mercado, de los movimientos de muchas empresas y porque al fin y al cabo, una empresa de estas características, si está bien gestionada y tiene buenas intenciones, crean empleo y riqueza en las regiones donde se implantan, hace que por lo menos le conceda a este tipo de servicios el beneficio de la duda.

El escenario actual del negocio del desarrollo de software no es nada alentador:

1) Se ha reducido el número de contrataciones.
2) Las contrataciones (por regla general) van más ajustadas presupuestariamente.
3) Para ganar dichas contrataciones hay que hacer rebajas (importantes en algunos casos) sobre presupuestos de contratación ya de por sí no proporcionados con los trabajos a realizar.
4) En los años de bonanza económica, el número de empresas de desarrollo de software ha crecido y no solo eso, la mayoría de ellas han aumentado en estructura (es decir hay más empresas y encima más grandes). Contra todas ellas hay que pelear para conseguir negocio.

También es cierto que cuando se inicie la recuperación económica, las variables 1) y 2) llevarán también una tendencia ascendente y se pasará de una situación crítica como la actual a una situación con mejores espectativas.

Pero mientras eso sucede hay que sobrevivir (estoy seguro que incluso en situaciones de crisis como la actual hay empresas que siguen creciendo, aunque en la mayoría de los casos, la pendiente será mucho menos pronunciada) y adaptarse a las circunstancias.

¿Están todas las empresas igual de preparadas para sobrevivir a la crisis? Evidentemente no. Algunas variables que considero favorables para que una empresa sea menos vulnerable, son las siguientes:

1) Fidelización de clientes.
2) Alianzas fuertes con otras empresas del sector.
3) Compromiso de los gestores (en estas circunstancias los trabajadores deben sentirse apoyados por los niveles más altos de la organización y sentir y apreciar que están tomando medidas para reducir el impacto provocado por la reducción del volumen de negocio, como por ejemplo, congelación de sus sueldos y de sus gastos de gestión (no deben ser sólo los trabajadores de base lo que carguen con eso), realización de actividades comerciales, búsqueda de alianzas, preocupación por la situación de los empleados (en algunos casos habrá que prescindir de personal, en otros el número de horas semanales no oficiales se incrementará, etc…).
4) Control de costes y de la productividad. Hay que saber objetivamente dónde se producen los gastos de la empresa (hay que controlar gastos relacionados directa e indirectamente con la producción, así como el conjunto de costes de estructura), qué proyectos son rentables y cuáles un sumidero de dinero, es necesario conocer qué personal es productivo y cuál no (por un lado hay que recompensar (ascensos, incrementos salariales por encima de la media) al personal comprometido y productivo y también si no hubiera más remedio y hubiera que reducir plantilla, ésta debería empezar por los puestos menos necesarios y por el personal menos comprometido y productivo).
5) Compromiso de los trabajadores.
6) Costes de producción por debajo de la media del sector (buena metodología interna de desarrollo, buen framework, buen conjunto de componentes y soluciones reutilizables, buen conocimiento del negocio de los distintos clientes, buena gestión interna y con los clientes de los proyectos, buen nivel técnico de los programadores y analistas programadores, buen nivel de los analistas funcionales, capacidad de reducir costes desviando trabajo a centros nearshore u offshore propios o subcontratados (cuidando que la merma de la calidad de los productos no superen el máximo umbral admisible tanto por la empresa como por los clientes), etc…

La crisis no será eterna y las cosas poco a poco volverán a su cauce, pero es necesario entender que no se puede vivir y gestionar una empresa igual en un período de crisis que en un período de bonanza económica.

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.