Jorge Serrano
  • Home

Cómo recompensar al equipo de desarrollo que cumple o no hacerlo

  • By jorge
  • Nov-10-2010
  • Sin categoría
  • 10 Comments.

Lo que me gusta de los blogs es que la gente puede departir, debatir, comentar y opinar respecto a las diferentes entradas que los bloggers escribimos.

Me gustaría que fueran más los comentarios que aparecen, más que nada porque estoy convencido y seguro de que todos tenemos algo que decir casi siempre, pero muchos no se atreven a hacerlo y es una lástima.

Sin embargo, he tenido la fortuna de leer un comentario en una entrada de Rodrigo Corral (que por otro lado recomiendo leer) en la que María Cecilia PeTri preguntaba algunos aspectos acerca de la motivación.

María preguntaba acerca de la motivación y en su caso concreto, en un proyecto con Scrum y un equipo de personas concreto.
Sus preguntas son sobre todo acercade si se debe recompensar al equipo de desarrollo que cumple sus objetivos en plazo o no.

Aunque en un principio pensaba responder en el blog de Rodrigo, posteriormente pensé que igual su comentario se merecía una entrada en mi blog, en el cuál ya he tratado en alguna ocasión el tema de la motivación.

Antes de comenzar a tratar la pregunta de María y mis respuestas, haré alusión a la entrada que escribí en Julio del 2008 acerca de el valor humano, la motivación y el sentirse valorado.

Indudablemente la motivación es fundamental, pero ojo con crear precedentes.
No es lo mismo recompensar por un proyecto que es un bloc de notas como el de Windows que por un proyecto estratégico para la compañía o por un proyecto de índole especial o incluso por un proyecto donde de antemano se sabe que requerirá un esfuerzo extra.
Esto debe ser tenido en cuenta siempre y los premios deben ser planteados como excepcionalidad siempre.

María en su intervención hacía el siguiente planteamiento:
¿Cómo recompensarían al equipo cuando terminan la iteración antes de tiempo? Este planteo surgió del equipo luego de varios sprints con los items cumplidos en tiempo total menor al estimado (Usamos SCRUM) Este planteo de solicitar recompensa surgió del equipo luego de varias iteraciones con los items terminados en un tiempo total menor al estimado.
a)¿Sería apropiado recompensar? ¿A individuos o al equipo?
b)¿Qué clase de recompensa sería apropiada? Dinero? Regalo?
c)Ante reiteradas oportunidades debería replantearse si la estimación fue hecha adecuadamente?
d)¿Debería esperarse a efectuar una revisión de calidad de los items cumplidos, para luego recompensar?
e)¿Debería realizarse una relación entre items cumplidos Vs Items defectuosos para luego recompensar? (por ejemplo, items que el product owner haya sugerido, y estos hayan sido, dependientes de otros items aun no incluidos o items definidos de forma que no fuera posible cumplir, u otro defecto que haya imposibilitado el desarrollo del item, aunque al momento de la planificación haya parecido apto.)
f) Cuando un miembro termina antes de tiempo, tiene la costumbre de ayudar a sus compañeros a terminar sus items. Y esto colabora con que el equipo completo termine antes de tiempo. En este caso ¿se debería premiar al individuo? ¿al equipo?
g) Otra posibilidad de recompensa es retirarse antes de la oficina el viernes.
Agradecería todas las sugerencias sobre este planteo. Gracias por el interés.

Voy a tratar de dar mi opinión al respecto, opinión que espero respete todo el mundo y que quizás alguno comparta en todos o en alguno de sus puntos, y que quizás otros no vean de esta manera.

Punto a): Por un lado, si varios sprints se cumplieron en un tiempo menor del estimado, es posible que lo que haya fallado es la estimación.
Por otro lado, no soy partidiario de recompensar los sprints finalizados, sino en su caso y al final del todo, el proyecto finalizado, que es diferente.
Respecto a premiar o recompensar a individuos o al equipo, creo que la pregunta contiene indirectamente su propia respuesta.
Si premias al individuo, estás sugiriendo una competición entre ellos que puede ser positiva y dañina al mismo tiempo, mientras que si incentivas al equipo estás valorando el trabajo en equipo y la consecución global de los objetivos.
Yo soy un fervoroso amante del trabajo en equipo.
En un equipo siempre habrá individuos más adaptados o más competentes que otros en diferentes ramas o tareas, pero sin el trabajo de todos, no se podrán conseguir los objetivos, y eso cuenta también.
Si no estás contenta con el equipo, haz como los equipos de futbol a final de temporada, cambia a los individuos no aptos para otros proyectos o gestiónalo de otra manera.
A veces una persona rinde más en un puesto que en otro, y esa visión es responsabilidad también del jefe de proyecto.
Si uno sabe apretar tuercas mejor que otro no le ponga a clavar clavos. A lo mejor clava clavos muy bien, pero donde se le sacará mejor provecho es en apretar tuercas. Quizás convenga que aprenda a clavar clavos, por lo que es seguro que al principio lo hará decentemente pero no suficiente y poco a poco vaya ejecutando su tarea de forma más brillante.
¿Es esa persona mejor que otra o hemos sido los responsables del equipo los que no hemos sabido sacar el máximo provecho a cada componente del equipo?. ¿Entendemos los límites de cada integrante del equipo y dónde desempeña mejor sus funciones o no debemos valorar a todos los integrantes del equipo por igual y mirar más sus conocimientos y limitaciones y en base a ellas valorar?.
Como ves, hay que hacer autocrítica también y a veces la culpa puede ser del director de orquesta que valora injustamente a cada miembro del equipo o no es consciente del rol que le está dando.

Punto b): Hablaré de mi experiencia una vez más.
En una ocasión y sin venir a cuento, a mí me regalaron un cheque para comprar lo que quisiera en unos grandes almacenes.
Eso ocurrió en Irlanda. En España no lo he visto nunca (puede haberlo pero no lo he visto nunca).
Hablando de ese mismo pais, comentaré algo que he contado en privado a mucha gente.
Tuve la oportunidad de conocer a algún manager de Oracle cuando estuve viviendo en aquel pais y me comentaron un día lo que hacían internamente.
El responsable del equipo tenía una bolsa de dinero mensual que administraba entre todos los miembros del equipo.
Cada responsable era el dueño de ese dinero y podía hacer con él lo que considerara oportuno (con lo que se considera un buen uso del mismo claro está).
Me contaron varias anécdotas todas muy dispares.
Uno de ellos prefería llevar todos los Viernes al final del trabajo a sus empleados (compañeros) a tomar pintas de cerveza. De esa manera estaban conversando en un ambiente más fluido y posiblemente desinibidos por el alcohol salían temas que de otra forma nunca se tratarían y ayudaban a mejorar el ambiente y resolver enganchones entre la gente, mejorar temas relativos al día a día, etc.
Otros managers preferían utilizar ese dinero en una comida o cena al final del mes con todos los integrantes del equipo.
Otros llevaban a la gente de fin de semana a algún sitio.
Algunos managers por su lado, hacían estas prácticas con independencia de los resultados. Otros sin embargo, no utilizaban ese dinero si el equipo no había logrado los objetivos.
Como podemos ver, cada responsable debe saber como gestionar este tema, pero siempre habrá daños colaterales.
Por ejemplo, un equipo sin premio habiendo integrantes que han cumplido es injusto para esos integrantes del equipo que han conseguido los objetivos marcados.
Del mismo modo, un equipo con premio habiendo integrantes que no han cumplido en absoluto, es injusto para esos integrantes que chupan rueda.
¿Qué recompensa es la más justa?
Siempre el tema económico es el más práctico porque para uno beber pintas será lo adecuado, mientras que para otros lo será tener una gratificación que le ayude a comprar ese gadget que había visto en la tienda.
Una vez más, lo más obvio es sondear al equipo, pero siempre y cuando se logren los objetivos, porque si lo haces antes pueden creer que se les va a gratificar sea cual sea la meta lograda.
En mi caso particular, yo siempre trato de hablar con la gente para ver que le gusta a cada uno, y así me hago una composición de lugar, pero es complicado y delicado tratar este tipo de temas.

No obstante, este punto tiene tras de sí un punto extra adicional que no se trata en muchas empresas, y es la de motivar al equipo.
No todas las empresas están dispuestas a llevar a cabo la práctica de las recompensas y mucho menos reservan una partida presupuestaria para este tipo de acciones.
Además, recuerdo una empresa española famosa en la que trabajé y con la que llegué al acuerdo de que si terminábamos en fecha un proyecto x recompensarían al equipo (10 personas) con una comida.
El proyecto se acabó y la comida nunca se produjo.
El resultado fue la desbandada de muchos de aquellos empleados a otras empresas.
Las promesas son para cumplirlas, sino, el empleado deja de creer y confiar en su propia empresa, así que ojo también con lo que se promete.

Punto c): Esta pregunta no la respondo porque no la entiendo.

Punto d): No soy partidiario de recompensar un conjunto de items y sí el proyecto.
De nada me sirve que un proyecto de 20 items (por poner un ejemplo mínimo pero esclarecedor) tenga 19 items de una calidad impresionante si al final el item pendiente hace que el proyecto fracase.
Un proyecto es un proyecto, y los items son partes indivisibles del proyecto que todas ellas juntas conforman el proyecto en sí.
Todos los items deben ser correctos y poseer la calidad y consecución concreta. Si fracasa un sólo item, el proyecto ha fracasado.

Punto e): Comparar items satisfactorios vs items defectuosos no es en mi opinión una medida adecuada.
Puede servir para detectar problemas o personas que no cumplen sus objetivos adecuadamente, pero nunca se deberían tomar para motivar o desmotivar.
Quizás, una persona que no cumpla sus objetivos adecuadamente requiera de una atención especial.
Quizás haya que motivarla de una forma diferente, o simplemente explicarla porqué lo hace mal y enseñarla a hacerlo bien.
Hay una frase del filósofo Lao-Tsé que decía: «Si das pescado a un hombre hambriento, le nutres una jornada. Si le enseñas a pescar, le nutrirás toda la vida.»
Con esto quiero argumentar que una persona necesita a veces ser enseñado para que sea autónomo.
Si el programador resuelve items que no estaban bien argumentados de inicio y sale adelante con ellos consiguiendo unos objetivos satisfactorios, es de agradecer, pero es en realidad el trabajo del programador.
Si es un fallo del Product Owner, igual al que hay que llamar la atención es al Product Owner, aunque espero que en ese caso, el Product Owner haya recibido de ese programador el feedback de que ese item estaba mal planteado.
Para la consecución satisfactoria del proyecto, los requerimientos deben estar bien cumplimentados y los items bien identificados, además de ser abordables y coherentes.

Punto f): Si un miembro termina antes de tiempo puede deberse a dos causas:
La primera que sus items están mal dimensionados.
La segunda que es una persona muy válida y extraordinaria.
En este punto, esa persona siempre podrá realizar diferentes tareas que sean del provecho personal o del equipo.
Puede utilizar ese tiempo para mejorar lo que ha realizado, auto-formarse, buscar mejoras, ayudar a otros compañeros, llevar a cabo tareas que se están dejando de lado en este momento pero que podría ir echando un vistazo, etc.
Lo más importante para mí en este caso, es que esa persona esté a gusto desempeñando esas tareas extra y que focalice en primer lugar sus esfuerzos en ayudar al equipo a conseguir las metas marcadas, y si las metas van por buen puerto, que realice tareas que le satisfagan y motiven.

Punto g): Retirarse antes de la oficina el viernes no me parece una recompensa adecuada.
Considero que cada integrante debe hacer sus horas semanales acordadas y si las ha hecho con exceso y ha terminado sus tareas, entonces es cierto que se puede ausentar, pero si ha terminado sus tareas a tiempo pero no ha cumplido sus horas semanales no tiene porqué ausentarse.
En Alemania por ejemplo está mal visto que la gente se quede más tiempo del que debe. Las tareas a acometer y los trabajos a desempeñar deben ser factibles, en caso contrario estarán mal dimensionados.
Una vez más, pondré como ejemplo mi experiencia en Irlanda, y es que cuando quería quedarme un rato más en el trabajo mis compañeros (irlandeses) tiraban de mí y me decían que no, que ya había cumplido.
Me chocó ver que en algunos paises no está bien visto hacer más horas (a excepción de casos muy especiales como es lógico).
El responsable del equipo debe saber qué hace con su gente y como la gestiona.
Yo he dado días libres a integrantes de mi equipo si veo que la persona cumple y que a lo mejor tiene que hacer asuntos personales, no se encuentra bien, o cualquier otro motivo.
En caso contrario, prefiero que esté trabajando echando un cable y si llega el caso que se vaya a casa antes que los demás, pero intentando evitar crear malos hábitos y comparaciones que no generen buen clima en el equipo.
Es muy difícil gestionar a las personas de un equipo y muy importante crear sinergias, ser claros y cumplir las promesas.

Espero que esta entrada genere un interesante debate acerca de cómo creéis que se debe motivar al equipo de desarrollo, así como en responder las preguntas que María hacía, ya que creo que son preguntas que nos podemos hacer con cierta frecuencia aunque no lo parezca.

Comments

10 Responsesso far

  1. anonymous dice:
    10 noviembre, 2010 a las 11:31 am

    ¿Que opinas de que en proyectos grandes, donde hay subdivision por módulos, se premie por equipos?

    Responder
  2. jorge dice:
    10 noviembre, 2010 a las 1:00 pm

    Interesante lo que comentas Ernesto.

    La verdad es que nunca me he visto en esa tesitura y opinar de esto que me planteas es ya hacerlo no basado en mi experiencia sino en lo que opino formalmente.

    El único proyecto grande en el que trabajé era de 200 personas y la subdivisión estaba repartida en diferentes empresas (casi todas consultoras externas) que trabajan casi de forma independiente, con vínculos y relaciones para llegar a buen puerto, pero cada una haciendo la guerra por su cuenta.
    En aquel caso, la motivación y reconocimiento era independiente y en cada «casa» se hacían las cosas según considerara la empresa.
    Allí el único reto era hacerlo mejor y más rápido que el resto.

    Si me encontrara en un proyecto de esa envergadura y con diferentes equipos y todos de la misma empresa, entiendo que la motivación es encajar todas las piezas del puzzle, y que algunas piezas se harán en primer lugar para encajarlas en otras, y que si una pieza no está bien hecha, retrasará al resto al igual que me pasaba en el proyecto en el que participé y que comentaba anteriormente.

    En este caso es muy complicado delimitar lo que es correcto o no. Se puede premiar a todo el equipo completo (200 personas) o dividir bolsas entre los equipos y que se premie por equipo independiente si ese equipo logra sus objetivos. Quizás esto último sería lo más adecuado, pero estos temas son difíciles de tratar porque se pueden herir susceptibilidades si analizamos a cada equipo de forma separada con gente de ese equipo que ha trabajado sensacionalmente y gente que no ha cumplido (paga el equipo que por otra parte es lo justo).

    Un saludo y gracias por opinar. 🙂

    Responder
  3. juank dice:
    10 noviembre, 2010 a las 2:35 pm

    Excelente aporte es articulo.
    mil gracias .

    Responder
  4. jirigoyen dice:
    10 noviembre, 2010 a las 6:51 pm

    La verdadera recompensa es que el proyecto funcione correctamente, que tus jefes te digan lo contentos que están del trabajo realizado, que te sientas cómodo con el equipo de trabajo, que para los integrantes del equipo sea una experiencia enriquecedora que les aporte conocimientos y experiencia y que les ayuden a mejorar su futuro profesional, que los integrantes del equipo opinen que han construido algo importante fruto de un trabajo bien hecho, que observen como su proyecto beneficia a la gente que lo utiliza, etc.

    Los demás incentivos se encuentran en otro plano, en mi opinión algunas de esas prácticas como cenas, incentivos económicos, etc, ni siquiera los incluiría en la clasificación de incentivos sino como herramientas para que en ciertas ocasiones ayuden a mejorar aspectos del trabajo, si bien muchas veces se convierten en fruto de problemas.

    Hay que tener en cuenta que muchos científicos brillantes han logrado sus mayores éxitos desde la sobriedad, pasando muchas necesidades económicas. En muchas ocasiones la necesidad agudiza el ingenio.
    Un Saludo.

    Responder
  5. lfranco dice:
    10 noviembre, 2010 a las 9:12 pm

    Hola J! 🙂

    Coincido contigo en que es muy difícil acertar con los incentivos, ya que cambian en función de cada persona e incluso en la misma persona a lo largo del tiempo.
    Además, el ser humano tiene cierta tendencia a la estabilidad y a la recurrencia (nos acomodamos y nos acostumbramos). De modo que una prima económica bien dada en un momento, puede crear un serio problema en un futuro. Como siempre decimos, es complicado 🙂
    Sólo apuntar a lo que dice Ernesto, que un proyecto grande debe subdividirse en proyectos pequeños y tratarlos independientemente. No he visto jamás una metodología que funcione en un proyecto de esa envergadura ‘como un todo’.
    Un saludo titán! Te llamo mañana 😉

    Responder
  6. alexphantom dice:
    10 noviembre, 2010 a las 10:48 pm

    Como dice Lluis acertar es dificil porque cada persona es un cuadro y tiene una situacion diferente, por tanto necesidades diferentes.
    Poder llegar a un optimo dentro de los incentivos entonces esta en el campo de hasta donde es razonable segun el trabajo realizado. Si te pasas entonces como bien dice Lluis se cae en la comodidad y conlleva a un bajo rendimiento en el futuro. Ahora, tambien es danhino no llegar porque al contrario de lo que opina Juan (es mi opinion) la necesidad lo que agudiza son las preocupaciones, y mientras mas lejos se este de llenar ese vacio que constituiria la necesidad «envasada» mas serian esas preocupaciones y malo seria el rendimiento. Y con preocupaciones, incluso dependiendo de su envergadura, es dificil llevar un proyecto adelante.
    Los pilotos de aviacion civil son un gran ejemplo de esto.

    Responder
  7. jirigoyen dice:
    10 noviembre, 2010 a las 11:13 pm

    @Alejandro, quizás no me has entendido bien, cuando hablo de Incentivos no estoy hablando de sueldos, considero que este está abierto a negociaciones constantes en base lo que cada persona es capaz de generar, yo no trabajo más o menos dependiendo de mi sueldo o incentivos, yo negocio un sueldo en base a mi capacidad y cuando no estoy contento pido que me lo suban, esto es algo normal en una negociación abierta, pero nunca pienso, como no estoy contento con lo que me pagan, no voy a realizar el trabajo al 100%, yo siempre intento hacer el trabajo lo mejor posible si me comprometo a realizarlo y esto es independiente de los incentivos y el sueldo que pueda recibir.

    Siempre puedo dejar mi trabajo e irme a otro lugar donde me valoren mejor si no estoy contento.

    Responder
  8. alexphantom dice:
    10 noviembre, 2010 a las 11:31 pm

    Exacto, pero no es debido a la necesidad sino a tu profesionalidad. Hay personas que de ninguna manera son serios en el trabajo, con incentivos o no. Pero claro que es importante la profesionalidad, pero como bien dices tambien negocias tu sueldo dependiendo de tu capacidad y segun el trabajo (el cual te lo pueden subir o no y ya eso tambien forma parte de los incentivos, aunq de acuerdo contigo en que el sueldo en si no formaria parte de los incentivos sino de la obligacion como acuerdo laboral). Pero resumiendo, es tu profesionalidad la que hace que rindas al 100% a pesar de carencias o que mas bien estes por encima de lo requerido. Ahora, dime si teniendo cierto grado de preocupaciones, y estas elevalas a un determinado peso, vas a rendir siempre a un 100% apoyado en tu profesionalidad. Y una cosa es cierta, claro que puedes irte a otro trabajo precisamente buscando solucionar esas preocupaciones, pero esto ya es una posible solucion al problema (que no siempre se da) y no el debate en si.
    Saludos Alex.

    Responder
  9. anonymous dice:
    11 noviembre, 2010 a las 11:18 am

    Para mí, no hay mejor recompensa que realizar bien tu trabajo y que tus encargados lo valoren. Es un pequeño empujón moral que te ayuda a seguir en tu esfuerzo de superarte. Los incentivos materiales están bien, pero lo importante está en el interior de cada uno y saber que tu esfuerzo ha supuesto un beneficio para el conjunto es la mejor recompensa.
    Los jefes de equipo y encargados deben motivar al personal a su cargo sobre todo moralmente para que se sientan satisfechos de lo que hacen. Aun así, cuando se trata de proyectos de envergadura, un pequeño incentivo tampoco está de más.
    Muy buena entrada, Jorge, como casi siempre.

    Responder
  10. eortuno dice:
    12 noviembre, 2010 a las 1:57 am

    Jorge, tienes la razon, encontrar un incentivo adecuado depende de cada persona del equipo, no podes tratar a todos bajo un comun denominador en lo que a incentivos se refiere, eso tambien demostrara la calidad de PM o lider que sos, por cuan bien conozcas a los miembros de tu equipo, para recompensarlos individualmente.
    Saludos

    Responder

Responder a juank Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

← Previous Post Next Post →

Jorge Serrano

MVP Reconnect


¡Subscríbete a mi canal!
YouTube

Donaciones
Donation

Entradas recientes

  • Go – Arrays
  • Go – Operators
  • Go – Constants
  • Go – Tipos de Datos
  • Go – Variables
  • Hello Go-rld!
  • Introducción a Go o Golang
  • JSON Patch en ASP.NET Core 5 Web API
  • Null Checking en C#
  • ¿Porqué mi página web por defecto de ASP.NET Core no se vé en mi Azure Web App y me da un 404?

Categorías

  • .NET 5
  • .NET Core
  • .NET Core 3.0
  • .NET Core 3.1
  • .NET Framework 2.0
  • .NET Framework 3.0
  • .NET Framework 3.5
  • .NET Framework 4.0
  • .NET Framework 4.5
  • .NET Framework 4.6
  • .NET Framework 4.7
  • .NET Framework 4.8
  • .NET Standard 2.0
  • .NET Standard 2.1
  • AMQP
  • Android
  • Angular
  • API REST
  • Apple
  • Apple iOS
  • Apple macOs
  • Arquitectura
  • ASP.NET
  • ASP.NET Core
  • ASP.NET Core 3
  • ASP.NET Core 5
  • AWS
  • Azure App Service
  • Azure Application Insights
  • Azure Cosmos DB
  • Azure Database Migration Service
  • Azure Databricks
  • Azure DevOps
  • Azure Event Grid
  • Azure Functions
  • Azure IoT
  • Azure Portal
  • Azure PowerShell
  • Azure Queue Storage
  • Azure SQL
  • Azure Storage
  • Azure Virtual Datacenter
  • Azure WebApps
  • Big Data
  • Bing
  • Blazor
  • Blog
  • Bots
  • C#
  • C# 7.0
  • C# 7.1
  • C# 7.2
  • C# 7.3
  • C# 8.0
  • C# 9.0
  • Channel 9
  • Codeplex
  • Codespaces
  • Containers
  • Debugging
  • DevOps
  • Docker
  • Electron
  • Entity Framework
  • Entity Framework Core
  • Entity Framework Core 3.0
  • Entity Framework Core 5
  • Eventos
  • F#
  • FaaS
  • FeatureFlags
  • FeatureToggles
  • Feeds
  • Fluent Assertions
  • General
  • GIMP
  • Git
  • GitHub
  • Go
  • Google
  • Google Analytics
  • Gradle
  • gRPC
  • GSA
  • Historia de la Informática
  • HoloLens
  • HtmlAgilityPack
  • IdentityServer4
  • Inkscape
  • Ionic
  • iOS
  • IoT
  • Java
  • JavaScript
  • JDBC
  • JSON
  • Kubernetes
  • Lenguajes de Programación
  • Libros y Cursos
  • LINQ
  • Linux
  • LiteDB
  • Machine Learning
  • macOS
  • Microservices
  • Microsoft
  • Microsoft .NET Framework 4.5
  • Microsoft 365
  • Microsoft Azure
  • Microsoft Build
  • Microsoft Ignite
  • Microsoft Learn
  • Microsoft Orleans
  • Microsoft Surface Go
  • Microsoft Teams
  • ML.NET
  • MQTT
  • MRO
  • MS-DOS
  • MsCoders Madrid
  • MVP
  • NancyFx
  • Node.js
  • NoSQL
  • NuGet
  • NUnit
  • OData
  • ODP.NET Core
  • Office 2007
  • Office 2010
  • Office 2013
  • Office 2016
  • Office 2019
  • Office 365
  • Open Source
  • Open XML SDK
  • Opinión
  • Orchard CMS
  • OT
  • PaaS
  • Patterns
  • PdfSharpCore
  • Performance
  • PHP
  • Postman
  • Power BI
  • PowerShell
  • PowerShell Core
  • Productividad
  • Project Server 2019
  • R
  • Rendimiento
  • Scala
  • Scraper
  • Security
  • Serverless
  • Service Fabric
  • SharePoint Server 2019
  • SignalR
  • Sin categoría
  • Sistemas Distribuidos
  • Skype
  • Skype for Business Server 2019
  • Small Basic Online
  • SQL Server 2005
  • SQL Server 2008
  • SQL Server 2012
  • SQL Server 2014
  • SQL Server 2016
  • SQL Server 2017
  • SQL Server 2019
  • STOMP
  • Swagger
  • Testing
  • TFS 2017
  • TFS 2018
  • Tools
  • TypeScript
  • Unity
  • UWP
  • UX
  • Visio
  • Visual Basic
  • Visual Studio 2010
  • Visual Studio 2012
  • Visual Studio 2013
  • Visual Studio 2015
  • Visual Studio 2017
  • Visual Studio 2017 for Mac
  • Visual Studio 2019
  • Visual Studio 2019 for Mac
  • Visual Studio App Center
  • Visual Studio Code
  • Visual Studio IntelliCode
  • Visual Studio Live Share
  • Visual Studio Live Share Audio
  • Visual Studio Online
  • VS Anywhere
  • Vue.js
  • Web API
  • WebAssembly
  • WinDbg
  • Windows
  • Windows 10
  • Windows Compatibility Pack
  • Windows Phone 10
  • Windows Phone 7
  • Windows Phone 8
  • Windows Server 2008
  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019
  • Windows Service
  • WinForms
  • WinUI
  • WPF
  • Xamarin
  • Xbox
  • Xcode
  • Xiaomi Mi Band 2
  • xUnit
  • YAML

Archivos

  • enero 2021
  • diciembre 2020
  • noviembre 2020
  • octubre 2020
  • septiembre 2020
  • agosto 2020
  • julio 2020
  • junio 2020
  • mayo 2020
  • abril 2020
  • marzo 2020
  • febrero 2020
  • enero 2020
  • diciembre 2019
  • noviembre 2019
  • octubre 2019
  • septiembre 2019
  • agosto 2019
  • julio 2019
  • junio 2019
  • mayo 2019
  • abril 2019
  • marzo 2019
  • febrero 2019
  • enero 2019
  • diciembre 2018
  • noviembre 2018
  • octubre 2018
  • septiembre 2018
  • agosto 2018
  • julio 2018
  • junio 2018
  • mayo 2018
  • abril 2018
  • marzo 2018
  • febrero 2018
  • enero 2018
  • diciembre 2017
  • noviembre 2017
  • octubre 2017
  • septiembre 2017
  • agosto 2017
  • julio 2017
  • junio 2017
  • febrero 2015
  • octubre 2014
  • junio 2014
  • marzo 2014
  • febrero 2014
  • enero 2014
  • diciembre 2013
  • septiembre 2013
  • agosto 2013
  • julio 2013
  • junio 2013
  • abril 2013
  • febrero 2013
  • enero 2013
  • diciembre 2012
  • noviembre 2012
  • septiembre 2012
  • agosto 2012
  • junio 2012
  • mayo 2012
  • abril 2012
  • marzo 2012
  • febrero 2012
  • enero 2012
  • diciembre 2011
  • noviembre 2011
  • octubre 2011
  • septiembre 2011
  • agosto 2011
  • julio 2011
  • junio 2011
  • mayo 2011
  • abril 2011
  • marzo 2011
  • enero 2011
  • diciembre 2010
  • noviembre 2010
  • octubre 2010
  • septiembre 2010
  • agosto 2010
  • julio 2010
  • junio 2010
  • mayo 2010
  • abril 2010
  • marzo 2010
  • febrero 2010
  • enero 2010
  • diciembre 2009
  • noviembre 2009
  • octubre 2009
  • septiembre 2009
  • agosto 2009
  • julio 2009
  • junio 2009
  • mayo 2009
  • abril 2009
  • marzo 2009
  • febrero 2009
  • enero 2009
  • diciembre 2008
  • noviembre 2008
  • octubre 2008
  • septiembre 2008
  • agosto 2008
  • julio 2008
  • junio 2008
  • mayo 2008
  • abril 2008
  • marzo 2008
  • febrero 2008
  • enero 2008
  • diciembre 2007
  • noviembre 2007
  • octubre 2007
  • septiembre 2007
  • agosto 2007
  • julio 2007
  • junio 2007
  • mayo 2007
  • abril 2007
  • marzo 2007
  • febrero 2007
  • enero 2007
  • diciembre 2006
  • noviembre 2006
  • octubre 2006
  • septiembre 2006
  • agosto 2006
  • julio 2006
  • junio 2006
  • mayo 2006
About This Site

A cras tincidunt, ut tellus et. Gravida scel ipsum sed iaculis, nunc non nam. Placerat sed phase llus, purus purus elit.

Archives Widget
  • January 2010
  • December 2009
  • November 2009
  • October 2009
Categories
  • Entertainment
  • Technology
  • Sports & Recreation
  • Jobs & Lifestyle
Search
  • twitter

Powered by WordPress  |  Business Directory by InkThemes.

This site uses cookies: Find out more.