domingo, 13 de marzo de 2011

Sentido de urgencia

urgencyPuesto que las personas confunden el estar corriendo con un verdadero sentido de urgencia, a veces tratan de crearlo. El frustrado jefe pide a gritos que “ejecuten”. Sus colaboradores se ponen frenéticos: corren, se reúnen, conforman grupos de trabajo, mandan correos electrónicos, todo lo cual crea un viento aullador. Pero eso es todo que es, un viento aullador,o, pero aún, un tornado que destruye mucho y no construye nada.

Sense of urgency de John P. Kotter

Esa descripción se parece mucho a mi experiencia reciente. Kotter lo llama falso sentido de urgencia. 

sábado, 9 de octubre de 2010

Evitar el feedback triangulado

Son incontables las veces que he leído un artículo donde se plantea un ejemplo de lo que no se debe hacer y veo que este refleja exactamente mi conducta en algún momento.

En este caso me sucedió con un artículo que habla sobre el rol que debe jugar un manager cuando una persona de su equipo critica algún aspecto del trabajo o el comportamiento de un compañero.

Esther Derby lista recomendaciones muy interesantes para esos casos en No More Middleman: Avoid triangulated feedback.

En resumen:

- Dar y recibir feedback es parte del trabajo de todos, no sólo de los managers
- Feedback de segunda mano daña las relaciones laborales
- El feedback entre pares puede mejorar las relaciones laborales

lunes, 20 de julio de 2009

¿Por qué siempre nos enfocamos en lo que hacemos mal?

Hace unos días comencé a leer "Ahora, descubra sus fortalezas" de Marcus Buckingham, principalmente porque me gustó mucho su libro "Primero, rompa todas las reglas".

La idea principal del libro es bastante simple y lógica. La mejor manera que tiene un manager de mejorar como profesional, y ayudar a mejorar a sus dirigidos, es identificando sus fortalezas y haciendo lo necesario para sacarle el máximo provecho.

Si bien esto no parece una gran revelación, comienza a observarse el valor cuando se describe lo que generalmente se hace: identificar las areas más debiles de uno y tratar de mejorarlas.

He estado pensando bastante en esa idea este ultimo tiempo, y sin embargo no he podido dejar caer en el error marcado por el autor.

En la empresa donde trabajo, los managers somos evaluados por las personas que dirigimos mediante una encuesta anónima. Esta encuesta pregunta sobre varios aspectos del trabajo y asigna puntajes a cada área según las respuestas.

Lo primero que hice al consultar el resultado de mi evaluación fue buscar los items donde tuve peor puntaje. Luego me puse a pensar cómo podía hacer para mejorar esos aspectos en los cuales me habían calificado peor. Justamente lo opuesto a lo que debería hacer segun Buckingham.

Evidentemente es dificil cambiar algunas costumbres. Pero igual voy a hacer el intento. Ya mismo me voy a fijar en qué areas me calificaron mejor y para que cosas soy realmente bueno.



miércoles, 24 de junio de 2009

Lazos gerente-empleado

Leyendo el libro Primero, rompa todas las reglas de Marcus Buckingham y Curt Coffman, encontré una frase que define claramente lo que podía intuir hace tiempo pero no lograba articular:
Las compañias sanas necesitan que hayan lazos fuertes entre cada gerente y cada empleado. Si el gerente no ha tenido voz en la selección de su gente y no participa en su éxito actual y su desarrollo futuro, esos lazos se marchitan...

La esencia modular del papel de un gerente se basa en esas cuatro actividades: seleccionar a la persona, establecer las expectativas, motivarla y desarrollarla. No es posible centralizar las actividades que solamente se pueden hacer bien a un nivel individual, entre el gerente y el empleado.
La pregunta que queda en el aire luego de analizar este concepto es, ¿qué se debe hacer cuando la estructura de la empresa en la que uno trabaja restringe estos lazos? ¿Cómo construirlos?

No hay nada que hacerle, asi es el conocimiento. Sólo genera más preguntas.

domingo, 7 de septiembre de 2008

¿Quién define los procesos de software?

No es fácil encontrar procesos de desarrollo de software que parezcan ser diseñados por personas que desarrollen software, al menos en mi experiencia personal. Sin embargo, me he cruzado con el caso prácticamente inverso: procesos diseñados por personas que no les atraía en lo más mínimo desarrollar software o aprender algo sobre el tema.

En estos casos, la línea de pensamiento parece ser la siguiente: "Aquellas personas a las que nos les atrae desarrollar software (diseñar una solución, escribir código, testearlo) pueden dedicarse a otra área, como la definición de procesos". De esa manera, se puede evitar la necesidad de conocer y dominar aspectos que hacen posible la construcción de software, porque se puede cubrir el vacío con conceptos abstractos o genéricos como variación, estabilidad de proceso, causas especiales y causas comunes de variación, entradas, herramientas o salidas.

Para hablar sobre estos temas no hace falta conocer de software. De hecho podríamos hablar de manufactura de tornillos y aplicar estos mismos conceptos. Por esta razón, considero que la aplicación directa de estos conocimientos generales carecen de gran valor si no tienen detrás un análisis que busque mejorar una realidad en un ámbito definido. Muchas veces este análisis no es realizado, o las personas que lo hacen no tienen los conocimientos necesarios para hacerlo adecuadamente. Esa situación indefectiblemente conlleva inconvenientes.

Philip Armour analiza este y otros problemas relacionados a los procesos de desarrollo de software en The Laws of Software Process: A New Model for the Production and Management of Software. Tiene varias ideas interesantes para tener en cuenta:

En muchos casos, los procesos [de desarrollo de software] son ideados por ingenieros de proceso, pero frecuentemente ellos no son las personas que están creando el sistema. Estos ingenieros incluso son separados para definir estrictamente el proceso. Los desarrolladores están demasiado ocupados haciendo el trabajo y, a veces, evitando aplicar el proceso. Cuando un proceso es desarrollado por personas que de hecho no lo utilizan, pasan varias cosas:

  • Los ingenieros de proceso pierden de vista la aplicación detallada que hacen un proceso valioso.
  • Sin tener acceso al detalle, ellos están forzados a trabajar mas a un nivel meta, que es fácil para ellos porque no tienen que desarrollar real conocimiento del dominio dentro del proceso.
  • Como ellos usualmente no aplican el proceso que están ideando, pueden perder la habilidad de validar si el proceso es realmente útil.
  • Casi inevitablemente, crece la mentalidad de que si el proceso es bueno, entonces mas proceso debe ser mejor.
  • El proceso toma importancia para estas personas, no por el valor que trae, sino porque es la razón por la cual tienen trabajo.
  • La definición del proceso es dejada a un nivel descriptivo, en forma de libro, no de manera ejecutable... Esto deja el trabajo real de hacerlo funcionar a los desarrolladores usando el proceso. Este es un lugar muy seguro para estar - para los ingenieros de proceso. Si el proceso funciona, el grupo de proceso puede reclamar el crédito; si no funciona, la culpa puede ponerse sobre los desarrolladores por no aplicarlo apropiadamente.

domingo, 31 de agosto de 2008

El arquitecto tambien implementa


Varias veces escuche la intención de algunos desarrolladores de focalizarse o crecer en su carrera profesional hacia una posición de Arquitecto, porque escribir código no era de su interes o no les parecia una tarea muy desafiante.
Ese pensamiento me resulta extraño, porque no creo que un arquitecto puede cumplir bien su rol si no escribe código.

Jim Coplien y Neil Harrison escriben en su libro Organizational Patterns of Agile Software Development el patrón que llaman "El arquitecto tambien implementa":

Demasiados arquitectos de software limitan su pensamiento y dirección a abstrascciones, y una abstracción es una forma disciplinada de ignorancia. Demasiados proyectos fallan por “detalles” de performance, sutilezas de APIs,e interconexión de componentes – o, a lo sumo, descubren este tipo de problemas tarde.
...Mas alla de aconsejar y comunicarse con los desarrolladores, los arquitectos deben participar tambien en la implementación.
El Arquitecto debe estar unido organizacionalmente con los desarrolladores y debe escribir codigo él mismo.

Concuerdo cien por ciento. La mejor forma de orientarse hacia una posición de liderazgo técnico es dominar los aspectos de implementación y no sólo focalizarse en grandes abstracciones.

domingo, 15 de junio de 2008

Algunos links interesantes


En las ultimas semanas he leído algunos artículos y presentaciones que capturaron mi atención, los cuales coinciden en un aspecto: se animan a criticar prácticas o modelos muy aceptados.

Estos son los links:

"No he trabajado en ningún proyecto donde fuese posible calcular el valor ganado (earned value). En mi experiencia, el valor ganado es demasiado frecuentemente una medida difusa para proyectos de software."
  • Questioning Earned Value Management (EVM) on IT projects de Scott Ambler. Desaconseja el uso de EVM en proyectos de IT.

    "En teoría, EVM suena como una gran cosa. Estas ganando valor de todos modos, y ¿quién puede discutir eso? Sin embargo, en la práctica en el mejor de los casos es un eufemismo para controlar los costos presupuestados gastados y en el peor de los casos es simplemente una justificación para buracracia."

  • Could the Software Engineering Institute be Wrong About Statistical Process Control? de Bob Raczynski. Presentación realizada en Systems & Software Technology Conference (SSTC) 2007.

    En este caso el título es muy descriptivo. El autor se pregunta si el control estadístico de procesos (CEP) es apropiado para organizaciones de desarrollo de software. Su respuesta es no.
    El CEP tiene gran importancia en el modelo CMMI y es algo que personalmente me intriga. Hace mas de dos años gestiono proyectos en una organización CMM (y luego CMMI) nivel 5, y debo ser sincero. No veo el valor de aplicar CEP en nuestros proyectos. Puede ser que aún no lo comprenda, pero si mañana debo dejar de aplicarlo, no lo voy a extrañar.

    "Bueno, si usted aplica CEP a procesos de desarrollo de software, puede que ocasionalmente tenga suerte e identifique una variación con causa asignable a pesar de los amplios limites de sus gráficos de control, areas desiguales de oportunidades, y procesos constantemente cambiantes.
    De las variaciones de causas asignables que logre detectar, ocasionalmente puede tener suerte y realmente peda identificar una de las causas de esa variación.
    De las muy pocas causas de variación que usted pueda identificar, una de ellas podría ocasionalmente ser de una naturaleza que puede realmente ser removida con cierta persistencia.
    Aún así, su sistema en general difícilmente será más predecible.
    ¿Es ese el mejor uso de sus recursos limitados?"

  • Software Data Violate SPC’s Underlying Assumptions de Bob Raczynski and Bill Curtis. (requiere subscripción de IEEE). Aquí los autores cuestionan el uso de gráficos de control para realizar control estadístico sobre procesos de software.

    "Nosotros pensamos que los supuestos detrás de los gráficos de control son tan fuertemente violados en los datos de software que su valor para entender y gestionar la variación es severamente disminuida...
    Desafortunadamente, el foco desproporcionado para controlar estadisticamente procesos y calidad de software ha desviado la atención de otros métodos estadísticos que podrían proveer mucho mejor entendimiento y predecibilidad de las causas de variación afectando al proceso de software."

  • Can a Manufacturing Quality Model Work for Software? de Shari Lawrence Pfleeger (requiere subscripción de IEEE).
    "¿Debe ser el modelo de manufactura Six Sigma aplicado al software? En una palabra, no. Aunque el software de alta calidad es algo bueno, hay al menos tres razones por las cuales el modelo Six Sigma no tiene sentido para el software."

Como cierre, incluyo unas palabras de Alistair Cockburn en el grupo de Yahoo scrumdevelopment:

"En mis 30 años en el negocio, industria, investigación y algo de gobierno, nunca vi una matriz de trazabilidad redituable."


Cuando algo es generalmente aceptado, el camino más fácil es tomar por sentado sus beneficios y defender sus aspectos positivos.

En lo personal no me agrada ese camino.

Valoro cuestionar y escrudiñar cada práctica, analizar y entender cada concepto, pensar y aprender, no simplemente repetir.