archivo

Archivo de la etiqueta: conocimiento

Abrir la mente es fundamental, no basta solo con poner los oídos sino que hay que estar dispuesto a escuchar y a poner en tela de juicio tus opiniones y tu punto de vista sobre los temas que se están tratando. Si de entrada crees que tienes la razón, la solución o la respuesta y que los demás, digan lo que digan, no la tienen, no hay forma de poder enriquecerse con las aportaciones que te hagan.

Si todo el equipo tuviera esa actitud solo quedaría como salida el “ordeno y mando” y eso limita mucho su capacidad porque se desaprovecha el talento individual y el colectivo y no se crea el contexto necesario para tener un equipo de proyecto dinámico y colaborativo en el que todos se sientan importantes, algo fundamental para un desarrollo ágil y generalizando, para cualquier enfoque que se vaya a utilizar.

Eso de considerar que mis ideas o mi código son los mejores son una resistencia al proyecto y no por el hecho de serlo, sino por la actitud que se toma con respecto a ellas ya que si se consideran como la verdad absoluta pueden provocar el descarte o minusvaloración del trabajo, apreciaciones, visiones u opiniones de otros componentes del equipo de trabajo y/o de otras personas que colaboran en el proyecto.

El equipo de proyecto debe aprender del negocio, de esta manera será mucho más efectivo. Saber para que sirve y la finalidad del producto en general y de las funcionalidades en las que trabajan en particular, permitirá abordar las tareas de manera más efectiva, con mayor perspectiva y hacer un testing mejor (es posible que el algoritmo parezca que funciona pero que después el resultado sea una barbaridad, el desarrollador si no entiende del negocio lo terminará dando probablemente por válido, integrándose en el producto y llegando también, en demasiadas ocasiones, a producción).

Esto rompe la línea tradicional de que el analista sea el único experto en el negocio. Tal vez sea quién más sepa pero, por supuesto, nunca debería ser el único, y en cualquier caso, la diferencia entre sus conocimientos y el resto debe tender a disminuir con el paso del tiempo.

No se trata de ninguna pérdida de tiempo, al contrario, los resultados demostrarán que este tipo de políticas es beneficiosa.

¿Se debe documentar ese conocimiento? Lo importante realmente es establecer unos mecanismos que permitan que el conocimiento llegue y que además se pueda constrastar su comprensión. El medio, si se consigue ese objetivo, será el que consideres más conveniente, efectivo y que requiera un menor esfuerzo.

La agilidad no consiste en no documentar. Cada proyecto tendrá sus propias peculiaridades y necesidades, no obstante en la mayoría de los casos lo que sí puede variar es ese enfoque tradicional de la documentación orientado a la utilización de soluciones ofimáticas por otro soportado por herramientas colaborativas y/o CASE.

En cualquier caso y sea cual sea la estrategia que utilices y/o requiera el proyecto (no siempre estarán alineadas) lo que sí es importante entender es que el conocimiento de un proyecto debe ir más allá de la documentación, de hecho debería considerarse en un segundo nivel con respecto a lo que debe suponer el principal objetivo que no es otro que el conocimiento esté distribuido en el equipo, de manera que cada cual sepa qué papel juegan las tareas que realiza tanto en el proyecto como en el producto, consiguiéndose de esta manera una mayor eficacia y una reducción de la dependencia respecto a determinadas personas.

Puede que no parezca el camino más corto pero a la larga el número de kilómetros que se recorren con este tipo de estrategias es mucho menor.

Es razonable que unos sepan más que otros en determinados aspectos pero la visión general debe ser compartida (independientemente de que existan diversas percepciones) y la particular, al menos, conocida, no debiendo quedar ningún elemento estratégico o crítico en manos de una sola persona. Este tipo de situaciones, en las que se crean parcelas de conocimiento (que al fin y al cabo es poder), no solo suponen un riesgo desde el punto de vista de la continuidad de determinadas tareas o de capacidad de adaptación al cambio sino que terminan por fracturar a los equipos.

¿Por qué hacer retrospectivas? A veces es necesario pararse a analizar si las decisiones, estrategias y comportamientos que se han adoptado están produciendo los resultados esperados, así como para analizar qué problemáticas y riesgos tenemos en el proyecto con el objeto de establecer una serie de medidas que permitan la mejora continua.

La vorágine de los proyectos nos llevan a tener un ritmo frenético de manera que, a veces, pararnos a analizar qué está pasando, nos puede hacer pensar que estamos perdiendo el tiempo, cuando justamente es al contrario porque la pérdida de tiempo, de esfuerzo y de dinero se produce precisamente por continuar políticas, estrategias o prácticas que no producen buenos resultados.

Se trata por tanto de adquirir conocimiento a través de la experiencia y con la objetividad (y subjetividad) de los resultados que estamos obteniendo. Una idea que teóricamente es muy buena en la práctica no tiene por qué proporcionar los resultados esperados en el contexto en el que estamos trabajando y a partir de ahí, si tenemos capacidad de autocrítica y de asumir nuestros errores, llegaremos a varias conclusiones interesantes: tener siempre en cuenta el contexto a la hora de tomar una decisión y de adoptar una determinada estrategia, que la idea en cuestión puede seguir siendo válida pero no resulta adecuada en estos momentos en el proyecto (y puede que también en otros proyectos con unas variables parecidas al nuestro) y, que por tanto, es necesario buscar otras soluciones.

Tener un gran conocimiento teórico siempre resulta interesante porque te permite una capacidad de análisis basada en las diferentes percepciones de personas que probablemente han tenido una gran experiencia en la materia.

No obstante, el verdadero conocimiento es la aplicación real del mismo en la práctica. Algo que no resulta nada sencillo porque siempre aparecen multitud de variables no recogidas en los libros y que tendrás que gestionar.

No estamos libres de equivocarnos, es más, los errores nos permiten crecer, pero la probabilidad de error cuando estamos trabajando en las trincheras es mayor cuanto más te separe la teoría de la práctica.

La experiencia (real) es la que termina enriqueciendo los conocimientos teóricos.

Ya lo decía Aristóteles: “La inteligencia no consiste sólo en el conocimiento; sino también en la destreza de aplicar los conocimientos en la práctica”.

Comenta Jeff Patton que: “No necesitamos una documentación precisa, sino un conocimiento compartido”.

Esa reflexión no descarta la documentación si bien no le da el monopolio sobre el conocimiento porque la documentación es eminentemente estática y el conocimiento es dinámico, porque la documentación presenta como límite la habilidad del redactor y la comprensión del lector y el conocimiento se basa más en la comunicación y en la interacción, si algo no lo he entendido lo consulto, si en algo no estoy de acuerdo trato de fundamentar otra posible solución (sin menospreciar la base teórica o informativa de los documentos escritos).

Los documentos se pueden utilizar como interfaz entre diferentes grupos de trabajo (siempre y cuando sus actividades no requieran una interacción continua o frecuente o la misma no sea posible, independientemente de que sea deseable), sin embargo, no se debe cometer el error de restringirlo como único canal de comunicación, precisamente por el hecho de que resulta prácticamente imposible que toda la información se haya plasmado adecuadamente y que el propio lector consiga interpretarlo con la misma intención que la persona que lo redactó (todos sabemos que existen tantas percepciones o visiones sobre un determinado asunto como observadores haya).

Por mucho tiempo que se dedique a la redacción del documento, siempre se va a perder información y se van a alimentar los malos entendidos. Cuando se requiere la colaboración continua entre personas o entre equipos, este modelo no funciona.

No hace mucho un amigo me hizo referencia a un proyecto de hace ya algunos años en el que la comunicación entre usuarios y desarrolladores se basaba principalmente en documentos (también existía diálogo, pero la pieza fundamental, eran encuestas, formularios, etc…), ¿podéis imaginaros cuál fue el resultado del proyecto?.

Por otro lado si la interfaz se basa en documentos, se alimenta la distancia entre los equipos, propiciando la aparición del antipatrón “arrojar al otro lado del muro“, en el que el proyecto queda en segundo plano, ante la actitud defensiva que toman los diversos implicados.

Si creemos que lo sabemos todo no vamos a evolucionar. Afortunadamente este mal tiene solución y tras cada batacazo que nos damos tenemos la oportunidad de recapacitar, si bien, para ello es necesario asumir que hemos sido parte del problema.

El conocimiento parte de cuestionar lo que creemos que sabemos, esto implicará analizar otras alternativas, aunque no te gusten, aunque pienses que no funcionan.

A veces las desecharás por completo, de otras cogerás una parte e incluso puede que alguna te lleve a un nuevo estado de iluminación en el que creas (de nuevo erróneamente) que vuelves a saberlo todo.

Analizar otras alternativas, escuchar a personas que ponen en tela de juicio tu forma de actuar o tu proyecto no es sencillo porque ellos pueden que no estén en primera línea y tu sí, porque tu eres el que se lleva los “golpes” cuando algo no va bien. Sin embargo, viene bien escuchar porque lo mismo tu día a día te impide ver cosas que desde fuera se aprecian más claramente.

Si es importante escuchar a personas de fuera, todavía lo es más con aquellas que trabajan contigo. Valora que te indiquen otras alternativas y valora que no estén de acuerdo contigo porque seguro que de esas situaciones se extrae conocimiento para una parte, para la otra o para ambas.