Archivo de la categoría: Gestión

Detecta qué necesitan/quieren/atrae a tus clientes.

Ayer y hoy estoy de curso, fuera de mi lugar de trabajo habitual, en la zona norte de Madrid.

El caso es que llegar aquí en hora punta suele llevar mucho tiempo por el tráfico y el aparcamiento es complicado por las numerosas oficinas existentes en la zona, lo que hace que cada vez más gente opte por madrugar para llegar antes de las 8 (muchos van llegando a partir de las 7) y así no tener que aparcar a un par de kilómetros.

Yo he llegado pronto así que he aprovechado para ir a desayunar con calma y de paso tenía intención de ver el correo y navegar por la red.

Frente al lugar donde impartían el curso hay dos restaurantes, uno ‘tradicional’ y otro de la cadena Vips, y como ayer probé el primero y vi que en el Vips ofrecían acceso a internet a sus clientes, he querido pasar hoy por el Vips para aprovechar la WiFi.

Pero cuando he llegado a la puerta, pese a que ya había gente dentro ultimando el local para su apertura, estaba cerrado puesto que eran las 7:30, así que no me ha quedado más remedio que acercarme al otro y quedarme sin WiFi aunque disfrutando de un buen desayuno.

Curioso que su lema ‘cuando quieres’ no se haya cumplido esta vez.

Este ejemplo sirve para darnos cuenta de que no siempre contar con un producto mejor puede ser suficiente para conseguir atraer y retener clientes.

Si comparamos la carta de ‘desayunos y buffets’ de Vips (la tenéis disponible en este enlace) con la del otro restaurante, os puedo asegurar que es mejor y más variada sobre el papel.

Pero aquí hay un factor que sin duda los señores de Vips no han tenido en cuenta, y es el hecho de no haber sabido detectar que sus potenciales clientes, que acuden temprano por las circunstancias del lugar (evitar tráfico o aparcar mejor), madrugan más de lo habitual y les podría apetecer entrar a desayunar o tomar un café de camino a su lugar de trabajo.

Sin embargo, el otro restaurante, con un horario de apertura de las 7 a.m. sí parece haberlo detectado y ha sabido responder a tal circunstancia, con lo que consigue que la primera hora su salón esté lleno de gente desayunando.

Aunque por otra parte han dejado pasar por alto otro detalle, el de ofrecer WiFi gratis a sus clientes como sí hace el Vips, como servicio complementario que posiblemente, en plena era de la movilidad, muchos clientes apreciarían (habituales, de paso a visitar alguna empresa o incluso alguno que busca escapar de la oficina momentaneamente) y que puede hacer que tras abrir sus puertas sea el Vips quien los atraiga con más facilidad.

Algo cada vez más apreciado por quien necesita de movilidad en su día a día.

Al coste que tiene hoy en día una línea ADSL, no es descabellado pensar en que puedas rentabilizarlo con apenas unos cuantos clientes más que consigas atraer a tu negocio.

Con todo esto lo que quiero dar a entender, como decía más arriba, es que no basta con tener un buen producto (incluso el mejor) para conseguir el mayor número de clientes. Hay que estar atentos para detectar pautas, comportamientos o posibles necesidades de nuestros clientes, o potenciales clientes, ya estén directamente relacionadas con lo que mejor hacemos o no, puesto que ahí puede estar la clave para convencer a un cliente a decantarse por nosotros frente a nuestros competidores.

Dame un objetivo.

Hace unos días, tras el regreso de las vacaciones, un compañero me comentaba que tras la última reorganización aún no tenía claro en qué situación quedaba ni qué debía hacer, dado que su hasta entonces responsable ya no le comunicaba qué debía hacer, y su nuevo responsable estaba aún en la vorágine del cambio y no había hablado con él.

Le pregunté entonces sobre qué estaba haciendo, respondiéndome que seguía con el trabajo que le habían asignado antes de irse de vacaciones y realizarse los cambios, pese a que sabía (de forma no oficial) que posiblemente no valdría para nada.

 

Esto me hizo recordar la importancia de la comunicación en una empresa, pero también la necesidad de que en nuestro día a día tengamos siempre un objetivo claro y que asumamos como válido y útil, para poder afrontar cada jornada laboral.

En este caso claramente la comunicación no estaba funcionando al 100%, pero  en parte también porque, como supe después, desde arriba aún estaban por decidir las nuevas estrategias y objetivos a seguir.

Lo curioso del caso es ver cómo ante una falta temporal de liderazgo, este compañero (como otros más) habían optado por aferrarse a su anterior objetivo, pese a saber que no tendrá continuidad.

Esto me hizo pensar en que en una empresa, al igual que en un ejército en una batalla, todos necesitamos tener una serie de objetivos que nos ayuden enfocar nuestro trabajo y esfuerzos, y una persona que nos dirija hacia ellos.

 

No en vano, la palabra objetivo proviene de ‘ob-jactum‘ que significa ‘a donde se dirigen nuestras acciones‘, y no solo nos valen para saber qué buscamos cuando realizamos nuestro trabajo, si no también como refuerzo de la legitimidad de lo que hacemos (vamos por el buen camino/hacemos lo que debemos hacer) y evaluar nuestra eficacia y productividad.
Por todo ello, todos los que tenemos la responsabilidad de liderar o supervisar a un grupo de personas, desde los niveles más inmediatos a los superiores, debemos tener siempre presente no solo la necesidad de mantener los canales de comunicación adecuados si no también de ser consciente de que tengan claros sus objetivos.
Y además de transmitir los objetivos adecuados, asegurarnos de:

  • Mantener su validez o cambiarlos por unos nuevos ante cambios estratégicos.
  • Que sean realistas para que cada persona, o las personas, que los reciban crean en ellos y no los den de lado. Unos objetivos no creíbles, pueden ser aún peor que no tener objetivos claros.

 

No tener esto en cuenta, dejando que tu equipo, o equipos de trabajo, trabajen sobre objetivos poco claros, no realistas o sin la convicción de que sirvan para algo, terminan provocando situaciones caóticas y desmotivadoras que afectan negativamente al trabajo y la productividad.

Fallos: la importancia de las pruebas.

Hace unos días, hablaba con un viejo amigo que se ha especializado en el área de Pruebas de sistemas (en LinkedIn podéis ver su perfil por si os interesa) y hablando de salarios me comentaba lo difícil que resultaba, habiéndose especializado en ese área, conseguir un salario alto.

 

Esto me hizo pensar en que quizás el problema podría estar en que si de por sí en nuestro sector la labor de Programador no estaba muy valorada, en el caso de Ingenieros de Pruebas la cosa era a veces incluso peor.

Lo curioso es que para mí, que llevo ya un tiempo en este mundillo, tan importante me resulta una tarea como otra, ya que ambas son parte del mismo proceso de Diseño y Desarrollo de Software. Y si la programación debe de conseguir implementar correctamente los requisitos de usuario, tanto en funcionalidad, operativa como en rendimiento, las pruebas deben de ser las que validen que así se ha hecho, además de validar (según la aplicación que estemos diseñando) cosas como la seguridad y estabilidad del sistema resultante.

 

Todo esto me hizo recordar una noticia que había leído hace muy poco (el 2 de agosto pasado) sobre las pérdidas sufridas por la firma de corretaje Knight Capital, de hasta 440 millones de dólares, por un error informático:

«Este problema estuvo relacionado con la instalación de un software para realizar transacciones en los mercados y que provocó que Knight enviase numerosas órdenes erróneas de valores cotizados en la bolsa de Nueva York (NYSE)», explicó hoy la empresa de Nueva Jersey en un comunicado.

 

Como podéis ver en este caso concreto, un fallo informático (aunque detrás de todo fallo informático está siempre un fallo humano, como bien dice Fernando Suárez)  ha supuesto un enorme descalabro en las cuentas de la empresa, y la pérdida de valor bursátil al día siguiente.

Y aunque no haya datos en este caso sobre el ‘error informático’, no estaría de más revisar cuál ha sido el proceso de diseño-desarrollo-pruebas del nuevo software, para establecer porqué no se detecto en las pruebas realizadas, o si es que realmente alguien decidió que no era necesario realizar tales pruebas (o no tenían que ser especialmente exhaustivas) pensando en ahorrar unos cuantos miles de dólares.

 

Esto, que a toro pasado parece algo evidente y lógico, por desgracia aún a día de hoy no está debidamente valorado, muchas veces por quien desarrolla el software, otras muchas por quien será el usuario de dicho software y paga la factura.

O sencillamente, las prisas por llevar a producción un sistema o no tener el entorno adecuado de pruebas, terminando provocando que lo que parecía una buena solución de ahorro pase a ser el motivo de pérdidas económicas.

 

Y es que según algún estudio, los fallos informáticos están a la orden del día y pueden suponer hasta 75.000€ de pérdidas por hora, algo que en tiempos de crisis y necesidad de optimizar y mejorar nuestra productividad no es algo como para no tener en cuenta.

Pérdidas que se pueden producir tanto por operaciones incorrectas, como en el caso anterior, como por número de horas de trabajo perdidas porque esa nueva versión software no funciona o lo hace a un rendimiento inferior al esperado.

Aunque también hay casos mucho más graves, como los que he encontrado en esta entrada en el blog ‘Pensamientos Computables’ donde se mencionan casos de fallo Software que han conllevado muertes humanas por mal funcionamiento.

Y por supuesto, no nos olvidemos de las pruebas relativas a la seguridad de aplicativos que se usen a través de internet, para evitar que algún intruso pueda acceder al sistema y liarla.

 

Por todo ello, en la Ingeniería del Software y según recogen las distintas metodologías de software, el proceso de pruebas es una parte más del proceso global, y por tanto nos lo debemos tomar muy en serio para asegurar la calidad del SW desarrollado y la menor tasa de errores en entornos de producción.

 

 

Y por eso mismo, asegurarnos de contar con la gente adecuada para realizar tanto el diseño de los casos de pruebas, como para montar los entornos de prueba adecuados (reproduciendo los entornos de producción finales), dotándoles de las herramientas adecuadas para poder realizar los distintos tipos de pruebas, evitando así llevarnos sustos innecesarios.

 

Si en algún momento nuestro proyecto requiere ahorrar en costes, la solución pasa por buscar el ahorro optimizando el trabajo o usando mejores herramientas, pero nunca eliminando partes necesarias del proceso de desarrollo o pensando que ‘cualquiera puede probar‘.

Productividad, costes y salarios.

Asistía hoy a un aula virtual, donde se trataba el tema de la situación económica actual en España, el tema del ‘rescate’ por parte de la UE y posibles salidas a la situación.

El caso es que en la ronda de preguntas, tras haberse mencionado el tema de ‘bajar los costes salariales’ para mejorar la productividad, yo he preguntado:

¿La rebaja de los salarios no supone también penalizar el ahorro y lastrar la recuperación? Los salarios ya son bajos y antes de la crisis la facilidad de acceso al crédito sostenía el consumo y causaba un alto endeudamiento, pero hoy el consume cae y bajarlos lastra la recuperación.

Aquí la respuesta ha sido que reducir los costes salariales nos hace más competitivos, puesto que consigue que se produzca más barato y facilita las exportaciones (en el 1er trimestre del año la balanza comercial nos es favorable).

Y aquí, si bien reconozco que el argumento es válido, no puedo estar totalmente de acuerdo.

El hecho es que si miramos la relación entre productividad y costes, vemos que la relación es la siguiente:

Productividad = Producto Generado / Coste

Está claro que no descubro nada nuevo, pero normalmente cuando se habla de los costes, es habitual escuchar siempre el término ‘costes salariales’ como único coste, o al menos como único coste ‘reducible’.

Lo cierto es que esto no es así, puesto que en los costes entran varios factores, y aún ciñéndonos solo a los ‘salariales’  debemos tener en cuenta que este coste se compone de:

Coste por hora * hora de trabajo

Y de nuevo no descubro nada, ya que esta relación es lógica y conocida.

Pero aquí debemos plantearnos una cosa, las hora de trabajo ¿son todas efectivas?

Todos sabemos que en una jornada media de 8h obtener un 100% de horas efectivas es imposible, debido a las distracciones, los pequeños problemas del día a día o que simplemente las personas no somos máquinas que puedan trabajar 8h sin descanso.

Pero asumiendo esa realidad, lo único que nos queda de hora a obtener una mayor productividad, es asegurarnos de que las horas improductivas no se disparan y que las horas efectivas sean lo más productivas posibles.

Y aquí entran diversos factores, como son:

  • dotar a cada trabajador de las herramientas adecuadas.
  • realizar un análisis de riesgos que nos permita adelantarnos a los problemas que puedan bloquear el trabajo.
  • identificar las tareas que no dependen de nosotros, pero requerimos o requeriremos en algún momento, y coordinar los esfuerzos de los equipos involucrados para evitar retrasos.
  • tener una planificación clara y accesible para que todos sepan qué deben hacer y cuándo…

En el mundo del desarrollo software hace tiempo que se vienen haciendo esfuerzos en este sentido, con modelos como el de CMMI que en su nivel 4 ya contempla estas cosas:

4 – Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El
software resultante es de alta calidad.

Así, cada vez más empresas que se embarcan en obtener la certificación, muchas veces exigida por grandes clientes y administraciones públicas, van incorporando formas de contabilizar las horas trabajadas y las métricas asociadas a la productividad.

O con frameworks de trabajo como Scrum, en los que además de buscar un mayor conocimiento de la propia capacidad del equipo y su avance, las figuras del Scrum Manager o el Product Owner ayudan a la hora de orientar los esfuerzos de una forma mucho más eficaz.

Pero fuera del mundo SW y de las grandes empresas que se embarcan en obtener estas certificaciones e incorporar métricas e indicadores de productividad, la norma general es encontrarse con innumerables empresas que descuidan muchos estos aspectos.

Desde empresas que no han automatizado muchos procesos, que no conocen mayor informatización que la de comprar PCs y un programa de contabilidad para su departamento de administración, o que simplemente no consideran analizar sus procesos de trabajo para ver dónde mejorar y ganar tiempo en sus tareas diarias.

Incorporar un CRM que te ayude a dar un mejor servicio a tus clientes, para que sus pedidos sean más cómodos y nos roben menos tiempo, o conocer las bondades de un BPM que nos ayude a conocernos mejor, identificar donde podemos mejorar o cambiar para ser más eficaces, son realidades al alcance de muchas empresas que por desgracia aún ven con reticencia y poco útiles.

Por todo esto es por lo que creo que a la hora de hablar de productividad, no solo debemos contar con los costes salariales como única variable de ‘abaratamiento’, si no que también debemos pensar en mejorar nuestras estructuras y procesos como empresa, como vía de reducir nuestros costes totales y mejorar la productividad.

Sirva un ejemplo:

Un desarrollador que diariamente emplea un 25-30% de su tiempo de trabajo en esperar a que determinados procesos (compilación, despliegue, rearranque de servidores, etc…) finalicen para poder continuar.

Quizás su equipo no sea el adecuado porque cuente con un viejo PC obsoleto, o el entorno de desarrollo o pruebas no es el adecuado.

Y aquí una inversión de unos 1000€ (el precio del HW en la actualidad ha bajado mucho)  podría suponer reducir ese 30% a un 10%, con lo que si el coste por hora es de 30€, un 20% de mejora supondría un ahorro de 48€ diarios (8h*30€ = 240€ diarios), es decir, en 21 jornadas de trabajo (1 mes) habríamos recuperado la inversión realizada y empezaríamos a ahorrar en costes.

Obviamente no siempre es tan sencillo ver el ahorro, pero una consultoría (aunque a priori nos parezca otro ‘gasto’) puede mostrarnos áreas de mejora, aconsejarnos soluciones y cómo modelar nuestro negocio para ser no solo más productivos (y por tanto más ‘baratos’) sino además más eficaces.

Si nos fijamos en nuestro sector, las empresas de mayor renombre (Google, Microsoft, Atlassian, …) son conocidas por los profesionales, entre otras cosas por pagar cifrar desorbitadas a sus desarrolladores.

Volviendo a la formula apuntada:

Productividad = Producto Generado / Coste

queda bien claro que mejorar la productividad no solo se consigue bajando el coste. También se consigue mejorando el valor Producto Generado, y esta parte es la que se olvida habitualmente.

Es muy facil cuadrar presupuestos al principio del proyecto bajando el salario. Pero, ¿que pasa con el presupuesto cuando ha pasado el 150% del tiempo planificado para hacer el proyecto y aquello no hay por donde agarrarlo?

En Madrid, por experiencia, si contratas a un desarrollador por menos de 22.000€, bajas los costes, pero consigues, iba a decir trabajo basura (que también), pero queda mas claro si digo Producto basura. Y ojo, es posible tener auténticos cracks contratables por debajo de 22.000€, en la misma proporción que puedes encontrar un Cristiano Ronaldo por menos de 1 millon de € de traspaso.

Entre 22.000 y 30.000 hay mucha mediocridad y algunos valores con futuro, pero tu equipo de desarrollo por esos precios de media, no van a hacer un Producto decente.

Sin embargo, por encima de 40.000, y teniendo cuidado con lo que se contrata, puedes aumentar exponencialmente el valor de tu Producto. Y es que, por mucho lo parezca, 2*22.000 no es igual a 1*44.000,  es bastante menor os lo puedo asegurar.

Ya lo decía mi abuela, que no era directiva ni se había pagado ningún Master en una escuela de negocios, «hay hijo, un día de darás cuenta de que, lo barato, a la larga,  sale caro».

Claro que los que piensa que no es así, son los mismos que piensan que 9 embarazadas hacen un niño en 1 mes, porque caen en el recurrente error de considerar al valor humano como un mero ‘recurso’ y considerar a todos sus ‘recursos’ como igual de productivos y válidos.

Por último, un par de gráficos y un artículo que vienen a corroborar lo dicho, donde podemos ver que la productividad española está en la media de la UE (desterrando el mito de nuestra baja productividad), donde los más productivos no son los países con manos de obra más barata, pero sí los que cuentan con mano de obra cualificada (y bien remunerada) y empresas que apuestan por innovar y mejorar.

Expansión:

¿Quien trabaja más en Europa y cual es el país más productivo?