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.

Truco: Solucionar error rtorrent en Raspberry Pi

Estos días atrás estuve trasteando, al fin, con mi Raspberry Pi.

El puente y el post que Javier Pastor publicó en su blog, Incognitosis, me animó a dedicar un rato a montar el Raspberry Pi con un cliente Torrent, además de un MySQL para usarlo como pequeño (muy pequeño) servidor casero.

Pero tras ponerlo en funcionamiento, aprovechando un viejo disco por USB de 2.5″ que tenía por casa, terminé encontrándome con un problema al cabo de un tiempo, que provocaba que el cliente de Torrent (rtorrent) terminase fallando.

rtorrent: page allocation failure: order:3, mode:0x20

Con el problema añadido de dejar el fichero de sesiones bloqueado y no permitiendo que el script de reinicio pudiese volver a arrancarlo.

Tras investigar un poco, encontré un foro donde un usuario indicaba que el problema parecía estar en la activación (en el fichero de configuración .rtorrent.rc) del uso de DHT.

Así que ayer procedí a cambiarlo y hoy he podido comprobar, tras más de 24h encendido, que de momento el problema no se ha vuelto a reproducir.

Por cierto, acaban de anunciar que el modelo B de Raspberry Pi ha sufrido una ampliación de RAM de los 256MB a los 512MB, manteniendo el precio de 35$, lo que lo hace aún más apetecible.

Actualización: pues el error se ha reproducido, es menos habitual pero aún hay fallos. Toca seguir investigando.

 

Edito: 06 noviembre 2012

Tras investigar un poco por los foros de Raspberry, el error apunta a un problema en el kernel de linux que estamos usando o un problema con los drivers USB, que provocaría un error ante condiciones de carga de CPU y uso intensivo del disco duro:

Kernel paging error during heavy network and disk load

 

I have an external, self powered 300gb NTFS drive mounted using ntfs-3g to /mnt/sda1. I am also running rtorrent in a background screen session using the recommended init.d startup script. rtorrent is configured to use ~/rtorrent/watch and ~/rtorrent/session as it’s watch and session directories (which are located on the sd card), and /mnt/sda1/rtorrent/downloads as the primary download directory.

After 30 mins or so of downloading a single torrent at ~1MB/s,
the Raspi crashes and I get the message:

Unable to handle kernel paging request at virtual address 8e78b8a2
pgd =cb9e4000
*pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT
Entering kdb (current0xca4ec520, pid 1313 Oops: (null) due to oops @ 0xc024d3d4

Incluso algún usuario apuntaba al modo ‘Turbo’ habilitado en la última versión, que haría que se usara más CPU para mejorar el tráfico de red:

setting to stabilize the official image

Please add «smsc95xx.turbo_mode=N» to /boot/cmdline.txt in the official image, it prevents the rpi from crashing under load.
Also prevents the log from filling with this:

CODE: SELECT ALL

smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped

by El_Presidente » Thu Aug 16, 2012 5:13 pm
OK – so I’ve done my own Googling and find that the turbo mode is meant to make the Ethernet more efficient but at the cost of using more Kernel memory. Putting this together with comments from around the Pi forum, it looks like the turbo mode grabs too much resource when heavily using the network, leading to kevent drops and page allocation issues. Others believe that because the Ethernet is effectively a port off the USB 3-port hub built into the Pi, it is flooding the whole USB subsystem, thus being a contributor to overall crap USB experience as well as kernel panic/crash.

Lo cierto es que con unas opciones u otras los errores se siguen produciendo, aunque al menos en esta última ocasión parece que con modo turbo anulado ha sido más estable y ha aguantado más tiempo en ejecución.

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‘.