Archivo de la etiqueta: trabajo

Autogestión en equipos dentro de consultoras – Novela corta de ciencia ficción

Amanece en la playa Muchavista, situado a media distancia entre la población de Campello y la ciudad de Alicante.  Ya se ve bastantes corredores aprovechando el buen tiempo para estirar las piernas a lo largo del paseo marítimo. Los barrenderos limpian los últimos restos y vasos de Mac Donalds dejados por los paseantes nocturnos antes de dar paso a un día que promete tener bastante ocupación de la playa.

Sin embargo, el verdadero movimiento no está precisamente en la arena. A pocos metros de la misma se ve un chico de 30 años, de pie mirando al mar y disfrutando de su café en una taza en la que se lee las palabras “Clean Code”. Da los últimos sorbos, deja la taza en una mesa del jardin y estira sus brazos y piernas para despertarlos después de una noche de sueño reponedor. Javier y su equipo son miembros de una consultora internacional, HGY,  que da servicio a grandes corporaciones financieras. Son un equipo 100% autogestionado dentro de la compañía, y muy disputado entre los clientes de la misma.

Javier recoge la taza y se va al interior de la pequeña casa de dos plantas con vistas al mar.  Deja atrás el pequeño jardín algo dejado a su destino al que nadie presta atención. Atraviesa la cocina  y sube los escalones que dividen la casa entre la planta en la que Javier y sus compañeros de equipo descansan y comen de la planta donde trabajan. El clac, clac, clac de un teclado mecánico le devuelve a Javier a la realidad del trabajo, y le produce una sonrisa.

– Diego, ¿Cómo fue la revisión de lo que entregamos ayer por la tarde a Banco Palomo? ¿Tenemos ya algún comentario de Daniel, nuestro querido Product Owner? – Pregunta tirando  una pelota de malabares que había encima de una de las mesas a  Diego, un miembro del equipo que estaba revisando el tablero Kanban del proyecto.

– De momento no, hay que dejarles que respiren. La entrega de ayer por la mañana les encantó como bien nos dijeron. Un par de días más y creo que ya tendrán el producto que esperaban. Bueno el que ni siquiera se esperaban. – Responde Diego cogiendo la pelota al vuelo, para sorpresa de Javier.

Diego tiene un poco más de edad que Javier pero, al contrario que él, aún no se le asoma ninguna cana.  Es especialista en sistemas web y entre él y Raúl han desarrollado casi todos los interfaces de usuario del sistema Peer Loans, que permite al banco que sus clientes elijan a quién prestar el dinero de sus depósitos.

– ¿Sabemos algo de Héctor? Desde que cogió el avión a Tailandia con su novia Malai no hemos recibido ninguna de sus fotos empalagosas de parejita feliz. – Pregunta Raúl sin mover la cara del monitor de 32 pulgadas en el que va añadiendo pruebas automatizadas para empezar a desarrollar uno de los últimos módulos de Peer Loans. –  Eso me recuerda que tenemos que revisar a los últimos candidatos para reemplazarlo. –

Raúl es un chico de 33 años, experto en lenguajes web y siempre viste con camisetas de Dragon Ball. Lleva en el equipo 3 años y siempre le acompaña su mujer y sus dos hijas allí donde vayan a trabajar.

– A mi me gustaba Jesús, le da a los dos palos de back y front con la suficiente soltura como la que necesitamos. Además es un miembro respetado del Meetup Full Stack Dev Alicante. – Dice Eva acercandose al monitor de Raúl  – Podemos hacerle una visita o quedar en algún bar para hablar con él. Si le gusta el sueldo que le ofrecemos, que seguro que lo hará, estará con nosotros en un par de días. –

Eva es la chica  de QA, de casi 40 años, y en los últimos años ha hecho un gran trabajo inculcando conocimientos sobre casuísticas de tests a los miembros del equipo. Tiene facilidad de palabra y habla muchos idiomas, lo que le permite estar en comunicación constante con los clientes para prevenir todos los escenarios posibles.

– Raúl, no te olvides del buffer overrun en el tratamiento de este campo –  Le dice Eva a Raúl acercándose a su hombro – Por cierto, buen trabajo con estos escenarios. – Una sonrisa de satisfacción casi imperceptible asoma en el rostro de Raúl mientras ejecuta los tests. Una columna de puntos rojos de tests fallidos le indican que es momento de empezar a trabajar en ese trozo de código.

–  No olvidemos que en un par de semanas tendremos nuevo proyecto. A este le quedan sólo un par de coletadas.-  Recuerda Javier desde su puesto de trabajo abriendo la página de la tecnológica Dell y buscando un servidor nuevo para su sistema de integración continua- ¿Habéis revisado últimamente la lista de posibles proyectos? –

Diego se acerca jugueteando con la pelota de malabares a su puesto. Pulsando un botón de su portátil pone en iluminacion su gran monitor así como los leds de su teclado y ratón. Sin sentarse coge el ratón y abre la lista de proyectos que los clientes de HGY les ha enviado. Su éxito con la nueva herramienta de Banco Palomo ha hecho que sean uno de los equipos más solicitados de toda la consultora y prácticamente de toda Europa.  Los honorarios que ellos mismos solicitan son altos pero hay muchos clientes a los que no le importa gastar un poco más para tener a estos chicos a su disposición.

– Ja, ja, ja. ¿A que no adivinais quién nos pide volver a trabajar con ellos? – Suelta Diego riéndose con las manos detrás de la nuca.

Eva y Javier se acercan a su monitor y se unen a Diego en las risas.

– ¿Podemos reirnos todos? – Suelta socarronamente Raúl sin levantar la mirada del monitor y sin dejar de teclear.

Eva, apoyada en la espalda de Diego, se vuelve a Raúl y le dice con una gran sonrisa – Nuestro “amigo” Financial Bureau quiere que le hagamos el sistema de banca con Realidad Aumentada igual al que le hicimos a Banco Marsella. –

–  ¡ Ni de coña ! – Suelta tajantemente Raúl mientras vuelve a ejecutar la lista de tests.  Ahora una columna de puntos verdes remplaza a los rojos, indicando que su cambio ha funcionado a la perfección. Aprovecha para girarse y mirar al resto del equipo. – ¿Os acordáis de lo impertinente que fue el CIO? Nos obligaba a trabajar a través de su entorno virtual. Como si nuestro entorno de red cifrada no fuera menos seguro que el suyo.  Quiere velocidad y calidad y nos da un martillo y un cincel para escribir código.  ¿Hay algun proyecto en Tailandia?  –

– Tú lo que quieres es intentar que Héctor vuelva con nosotros. Si encontramos una oficina cerca de donde van a montar la Startup estarías visitándole a todas horas. – Le dice Eva mirando la lista de posibles clientes.

– No. Es que allí tiene la oficina central Jurgen Fowler, el experto en EcmaScript 11, y que lideró su definición. – Responde Raúl, con media sonrisa –  He estado en comunicación con él últimamente y creo que nos puede preparar un curso intensivo al menos unos días si estamos por allí. El precio que pone es asequible y algunos lo necesitáis bastante… –

– Venga, me apetece empezar a codificar ya. ¿Qué os parece que hagamos una ronda de 3 pomodoros? – Sugiere Diego dirigiéndose a su silla. Esta idea hace que Javier y Eva también vayan corriendo a sus sillas y Raúl haga crujir sus dedos preparándose para una sesión intensa. – Pongo el crono de 25 minutos en marcha.  Empezamos en  3,2,1… –

El sol ya está iluminando con fuerza la arena y los primeros bañistas entran en las aguas de la playa Muchavista. Javier y su equipo están ya concentrados trabajando el resto día para terminar lo poco que le queda de su asignación actual. En un par de semanas, en la fachada de la casa colgará un cartel de “Se alquila”. El equipo se habrá desplazado a un lugar algo más montañoso, por sugerencia de Eva. Sólo ellos mismos saben cual será el siguiente proyecto y lugar en el que trabajen. Son dueños de su propio destino.

FIN

Esta historia, que es naturalmente una historia de ficción, representa una imagen que a día de hoy parece imposible de conseguir en equipos que trabajan para consultoras. Hemos visto algunos ejemplos de decisiones en manos en un equipo totalmente autogestionado, aunque puede haber más. Estos equipos:

  • Deciden quién entra y quién se va de su equipo
  • Deciden su sueldo
  • Deciden su proyecto
  • Deciden dónde trabajan fisicamente
  • Deciden sus herramientas
  • Deciden su formación
  • Deciden cuándo toman vacaciones

Cuando un equipo llega a estos niveles de autonomía, logran una gran motivación y eficacia, lo cual les convierte en un equipo de alto rendimiento y para los clientes se traduce en productos de gran calidad e innovación. Sin embargo para llegar a estos niveles hace falta que tanto los miembros de los equipos como los directivos de las organizaciones tengan como meta conjunta esa autogestión. Los directivos y cargos intermedios tienen que aprender a delegar aunque suponga que al principio cometerán errores. Pero también cada miembro del equipo debe responsabilizarse del poder que se le da y saber dar el paso adelante para tomar esas decisiones. Aunque no lo parezca, tan difícil es lo uno como lo otro. Pero ¿quién sabe?, la ciencia ficción a veces se convierte en realidad. Todo camino empieza por un primer paso ¿Qué tal si empezamos por que los miembros de tu equipo puedan  autoasigarse las tareas?

 

 

Eficacia vs Eficiencia en Scrum

Llevo tiempo dandole vueltas

Ultima mente creo que estoy dando el mensaje incorrecto sobre Agile, que no persigue la eficiencia ya que waterfall es mas eficiente. Todo esto surge de una de las lineas que vi como propuesta del Manifiesto Lean Kanban. No hay sistema teoricamente más eficiente que el waterfall. Cada fase está realizada por un equipo especialista que, sin cambio de contexto, pasa todo su trabajo de una a la fase siguiente. Sin embargo waterfall falla en cuando hay cambios a mitad de proyecto, o cuando hay alguien que no hace perfectamente su trabajo. Cosas que ocurren el 100% de los proyectos. Sin embargo, un equipo que pasa de waterfall a scrum tiene sensación de perdida de eficiencia por las siguientes razones:

  • Reworking. Cada vez que se enseña el software al cliente existe la posibilidad de que toque rehacer algo. Implica cambiar cosas que has hecho en un sprint en el sprint siguiente. También para que el software sea entregable al fin de sprint muchas veces hay que hacer trabajo extra para dejarlo listo.
  • Tener que integrar en cada sprint hace que se tenga que cambiar el contexto continuamente. Si desde el sprint 1 el equipo está peleando con integraciones, a primer momento parece no ser tan eficiente como estar solamente desarrollando. Sin embargo, esto convierte el gran problema de la integración final en una molestia desde el primer sprint.
  • Reuniones de Scrum : planning, daily, review y el refinement. A los equipos a los que se les tradicionalmente se les da una lista de tareas sin mayor explicación, les parece que son innecesarias todas estas reuniones… “Era más productivo cuando se me daba la lista de tareas”.

Sin embargo, aunque no lo parezca Scrum hace que un equipo pueda llegar a ser mucho más productivo. Como indica el titulo del libro de Jeff Sutherland, se puede llegar a entregar el doble de valor en la mitad de tiempo que con metodologías tradicionales. Aunque esto no se consigue por la metra transición a Scrum y mucho menos en el primer sprint. Lo que sí que permite es el marco para que el equipo consiga gran eficiencia. ¿Cómo?

  • Promoviendo que no se haga más de lo solicitado (“make the right think done”). No se debe escribir una sola linea de código que no tenga que ver con el objetivo de la historia de usuario y no se debe hacer una sola tarea o historia que no esté dentro del objetivo de sprint.
  • Protegiendo al equipo de las interrupciones. El equipo está expuesto a interrupciones para hacer burocracia, explicar o documentar su progreso y hacer cosas que no tienen que ver con su objetivo de sprint. El Scrum Master es responsable de proteger a los miembros del equipo.
  • Focalizando las reuniones. Cada reunión Scrum tiene su objetivo y su ventana temporal. Esto hace que las reuniones mismas sean más productivas y permite que durante el tiempo en la que el equipo no está reunido (work time) no tenga que cambiar de contexto por culpa de ellas. Hay que detectar y minimizar o eliminar las reuniones sin foco y que no aporten nada al equipo o producto.
  • Mejorando la comunicación del equipo, haciendo que estén mas coordinados y tengan menos esperas y colisiones entre ellos.
  • Acercando el feedback y testing al momento de desarrollo. Esto hace que la corrección tarde hasta 20 veces menos que si se hubiera hecho semanas después.
  • Permitiendo al equipo pensar de qué modo mejorar a si mismo. Al juntarse en las retrospectivas les permite analizar cómo eliminar los impedimentos y desperdicios (waste) para hacer más y más puntos de historia cada sprint.
  • Permitiendo hacer experimentos de mejora durante un sprint y evaluar si seguirlo o no. Un equipo puede probar algo que parece una locura durante un sprint y evaluar en la siguiente retrospectiva su resultado. De este modo es posible encontrar modos ingeniosos de mejorar la productividad sin poner en riesgo el proyecto.

La proxima vez que explique Scrum, no olvidaré en contar ambas facetas (efectividad y eficiencia). Efectivamente se prima la efectividad ante la eficiencia, pero hay que transmitir que se puede conseguir mucha más eficiencia con equipo Scrum que en equipos tradicionales.

 

 

Precaución: el trabajo en equipo puede perjudicar al equipo

Estamos en una época de revolución de los métodos de trabajo. Se está demostrando que un equipo motivado, autoorganizado y con visión de producto es capaz de dar valor al cliente de forma rápida mientras aprende lo que va necesitando. Hemos aprendido a trabajar en equipo, colaborar, estimar en equipo, planificar en equipo…  Prácticas como el mob-programming en las que un grupo de desarrolladores trabajan en un mismo código con un mismo teclado están creando tendencia. Estamos abriendo las oficinas, quitando muros y juntando mesas para que haya comunicación entre todos los miembros, para que se vean y se oigan fácilmente y la comunicación osmótica fluya.

Sin embargo, todo esto tiene un límite. Estudios recientes están demostrando que la colaboración puede llegar a ser excesiva cuando impide conseguir los objetivos personales de los miembros del equipo. Actividades de colaboración (reuniones, responder preguntas, hacer coaching a un compañero, conectar por escritorio remoto para ayudar a un colega, etc …) puede llegar a suponer más del 50% del tiempo disponible de trabajo.

Además, se está demostrando que alrededor del 25-30% del valor añadido en estas colaboraciones es aportado por solamente el 3 ó 5% de los miembros. Son estas personas que están continuamente en reuniones o resolviendo preguntas. Su experiencia les ha convertido en personas indispensables a la hora de tomar cualquier decisión. Y esto desde cierto punto de vista está bien pero se acaba generando un círculo vicioso que hace que cada vez estas personas sean más indispensables y tengan menos tiempo para su trabajo personal.

Igualmente también nuestros adorados espacios abiertos se están convirtiendo en un problema. El ruido de conversaciones, notificaciones de los teléfonos móviles, sonidos de teclado pueden llegar a anular totalmente la capacidad de concentrarse en el trabajo. Según la comunicación osmótica es importante el valor añadido que puede dar una idea tuya que das por haber oído una conversación cercana o lo que puedes aprender de esa conversación. Pero estos hechos muchas veces son tan aislados que no compensa la falta de productividad que genera el no poder entrar en flujo por culpa del ruido ambiental.

La respuesta está en ser generoso  hacia el equipo con el tiempo personal pero también darle un gran valor. Cosas que se pueden hacer:

  • Saber decir que NO.
  • Priorizar las peticiones de ayuda (informativas, persuasivas y de tiempo).
  • Obligarse a tomar tiempo de concentración (pomodoros) con los auriculares puestos para evitar interrupciones.
  • Gestionar bien las reuniones. JGI
  • Gestionar correctamente el email y los sistemas de mensajería interna.

 

Fuentes

https://hbr.org/2016/01/collaborative-overload

http://time.com/money/4160139/collaboration-teamwork-lower-productivity/

https://hbr.org/2015/12/muting-unwanted-noise-in-an-open-office

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.