archivo

Archivos Mensuales: julio 2009

Hace tiempo escribí un post sobre el uso, en el plano personal, más que necesario del quién no llora no mama, para intentar en determinados entornos y circunstancias, determinados objetivos.

En este caso lo voy a enfocar al ámbito de las empresas y la consecución de negocios. En muchos artículos he comentado lo interesante que resulta cuando no se consigue un determinado contrato ir al cliente y preguntar en qué aspectos se ha fallado en la oferta, con el objetivo de mejorar en las próximas. Pues bien, esto además de resultar más que útil por la posibilidad de conocer un poco mejor al cliente y a los que toman las decisiones, (lo que provocará que las ofertas sean cada vez más adaptadas a los que ellos quieren y buscan), es una herramienta psicológica muy importante (si se aplica en condiciones, es decir, si se va de buenas y no en plan borde), que como es lógico no afecta a todos por igual, ya que hace ver al cliente que lo intentas una y otra vez y que no consigues negocio con él, pese a que cada vez inviertes más esfuerzo en la realización de las ofertas y estas cada vez son mejores y que se merecen una oportunidad para demostrar que lo pueden hacer muy bien. Si se hace correctamente (y hay auténticos especialistas en el mundo de los negocios), el quién no llora no mama puede ser un instrumento muy eficaz.

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.

El desarrollo de software es un trabajo en equipo. Pero, ¿qué es el equipo? Pues el formado por el proveedor de servicios de desarrollo de software y el cliente en sus dos vertientes, la de la dirección técnica del proyecto y la usuaria.

Ya es complicado desarrollar software como para que se complique todavía más el asunto si el equipo no funciona bien. Las tres patas que he comentado son fundamentales para que el proyecto salga adelante, la deficiencia de alguna de ellas provoca efectos negativos en el proyecto y en última instancia el fracaso absoluto en el mismo.

No es por restarnos culpas los que gestionamos proyectos o los que desarrollan software, pero en demasiadas ocasiones son los usuarios lo que echan al traste el proyecto, por la errónea percepción de que todo debe recaer sobre el área informática. Nuestra misión es abstraer a un programa de ordenador un determinado proceso o subproceso que se quiere informatizar, pero es necesario que se nos describa correctamente cómo se desea la informatización de ese subproceso y estar atento al proceso de desarrollo para intentar evitar desviaciones o errores funcionales desde las etapas más tempranas del proyecto. Cuanto más se tarde en encontrar deficiencias, más retrasos se producirán, más caro será el proyecto y menos se ajustará a lo que el usuario desea.

No confío mucho, profesionalmente hablando, de aquellas personas que cambian de organización muy frecuentemente. En primer lugar porque con tanto cambio, es difícil que le haya dado tiempo de aportar mucho a cada organización en la que ha trabajado y por otra parte porque no muestra ningún tipo de fidelización o identificación con las distintas entidades con las que han tenido relación. Conozco casos de personas que han cambiado de empleo en un año y de forma voluntaria hasta cuatro veces.

Evidentemente, en un proceso de selección de personal habría que estudiar cada caso concretamente y escuchar las explicaciones del candidato.

La identificación de una persona con la organización y entorno laboral en el que trabaja es fundamental para un desempeño lo más eficiente y productivo posible de su labor profesional. Es por eso por lo que resulta fundamental saber si un candidato encaja en una organización y más todavía si ese candidato tiene una importante rotación laboral.

De la última migración de versión del sistema de gestión de base de datos utilizado en mi organización, he sacado varias conclusiones:

– Los desarrollos de nuestra organización deben tender a una sola tecnología.

En mi organización ya decidimos hace tiempo que esa tecnología era Java, por lo que el camino ya está iniciado, no obstante, debemos comenzar cuanto antes la migración de todo lo que no está en Java a esa tecnología.

– Los desarrollos de nuestra organización deben tender a un solo framework.

En mi organización se ha están sentando las bases para que todos los desarrollos sigan un mismo marco, de ahí el libro blanco que rige los desarrollos, el cual está en pleno y continuo proceso de evolución.

– El framework debe ser lo más cerrado posible.

También estamos sentando las bases para conseguir esto, ya que las evoluciones del libro blanco van encaminadas a acotar este framework cada vez más. Evidentemente la evolución de la tecnología va a provocar que con el paso del tiempo haya aspectos que varíen en el framework de desarrollo, pero evidentemente será una situación mucho más aceptable que tener muchos proyectos desarrollados en tecnología Java, siguiendo estrategias distintas.

Es fundamental para la mantenibilidad de las aplicaciones (además de que estén bien documentadas y exista una correcta gestión de la configuración) que en la medida de lo posible, las soluciones técnicas sean lo más parecidas que se pueda. Desde mi punto de vista, la consecución de este objetivo tendrá un ahorro de costes importante a medio plazo.

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.

Por regla general, cuando uno no tiene muy clara una agenda de actividades o tareas a realizar o bien no tiene un marco temporal para la realización de las mismas, se tiende a la dispersión.

Por tanto, dos antídotos importantes contra la dispersión son por un lado intentar organizar el conjunto de tareas que hay que realizar, aunque sea apuntándolas a boli en un cuaderno e ir actualizando ese conjunto de actividades a diario priorizándolas adecuadamente y por otro marcarnos plazos para la realización de las mismas.

Si se trabaja sin plazos el trabajo tiende a no terminar nunca, ya que por un lado se tiende a darle muchas vueltas a lo que se hace (rizar el rizo) y por otro se tiende a la relajación (al fin y al cabo no tengo plazos, no tengo presión).

Generalmente la ausencia de plazos se debe a una falta de control por parte de los gestores del proyecto o de los gestores de la organización. Muy importante, no confundir retrasos en proyectos con la ausencia de plazos, sin plazos ni siquiera se puede hablar de retrasos (aunque evidentemente sean causa de los mismos), y al menos asumir que existen retrasos implica asumir que existen plazos (que no se han cumplido).

Uno de los grandes problemas de la dispersión es que no solo afecta a quien está disperso, sino a los que están alrededor ya que por un lado provoca distracciones y por otro supone un ejemplo negativo para el resto.

Es cierto que la dispersión también depende mucho del individuo, ¿quién no conoce a alguien que se distrae hasta con el vuelo de una mosca?, pero los factores de organización individual del trabajo y de control del mismo que he comentado en los párrafos anteriores también resultan muy importantes.

En el artículo anterior hablé de concentración, en este de dispersión, evidentemente no se trabaja igual de una manera que de otra y en consecuencia la productividad no es la misma. Por esto comento siempre que el tiempo de permanencia en el puesto de trabajo (acumulación de horas de trabajo) no es un indicador (por sí solo) de la productividad, tal vez sí lo sea del compromiso (si se conoce el trabajo que se realiza, ya que lo mismo el tiempo de más que se invierte es como compensación del grado de dispersión de las tareas que se realiza el trabajador) o de otras virtudes, pero utilizarlo como único mecanismo para medir la productividad es un error.