Jummp’s Blog

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.

Un aspecto que puede hablar bien a las claras de la salud de una empresa a nivel de gestión, planificación y control es la reducción progresiva de tiempos que tienen los trabajadores sin tener tareas asignadas. ¿Cuántas veces sucede que mientras hay algunos equipos de la empresa qué tienen cargas de trabajo elevadas, otros equipos o personas específicas pueden pasar horas o días sin tener una tarea asignada?.

Me estoy refiriendo exclusivamente a la no asignación de tareas por motivos de descoordinación, mala gestión, mala planificación o también, por qué no decirlo, por la falta de actitud del trabajador (de nada vale una planificación o gestión exquisita si después el que tiene que ejecutar la tarea no responde o no indica que está disponible cuando la ha terminado). No me refiero como es lógico a la no asignación de tareas por falta de negocio (aunque en muchos casos sea factible asignar tareas no facturables, pero que pueden resultar interesantes para la empresa, como por ejemplo, desarrollos internos, esas mejoras de aplicaciones internas que nunca da tiempo a hacer, esa mejora en el framework que tantas veces se había considerado necesaria, probar ese producto que leímos en aquel blog y que nos permitiría mecanizar tal proceso, etc…).

Evidentemente no es nada fácil que una persona se vaya moviendo entre proyectos (o incluso que se ponga a trabajar en un módulo que desconoce del proyecto en el que está trabajando), ya que por regla general (sobre todo si no hay una infraestructura de desarrollo común) se necesita un período de adaptación, salvo que la tarea que se le asigne no requiera de ese aprendizaje previo (no es fácil, pero no imposible).

El control lo debe hacer el jefe de proyecto o el jefe de equipo (que puede ser perfectamente el analista principal del proyecto), el cual debe encargarse de que los parones de los miembros del equipo de proyecto sean los menores posibles, ya que por un lado provoca gastos al proyecto (al fin y al cabo un porcentaje del trabajador está asignado al proyecto) y a la empresa (que es la que asume las no ganancias o pérdidas del proyecto). Y no solo eso, ya que si hay personas que no tienen carga de trabajo asignada y otras sí, siempre surgirán las comparaciones, lo que restará por un lado productividad a los que tienen tareas que hacer y por otro también provocará que el ambiente se enturbie.

Si el jefe de proyecto (porque tenga muchos proyectos y no pueda estar al día a día de lo que ocurre en el mismo, aunque al final la cuenta económica del proyecto hablará bien a las claras de lo rentable que ha sido y de la productividad del equipo (con esto no quiero decir que si un proyecto presenta pérdidas sea por el equipo, ya que esto depende de múltiples factores)) no tiene la posibilidad de hacer un seguimiento en profundidad de la ejecución de tareas por parte del personal del proyecto, debe delegar ese seguimiento en el jefe de equipo o analista principal del proyecto. Esta figura, sí que sabrá cómo está repartida la carga y sí que podrá prever tiempos muertos, cuando los detecte, deberá informar al jefe de proyecto para que intente minimizar los tiempos muertos o si no es posible y este se prolonga permita que el trabajador pueda repartir su tiempo con otro proyecto que sí tenga necesidades de recibir algún tipo de apoyo.

Los proyectos de desarrollo de software tienen otros costes además del personal asignado a los mismos y muchas veces se olvidan debido a que se piensa que son cifras ridículas en comparación con las otras.

Para gestionar un proyecto de desarrollo de software hay que tener en cuenta todos los costes, incluido si te tomas un café de trabajo con el cliente: gastos de transporte, garaje, comida, móvil corporativo, etc…

Además, hay que tener en cuenta otros costes, estos sí son más o menos fijos y es el coste de mantener el puesto físico de trabajo de la persona, que es la suma también de una serie de factores: coste del metro cuadrado de suelo de la empresa, parte proporcional del gasto de luz, de limpieza, fungibles, etc…

Hay organizaciones que tiene calculado milimétricamente el coste de cada empleado y los costes que incurren en el proyecto, otras aplican un factor porcentual sobre el salario de cada empleado, que da una aproximación bastante realista al coste del mismo.

En cualquier caso, es necesario conocer la cantidad de tiempo que invierte cada trabajador en un proyecto, tener en cuenta los costes extraordinarios del proyecto (viajes, dietas, etc…) y conocer el coste de cada trabajador (aunque sea la solución aproximada del factor porcentual), en caso contrario se perderá precisión en el seguimiento económico de los proyectos y habrá siempre una grieta por la que se escaparán euros continuamente.

Es en cierto modo lógico el miedo a crecer de muchas empresas dedicadas al negocio de las TIC, ya que ese crecimiento viene ligado en la mayoría de los casos a un incremento de los recursos humanos lo que provoca necesariamente que los objetivos anuales en cuanto a facturación crezcan proporcionalmente a los mismos (y además que se mejoren algunos mecanismos como la gestión de cobros, para evitar en la medida de lo posible gastos financieros por faltas puntuales de liquidez, la productividad, el control de gastos, etc…).

Por tanto, el crecimiento debe ir de la mano de dos aspectos fundamentales:

1) Un mayor esfuerzo y eficiencia comercial. Esto pasa en las empresas grandes y chicas, para subsistir tienen que vender servicios y esas ventas deben ser proporcionales al tamaño de la empresa y a la estructura de las mismas.

2) Una mejora en la gestión y una reestructuración de la empresa. Si la empresa tiene cien empleados no es lo mismo que si tiene quinientos, por lo que la forma de gestionar la empresa, la estructura orgánica y funcional de la misma e incluiso los procedimientos deben ser distintos. Si se intenta gestionar una empresa de quinientos empleados aplicando las mismas técnicas y recursos de gestión que una empresa de cien, los problemas pueden ser tan importantes que incluso podrían afectar a la propia viabilidad de la empresa.

Una vez indicados algunos de los inconvenientes y/o riesgos, por otro lado lógicos, que puede provocar el crecimiento de las empresas, vamos a ver a continuación, algunos de los beneficios:

1) Imaginemos que una empresa tiene una facturación anual de 4 millones de euros con un margen de beneficios que se sitúa alrededor del 20%. Supongamos que gracias al crecimiento la facturación anual pasa a ser de 6 millones de euros, situándose los beneficios también en torno al 20%. Se ha pasado por tanto de unos beneficios de 800.000 euros anuales a unos beneficios de 1.200.000 euros anuales. Esos beneficios de 400.000 euros de más, lo agradecerán accionistas y/o socios, los cuales podrán invertirlos en sí mismos y/o en la misma empresa (subir el sueldo y/o promocionar a los empleados, reforzar o crear un departamento de I+D, reforzar la estructura de la empresa, mejorar los procesos, realizar fichajes que mejoren el nivel medio de la empresa, etc…).

2) No conozco a ningún trabajador que se conforme (otra cosa es que por las razones que sean no tenga más remedio) con tener siempre el mismo sueldo. Esto implica que o bien la empresa va incrementando periódicamente el sueldo de los empleados o se va a encontrar con que períodicamente los empleados se van a ir marchando de la empresa, con el riesgo que eso supone (contratar a personal, probablemente con menos experiencia y que tardarán unos más y otros menos en alcanzar un nivel similar a los que se han ido marchando, lo cual lo sufrirá directamente la empresa y la calidad de los servicios que presta). Este incremento anual de la masa salarial puede ser asumido por una organización, sin modificar su nivel de crecimiento, durante un tiempo, pero al final llega a ser insostenible, es decir, o se crece o se debe empezar a asumir la marcha de talento de la organización.

3) Tiene una gran relación con el punto anterior el nivel de responsabilidad. Existirán muchos empleados de la organización que quieran asumir un mayor nivel de responsabilidad, ya que a la mayoría de las personas no le atrae realizar siempre el mismo trabajo (y además ese incremento en el nivel de responsabilidad, viene parejo en la mayoría de las casos con un incremento salarial), evidentemente si una empresa tiene cien empleados no todos pueden ser analistas funcionales, jefes de proyecto, arquitectos, gerentes, responsables de I+D, etc…, pero si la empresa crece, lo hará también el número de perfiles de alto nivel y permitirá a su vez promocionar el resto de perfiles. Por tanto, de igual forma que en el punto anterior, o se crece o se debe empezar a asumir la marcha de talento de la organización a otras en los que sí puedan ocupar esos puestos de mayor responsabilidad.

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.

Sé que muchas empresas poseen internamente herramientas de valoración que permiten, con un cierto conocimiento del desarrollo que se pide, de la tecnología, de si es un mantenimiento evolutivo, correctivo o un desarrollo nuevo o incluso el tipo de cliente, conocer cuánto realmente costaría hacer el producto y por tanto, conociendo el coste de producción y los beneficios que espera conseguir la empresa, plantear de si le interesa o no participar en el proyecto y cuál es la estrategia de desarrollo del mismo para ser rentable.

También reconozco que creo en la utilización de este tipo de software y que se puede obtener resultados interesantes con ellos. Evidentemente para conseguir resultados lo más fiables posibles hay que tener un modelo adecuado y una buena base de datos de proyectos.

Pero también es cierto que hasta donde conozco y sé, la inmensa mayoría de las valoraciones que se hacen, no se hacen utilizando este tipo de herramientas, se aplican otros criterios como la experiencia de la persona que realiza la valoración, del equipo que está a su cargo y de las características de la organización destino (criterios que muy probablemente estarían dentro de un modelo informático de estimación de costes).

Me encantaría ver casos de éxito de herramientas de estimación software y ver el grado de desviación entre el coste previsto y el real.

Lo comentado en el artículo anterior sobre las políticas en Redmine, tiene una repercusión indudable en el coste del proyecto.

Esto es una línea argumental de mi blog, la calidad es el objetivo a cumplir en el desarrollo del software, ya que gracias a ella podemos liberarnos en gran medida de la cautividad de los proveedores, el producto resultante tendrá menos errores, satisfará en gran medida a los usuarios, será más sencillo y barato de evolucionar, el proceso de desarrollo de software traerá menos complicaciones, etc, etc, etc…

La calidad vale dinero, ya que implica dedicar más recursos a la gestión del proyecto, pero después ese dinero de más invertido al principio, se retorna y con intereses una vez que se obtiene un producto mucho mejor acabado, más flexible, fácil de mantener y con todo su historial registrado, lo que permite adquirir un conocimiento muy valioso para futuros proyectos.

Por tanto, a la hora de hacer presupuestos, tened en cuenta el coste de la calidad en el proceso de desarrollo de software en todas sus vertientes y considerarlo como una inversión a futuro.