Feliz Navidad y Feliz Año Nuevo Emprendedor 2011

Escrito por Jaime el 23 dic, 2010 en Nuestra historia | 1 comentario

Simplemente nos gustaría felicitar las fiestas a todos nuestros lectores, y aprovechar para dar las gracias a aquellos que nos han acompañado y apoyado durante todo este año de novedades y aprendizaje para nosotros.

Esperemos que el siguiente año sea todo lo mejor posible y que se cumplan todos vuestros deseos. Nosotros intentaremos que se cumplan los nuestros.

Pixellated Christmas: 362/365 by Helen Sotiriadis

Feliz Navidad y Feliz Año Nuevo Emprendedor 2011,

Nuestra Empresa Desde Cero.

Dorita, ¡Sigue el camino de las baldosas amarillas!

Escrito por Jaime el 2 dic, 2010 en Nuestra historia | 2 comentarios

Es necesario enfocarse. Para llevar un proyecto a buen puerto, hay que fijar unos objetivos, elaborar un plan para alcanzar dichos objetivos y desviarse del plan lo menos posible.

Esto, que escrito en un post es facilísimo, en la realidad, es un asunto muy complejo. De hecho, nosotros nos desenfocamos con bastante frecuencia y por eso creo que podemos hablar de ello.

Desde luego que la falta de unos objetivos claros provocan un desenfoque total, pero esto no es perder el foco, es no haber tenido nunca tal foco. De la misma manera, habrá situaciones inevitables durante el proyecto que hagan perdernos.

Camino de baldosas amarillas by Soniation

Sin embargo, podemos quedarnos en un punto intermedio e intentar evitar una serie de situaciones por las que, desde nuestra experiencia, se suele perder el foco. Os damos una serie de consejos que os pueden ayudar:

• Tener claro el camino crítico, aquellos hitos del proyecto en los que su retraso impacta directamente en otros hitos y, por tanto, éstos también se retrasan.
• Definir objetivos a corto plazo que ayuden y motiven a seguir adelante con la intensidad necesaria: “quick wins”.
• Definir tareas a un nivel atómico tal que no se tornen infinitas.
• No reemplazar los objetivos reales de un proyecto por objetivos espejismo, aquellos que parecen que nos ayudan pero que, en realidad, lo que hacen es perjudicarnos y retrasarnos.
• No escuchar el ruido. Durante el proyecto surge ruido, pequeñas tareas prescindibles que requieren tiempo. Hay que ponerse los cascos (en la medida de lo posible).
• Evitar abrir tareas a un ritmo mucho más alto que el ritmo de cerrarlas (en las fases iniciales es normal que ocurra, pero no durante todo el proyecto). Imaginaos una bañera con 5 grifos y 1 único sumidero por el que se pierde el agua correspondiente a 1 solo grifo… ¿qué pasa?
• Intentar evitar las ramificaciones, es decir, aquellas tareas que no forman parte del núcleo del proyecto y que lo que hacen es diversificar el tiempo. Hay que sacar la podadora.
• No ser consecuente con las decisiones tomadas, y necesitar una replanificación constante (mejor hacer algo regular que no llegar nunca a hacer nada).
• No diferenciar entre las tareas urgentes (aquellas que hay que hacer ahora mismo) y las tareas importantes (aquellas que hay que hacer, pero no ahora mismo).

Es muy complicado, lo sabemos, pero hay que intentar reducir al máximo o eliminar estas situaciones que hacen perder el foco del proyecto, y así conseguir finalizarlo con éxito (on budget and on time).

Toc, Toc. ¿Quién es?

Escrito por Victor el 25 nov, 2010 en Nuestra historia | 0 comentarios

Soy una nueva empresa con una tecnología puntera y quiero que seas uno de los primeros en probarme. Seguramente a los tecnólogos que nos lean, este planteamiento puede hacerles salivar, pero por lo general, esta frase es el principio de un buen epitafio. Lo que menos quiere una empresa es algo arriesgado sin verle claramente una finalidad para su negocio.

Nuestro equipo está formado por ingenieros, y como tal, tenemos una tendencia natural a enredarnos en los tecnicismos, algo que nos gusta y además nos hace sentirnos cómodos. Nos gusta montar sistemas complejos y bonitos, seguros y con un montón de funcionalidad, pero en cambio, nos cuesta mucho salir de la madriguera.

Toc toc toc!!! by Lumiago

Y es eso exactamente lo que se necesita una vez que se tiene la idea, mirar a los futuros clientes y tener claro qué problema les vamos a solucionar, qué servicio que necesitan les vamos a ofrecer, porque sin eso, nada vale. Hace poco, las Telecos se dieron cuenta de ello, a nadie le importa si el móvil descarga datos mediante GPRS, 3G, UMTS, HSDPA, de todos ellos o de ninguno, lo que quieren es tener correo electrónico, Facebook, ver fotos de su familia y un montón de aplicaciones. Ahora eso está más o menos claro, pero no olvidemos que hasta “ayer” los móviles y los operadores se anunciaban como los que ofrecían tribanda, IrDA, WAP… aunque nadie tenía muy claro para qué servía eso.

Bueno, y si tenemos claro el problema a solucionar y cómo solucionarlo, ¿Cuál es el próximo paso? La venta, la parte comercial, el cara a cara, la gran prueba de fuego. Pero es necesario enfrentarse a ello cuanto antes, ya que esos deben ser los dos brazos de una empresa: la parte comercial y la parte técnica. Hay que aprovechar la experiencia de venta para estar cerca del cliente y saber qué quiere y cómo lo quiere, y ajustar la solución a ello.

A no ser que estéis haciendo algo por amor al arte, es mejor no alejarse mucho del cliente, pues como dice el dicho periodístico: “No vaya a ser que la realidad te joda una buena noticia”.

Divide y Vencerás

Escrito por Jaime el 2 nov, 2010 en Nuestra historia | 0 comentarios

Con una sentencia tan contundente comenzaba el capítulo de programación modular de una de nuestras asignaturas de la carrera (Estructuras de Datos y Algoritmos). En qué lugar habrá quedado el paradigma de programación modular en un mundo tan orientado a objetos y clases (este primer párrafo NO es APTO para todos los públicos).

I-con by Lightmash

Este proverbio, que venía muy bien para justificar la necesidad de dividir en módulos las líneas de código de un programa informático para su mejor gestión y utilización, es extrapolable a cualquier tipo de actividad cotidiana y, por supuesto, empresarial. En general, se trata de dividir un problema complejo en partes más simples, tantas veces como sea necesario, hasta que la resolución de las partes sea obvia.

La razón de ser de este post es explicar uno de nuestros avances en los últimos tiempos. Hasta ahora para ir acometiendo nuestros hitos, nos proponíamos tareas de alto nivel, sin ninguna estimación para su ejecución, tan sólo iban acompañadas de un responsable y una fecha para su finalización (bastante dilatada en el tiempo). La realidad de esta situación era que nos poníamos a trabajar sobre la tarea justo al final (el efecto examen: estudiar la última noche) con lo que, en el mejor caso, entregábamos algo incompleto o mejorable y requería de replanificación (en otros casos, ni siquiera hacíamos la tarea y por tanto, también requerían replanificación).

Para evitar este problema, tiramos de los apuntes de 2º de carrera: dividamos las megatareas en tareas más atómicas que podamos realizar en una semana, asignando responsables concretos y tiempos estimados de ejecución. Con esto, obtendríamos un listado de todas las tareas que tenemos que realizar durante la semana.

Las ventajas (habiéndose contrastado durante las últimas semanas) son las siguientes:

• Más motivación para finalizar la tarea, al ser una tarea fácilmente abarcable.
• Mejor monitorización y control de lo que se ha realizado y falta por realizar.
• Capacidad de planificación a corto y medio plazo.
• Rápida detección de riesgos y problemas que impacten en el retraso de la realización de una tarea.
• Consecución de los hitos en tiempo.

Con el tiempo probablemente iremos encontrando muchas más ventajas (y alguna desventaja, adicional al incremento temporal de identificación/desglose/asignación de tareas) que os iremos contando, pero nuestra primera impresión es el haber vencido gracias a la división.

¿Qué pesa más, una libra de paja o una libra de hierro?

Escrito por Victor el 28 oct, 2010 en Nuestra historia | 0 comentarios

Ya hemos probado el piloto y, aunque aún le quedan algunas horas de vuelo para poder pilotar un 737, nos gusta su estilo. Este fin de semana nos lo pasamos probándolo y enseñándoselo a nuestros primeros usuarios alfa y parece que coinciden con nosotros: tiene potencial.

Pero una vez pasada la euforia, toca hablar de futuro y, en el momento en el que estamos, eso significa subvención. Los dos polos hacia donde oscila el péndulo son: mantener todo el trabajo dentro del equipo, con un esfuerzo considerable en horas; o externalizar parte del proyecto, con el coste económico que conlleva. Para elegir entre una y otra tenemos buenas razones.

Para externalizar tenemos:

• Una mayor velocidad de ejecución.
• Más experiencia en la mayoría de los campos.
• Disponibilidad amplia (por ejemplo, para dar soporte o poder hablar con los clientes durante la semana).

Y para hacerlo nosotros:

• Mantenemos el conocimiento dentro del equipo.
• Ahorro de dinero.
• Es más sencillo ajustar los requerimientos al producto final.

No es una solución sencilla, especialmente, cuando dentro del equipo hay diferentes sensibilidades para el dinero y para el tiempo disponible.

Question Marks by Don Moyer

Y ahí surgió un dilema, ¿Podríamos plantear un modelo desigual? Es decir, parte del equipo prefiere aportar más horas en vez de capital y, otra parte, se decide más por capital frente a tiempo. De ahí el título, ¿Qué pesa más? La respuesta puede parecer sencilla, pesan lo mismo. Pero, ¿Lo es la solución? Es decir, ¿Cómo podemos asegurar que las dos cosas son una libra? Básicamente, ¿Cómo valorar económicamente el esfuerzo en tiempo? De momento no tenemos la solución. Temporalmente hemos optado por seguir trabajando 5 horas cada uno y aportar todos el mismo capital. Pero sólo de momento, la propuesta sigue abierta. El modelo desigual, ¿No será más un problema que una solución? ¿Quién estima el coste? ¿Quién evalúa el trabajo? ¿Es lo mismo el dinero ahora, que el trabajo a futuro? ¿Es asumible tener que estimar económicamente cada tarea que tengamos? ¿Qué pasa con el trabajo previo?… No hay solución sencilla, y por eso este post está lleno de dudas, pero ha llegado el momento donde una decisión puede lastrar un proyecto. Tenemos que acertar con la solución, no tenemos mucho tiempo, y debe ser una solución viable. Que no nos pase como al Mercader de Venecia y pidamos una libra de carne pero no podamos cortarla sin hacer sangre.

La importancia de un buen equipo

Escrito por Juanma el 15 oct, 2010 en Nuestra historia | 2 comentarios

Hace un par de días, el mundo quedó eclipsado por un equipo de mineros chilenos, que tras más de dos meses bajo tierra, volvían a nacer. Ha sido una historia que he seguido de cerca, quedando admirado de la forma de proceder tanto de las autoridades, como de los mineros atrapados. De estos últimos, admiro su compostura, la forma en que supieron aceptar lo que les venía y, sobre todo, la entereza con la que han aguantado.

Nosotros by nuestraempresadesdecero

Siempre hemos venido hablando de la importancia de tener un buen equipo. Por suerte, nosotros no hemos tenido que vernos en tales dificultades, pero también hemos tenido nuestros altibajos. Después de un año, seguimos adelante con más ganas que nunca. Este fin de semana toca reunión. Pero no es una reunión normal, es la reunión de revisión de nuestro proyecto piloto. Ya está terminado (lleva ya terminado un tiempecillo), y hemos quedado para probarlo en común. Espero que sobre el terreno sea tan útil como nos lo parece a nosotros. Tendremos que ver qué dicen los usuarios iniciales.

Independientemente del resultado quiero dar las gracias a mi equipo, por aguantar en los momentos de apatía y flojera. Y también por apretar y esforzarse en los momentos de euforia y alegría. Todos juntos lo hemos conseguido.