Mes: diciembre 2008

No hace mucho tiempo, pensaba que la única salida que teníamos los desarrolladores era la de especializarnos en una tecnología determinada para poder asegurar nuestro futuro. Los continuos cambios y las nuevas tecnologías hacen que cada vez sea mas difícil mantenernos «actualizados» para ser competitivos en el mercado que nos rodea. Esta es una pregunta que desde hace tiempo me quita el sueño y de la que no logro obtener una respuesta clara. Esta claro que ser un experto en una determinada tecnología, puede aportarnos muchas ventajas. Para las pequeñas empresas de desarrollo de software obtener personal especializado en una determinada área es prácticamente imposible, ya que, para ello deberíamos contar con medios y con multitud de personas para conformar un equipo de trabajo.

En mi empresa desde hace tiempo observo que cada vez se da mas importancia a la obtención de personas con perfiles polivalentes, que según las necesidades de esta normalmente delimitadas por las situaciones de un mercado cada vez mas dinámico, sean capaz de adaptarse y asumir roles diferentes a los que están habituados con el fin de conseguir que estas, sean mas competitivas, pero los trabajos son, relativamente mas sencillos, en ningún caso, comparables al desarrollo de software.

Un simple desarrollador en asp.net debe ser capaz de conocer diferentes tecnologías, desde xml, ado, html, servicios web, iis, conocimientos de seguridad, etc. Creo que, una de las características mas valiosa de las personas en el área del desarrollo es la «capacidad de adaptación», ser capaz de asumir una tecnología en poco tiempo y sacarla partido es algo cada vez mas importante en nuestro trabajo, para ello no basta con estar preparados, estudiar o realizar diferentes cursos, hay que tener un nivel de predisposición al cambio, y esto es algo que rara vez se encuentra en las personas, es lógico, cualquier cambio, por pequeño que sea, siempre traerá consigo un sinfín de problemas que debemos solucionar. Por otra parte, estas personas tendrán que renunciar a cierta especialización para ser mas polivalentes. En el área del desarrollo de software es cada vez mas difícil obtener perfiles polivalentes ya que llegar a dominar una sola de las tecnologías con las que trabajamos puede suponer años de estudio y experiencia.

Por otra parte, creo que muchas veces, olvidamos el verdadero sentido de nuestro trabajo, este no es el de realizar aplicaciones utilizando las últimas tendencias y tecnologías, sino el de dar una «solución» a un problema especifico. Desde luego la solución debe combinar muchas factores importantes entre los que destaco el «tiempo», en la mayoría de los casos la introducción de una nueva tecnología frente a una solución ya conocida tendrá inicialmente un coste superior que debemos valorar y que muchas veces olvidamos, para dotar a nuestras aplicaciones de una arquitectura mas moderna, versátil y adaptable, pero que requiere mucho mas tiempo de desarrollo. Uno de los mayores problemas que observo en los desarrolladores, y me incluyo, es que normalmente buscamos que nuestra aplicación sea lo mas perfecta posible, esto incluye la adopción de las mas modernas tecnologías.

Especializarnos en un determinado área pueda hacer que en determinados casos seamos mas competitivos además de ser los únicos capaces de solucionar determinados problemas. Hablando con Fernando Guerrero, me comentaba que su empresa se había especializado en ofrecer soluciones muy determinadas, por ejemplo le llamaban para dar solución a un cliente que tenia una pagina web y que recibía mas de un millón de visitas semanales y en puntas de acceso los servidores se colapsaban, desde luego dar una solución adecuada para un problema similar normalmente pasa por disponer dentro de la empresa a personas con perfiles muy especializados, comentaba que ellos se dedicaban a ofrecer soluciones de problemas muy determinados y que estos suponían un porcentaje ridículo dentro del ámbito del desarrollo de software, y me aseguraba que estaban saturados de trabajo. En este caso contar con perfiles especializados hacia que su empresa podía ofrecer soluciones que otras nunca podrían resolver en un corto periodo de tiempo.

Por otra parte, en mi trabajo, la necesidad de obtener perfiles polivalentes es cada vez mas importante, un simple desarrollador debe conocer diferentes tecnologías y llegar a conocer alguna de ellas en detalle puede llevar mucho tiempo. Ser capaz de conocer a fondo una sola de las tecnologías que utilizamos, por ejemplo «Sql Server», nos puede llevar años de trabajo.

El otro día Rodrigo Corral escribía un post hablando de la importancia de aprender a desarrollar en entornos con multiples procesadores para aprovechar las características del nuevo hardware, comentaba que si somos capaces de aprender y dominar estas nuevas tecnologías tendremos un mercado que nos permitirá marcar la diferencia frente a otros desarrolladores. Lo cierto es que incluso, asumir una nueva tecnología como de las que habla en su post, pasa por conocer muchas otras y que el nivel necesario para poder entender aspectos como la multitarea es algo que no todos están capacitados para realizar.

Quizás la decisión mas adecuada pase por escoger lo mejor de ambos mundos, dominar una o dos areas e intentar ser polivalentes estudiando otras tecnologías para ser capaces de asumir cambios con rapidez, aunque todo dependerá de las necesidades de la empresa para la que trabajemos, por otro lado la especialización en un determinada tecnologia podría ayudarnos en la búsqueda de un futuro profesional mejor.

Así que sigo preguntándome que será mejor: Especializarse o ser polivalente y saber un poco de todo. ¿ Son areas diferenciadas o se pueden  complementar ?… Espero con vuestras opiniones poder aproximarme a la solución mas adecuada. Como decía Malder, «La verdad esta ahí fuera…».

He leído varios comentarios, sobre la importancia del valor del equipo en los departamentos de desarrollo. En el ámbito de las empresas que conozco, normalmente el equipo viene conformado de antemano, a veces porque la empresa cuenta ya con personal, otras porque el proceso de selección se lo encargan a una empresa externa que lo unico que tiene es un perfil predeterminado, son muchos los factores impiden seleccionar al equipo mas adecuado.

Por otro lado, te puedes encontrar que alguna de las personas del grupo no cumple las expectativas esperadas. Llegados a este punto, muchos piensan «Si un desarrollador en un momento determinado no cumple las expectativas lo mejor es deshacerse de el lo antes posible», en este caso, la empresa tendrá un alto precio que pagar ya que normalmente habrá invertido en formación y recursos para mejorar la calidad de su personal y debe buscar a alguien capaz de asumir el trabajo. En el mundo en que nos movemos, si la empresa utiliza tecnologías de última generación o el conocimiento de los procesos internos es complejo, esto se puede convertir en algo sumamente complicado, además de asumir el coste de echar al empleado, debemos formar de nuevo a otra persona e introducirla en el ámbito laboral. Normalmente esta tarea no se realiza en periodos cortos de tiempo y corremos el riesgo de volver a encontrarnos con alguien que no cumple nuestras expectativas y vuelta a empezar….

Comparo algunos equipos de desarrollo con una partida de pocker por la singularidad de sus miembros, en este caso los jefes de proyecto aspiran a recibir una escalera real.  Muchos son los motivos que hacen que una persona no desarrolle su trabajo de forma eficaz, cuando indagas un poco, descubres que algunos tienen problemas familiares,otros se consideran mal pagados y no estan dispuestos a esforzarse mas, en otros casos sus jefes no

saben delegar y se limitan a darles el trabajo basura… Podríamos escribir las causas utilizando los doce tomos de la biblia y nos quedaríamos cortos.

Creo que los responsables de un equipo cuentan con recursos para mejorar esta situación. Una palmadita en la espalda de vez en cuando, mostrar cierto interés hacia la persona, puede hacer que esta se sienta completamente motivada y valorada en su entorno. Ponernos de vez en cuando en el lugar de los demás es algo que debemos intentar para comprender mejor a las personas.

Como responsables de un equipo de trabajo, nuestro cometido pasa por conocer bien a las personas, debemos hacer de psicólogos para entender su comportamiento. Un responsable de equipo en cualquier ámbito debe ser capaz de escuchar, comunicar, delegar, incentivar, transmitir, compartir, enseñar, bromear, irse a tomar unas cervezas o a cenar de vez en cuando con su equipo….. , etc, etc. Después de leer esta frase, alguno en mi oficina se estará descojonando de la risa….. «capaz de escuchar,  motivar…. jajajajajaja….», también es importante asumir nuestros errores, limitaciones y debilidades para tratar de corregirlas, al fin y al cabo, nadie es perfecto.

Existen muchas técnicas para mejorar la relación en un equipo de trabajo, recuerdo tres en especial que me llamaron mucho la atención, la primera era algo así: «Tenemos un grupo de 5 personas, cuatro de las cuales realizan el trabajo de una forma correcta pero el quinto no hace mas que darnos problemas», el proceso de mejora consistía en aplicar dos reglas, primero explicar detalladamente al equipo las ventajas de realizar su trabajo de una forma determinada y la dependencia que tenían los unos de los otros para realizar su cometido y segundo, poner al mas problemático a cargo del equipo. Habitualmente se detectaba que este, cuando comprendía que su trabajo afectaba a los demás y asumía su nuevo Rol se convertía en la persona que mas aportaba cambiando su actitud de rechazo hacia el equipo.

La segunda es bastante conocida y esta basada en la rotación, de vez en cuando los roles del equipo se invertían, un operario pasaba a ser jefe de equipo y al contrario…

La tercera técnica la vi en el programa «el encantador de perros», que pasaba por introducir a un perro inadaptado en una manada estable, al cabo de una semana este abandonaba su actitud y pasaba a formar parte de la manada, haciendo lo mismo que los demás cuando otro perro en su misma situación llegaba. Desde luego contar con un buen equipo que camina en una única dirección hará que cualquier persona que se integre en el, se adapte mas fácilmente a sus reglas. Desgraciadamente algunos animales son mas inteligentes que los hombres.

El trabajo en equipo es una aptitud, independiente del nivel profesional que se pueda tener. Lo malo es que desde pequeños nos han educado a ser individualistas. Cuando vamos al colegio o a la universidad lo único que pensamos es en aprobar, muy pocos acuden con el único fin de aprender, tan solo es un proceso de selección que si pasamos, nos permitirá acceder a una vida mejor. Frases como «tienes que ser mejor que los demás o similares…» son las enseñanzas de la sociedad actual. Los trabajos en equipo desde el colegio, bachillerato pasando por la universidad brillan por su ausencia y claro, cuando nos incorporamos al mercado laboral desconocemos como trabajar con mas personas. Aprender algo basado en todo lo contrario a lo que nos han enseñado desde pequeños es muy complicado, y no seremos capaces de hacerlo si no tenemos plena confianza en el valor de las personas. Muchos responsables no creen en esto, porque jamás se lo han enseñado, así que lo tendrán muy difícil para conformar un buen equipo de trabajo.

Por otro lado, algunos de los genios mas grandes de la historia han ofrecido al mundo sus avances desde la soledad de su trabajo, he conocido personas brillantes que se adaptan muy mal a las reglas del trabajo en equipo o les resulta muy difícil relacionarse con los demás, estas logran su máxima capacidad productiva cuando no tienen reglas que acatar. Detectar a estas personas y dotarlas de capacidad de independencia puede llegar a ser una mejor práctica que obligarla a acatar todas las reglas de un equipo.

La mayoría de la gente no sabe trabajar en equipo simplemente porque nadie les a enseñado la forma de hacerlo, explicar el porque de las cosas, escuchar a todos los componentes, ayudarles y motivarles será el primer paso para transmitir las ventajas del trabajo en equipo. He descubierto a lo largo de mi experiencia, que conocer a las personas nos aporta una visión única, que nos permitirá corregir y mejorar determinados comportamientos, si optamos por la vía mas fácil cuando detectamos problemas, habremos fracasado en nuestro cometido, un jugador de pocker juega con las cartas que recibe.Los buenos jugadores de pocker no basan su juego en las cartas. Los buenos jugadores de pocker analizan la mesa, cada gesto, cada mirada, estudian sus probabilidades e intentan conocer al contrario, aunque contar con buenas cartas hace que sus probabilidades de ganar sean mayores.

Para los buenos jugadores de pocker, las cartas serán un factor importante, pero no determinante.

No puedo resistir dejaros esta foto, que nadie se lo tome a mal….

Pd. Recuerdo de la última partida, jejejeje…, gane…… lo siento Francisco, Victor, Garris,  jajajajajajaja……

En mis primeros años de desarrollo estaba solo, habitualmente desarrollaba mis proyectos como quería, con el paso del tiempo y el aumento de las funcionalidades de los programas y de los avances en los lenguajes de programación, empecé a darme cuenta que pronto no iba a poder desarrollar sistemas de cierto nivel yo solo, en ese momento comencé un nuevo proyecto y me anime con unos amigos a conformar una pequeña empresa dedicada a ofrecer todo tipo de servicios informáticos, hacíamos de todo, desde vender equipos e instalarlos hasta desarrollar pequeñas aplicaciones y algunas páginas web, cuando la empresa fue prosperando necesitamos incorporar más gente al equipo de desarrollo, habitualmente cada uno se iba dedicando a un proyecto de forma individual, observaba a unos desarrolladores que les gustaba el trabajo que hacían y otros que solo trabajaban, digamos, para subsistir, los que verdaderamente aportaban valor eran aquellos que veían su trabajo como un hobbie, a partir de entonces, cuando seleccionaba a alguien, me importaba mas si verdaderamente le gustaba el trabajo que iba a realizar, que las titulaciones y los conocimientos técnicos que tenía. Para mi estaba claro, el valor estaba en las personas que tenían interés por su trabajo. Normalmente los programas no eran muy grandes, hacíamos pequeños análisis y desarrollábamos los proyectos, cuando procedíamos a su instalación el cliente nos hacia observaciones y correcciones, que de forma inmediata se iban resolviendo para adaptarlo completamente a sus especificaciones. El cliente no solamente se limitaba a hacerme correcciones, sino que me proporcionaba ideas para mejorar mis desarrollos, el problema era que esto normalmente lo hacia al final de la implantación y muchas veces tenia que rehacer gran parte de los proyectos asumiendo el coste originado. Habitualmente nos reuníamos con los desarrolladores y hablábamos de cómo realizar el trabajo, ellos proponían sus ideas y compartíamos diferentes puntos de vistas, como dice el refrán “dos ojos ven más que uno”, otras veces me sentaba con algún programador e intentábamos
corregir un error. Para gestionar los proyectos solíamos utilizar excel, project o la lista de tareas de outlook, estas se escribían y se iban tachando a medida que se iban completando.

Cuando comencé a trabajar en equipo, empezaron a aflorar una serie de problemas, los desarrolladores que tenían un nivel más bajo, demandaban de forma constante mi ayuda, y me interrumpían constantemente cuando trabajaba, observaba que dedicaba mucho tiempo a enseñar, corregir e indicar como tenían que realizarse los desarrollos, cuando me preguntaban ¿como vais?, yo estaba totalmente descolocado, en mi caso, conocía la velocidad del trabajo que realizaba, pero no sabía cuánto podrían tardar las personas que tenían otros conocimientos y habilidades. El número de tareas creció mucho mas y su gestión me llevaba mucho tiempo. Me encontraba perdido, porque mis estimaciones fallaban constantemente.

Buscando una solución para estos problemas y gracias a Miguel Jimenez comencé a interesarme por nuevas tendencias en el área del desarrollo de software, empecé a leer sobre desarrollo ágil, en concreto me gustaron las que hablaban de programación extrema o XP, en las que se hablaba de pruebas unitarias, programación en parejas, priorización en la corrección de errores, entregas frecuentes, refactorización, integración del cliente como parte fundamental del equipo, propiedad de código compartida y simplicidad, alguna de las prácticas que se recomendaban eran utilizadas por mi desde hacia tiempo, así que me gustaron especialmente y comencé a estudiarlas un poco más en detalle.

Fue en este momento cuando me tropecé con Scrum y CMMI, buscando información me encontré con el magnífico trabajo realizado en Navegapolis por Juan Palacio y por supuesto, con los post de Rodrigo Corral.

Cuando conocí Scrum, observe que alguno de los factores que me habían llevado a realizar proyectos exitosos estaban ahí, y que además, me proporcionaba una solución para aquellos problemas que estaba tratando de resolver, mejoras en la planificación y la estimación, evitar las constantes interrupciones, mejorar la comunicación con el equipo, involucrar más a las personas, etc.

Las constantes reuniones diarias son la base de la metodología y nos proporcionaban varias ventajas:

– Muchas veces ocurría que cuando hablabas con un desarrollador al cabo un tiempo observaba que llevaba unos días desarrollando de forma incorrecta algún modulo. La falta de comunicación hacia que los retrasos por estas causas aumentasen, con la reunión diaria evitabas enterarte de esto al cabo de un tiempo, reduciendo retrasos y errores en la planificación. Estos se identificaban al principio y permitían mantener el ritmo de desarrollo.

– Al realizar la reunión diaria podías atender todas las dudas y consultas del equipo de desarrollo en ese periodo, con lo que las constantes interrupciones se evitaban, cuando un desarrollador preguntaba algo, se le decía: «eso se atenderá en la reunión de Scrum.»

– El equipo tenía constancia del trabajo que realizaban los demás, redundando en un mejor conocimiento de la aplicación. Ocurría muchas veces que los desarrolladores que realizaban un determinado módulo desconocían el trabajo de los demás, cuando se intentaban enlazar dos módulos aparecían problemas que no se habían tenido en cuenta por falta de información.

– El equipo aporta valor, ya no era el único que resolvía las dudas o decía como tenían que realizarse las cosas, los propios integrantes del equipo ayudaban a sus compañeros a resolver sus problemas y a mí, aportándome ideas y otros puntos de vista sobre cómo llegar a soluciones más óptimas. Esto mejoraba la relación del equipo y el desarrollo del proyecto.

– Resultaba ser una eficaz herramienta de control, como sabéis en la reunión de Scrum se responde a tres preguntas.

      ¿Qué hicistes desde el último Scrum Diario respecto al proyecto?

      ¿Qué harás desde ahora y hasta el próximo Scrum Diario?

      ¿Qué te está impidiendo hacer tu trabajo lo mejor posible o que necesidades tienes para realizar el desarrollo?

La reunión permite conocer el trabajo de cada desarrollador, las dudas y los impedimentos que tienen para realizar su trabajo ademas de la evaluación continua de su trabajo diario. Es como cuando íbamos al colegio y nos preguntaban por la tarea del día anterior, desde luego no hacer la tarea es un riesgo, ya que todo el equipo sabe que nos has realizado tu cometido. Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.

Como sabéis en Scrum se planifican los llamados «sprints» que tienen una duración de entre 20-40 días, en ellos de definen las tareas que vamos a ser capaces de realizar en el periodo determinado. La planificación de cada uno marcaba una dirección clara para el equipo, todos conocen los objetivos y saben que van a obtener al final de cada sprint. En la conformación de los sprints cada miembro del equipo realiza la
estimación y gestión de sus tareas, ellos son los mejores conocedores
de su velocidad, esto hace que el control sea relativamente sencillo de
realizar. En un equipo realizar este proceso era muy complicado, ya que
los desarrolladores no tenían el mismo nivel, por otra parte, un
desarrollador no programa siempre igual, la adopción de nuevas
tecnologías, el progreso y las habilidades de cada uno, hacen que este
sea un factor muy cambiante. Es el desarrollador el que se impone la
tarea y el periodo determinado para desarrollarla, este hecho aporta
gran valor, pues solo se le exige aquello que se ha comprometido a
realizar. Aqui radica una de las premisas de Scrum, la confianza en las
personas es una de las bases de la metologia, si bien puedes ayudar en
las estimaciones al final el desarrollador es el que se compromete.

Posteriormente la evaluación en el sprint review nos permitía
corregir aquello que se había realizado mal en el sprint anterior
evitando incurrir en errores mas de una vez. 

Las constantes entregas permiten al cliente evaluar el trabajo realizado, como se intentan desarrollar módulos «independientes», estos se pueden comenzar a amortizar la aplicación mucho antes de finalizarla.

El feedback del cliente permite realizar cambios mucho mas temprano, evitando rehacer gran parte del proyecto.

Cuando analizaba procesos, comencé a darme cuenta de que la mayoría de los problemas que detectaba, habitualmente, estaban derivados directamente de las relaciones interpersonales, la mayor parte de los responsables desconocía cómo había que trabajar en equipo, esto derivaba en consecuencias verdaderamente catastróficas, normalmente acostumbraban a dar órdenes y eran los únicos que aglutinaban la información de cómo se debían ejecutar los procesos. Cuando hablabas con las personas que realizaban el trabajo, te dabas cuenta de que sus jefes carecían de mucha de la información que ellos manejaban y consecuentemente no podían tomar las decisiones adecuadas, si la comunicación no era fluida entre el responsable y su equipo de trabajo, nunca podrían llegar a mejorar los procesos en los cuales trabajaban. Esto generaba un malestar general entre el equipo que sentía como sus valoraciones no eran escuchadas y redundaba en la bajada de la autoestima y consecuentemente en su rendimiento. Desgraciadamente todavía son muchos, incluidos los jefes de proyecto y las empresas de desarrollo los que no ven a las “personas” como su principal valor. Piensan que las infraestructuras, las máquinas, los procesos y ciertas «certificaciones» son la base de sus negocios. Me cuesta entender que a día de hoy, una gran mayoría de empresas sigan aplicando el método dirigir y controlar o el de Economia 101 tal y como cuenta Joel Spolsky.

Por otra parte, cada día encuentro mas empresas que adoptan una metología simplemente por estrategia, para vender software a terceros que tienen esa exigencia o por disponer de una certificación que avala lo bien que trabajan, recuerdo cuando se puso de moda la Iso 9001…., no estoy diciendo que no aporten cierto valor, pero creo que tienen un precio muy alto que pagar.

Scrum proporciona un método sencillo para estimar, controlar y dirigir proyectos minimizando la burocracia, centrándose y adaptándose a las necesidades de cada momento. 

En Scrum se trabaja en equipo, todos tienen voz y voto, sus opiniones se toman en cuenta y pasan a formar parte del proyecto. Para todos aquellos que crean que su principal valor esta en las «personas», Scrum será una excelente metología.