Todavía aplica el Método Ágil de Desarrollo de Software?

Históricamente el Hardware hizo evolución más rápida que el Software y, ya que ambos tuvieron en las primeras etapas su uso en el ámbito empresarial, se aplicó para el Desarrollo de Software una metodología muy estricta especialmente en lo referente a la planificación previa y a la documentación exigida. Los desarrolladores de alguna manera se sentían prisioneros de la documentación y no podían, como era su deseo, dedicar el grueso de su tiempo a lo que disfrutaban haciendo: programar. También los proyectos eran largos y engorrosos y mucha veces frustrantes o fracasaban. En el año 2001 se hizo un  “Manifiesto Ágil” que logró una transformación mayor e hizo que el Desarrollo del Software se hiciera mucho más veloz y a través de los años se han visto los resultados prácticos.

El Método Ágil ha permitido que las apps en nuestros móviles se multipliquen de manera espectacular y en muy poco tiempo. Estamos sintiendo el impacto de la consumerización de la Tecnología de Información y ahora enfrentamos un mundo mucho más complejo. Los proyectos son de mayor impacto y el costo de un fracaso es mucho mayor, y existe la necesidad hacer evolucionar el Método Ágil. Trataremos en el artículo de revisitar el “Manifiesto Ágil”, plantear las circunstancias actuales y algunas opciones y acciones hacia el futuro.

El Manifiesto Ágil en 2001

En el año 2001 críticos de los modelos de mejora del desarrollo de software basados en procesos, se reunieron para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el término “Métodos Ágiles” para definir los métodos que estaban surgiendo como alternativa a las metodologías formales (CMMI, SPICE), las cuáles consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo. Los métodos alternativos se resumieron  en cuatro postulados, los que han quedado denominados como el “Manifiesto Ágil” donde se plantean que “Están poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros para que lo hagan. Con este trabajo han llegado a valorar”:

1.     A los individuos y su interacción, por encima de los procesos y las herramientas.

2.     El software que funciona, por encima de la documentación exhaustiva.

3.     La colaboración con el cliente, por encima de la negociación contractual.

4.     La respuesta al cambio, por encima del seguimiento de un plan.

Aun cuando hay valor en los elementos de la derecha, se valora más los de la izquierda.

El Manifiesto Ágil 2001 y los Analistas de Negocios

El Manifiesto en el año 2001 fue extraordinario para los equipos de desarrollo de software, pero representó retos reales para los Analistas de Negocios y otras partes importantes involucradas en una visión más amplia del desarrollo de aplicaciones. Los problemas que ya existían con el enfoque ágil en el 2001, todavía están presentes hoy, pero han sido magnificados por el panorama cambiante de la entrega de productos de software y como resultado:

·         Hay más información disponible, posiblemente en exceso.

·         Hay contextos, conversaciones y decisiones no documentadas.

·         Las brechas de  comunicaciones se amplían por la mayor dispersión geográfica de los equipos de trabajo.

·         El tiempo de comercialización se ha recortado dramáticamente.

·         Las necesidades de los clientes siguen sin satisfacerse.

La realidad en 2015

En 2015, hay que seriamente repensar el Manifiesto Ágil, ya que en 2001 cuándo se publicó el “Manifiesto Ágil”, la tecnología para el lugar de trabajo lucía muy diferente a lo que encontramos hoy en día. Los canales de comunicación eran más limitados en variedad y compartir la información no era comparable en facilidad a la que hay hoy en día con Internet de alta-velocidad, data móvil y una multitud de opciones de almacenamiento en la Nube. Es necesario repensar el Manifiesto Ágil ya que: (1) El Mundo ha cambiado, (2) El Software está en todas partes (3), La complejidad ha aumentado y (4) Los proyectos todavía fallan. Por eso bueno preguntarse: (a) Cómo luce el “Ágil” hoy en día?, (b) Los Valores del Manifiesto Ágil todavía aplican?, (c) En cuál momento Ágil pasó de procesos a  actitud o mentalidad?, (d) Cómo se puede integrar la intención del Manifiesto con la nueva forma de trabajo? y (e) Cómo se pueden hacer evolucionar los conceptos de agilidad para enfrentar los retos hoy en día de una nueva forma?.

El Manifiesto Ágil en 2015

Hay quienes proponen que es posible que en un Manifiesto del 2015 se tengan que hacer consideraciones como las siguientes:

·         A los individuos y su interacción, combinado con los procesos y las herramientas.

·         El software que funciona, balanceado con la documentación exhaustiva.

·         La colaboración con el cliente, combinada con la negociación contractual.

·         La respuesta al cambio, combinada con el seguimiento de un plan.

Los valores de la izquierda y de la derecha deben ser balanceados.

A esto habría que agregar que en las metodología futuras estarán presentes los siguientes elementos: (a) La data y las ciencias conducirán las decisiones, (b) La cultura será un foco, (c) El comportamiento individual será un conductor y (d) Las herramientas tendrán un rol mucho más determinante.

Algunas recomendaciones para hoy en día

Mientras no aparezca una actualización formal de la Metodología Ágil hay algunas recomendaciones que aplican:

•     Tomar una pausa y repensar temas como estos: (a) Desacoplar el Manifiesto de Ágil, (b) Continuar la evolución del entendimiento y la definición del fracaso, (c)  Evaluar los métodos usados para la comunicación, (d) Hacer seguimiento de las métricas y usarlas para iterar y (e) Pensar en Agilidad desde el punto de vista organizacional.
•    Comunicar: (a) Encontrar formas de constantemente proveer visibilidad a la organización, (b) Permitir el flujo libre de las comunicaciones y las opiniones, (c) Identificar donde las decisiones son tomadas y capturadas y (d) Constantemente preguntar a la gente si entienden no solamente lo que hacen sino también el por qué lo hacen.
•         Evolucionar: (a) Abrir el diálogo sobre cultura, (b) Abrazar los procesos, (c) Comunicar, comunicar, comunicar y (d) Es preferible empezar con exceso de información, a partir de allí se puede seleccionar y limitar para balancear.

Se hace referencia a “A Modern Take on the  Agile Manifesto” publicado por Jama Software (Disponible por solicitud en formato Adobe) y “The Agile Business Analyst: How Much Is Enough?” publicado por Global Software (Disponible por solicitud en formato Adobe).

Proyectos complejos y sus obstáculos

Por qué son una lucha constante los grandes proyectos para las organizaciones? Por qué se siente este fenómeno particularmente en los proyectos de TI? Parcialmente se debe a que los proyectos de TI se han convertido en más y más complejos y más extensos a través de los años.  Los proyectos tienen alcances más amplios, presupuestos mayores, compromisos más extendidos en el tiempo y abarcan equipos humanos más globales. La intensa competencia existente en el mercado también hace que los proyectos sean críticos para el negocio y por ello se puede estar arriesgando mucho en ellos.   

Estudios realizados sobre la experiencia con proyectos han identificado la escasez de talento, la comunicación no adecuada y la debilidad en la Gerencia de Proyectos como barreras importantes para el éxito de los proyectos. Por esas razones se han compilando una serie de observaciones y recomendaciones para los diferentes momentos del proyecto y al final algunas ideas sobre el manejo de obstáculos. Como una nota, usaremos la expresión “stakeholder” a través del artículo para identificar a cada una de las partes interesadas y que participan en un proyecto aun cuando no sean los ejecutores directos:

Definir los resultados de negocios esperados

Los resultados esperados, el propósito de la inversión en tecnología y los beneficios específicos en el proyecto deben estar incluidos y ser específicos para todos y cada uno de los stakeholders.

·         Los promotores y los stakeholders  en el proyecto deben identificar los cambios y las mejoras que esperan ver una vez que se complete la implementación y que estén en producción la nueva tecnología y los nuevos procesos.

·         También es necesario identificar métricas tangibles y significativas.  No es suficiente indicar que se desea simplificar los procesos, disminuir los costos o mejorar la calidad de los datos.

·         Los equipos de trabajo asignados directamente al  proyecto y los involucrados desde las líneas de negocios tienen que ser exigidos y medidos en conjunto y no en forma independiente.

·         Una vez iniciado el proyecto, los promotores del proyecto deben recordar continuamente esos objetivos bien definidos a todos los stakeholders y al equipo del proyecto.  Además se deben crear incentivos que motiven a los miembros del equipo a alcanzar dichos objetivos. 

·         El conciencia de las prioridades ayuda en la toma de las decisiones difíciles cuando haya conflictos o competencia por prioridades.

Ensamblaje y soporte del equipo de proyectos

·         En un mundo ideal los Gerentes de Proyecto siempre pueden armar su “Equipo A” con el mejor personal disponible, pero la escasez de talento a veces obliga a identificar donde se requieren los actores principales y donde se puede operar con otro tipo de recursos.

·         El proyecto puede plantearse como una oportunidad de desarrollo personal a los participantes, combinando miembros del equipos menos experimentados con personas probadas y exitosas, hasta que las primeras puedan operar independientemente.

·         Los líderes de proyecto deben integrar, orientar y entrenar al equipo en (1) los principios básicos y los objetivos del proyecto, (2) en los roles y responsabilidades de cada uno y (3) en las metodologías y herramientas a ser utilizadas.

·         Teniendo claro como se está conformando el  equipo de trabajo se puede determinar cómo enfrentar cualquier brecha de habilidades y se puede comenzar a preparar el plan del proyecto.

Diseñar un Plan de Proyecto razonable

·         Tres actividades asociadas al plan del proyecto son consideradas entre las más difíciles de lograr: (1) aferrarse al plan, (2) la administración de la cronología y de los hitos y (3) la administración de la carga de trabajo del equipo.

·         El Plan del Proyecto define el alcance del proyecto, las fechas de inicio y las responsabilidades.  Es un documento vivo que requiere atención, vigilancia y mantenimiento continuo.  Los equipos de proyecto pueden confirmar su adhesión al plan al comenzar cada reunión con una revisión del mismo.  Las decisiones tomadas en estas reuniones sobre recursos o cambios de alcance, por ejemplo, deben ser consideradas con el entendimiento de como ellas afectarán el proyecto en general.

·         No se deben tolerar desviaciones que no sean aprobadas a través de un proceso formal de requerimiento de cambio.

Prepararse para los obstáculos

·         Prepararse para evitarlos:

o    Hay que focalizarse exclusivamente en los obstáculos importantes, en los que afectan el camino crítico.  Es necesario determinar en qué puede afectar el obstáculo, si se puede vivir con el resultado posible y si se puede hacer algo para prevenirlo. 

o    Es conveniente aplicar este proceso de análisis a los tres obstáculos potenciales para cada prioridad crítica, como resultado habrá menos obstáculos y habrá mayor efectivividad al poder concentrarse en un número menor de obstáculos.

·         Mantener la calma:

o    La calma es uno de los ingredientes claves para el éxito de un proyecto y aun cuando exista la tendencia natural a estresarse o sentirse mal por una situación, hay que evitar que eso ocurra. Se piensa con mayor claridad cuando no se está estresado.

o    Hay que concentrar la energía en la resolución de la situación, evitando la desviación momentánea hacia las circunstancias en las cuales alguien se equivocó y además que fue lo que provocó el obstáculo.

·         Buscar opciones

o    Hay que focalizarse en las opciones existentes para superar el obstáculo. Igualmente no es recomendable concentrarse en lo que causó el obstáculo, a menos que esto ayude a resolverlo.

o    Hay que solicitar ideas a los miembros del equipo, hablar con colegas, preguntar a fuentes no clásicas o típicas. La Gerencia de Proyectos es un deporte de equipo!

·         Evaluar

o    Una vez que haya varias ideas potenciales es necesario evaluar las más factibles: Esas ideas pueden tener éxito?  Cuáles son sus efectos colaterales?  Qué otros efectos negativos?

o    En el inicio, es preferible extraer del análisis los recursos que requiera la opción que se esté considerando, de manera que se pueda tomar en cuenta la solución óptima. La pregunta es si conveniente desechar la solución perfecta solo por no estar seguro de quién o quienes se deben asignar? 

Las estadísticas demuestran que la mayoría, sino todos los proyectos, de una manera u otra entregan menos de lo ofrecido originalmente. El “Project Management Institute” encontró en 2014 que 44% de todas las iniciativas (no limitadas a TI exclusivamente) se consideraban no exitosas, ya que no habían logrado cumplir sus objetivos originales o intención de negocios.  Relacionados a proyectos de TI, el “Standish Group” en 2012 encontró que el 43% de los proyectos de TI completados habían sido entregados tarde, sobre el presupuesto o sin las funcionalidades esperadas y 18% directamente habían fallado (cancelados, no completados o no implementados).

Se hace referencia a “3 Rules for Managing Complex Technology Proyects” http://bit.ly/1HWt8NR  y “Overcoming Project Bottlenecks” http://bit.ly/1FRy7A3 . 

Consejos claves para el manejo de expectativas en la gerencia de Proyectos de Desarrollo (CIO)

Mantener bajo control proyectos, especialmente cuando hay que enfrentar contantes solicitudes de cambio y de adiciones, es el reto más grande que enfrenta un Gerente de Proyecto. Los plazos de cumplimiento de los proyectos sufrirán cuándo los Gerentes de Proyecto desde el principio no establecen correctamente las expectativas con la gerencia, con el cliente o con su equipo, y si no tienen una estrategia para lidiar con un cambio de alcance o de solicitudes de modificaciones de último momento. 

La publicación CIO realizó una encuesta con docenas de ejecutivos de TI, gerentes de proyecto y expertos en gerenciación de proyectos para conocer las sugerencias que tienen para establecer, administrar y ajustar expectativas con el fin de asegurar que se cumplan los compromisos de cumplimiento.  A continuación las 11 principales recomendaciones: 

Involucramiento tempranero, durante el proceso de planificación

Es común que la Alta Gerencia establezca las expectativas para los proyectos, especialmente los de TI, sin tomar en consideración los detalles que su entrega pueda involucrar.  Por esa razón es crítico  dedicar el tiempo apropiado con la Alta Gerencia durante el proceso de planificación para establecer los objetivos medibles con los cuales todos estén de acuerdo.  De esta manera cuando aparezcan temas o problemas siempre se puede referir a dichos objetivos y preguntar a la Gerencia si esos temas afectan su habilidad para producir los resultados.   

Mejor todavía es,  si es posible, participar en el proceso de venta del proyecto, de manera que se conozca lo que espera y los detalles que se discutieron desde un principio.  Mientras mejor conozca el Gerente de Proyecto los objetivos del proyecto, mejor puede guir a su equipo hacia el éxito.      

Involucrar a todos los actores involucrados (Stakeholders), especialmente TI

Cuándo el proyecto tiene un fuerte componente TI es conveniente traer a todo el equipo de TI a una sala, incluyendo  al CIO hasta el programador junior, para asegurar que todos los involucrados tienen clara la cronología y las expectativas del proyecto.   De esta manera, incluso las personas que hacen el código o los que instalan un servidor entienden en un 100% de lo que trata el proyecto y pueden ser ganados al mismo. 

Tener un alcance definido, con condiciones de cierre, y establecer prioridades

Poder contener y mantener el alcance es el “talón de Aquiles” de todos los proyectos, ya que incluso los cambios aparentemente menores pueden acumularse y causar daño mayor.  Los cambios propuestos deben ser rigurosamente evaluados para determinar su impacto sobre el calendario comprometido y los costos involucrados, independientemente de lo insignifantes que aparenten ser.

 

Es importante involucrar al equipo del proyecto en la evaluación de estos cambios.  Se recomienda que los cambios propuestos en proyectos específicos sean incluidos en la revisión de seguimiento semanal de todos los proyectos de desarrollo, ya que el tiempo total de dedicación de desarrollo debe ser considerado cuando se tomen decisiones que puedan afectar las prioridades. 

Ser realista

Desde los primeros días del proyecto es importante establecer fechas realistas que permitan pronósticos precisos.  Completar a tiempo y mantener el proeycto dentro de su presupuesto requiere el compromiso de todas las partes involcradas.  Eso significa que que el cliente, la gerencia y el equipo del proyecto siempre deben estar involucrados en el establecimiento de expectativas y de las fechas a las que se apunta para asegurar que todos participen y apoyen. 

Asegurar que todos, incluyendo Alta Gerencia, entiendan su rol y responsabilidades

Los Gerentes de Proyecto deben aclarar el tiempo y las actividades esperadas, con respecto al proyecto, de cada miembro del equipo y de la gerencia.  Es probablemente todavía más importante esta aclaratoria con respecto a la Alta Gerencia, ya que estos generalmente tienen sus calendarios comprometidos por múltiples semanas. Cada persona debe saber cuándo se efectuaran las reuniones y cual es el objetivo de cada una de ellas.  Muchas veces el error ocurre cuándo no se comunican claramente los objetivos, los tiempos y las mediciones del éxito del proyecto. 

Asegurar que los miembros del equipo se comunican entre ellos

El proyecto debe incluir un Plan de Comunicaciones.  Un Plan de Comunicaciones exitoso generalmente incluye el alcance, los propietarios de cada tarea, las fechas compromiso de cada tarea y el status actualizado y quién debe ser notificado cuando aparecen cuestiones o problemas. 

Tratar de identificar posibles puntos débiles

El diseño de cada proyecto incluye muchas variables y aún contando con preparación infinita, es imposible identificar todos y cada aspecto.  El  identificar esos puntos débiles en forma tempranera en el ciclo de desarrollo ayuda a las relaciones con el cliente, y los posiciona para poder responder rápidamente si la situación lo requiere y así mantener los proyectos dentro del tiempo programado. 

Establecer recordatorios de calendario para los hitos del proyecto

Para mantener los proyectos y equipos dentro de la progresión esperada hay que establecer notificaciones de calendario, alertando a los miembros cuándo los pasos deben ser completados y la fechas comprometidas. 

Disponer de una estrategia de escalación

Nada nunca ocurre de acuerdo a lo planificado, así que para mantener las expectativas bajo control, es necesario trabajar con la gerencia para identificar que temas deben ser escalados y cuales no deben ser escalados.  Sobre la base de esta guía se debe discutir con el equipo del proyecto, y al identificar lo escalable y lo no escalable, se puede establecer la responsabilidad y la rendición de cuentas al nivel de cada uno.  

Programar reuniones de revisión de status – e incluir recordatorios para asegurar que todos asisten

Las reuniones deben ser programadas con la frecuencia considerada conveniente y estas reuniones pueden ser conferencias a distancia o presenciales.  Es muy importante que las reuniones sean abiertas, honestas e inclusivas.  Está comprobado que la comunicación directa entre todas las partes es la mejor y más eficiente forma de entregar un proyecto con calidad. 

No tener miedo de comunicar malas noticias – y ajustar expectativas

Cualquier cosa que ocurra que afecte las fechas del proyecto debe ser comunicada inmediatamente a todos los “stakeholders”.  Nada bueno ocurre si se trata de esconder un problema.  Es importante ser claro y conciso en la transmisión.  En general, los clientes y la gerencia aprecian ser involucrados más temprano que tarde.  Por supuesto, cuando se presentan malas noticias, es importante acompañarlas de las opciones de solución. 

En el artículo de CIO además identifican a través de referencias directas los consultores y las empresas que participaron en la encuesta.

 

http://bit.ly/QmS2R6

Futuro de TI: Evolución de Especialista TI a Ingeniero Versátil (GE Capital)

GE Capital es una corporación muy importante, con más de 50.000 empleados operando en 55 países y con activos de US$514 Billones.  Ella necesita responder a un incremento exponencial en el ritmo de cambio tanto del negocio como de la tecnología.  Este cambio es de un impacto mayor que hace solamente dos o cinco años y definitivamente mucho mayor que hace diez años.  Ello obliga a modificar la manera en que debemos pensar sobre cómo se entrega soluciones y como se invierte en el corto y el largo plazo.  Por ello, la empresa considerar que deben moverse rápidamente, probando enfoques nuevos e iterando velozmente.  

Al igual como muchas organizaciones tradicionales de TI, GE Capital ha tenido un grupo que desarrolla y administra aplicaciones y otro grupo que diseña y administra infraestructura.  A través del tiempo ambos grupos han venido haciendo mucho Outsourcing.  Definitivamente esta no era una estructura organizacional construida para responder rápido. 

Por otro lado, hace un par de décadas, en GE se comenzó a aplicar y en forma exitosa, un proceso de Introducción de Productos Nuevos(IPN).  Eric Reed, CTO de GE Capital, decidió probar el uso de IPN en el mundo de Desarrollo de TI.  Años atrás un ingeniero en GE progresaba a través de  asignaciones a roles como soporte en planta, servicio al cliente y desarrollo de nuevos productos. Con IPN se decidió crear equipos de diferentes disciplinas para focalizarse en el desarrollo de un producto específico.  Reed aplicó esto a TI, seleccionando personas que podían hacer cinco cosas diferentes en un día y se les focalizó en una sola tarea, con el detalle adicionado que no podía ser solamente una persona que escribiera código de la aplicación. 

Se conforma un nuevo tipo de equipo de TI 

En 2013 se creó el primer equipo para el “Desarrollo de un sistema de administración de la flota móvil para la Región Nórdica”.  Se ensambló un grupo diverso de 20 personas, que con experiencia y que previamente se habían especializado en redes, computación, almacenamiento, aplicaciones y middleware para que trabajaran conjuntamente en forma virtual.  Todos quedaron en sus puestos de trabajo originales, en sui misma ubicación física y reportando al mismo supervisor, pero por seis meses no tenían obligaciones diferentes a las del nuevo equipo. 

El equipo recibió entrenamiento en automatización y se les asignaron tres objetivos:

1.     Desarrollar la aplicación rápidamente.

2.     Determinar cómo automatizar la infraestructura.

3.     Aumentar el grado de automatización de la implementación y de las pruebas, de manera de poder integrar DevOps con la entrega continua de aplicaciones.  

Es importante mencionar que no se asignaron ni reglas ni roles, se le dijo al equipo que ellos mismos debían decidirlo.  En la realidad resultó que algunos de los miembros tenían un conocimiento más amplio y las líneas entre las responsabilidades comenzaron a borrarse.  Algunos eran fuertes en ciertas áreas y compartieron su experiencia con otros.  Profesionales tradicionales de Infraestructura tenían algún conocimiento de middleware y de codificación, el suficiente como para usar estos. 

Dentro del enfoque era clave que se creara un ambiente en el cual se permitiera tomar riesgos y cometer errores, lo cual no es nada fácil en GE Capital, reconocido por su reputación en la ejecución. 

Éxito en el proyecto

El proyecto no solamente avanzó rápidamente y la aplicación se entregó en pocos meses, sino que se establecieron nuevos procesos de TI:

Ø  Se aumentó el grado de automatización en el nivel de Infraestructura.

Ø  Se aumentó el grado de automatización en la capa de aplicaciones.

Ø  Se apuntó a un 60%-70% de reutilización en el desarrollo de la aplicación, creándose componentes básicos (Building Blocks) tipo Lego, que se podrán reciclar en futuros proyectos. 

A los del área de negocios de GE Capital les gustó el nuevo enfoque.  Indicaron que típicamente tratan de forzar el máximo los requerimientos para la versión inicial de la aplicación, ya que nunca saben cuándo tendrán oportunidad de hacer mejoras.  El nuevo proceso es más ágil, se implementa una primera solución viable y las capacidades adicionales se van agregando en el tiempo. 

Para TI fue un cambio radical en su forma de pensar.  Después de operar de la misma manera por décadas, se realizó este cambio mayor y hubo momentos de terror.  Definitivamente no era para todos, algunos miembros del equipo salieron del proyecto y regresaron a sus roles anteriores.  Pero Reed está preparado para aplicarlo a proyectos futuros y repensar la forma en que sistemas legacy se construyen y se administran. Se ha hablado mucho de Arquitectura-Orientada-a-Servicios y ahora en GE Capital existe una manera tangible de lograrlo.  Por el lado de los sistemas legacy hay que decidir si se automatiza en mayor grado en Infraestructura y se mantiene el enfoque tradicional de desarrollo de aplicaciones o se invierte en el nuevo enfoque. 

De los miembros del equipo hay algunos que se quedaron con el equipo de la aplicación de flota, otros comenzaron un nuevo proyecto y unos pocos regresaron a su rol original.  Se está tratando de generar discípulos de manera que un  número mayor de personas conozcan el nuevo proceso. 

Reed piensa que la organización de TI cambiará eventualmente:  “Las características que se buscan en la gente cuando se le contrata cambiará,  Por años se buscó gente con gran capacidad técnica.  Después llegó el momento donde creció el Outsourcing y se buscaron perfiles que pudieran manejar proyectos y proveedores.  Ahora se necesitan ambos perfiles  y hay que ver como los mantenemos incentivados.”

Por ello, podemos concluir que GE Capital está repensando como hace TI y para ello está buscando profesionales de tecnología versátiles para responderle a entornos empresariales dentro de un ambiente global de cambio rápido.

 

El material más completo se encuentra en un excelente artículo en la revista CIO

http://bit.ly/1kyG8jB

15 Destructores de la Productividad en Programación

Peter Wayner, escribiendo en “CIO” y haciendo mucho uso del humor desde la perspectiva del programador, hace un interesante análisis de los 15 principales obstáculos que bloquean el progreso en programación: 

1.     Reuniones

El trabajo de programación incluye un esfuerzo mental que implica concentración para poder profundizar en temas como manipulación de conceptos abstractos y  mover el switche para pasar del modo de codificación al modo de reuniones no es nada simple.  Las reuniones requieren otras habilidades y atención y no son fáciles para las programadores donde adicionalmente, el mal manejo de estos encuentros en muchas ocasiones las extiende innecesariamente.  Lo ideal es que las reuniones sean cortas y concretas. 

2.     Responder todos los correos electrónicos

Si para evitar reuniones se concentra el esfuerzo en correo electrónico, la alternativa puede ser hasta peor.  Un gran volumen de correos puede conducir a un abandono total del uso del correo electrónico por parte del programador.  Por esa razón hay que buscar los mecanismos idóneos para hacer el uso racional del mismo.  Como lograr esto dependerá de cada ambiente de trabajo. 

3.     Tratar de medir productividad

Cuándo se enfoca la medición de la productividad de una manera mecánica, por ejemplo usando como indicadores el número de líneas de código o el número de bugs, se está desviando del objetivo real.  Hay que asegurar que los programas funcionen como se espera, que se completen dentro del tiempo previsto y que se integren.  Es importante medir la productividad, y existen herramientas que pueden ayudar a disminuir el código y la redundancia, pero no existe una solución fácil a este problema, ya que es imposible medir elegancia.   

4.     Desarrolladores “prima donna”

Desde el punto de vista del desarrollador solo existe una figura peor que la de su jefe: el colega desarrollador que hizo la última modificación del programa sobre el que debe  trabajar y el cual no funciona.  Esta actitud también se puede extender a la generación anterior de desarrolladores y a la forma en que estos programaban.  Por supuesto, muchos no consideran que no se disponía de las librerías que existen hoy en día para facilitar la vida del desarrollador.  Estas actitudes de “prima donna” de algunos programadores pueden retrasar un proyecto, ya que el orgullo y el egocentrismo puede llevar a ignorar código adecuado ya hecho y a reconstruir continuamente en la búsqueda de la “vía correcta”. 

5.     La mentalidad de “lo arreglo más tarde”

En proyectos nunca parece existir el tiempo necesario para construir todo lo necesario.  Para poder cumplir con los compromisos se apura el trabajo, se buscan vías para recortar el tiempo y muchas veces se termina parcheando el código.  Hay quienes llaman esto “deuda técnica” y existe en todos los proyectos.  En la generación siguiente de programadores aparecen estas “deudas técnicas” y son ellos quienes tienen que corregir la situación que encuentran.  

6.     Gerentes no programadores

Hay personas que llegan a cargos de gerencia técnica sin tener la formación académica y la experiencia apropiada en programación.  Esto puede alegrar a programadores que disfrutan engañando a sus jefes, pero en mucha ocasiones estos Gerentes no pueden ofrecer mucha guía y su principal contribución es proveer calidad en las pruebas.  

7.     Gerentes programadores

También ocurre que al mismo tiempo que programadores se quejan de jefes que no conocen el tema, por otro lado pueden sufrir con gerentes que saben “demasiado” de tecnología.  El gerente que fue un genio programador puede hacer micro-gerencia e incluso realizar cambios a nivel de código.  El problema principal es que el Gerente puede perder la visión global por estar concentrado en el detalle y no gerenciar realmente la unidad.  

8.     Programadores “macho”

Los programadores admiten que hay problemas que pueden estar del lado de ellos, muchas veces son malos comunicándose y no son famosos por darle peso a los sentimientos o los egos.  Con frecuencia los programadores se desvían exclusivamente hacia los temas técnicos y esto puede llevar a  malas consecuencias cuando dentro de un equipo se concentran en convencer sobre su visión técnica, en lugar de trabajar para conseguir resultados prácticos. 

9.     Programadores egoístas

El programador narcisista hace un trabajo brillante de codificación, pero deja en manos de otros las pruebas.  Frecuentemente en los equipos de trabajo de un proyecto esto se descubre demasiado tarde.  Todo luce bien con el código al inicio, pero cuando alguien se comienza a procesar data real allí se descubre que nadie se había preocupado por detectar los problemas de la aplicación. 

10.  Documentación pobre

Documentar toma tiempo, pero el programador considera que le están pagando por producir código.  Así que se deja para más tarde la documentación.  También ocurren  situaciones en las cuales hay documentación disponible, pero esta se refiere a una versión anterior hecha meses o años antes.    

11.  Devoción esclavista a la documentación

Igual que hemos experimentado proyectos sin documentación, también existen las situaciones en las cuales hay proyectos que fallan donde no se dedicó esfuerzo suficiente al código, pero en cambio sí hay mucha documentación.  Hasta hay quienes juran que se les paga por el volumen de documentación!!   Otra situación que ocurre es cuando se escribe mucha documentación sin resumir  y ello hace su aprovechamiento muy difícil, ya que es como se si estuviera escribiendo la documentación en otro lenguaje de programación.  

12.  Ambiente de circo

Los programadores requieren silencio del tipo que existe en las bibliotecas.  Conversaciones u otros ruidos pueden llevar al programador a desconectarse de su zona mental de trabajo abstracto y entrar en otra realidad.  En algunos lugares se les proveen mesas de ping-pong a los desarrolladores, pero se olvida que también se necesita un ambiente de silencio para la concentración.  

13.  “Afinidad cultural”

Los equipos trabajan mejor cuando las personas tienen un estilo común.  Los equipos que no encuentran el terreno común fallan rápidamente, ya que no se establecen buenas vías de comunicación.  Es difícil generalizar sobre cuál es el mejor ambiente de trabajo, es mejor dejar que eso lo encuentre y defina el equipo de trabajo.  Eso implica que para ciertas circunstancias es mejor que las personas trabajen uno cerca del otro, pero existen otras condiciones como el trabajo de creación de un algoritmo complejo donde es preferible trabajar aislado. 

14.  Aferrado a tecnología legacy

En Dice.com hay una lista de 70.000 cargos, solo 680 son para programadores de Cobol.  Sin embargo, todavía el 1% de los programadores que son defensores de Cobol dirán que es una gran tecnología y para que re-escribirla? ….  Con esta actitud es difícil lograr el uso de tecnología nueva y siempre se tendrán aplicaciones que pocos conocen y que algún día generaran problemas mayores de mantenimiento.  

15.  Lujuria por lo nuevo

Las herramientas más recientes son simpáticas para jugar con ellas, pero deben ser utilizadas en una fábrica de software considerando que hay que reprogramar lo hecho la semana próxima?   Gente que trabaja en la tecnología de punta con frecuencia están desechando secciones de API y reescribiéndolas, obligando a los que trabajan río abajo a re-escribir su código.  Realmente las nuevas herramientas deben ser probadas en el tiempo.

 

CIO - Presentación en la edición de CIO del 25/11/2013