Acabo de leer esta entrada en navegapolis.net. Básicamente presenta dos tipos de jefes: orientados a resultados y orientados a personas, y dos tipos de trabajadores: los que ven al trabajo como una obligación a la que hay que acudir todos los días y los que lo ven como un medio de realización personal. Esto como un muy breve resumen, les recomiendo segur el link.
Me pareció muy interesante cómo se relaciona esa clasificación con el modo en el que la organización conserva o pretende conservar el conocimiento.
Si combinamos la "orientación a resultados" por parte de los jefes con la "obligación de acudir todos los días" por parte de los trabajadores, tenemos una organización en la cual el conocimiento está basado en el proceso. Lo asocié rápidamente con algunas las grandes consultoras de software, en las que los procesos están fuertemente establecidos y el trabajo es realizado por una pirámide de programadores, con base en los juniors y ápice en los seniors o arquitectos de software. En estas organizaciones un sólo programador senior podría coordinar gran cantidad de proyectos, estableciendo estructuras que luego serían rellenadas con código altamente estandarizado (o no, pero en todo caso encapsulado de tal manera que no pueda afectar al sistema en conjunto) por un ejército de programadores de menor experiencia.
Por un lado este esquema soporta una alta rotación (y de hecho la hay) y asegura continuidad más allá de las personas. Por el otro no se incentiva la creatividad, genera mayor dificultad para promover cambios y me imagino que el desarrollo debe ser necesariamente más lento que lo que comento a continuación.
En el otro extremo, si juntamos "orientación a las personas" por parte de los jefes y "realización personal" por parte de los trabajadores, podríamos suponer que el conocimiento está asentado en las personas. La imagen es la de un pequeño equipo de trabajo en el que las soluciones son discutidas entre iguales que defenderán sus puntos de vista de acuerdo a su experiencia, modo de trabajo y opiniones personales.
Este último esquema estará más afectado por la rotación, ya que si cambian las personas de alguna manera cambiará el proceso y el conocimiento. Definitivamente es un espacio propicio para la creatividad, los bruscos cambios de dirección y los desarrollos veloces. También es verdad que es un espacio propicio para la desprolijidad, las fallas de calidad, el descontrol, y que en este esquema pueden producirse tensiones que paralizarían al proyecto si el equipo no logra resolverlas.
Es obvio que, como dice el artículo, estas visiones de blanco/negro nos apartan de la realidad, que es mucho más gris y rica en posibilidades.
Si vamos al caso del desarrollo de software, es indudable que la "orientación a equipos" y el "conocimiento basado en las personas" ha ganado la batalla en el mundo real. El negocio del desarrollo se ha vuelto hostil hacia aquellas organizaciones de movimientos lentos, y las metodologías ágiles han propuesto soluciones efectivas para los problemas señalados (la rotación, las tensiones internas, etc.).
Sin embargo, ningún equipo puede sobrevivir si no tiene una estructura que lo soporte. Y creo que es en esta estructura de contención donde el conocimiento debería tender a basarse en los procesos. ¿A qué estructura me refiero? Pienso, por ejemplo, en las tareas de seguimiento del avance del proyecto, gestión de los cambios, versionado, instalación, seguimiento de incidencias, etc.
Cuanto más dinámico, cambiante e inestable se vuelve el desarrollo, más estables deberán ser estas estructuras.
Por ejemplo, si el negocio nos hace cambiar el rumbo frecuentemente, deberemos gestionar estos cambios con eficiencia. Si no lo hacemos llegará el momento en el que no podremos diferenciar "lo que el sistema hace" (supongamos que lo hace bien) de lo que "el sistema debe hacer" (que tal vez es otra cosa). Es el momento en el que ante una duda funcional (lo que debe hacer) se recurre al código (lo que hace).
Pero esta pretendida estabilidad no implica necesariamente trabajo monótono, repetitivo y estandarizado... no para los humanos por lo menos. Monótono, repetitivo y estandarizado es la definción de lo que un programa puede hacer. Para cada una de estas tareas de soporte existen herramientas.
En "mi mundo ideal" el equipo se dedica solamente a aquello en lo que no puede ser reemplazado por un programa: ver cambios en el negocio, diseñar, desarrollar. El conocimiento en una organización así está basado parte en el proceso (materializado en las herramientas de gestión, de diseño, versionado, instalación, etc.) y parte en las personas, un equipo motivado resolviendo nuevos problemas con creatividad (y todos felices y contentos).
¿Qué es más motivador: testear un sistema o diseñar tests automáticos?
¿Confeccionar y seguir una larga lista de pasos de instalación o desarrollar un instalador completo?
¿Actualizar un sinfín de documentos de diseño cada x meses o pensar un sistema que nos permita sugerir y debatir continuamente hasta llegar a una conclusión, llevando un registro de todo eso que todo podemos consultar en cualquier momento?
1 comentario:
Nuevamente excelente articulo.
Publicar un comentario