Todas las entradas de: admin

Antipatrón, midiendo el esfuerzo

<ironic>

Es muy dificil encontrar una métrica que evalúe el rendimiento de los miembros del equipo por separado. Cualquier libro moderno de gestión de personas recomienda evaluar al equipo globalmente pero nosotros, los buenos jefes de equipo, tenemos que recompensar a los que se están dejando el pellejo y localizar a los que no tienen suficiente compromiso con el proyecto.

Una cosa que hacemos bien en España, y por eso somos de los países más competitivos, es nuestra orientación al esfuerzo. Si no dedicamos mil horas diarias a algo y nos dejamos hasta la ultima gota de energía de nuestro cuerpo, un trabajo no está bien hecho. Otros países «más modernos» prefieren buscar formas de hacer el trabajo más comodamente… ¡Nenazas!

El esfuerzo es algo muy dificil de medir. Lamentablemente, las leyes de privacidad nos impiden usar electrocardiogramas en los trabajadores. Con ellas podríamos obtener de manera muy fiable el ritmo de trabajo de cada uno.

Afortunadamente hay otras formas más legales:

Medidor de sudor. Es una sencilla banda adhesiva que se pone en la frente de los trabajadores. Esta banda tiene un pequeño chip y un emisor bluetooth. La banda obtiene el nivel de sudoración en tiempo real y lo envía al servidor central. Cada día los trabajadores tienen que cambiar la banda adhesiva ya que queda (debería quedar) llena de sudor. Es importante tener consumibles  disponibles para que no haya trabajador sin banda. El único problema es que  cada persona sudora de manera distinta y el dispositivo es difícil de calibrar.

Medidor de sudor
Medidor de sudor

Dinamómetro de nalgas. Este es el más fiable  Es un sencillo dispositivo que se coloca entre las nalgas de cada trabajador. Mide la presión ejercida durante el trabajo por su parte trasera y se envía igualmente por bluetooth. A más presión recibida, mayor esfuerzo es el que está efectuando el trabajador. El dinamómetro es personal y cada trabajador debe ser responsable de su limpieza diaria.

Dinamometro de nalgas
Dinamometro de nalgas

Los datos recibidos del esfuerzo son monitorizados en tiempo real. De este modo, nosotros como jefes podemos alentar o castigar a esos trabajadores que no tienen los valores esperados. Se puede definir un máximo y mínimo para que el sistema genere una alarma en tiempo real. Todos los valores son almacenados por un servidor y pueden servir para una recompensa en retribución variable o ascensos. Igualmente, si los datos no son buenos, si por ejemplo no ha ocurrido ninguna presión de nalgas en un mes, con estos datos se dispone de una herramienta objetiva para un despido.

Naturalmente usando este sistema hay que evitar cualquier cambio que suponga una reducción en el esfuerzo. Iría en contra de nuestra política de recompensar el esfuerzo. Las metodologías ágiles son totalmente contraproducentes ya que se ha demostrado que su uso continuado puede bajar el nivel de esfuerzo global. Hay que evitarlas a toda costa.

</ironic>

Índice de emparramiento y problemas del multitasking

La sociedad de la información nos inunda con información desde todos los lados. Notificaciones de mensajes por whatsapp, actividad de tweeter, etiquetados en facebook, emails que llegan, artículos nuevos al blog que estas suscrito. Estamos acostumbrados a hacer como mínimo dos cosas a la vez, vemos la tele mientras navegamos, vemos las redes sociales mientras estamos en el trono, trabajamos con dos monitores para estar atento  a los emails mientras se está programando o escribiendo algún documento…

Estamos acostumbrados a trabajar en multitarea (o multitasking en inglés). Alardeamos de que podemos resolver varias incidencias o problemas a la vez. Sin embargo acostumbrarse a la multitarea tiene su lado negativo, no llegamos a establecer concentración plena en ninguna de las tareas que tenemos delante. El tener capacidad de multitasking nos permite cambiar de una a otra sin problemas pero no llegamos a usar nuestro pleno potencial en ninguna de ellas.

El multitasking no sólo afecta al trabajo. El navegar mentalmente de un tema a otro nos hace vivir el día a día en modo automático mientras pensamos en cómo resolver ese problema del trabajo, en que hay que llevar el coche al taller,  en que queda poco dinero en la cuenta, que la próxima semana hay que ir a la reunión del niño, las cosas que quieres hacer el siguiente mes, etc, etc, etc y… etc.

Yo soy una víctima de ello. Pensaba que mi navegación mental era una aptitud que me permitía encontrar soluciones a las que nadie más llegaba. Esto hasta que me di cuenta que había perdido el control del timón. Esta perdida de concentración estaba afectando a mi trabajo y a mi vida fuera de él.

Leyendo este hallazgo sobre «The Effects of Mindfulness Meditation Training on Multitasking in a
High-Stress Information Environment» encontré este test. Te mide el índice de atención plena que sería lo contrario al índice de emparramiento, que es la capacidad de «estar en la parra», con la mente en otro lado distinto al presente.

Sólo ver el test, si eres de los mios, te sentirás identificado. Tranquilo, parece que hay solución al problema. Se llama Mindfulness. Es un modo de meditación en la que solamente hay que centrarse en la respiración o en las sensaciones del propio cuerpo. Solamente existe el presente y uno mismo. Cualquier pensamiento ajeno hay que descartarlo y volver al presente. Iré contando resultados.

Los tres primeros pasos en la gestión Ágil/Lean

Cuando uno empieza a querer organizar su forma de trabajar quizá lo que aporta Internet es demasiada información. Hace falta saber qué buscar para conseguir lo que necesitas para empezar a cambiar. Después de todos los años que llevo estudiando y aplicando las metodologías ágiles lo que aconsejo siempre es empezar con 3 sencillas cosas. El ABC de la gestión Agil.

1.- Daily Standup. Reuniones de máximo 15 minutos con los miembros del equipo en posición de pie en la cual cada uno comparte en qué trabajo el día anterior, en qué va a trabajar y qué obstáculos o problemas tiene en su camino.

Consejos:

  • No debe ser un informe al jefe. La información es de todos para todos
  • Debe empezar lo antes posible para que de pistoletazo al día pero que este presente el máximo número de personas
  • Si se abre un tema que necesite discusión larga se deja para después del daily.
  • Gente fuera del equipo puede hacer participaciones cortas que ayuden a algún problema. Lo fundamental es no pasarse de los 15 minutos.

2.- Tablero kanban. Panel en el cual hay una columna por fase por la que pasa cada elemento de trabajo representadas por etiquetas. Estos elementos pueden ser historias de usuario, diseños que hay que hacer, máquinas que montar, arreglar, etc.. Cada mes se limpian las etiquetas completadas en la última fase. Cada miembro del equipo mueve la etiqueta de una columna a otra según se va completando. Permite una visión común de cómo va el trabajo y permite tomar decisiones de mejora y de eliminar los bloqueos.

Consejos

  • Ponerlo en un lugar visible y accesible para todos
  • No debe haber más de 20 etiquetas por equipo para que se pueda ver de modo más sencillo
  • Debería haber límites máximo por columna aunque sean altos a principio. Si llega un momento en el que se supera ese límite debería analizarse la causa del problema y mejorar.
  • Ir bajando ese límite máximo según se va mejorando para conseguir un sistema más lineal y eficiente.

3.- Retrospectivas. Reunión a final de mes en cual se junta el equipo para ver qué han hecho bien y qué pueden mejorar. Se puede usar el método del barco  para además identificar las minas, es decir, los elementos externos que os afectan como equipo y para las que tenéis que estar preparados. No debería durar más de una hora u hora y media.

Consejos:

  • Sinceridad pero sin buscar culpables. Algo mal hecho es porque no se tenía conocimientos o herramientas para hacerlo mejor. Esta reunión sirve para buscar estas cosas.
  • Los problemas encontrados deberían buscarse soluciones. Asignar responsables para trabajar en ellas.
  • Se puede usar para dar pequeñas formaciones que ayuden al equipo. Club de lectura, vídeos de Internet, etc..

Con estas tres herramientas cualquier equipo puede empezar a trabajar mejor y de forma más organizada. Es posible que se vean nuevos problemas y se piense que antes no estaban, pero seguramente sea porque antes no se veían. Surgirán problemas que estaban ocultos y que ahora salen a la luz. Permitirá que surjan nuevas necesidades para ir mejorando cada vez más vuestro método de trabajo. Es posible que necesitéis nuevas herramientas para cubrir esas necesidades pero estas tres herramientas básicas os acompañarán día tras día.

Conseguir el ISO y el CMMI3 sin dejar de ser Ágiles, interesante reto

Este año en VSN nos hemos propuesto a pasar la certificación ISO para poder optar a proyectos en que lo requieren. Estamos con la ayuda de un consultor que nos va diciendo lo que tenemos que hacer.

De momento lo que vamos haciendo consiste en documentar todos nuestros procesos internos. No parece más que dejar bien por escrito todo lo que hacemos de manera corporativa. En desarrollo es concreto me toca escribir cómo manejamos los requerimientos en sprints, cómo hacemos seguimiento mediante los dailys y el Diagrama de Flujo Acumulado, como aseguramos la calidad mediante los tests automáticos y manuales. Como hemos ido escribiendo todo lo que ibamos estandarizando en las retrospetivas tenemos bastante escrito.  Sobre todo parece que hay que tener manual de todo lo que se desarrolle. No puede salir un desarrollo nuevo sin un escrito en el que se dice qué y cómo funciona. Yo espero que lo que escribimos como procedimiento de test para que otro desarrollador lo pruebe sea suficiente documentación.

Aparte del ISO se nos recomienda tener una certificación concreta de software. Yo estoy seguro que podemos optar a un CMMI 3 también con el modo ágil en el que trabajamos. De momento me toca ir empollando bien qué piden y si nos falta algo más que gestionar. Cuento con que mejoremos sin dejar de ser ágiles. Veremos si en lo que escribí a mediados de 2009 tenía razón.

Iré contando los avances…

¿Está TDD muerto? Resumen del videodebate

Mientras hacen subtitulos para el Hangout entre David Heinemeier Hansson, Kent Beck y Martin Fowler, voy a escribir un poco lo que han hablado para que los que no entiendan el inglés, o no tienen los 30 minutos para verlo entero, puedan quedarse con las claves. En mi anterior artículo hablo de los artículos y tweets que empezaron la discusión.

El link al video es éste.

Empieza David hablando de los 3 problemas que ve al TDD: la insistencia en que los tests tienen que correr en milisegundos, que termina creando un diseño feo y complejo y que el bucle de rojo-verde-refactor es poco natural para el programador.

Kent cuenta que el TDD le da la confianza que necesita a la hora de dar un desarrollo por completado y funcionando. Sin TDD, uno se va a casa sin la seguridad de que el código que ha escrito funcione bien. Además le ayuda a pensar primero en el problema. Cuando no se tienen especificaciones concretas TDD sirve para empezar de lo más concreto (ejemplos en los tests) a la implementación más genérica.

David entiende en que Kent piense en la seguridad como un factor de felicidad del programador. Él mismo dice que le da prioridad a la felicidad del programador cuando empezó Ruby on Rails. Sin embargo, la seguridad de que todo va a funcionar es sólo un factor de felicidad del programador pero hay otros. El tener que cambiar el flujo de pensamiento a pensar primero el test antes de empezar lo ve como una forma de confundir al programador y no dejarle crear del modo que le es más natural. Además dice que la seguridad de que el código funciona no debería venir unicamente del TDD

Ante un ejemplo reciente de Kent sobre un uso idoneo del TDD, David responde que en los desarrollos que él hace no es normal tener un código tan aislado como el que Kent comenta. Que para poder conseguir un codigo perfecto testeable típico de un input consigue un output tiene que separar capas y capas y crear muchos mocks. Que tiene que hacer un gran sacrificio para conseguir ese código perfecto para TDD.

Kent afirma que en todo esto tiene que haber un balance. Hay que tener en cuenta el coste de aislarlo todo para testearlo de manera independiente y su beneficio. Que no hace falta hacer mocks de todo. Si tienes unos tests de objetos que usan otros objetos reales o un sistema real y se es capaz de tener así la prueba de si va o no va, es suficiente. Cuenta que mucha gente se queja de que el Unit Test no le deja refactorizar. Esto ocurre porque sus tests complejos que tienen mocks que devuelven mocks y como fruto estos tests están muy acoplados a la implementación.

Segun David, el problema está en la definicion de TDD segun algunos sectores del desarrollo. Estos sectores afirman cosas como que cualquier test tiene que estar basado en mocks y que si no usas TDD no eres buen profesional. Incluso que si el diseño del programa no está dirigido por tests, no es buen diseño. Para David es al contrario, TDD fuerza a tener un diseño no natural.

Martin Fowler, quedandose un poco en medio y actuando un poco como arbitro del debate, también dando su opinión más pragmática. Dice que hay en la calle muchas definiciones de TDD. Algunas de ellas dicen que todo tiene que estar con mocks. Sin embargo la realidad es que si no usa mocks y el test es util, perfecto. Dice que el TDD y el Unit test son dos cosas aisladas y hay que tratarlas como tal. Se puede hacer TDD sin que todo el codigo testeado esté aislado. Para él, como ya dijo en su artículo, lo importante es que el código sea autotesteable, que haya un botón que pueda probar todo el código. TDD está bien porque ofrece esto como uno de sus beneficios.  Está de acuerdo en que en ocasiones no se puede usar TDD, cosa que le apena ya que dice que es una herramienta que le gusta. También opina que incluso hay que separar conceptualmente el Unit testing aislado y el no aislado.

El debate termina barajando un posible futuro debate hablando unicamente de si el TDD crea un buen diseño o no.

 

 

 

Negocios sin mentiras

En el libro «La Máquina de la Verdad» de Jams L. Halperin (conseguir) habla de una máquina de la verdad 100% fiable. Empieza usándose en ámbitos como juicios, en el gobierno y acaba siendo una tecnología que todo el mundo lleva encima como si fuera un reloj. Este detector de mentiras portable consigue erradicar la mentira de todos los ámbitos incluso en los negocios. Las empresas cuando hacen negocios entre ellas sólo se dicen qué necesitan de forma sincera y llegan a la mejor solución para ambos.

¿Qué ocurriría en el mundo de los negocios sin la mentira? ¿Que ocurriría si siempre dos partes que hablen entre sí buscasen la mejor manera de ayudarse y no de sacar el máximo provecho sin pensar en el otro?

La confianza es muy importante si se quiere conseguir la mayor eficiencia. En el manifiesto ágil se le dá una gran importancia. El 50% del manifiesto de hecho habla sobre ella.

Individuos e interacciones sobre procesos (Confianza en la gente con la que se trabaja)
Colaboración con el cliente sobre negociación contractual (Confianza cliente – proveedor)

Cuanta menos confianza, más trabajo extra se hace en contratos, controles, seguimientos,… que no dan valor directo al cliente y que son realmente un lastre para el equipo de desarrollo y la empresa en general. Ten más confianza con la gente con la que  trabajas y consigue que tengan más confianza en ti. Esto sí que será un WIN-WIN.

En Toyota la confianza se consigue con relaciones a largo plazo y colaboración mutua. Con los proveedores se colabora para que consigan entregar en menor plazo posible y con menor coste. No se rompe relaciones simplemente porque otro proveedor ofrezca un precio más bajo sino que la ayuda a que llegue a ese precio siendo más eficiente. La confianza del equipo se consigue también con una relación a largo plazo. Todos los trabajadores de Toyota son casi de por vida. El sueldo va aumentando año tras año de trabajo con ellos y los puestos avanzados se consiguen también después de haber trabajado mucho con ellos. De este modo se consigue que cada trabajador entienda la cultura de la empresa y sea una parte inseparable. Cada trabajador de linea tiene el poder de parar la cadena de producción en cuando ve un problema de calidad que no es capaz de arreglar hasta que pasa a la siguiente fase. Esto sólo se puede hacer cuando se tiene mucha confianza en todas y cada una de los personas con las que se trabaja.

Pregunta a tus clientes qué es lo que realmente quieren, no dejes que un contrato os ate  tanto a ti como a ellos. Satisface sus necesidades y, no solo conseguirás recompensa económica por el servicio, también conseguirás que vuelva a hacer negocios contigo. Ataros con un contrato blindado y, ni el cliente podrá ajustar su pedido a sus necesidades ni tu podrás salirte ni una coma aunque ello pueda dar más valor.

To TDD or not to TDD. That is the question

Menuda guerra ha ocurrido esta semana. Cómo decía un compañero, parecía una discusión de Salvame Deluxe pero en el mundo del desarrollo.

Todo empezó cuando David Heinemeier Hansson, padre del Ruby on Rails,  escribió un artículo sobre los problemas de usar TDD. David afirma que hacer TDD no es conveniente, que obliga a separar demasiados intefaces  y que es mejor hacer tests de integración más lentos que de todos modos, con paralelización y test en la nube se pueden hacer muchos a la vez.

Al poco, Bob Martin (Uncle Bob) respondió en su blog que unicamente cuando se aplica TDD se consigue reducir el tiempo de depuración, una documentación unequivoca en los tests y un desacoplamiento entre clases muy valioso por sí mismo. Poco después volvió a escribir explicando un poco más dónde no se puede usar TDD y dónde sí. De este modo respondía a las críticas que suelen surgir sobre la falta de aplicabilidad en algunos entornos.

El propio  Kent Beck, padre del TDD, escribió en facebook un supuesta nota postuma sobre el TDD, echando de menos la técnica y rogando poder encontrar otra que le diera la misma seguridad a la hora de escribir, la misma documentación y enfoque a la hora de escribir.

Personalmente el TDD es una herramienta que vale la pena conocer bien. Entiendo sus dificultades. En más dificil hacerlo bien que cualquier framework, IDE o incluso lenguaje. Requiere que el desarrollador dedique tiempo no a crear, que es lo que más le gusta, sino a poner redes de seguridad a lo que aún no ha empezado a escribir. En VSN no lo hacemos el 100% de las veces. Tenemos «sólo» un 40% de cobertura que nos ofrece ya una gran seguridad a la hora de añadir nuevas funcionalidades o refactorizar. Sin embargo, nada no nos impide intentar tener cada vez más cobertura y usar TDD cada vez en más ocasiones. Como alguien me dijo una vez, si intentas saltar tan alto como para tocar la luna lo más seguro es que nunca lo consigas, pero llegarás muchísimo más alto que si nunca lo hubieses intentado.

Motores, lastres y minas en retrospectivas

¿Cuánto tiempo tardas en ir de casa al trabajo? Normalmente ese tiempo varía un poco cada día. Por ejemplo un día tardas 20 minutos, otro 23, otro 19, 20,… Esa variación de tiempo que ya tienes asumida se llama «Variación de causa común«. Ahora piensa en la última vez que llegaste tarde. Pudo ser por un problema de tráfico, tu hijo estaba enfermo y hubo que llevarlo a casa de la abuela… Esa vez tardaste 40 minutos. Ese tipo de variación se llama «Variación de causa asignable«. Es asignable porque puedes asignarle una razón (o una excusa).

En VSN trabajamos desde hace unos meses  la retrospectiva con la analogía de la lancha. El equipo es una lancha en la que los motores representan aquellas cosas que nos hacen ir rápidos y con calidad.  Los lastres atados son las cosas que nos hacen ir más lentos. Desde hoy tenemos un elemento nuevo. Ahora identificamos también las minas con las que se encuentra esta lancha por el camino. Estas minas representan esos problemas de causa asignable, esos problemas ocasionales que han ocurrido y pueden volver a ocurrir, o no.

20140411_145919_pq

Cuando trabajamos estas retrospectivas, el equipo escribe en los Post-It amarillos los elementos a destacar del sprint: los motores, los lastres y ahora las minas. Una vez están todas las etiquetas en la pizarra las organizamos juntando las comunes y las analizamos. Primero buscamos soluciones para los lastres, después confirmamos que los motores que tenemos siguen siendo útiles y debemos seguir usandolos y por último analizamos las minas para ver cómo actuar cuando nos las volvamos a encontrar.

Primero indicamos la posibilidad de encontrarnosla. Podría ser eventual, esto quiere decir que el problema ha ocurrido y ya está, que es raro que vuelva a ocurrir.Podría ser frecuente, una vez cada sprint o cada pocos sprints. Si es un problema constante lo más normal es que se encuentre en la parte de lastres.  Despues recordamos el efecto que ha causado en el equipo. En qué nos ha afectado. Ha sido una molestia o ha sido un gran trauma. Por último definimos el plan de defensa, qué hacer con la mina la próxima vez que nos la encontremos. Aquí tenemos 3 opciones:

  1. Preparar contramedida para destruir la mina la próxima vez. Se piensa cómo eliminar el riesgo para que no vuelva a afectar lo más mínimo al equipo.
  2. Mitigar el daño cuando ocurra el choque. Podría ser que lo mejor es que cuando el problema ocurra de nuevo estar preparado para que afecte lo menos posible.
  3. Ignorar la mina. Cerrar los ojos, apretar el culo y sencillamente aceptarla tal cual llega. Esto se decide así cuando las consecuencias de tener un plan de acción podrían sobrepasan el efecto de la propia mina.

Los planes que se hacen con las minas las vamos a recoger en un documento accesible por todo el equipo. Cuando en un análisis de sprint, de historia o en algún Daily asome la sospecha de que se nos acerca una mina conocida, sabremos cómo actuar. Con esta sencilla analogía de las minas vamos a tener  lo que se llama en gestión de proyectos tradicional, Gestión de Riesgos. Sin embargo lo hacemos de una manera Ágil. Primero porque lo hace el propio equipo y segundo porque se minimiza el tiempo gestionando este nuevo artefacto respecto a la mejora en el equipo que esperamos que produzca.

Cuando el manager se convierte en un lastre para el equipo

En nuestro equipo de desarrollo hacemos una retrospectiva al final de cada sprint (como se debe). Nosotros usamos la técnica del barco. Dibujo un barco en la pizarra con un espacio de motores que simboliza los lo que nos hace ir a buena velocidad y unos lastres atados que simboliza problemas que nos dificultan ir a mayor velocidad.

En la retrospectiva anterior que celebramos ocurrió algo que no había pasado y el que ocurriera me llenó de orgullo. Me dijeron que YO era un lastre cuando tocaba código de producción. Ocurrió que para intentar hacer una historia de usuario que parecía que no iba a entrar decidí hacerla yo por mi cuenta. Al final produjo unos problemas que les hizo perder el tiempo arreglándolo 😛

Por un lado, como me gusta tanto programar fue en parte una lástima pero como facilitador de equipo me encantó. De hecho di las gracias personalmente después de la reunión a quien me lo dijo y explico por qué.

1.- Decir algo así a quien en principio «es tu jefe» requiere cierto grado de valentía. No debe ser fácil. Por lo tanto veo que hay CONFIANZA por su parte.
2.- Yo, que me esfuerzo en que el equipo vaya cada vez más rápido y con mejor calidad, si en lugar de tener que hacer algo para ello tengo que dejar de hacerlo, para mi es más sencillo.
3.-  Me hace ver que hay el clima de sinceridad en las retrospectivas que es muy necesario para mejorar sprint tras sprint.

Por lo tanto, no tengáis miedo si un día os dicen que habéis hecho algo que se considera un lastre para el equipo, u os habéis equivocado. Es el mejor indicador de que el trabajo de uno es importante y que el resto de cosas se hacen bien, ya que si no fuera así alguien se lo diría para mejorarlo.

En VSN buscamos C++ developer. Lo que no nos cabe en Infojobs

EN VSN estamos contratando. Necesitamos bastante urgentemente dos programadores C++. Quisiera ampliar aquí lo que no nos ha cabido en la oferta de Infojobs.

Analista/Programador Senior C++  – Programador Junior C++
Dos puestos, uno junior y otro aguerrido, un C++ Black Belt que mapee mentalmente el heap y stack sin siquiera levantar la ceja.

Empresa: Video Stream Networks S.L.
Nos dedicamos a hacer software para cadenas de televisión. Tenemos muchos clientes «pequeños» como televisiones locales y últimamente hacemos muchos clientes grandes como la productora Telson/Turner o Dorna, los que retransmiten el MOTOGP. Tenemos oficinas en varias partes del mundo y clientes en casi todos los lados. Nos falta el Ártico y algún rincón más.

Provincia:
Alicante – España

Concretamente en San Juan de Alicante. Hay facilidades de aparcamiento por ser un pueblo, acceso facil desde la autovía y tiendas cercanas de casi todo. Sólo nos echamos de menos un FNAC.

Perfil del Candidato:
Titulado en Ingeniería, preferiblemente en Informática o Telecomunicaciones o Licenciado en Ciencias (Físicas, Matemáticas)
Usamos regularmente conceptos avanzados cómo muestreo de señal digital, algorítmia avanzada, las capas de la comunicación TCP. Necesitamos que tengas una buena base de conocimientos técnicos y una mente bien entrenada.

Analista Programador – Programador C++ con al menos tres años de experiencia.
Te vamos a meter a saco a mantener un programa complejo y sacarlo adelante por lo que necesitamos que le des caña desde el primer día.

Capacidad para asimilar grandes proyectos y entender su código fuente rápidamente.
Como vas a mantener un programa que ya existe, debes tener facilidad en entender el por qué lo que hace. Nosotros te ayudaremos pero eres tú el que debes darnos la mayoría de respuestas. Si te mola bajarte proyectos del Github por el mero hecho de leerlos para ti esto será pan comido.

Buena capacidad comunicativa tanto hablada como escrita para el trabajo en equipo.
El C++ déjalo para el compilador. Tus compañeros necesitamos entenderte bien, y no digamos ya los que trabajan en otros departamentos.

Must have:

C++.
Como segunda (o primera) lengua madre

Aplicaciones visuales (GUI) sobre plataforma Windows (preferiblemente con MFC/Win32).
Crear botones, grids, ponerles textos comprensibles, elementos alineaditos…

Multihilos/Concurrencia/Tiempo real
Tengo que ser sincero. Te vas a tener que pelear con semáforos y sincronía de hilos.  La aplicación que vas a mantener necesita comunicarse continuamente con otros elementos y no puede pararse a pensar ni 40 milisegundos.

TCP / IP, Sockets.
Crear server, crear cliente, conectar, send buffer, receive buffer… ese tipo de cosas

SO Windows.
Entender bien cómo funcionan los hilos y sistema de ficheros en Windows sobre todo. Leer y escribir en registro y otras cosillas que tan poco gusta a los linuxeros.

Microsoft Visual Studio.
Esta será tu herramienta. Si ya la sabes manejar, y conoces sus secretos sabemos que serás más productivo desde el principio que si nunca lo has tocado.

INGLÉS
Esta claro que si sabes bien programar es muy probable que sepas inglés escrito. Sin embargo esperamos que te desenvuelvas bien también en el oral para poder contar contigo en todo tipo de situaciones. En ocasiones hay que llamar a algún cliente, a algun compañero que vive en otro continente, recibir formación en otro pais,….

Good to have:
(Lo que ya nos emocionará si lo tienes)

* Git, Subversion.
Tenemos la mitad de proyectos en Subversion pero los que mantendrás al empezar estan en GIT. Hacer PULL, PUSH, CLONE… Pero cuidado que yo odio los Feature Branches por lo que voy a estar muy atento de cómo lo usas.

* WxWidgets
Como objetivo de que sea multiplatarforma está hecho en xwWidgets… Lo sentimos

* Boost, STL
Esas herramientas que hacen del C++ un mundo mejor en el que vivir

* ActiveX, OCX, Interfaces COM.
CoCreateInstances y QueryIntefaces. Si te suenan nos harás tilín en la entrevista

* Conocimientos en los estándares, codecs y protocolos de streaming de video.
No sólo el DIVX, piratilla. En las teles usan muchos codecs distintos. Si no los conoces ya te irás familiarizando aqui.

* Java, C#.
Sobretodo el C# que es en lo que estamos basando los nuevos productos aunque el Java también nos será útil

* MS SQL Server, diseño de BD, procedimientos almacenados.
Todo necesita su persistencia y nosotros usamos SQL Server. Tendrás que crearte las tablas y lo que necesites tú mismo.

* Conocimientos sobre servicios REST, SOA.
Es a lo que estamos tendiendo, todo basado en servicios web con REST. Si sabes de qué hablamos cuando te lo preguntemos empezaremos con buen pié.

* ActiveMQ
(sigh)

* TDD, Refactoring, Código Limpio.
Es posible que en la entrevista hagas un kata con TDD. En VSN llevamos muchos años perfeccionando el cómo generar test y cómo hacer código limpio y estructurado. ¡ Muestranos lo que sabes y por lo menos a mí me tendrás en el bolsillo !

* Haber trabajado en un proyecto Open Source
Esto es propuesta mia.  Je, je. Si eres friki del desarrollo, sientete orgulloso y hablanos de cómo has pasado sabados por la noche peleandote con el código sólo por gusto.

Ofrecemos:

* Participar en las decisiones de diseño e implementación de los productos.
Desde el primer día. Pensamos que no existe idea mala y queremos oir tu voz en todas las reuniones.

* 6 Meses + 6 Meses + Contrato Indefinido e incorporación a proyecto estable.
Es un puesto que necesitamos y necesitaremos por lo que si lo haces bien tienes tu sitio asegurado.

* Salario en función de la experiencia aportada por el candidato/a.
No es confirmado pero puedes esperar algo entre 25000 y 30000 euros brutos al año. Pensamos que es un buen sueldo para empezar y pero también que el sueldo no debería ser la única motivación para trabajar con nosotros.

* Facilidades para combinar la vida familiar
Para nosotros es muy importante que estés en la oficina en el mismo horario que el resto de compañeros, sobre todo para trabajar en equipo. Sin embargo si necesitas dejar a tus hijos en el cole y llegar algo más tarde no hay problema. Hay facilidades para ajustar el horario un poco hacia los lados.

* Formar parte de una plantilla con el mejor ambiente de trabajo, participando en proyectos de gran envergadura.
Formarás parte de un equipo muy motivado en el que trabajar con intensidad no está reñido con estar de buen humor.

* Gran colaboración entre miembros del equipo de trabajo.
El departamento de desarrollo forma una especie de círculo alargado y siempre vamos moviéndonos en la sillas de un puesto a otro ayudando a quien lo necesite.

* Trabajos colaborativos en grandes proyectos.
Hay algunos proyectos que llevamos entre varias personas.  Así mejoramos la velocidad y disminuimos el riesgo por si alguno se pone malito o tiene algún compromiso.

* Trabajar en un entorno ágil en el que se valora el talento y las ideas de los miembros del equipo.
Hacemos standup dailies reales(menos de 15 min.), tenemos un buen sistema de integración continua, el testing está integrado en el equipo de desarrollo, vamos mejorando retrospectiva tras retrospectiva,… No hacemos SCRUM sino que es más parecido a FDD aunque hacemos entregas oficiales cada 3 semanas.

* Un puesto rotativo de desarrollo de pié para estirar de vez en cuando las piernas
En VSN cuidamos de tu salud. Si necesitas estirar las piernas puedes pasarte un rato a un puesto de desarrollo en el que podrás trabajar de pié y ver las cosas desde otro ángulo.

Experiencia:
3-5 años
Lo sentimos. No necesitamos un newby esta vez

Datos del Puesto:

* El candidato liderará la evolución del producto,siendo apoyado e instruido por un miembro del equipo de desarrollo actual, proponiendo mejoras a la arquitectura actual del sistema, así como las tecnologías y herramientas más apropiadas para la tarea.
Raro pero no tengo nada que añadir.

Nivel Profesional:
Empleado.
A cuenta ajena, claro.

Jornada:
Jornada completa (L-J 9:00-14:00  15:00 – 18:30, V-9:00 15:00)

Si vives cerca y prefieres y a comer allí podrás comer de 14 a 15:30 y después salir a las 19. El salir los viernes a las 15 es una PASADA…

Tipo de contrato:
Indefinido

Creo que ya hemos hablado de esto. Si ambas partes estamos contentas puede que te jubiles con nosotros, sea el que sea el lenguaje de programación que se use entonces.

Funciones:
Analista Programador – Programador

¡Ups!. Esto no me había dado cuenta, que fallo. Para mí el puesto es de DESARROLLADOR en mayúsculas. Olvídate de las funciones típicas. En VSN cortamos, pegamos y coloreamos todo lo que hace falta para sacar el producto con calidad.

Tecnología:
C++,Video, MultiHilo, Concurrencia, TCP/IP,Sockets,Windows,HTTP,Visual Studio,GIT,
Esperamos que no te asuste todo esto.

Si no lo ha hecho, saca brillo a tu currículum y envíamelo a jmuria en el dominio vsn.es. Tus propios compañeros lo leerán y colaborarán en tu selección.